DynamoDB: アーリーからレイトステージまで支える揺るぎない信頼性
参考になった
4
株式会社カケハシ / 高木
メンバー / SRE
| ツールの利用開始時期 | 事業形態 |
|---|---|
| 2017年 | B to B |
| ツールの利用開始時期 | 2017年 |
|---|---|
| 事業形態 | B to B |
アーキテクチャ
導入の背景・解決したかった問題
導入背景
創業当初の不確実な状況のためスキーマの柔軟性を確保しつつ、成長後の大量データへの対応を目指していた。
比較検討したサービス
- Amazon Aurora
導入の成果
サービス開始から8年ほど経ち、成長に次ぐ成長で弊社も業界で大きなシェアを占めるようになりました。 創業プロダクトであるMusubiについて、DynamoDBに対するシステムスケーリング対応のプロジェクト等は不要のまま来ており、それでもスケーリング関係の障害が起きたことはありません。 getItemのレイテンシはピーク時間帯含め時間帯によらず常に安定しており信頼できます。
導入に向けた社内への説明
上長・チームへの説明
創業プロダクトであり、創業CTOが選定したものであるため、特に説明は行なっていない。
活用方法
よく使う機能
DynamoDB Streams/Kinesis Data StreamsとDynamoDB Exportにより後続へのストリーム連携や大量データ連携も可能です。
ツールの良い点
信頼して設計や運用ができ、手離れが良い。
メトリクスを見たがったり運用を意識できたりする開発者はテックリード相当でさえ少数派であり、あまりメトリクスを見なくとも良いのはメリット。
Scale to Zeroなので各開発者/ブランチ専用の環境を準備可能。ブランチ同士の依存関係を薄くして開発のボトルネックを削れるほか、特に非本番環境のDBコストを圧縮できる。この面では非クリティカルなサービスにも向いている。
制限は多いが制限は懇切丁寧に全てドキュメントに書いてある。ただひたすら読むだけ。
ツールの課題点
DynamoDBは正直開発と改修が難しい。アクセスパターンを事前に割り出しておく必要があるほか、シングルテーブルデザインだと今までのDB設計とは発想転換が必要で受け入れしにくい。
リクエストレスポンスの制限も多い。JOINの柔軟性がなく、分析クエリが難しい。CQRSは必須。 (OLTPにRDBを選定しても結局必須だが)
データマイグレーションすると出費が発生するのでデータを適正化するモチベーションがこの方面では薄くなる。
カラム追加も無停止で気軽にできるが、気軽に行うとデフォルト値やバージョン不整合の代償を支払うこととなる。
明朗会計だが従量課金であり誰も確認しないと新しいことをするたびに出費がどんどん嵩む。
ツールを検討されている方へ
DynamoDBかRDBかという選択になると思いますが、重要プロダクトならどのタイミングでどの部分に信頼性とスケーラビリティを任せるかで決まります。 DynamoDBに完全に委ね、アプリケーション側でDynamoDBの制限という名の契約を守るか、 RDBのようにDB側とアプリケーション側双方について自分たちで常に状況を把握して努力するかです。 複雑さを飲み込めば両方使うという選択肢もあります。
今後の展望
DynamoDB以外のほうが優先順位が高いため、そちらを改善予定です。逆にいうと緊急度重要度を低く保てます。
株式会社カケハシ / 高木
メンバー / SRE
株式会社カケハシ / 高木
メンバー / SRE
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法