ビジネスチャットサービス 大規模DBでのDynamoDB採用事例
株式会社kubell / tsuji
EM / EM / 従業員規模: 501名〜1,000名 / エンジニア組織: 51名〜100名
利用プラン | 利用機能 | ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
---|---|---|---|---|
オンデマンドキャパシティ | DynamoDBテーブル | 11名〜50名 | 2024年11月 | B to B B to C |
利用プラン | オンデマンドキャパシティ |
---|---|
利用機能 | DynamoDBテーブル |
ツールの利用規模 | 11名〜50名 |
ツールの利用開始時期 | 2024年11月 |
事業形態 | B to B B to C |
アーキテクチャ
導入の背景・解決したかった問題
導入背景
背景
当社が提供するビジネスチャットサービス「Chatwork」において、メッセージの送受信はコア機能です。そのため、いかなる状況でもメッセージの投稿と閲覧が滞りなく行えることが不可欠です。
「Chatwork」は2011年にローンチしてから13年が経過しており、利用者増に応じてシステム構成も変化していくなかで、投稿されたメッセージを蓄積するデータベースとしてセルフホスティングした Apache HBase を利用していました。
課題
今回解決しなければならなかった課題は、この Apache HBase のサポート切れ(いわゆるEOL対応)です。 チャットメッセージという極めて重要な情報を蓄積するデータベースなので、サポート切れで運用するわけにはいきません。
加えて、セルフホスティングしているが故に運用負担が大きいなどの潜在的課題もありました。
対応方針
複数案のメリット/デメリットを評価し、従来の Apache HBase から Amazon DynamoDB にリプレイスする方針としました。
前提
「Chatwork」は内部的に複数のコンポーネントに責務分割されていますが、今回 Apache HBase を利用していたコンポーネントはCQRS(Command Query Responsibility Segregation)アーキテクチャが採用されており、そのクエリ専用データベース(Read DB)で HBase が使われていました。
CQRSアーキテクチャになっていたことで新データベースに求められる要件がシンプルであったことが、DynamoDBを採用できた決め手の一つと言えます。
比較検討したサービス
比較した軸
重要視しなかった点
今回は既存データベースのEOL対応が目的であったため、限られた期間内での対応を最優先とし、追加要件や将来的な機能拡張性は意図的に検討範囲から除外しました。
クエリの柔軟性
今回対象のデータベースはその役割が明確であり、求められるユースケースはキーを使った1件取得、範囲指定による複数件取得だけでした。 また、CQRSアーキテクチャを採用しているので今後新たなクエリ要件が発生した場合は別のデータベース(Read DB)を追加すれば対応できるので、クエリの柔軟性は求めませんでした。多機能性
データ分析のような付加価値は、選定基準から外しました。
重要視した点
一方で、ビジネスチャットに投稿されたメッセージの閲覧というユースケースの特性上、非機能要件は現行データベースと同等ないしそれ以上を求めました。
レイテンシ
現行データベース(セルフホスティングした Apache HBase)は高度にチューニングされており、レイテンシはどのような問い合わせにも1桁msで応答を返す性能を持っていました。 新データベースでも高い性能は求められますが、ユーザーが体感できないレベルの極端な高性能は求めず、必要十分なパフォーマンスを満たせれば良いと判断しました。アベイラビリティ
ビジネスチャットサービスの根幹にあたるデータベースのため、高い可用性が求められます。スケーラビリティ
ユーザーの増加や利活用シーンの拡大に応じて処理能力をスケールさせていく必要があります。保存できるデータ量
ビジネスチャットの特性上、メッセージは継続的に大量蓄積されるため、保存可能なデータ量に実質的な制限がないことが採用の条件でした。サーバーコスト
SaaSビジネスで利益を出していくためには、サーバーコストを如何に抑えるかも重要になります。
ただし、今回はサポート切れ対応ということでサービスの提供維持が最重要であったため、サーバーコスト削減は主な目的とせず、現行データベースのコストを上回らないことを許容範囲としました。運用コスト
今後も長期間運用していくことを考え、運用コストはできるだけ抑えたいところでした。 特にセルフホスティングしてしまうとまたサポート切れなどが必要になって人件費もかかってしまうため、フルマネージドサービスが理想的です。導入容易性・開発期間
今回は期限までに完了させることが重要であったため、導入の容易さと開発期間も大きな判断基準であり、社内でも利用事例があれば採用しやすい背景がありました。
選定理由
今回決め手となったのは、
- 現行データベースのサポート切れという、限られた時間でリプレイスが可能であること。
- ユーザー体験を悪化させない必要十分なレイテンシ、アベイラビリティが得られること。
の2点です。
サービスの安定的な継続提供を最優先事項とし、さらに社内での豊富な採用実績も考慮して、Amazon DynamoDBの採用を決定しました。
他の候補であったものは、以下のような理由で選外としました。
Amazon EMR (HBase on S3)
同じ HBase から HBase へのリプレイスで変更は少なく済むものの、性能検証の結果レイテンシの悪化度合いが許容範囲を超えていたこと、将来的にサポート切れ対応が必要になることがネックになりました。TiDB
非常に多機能で魅力的なデータベース製品ですが、目的に対してオーバースペックであること、社内に採用事例がなく限られた時間内に対応できないリスクが大きいことがネックになりました。
導入の成果
Amazon DynamoDB にリプレイスしたことで、以下のような成果が得られました。
サービス提供の維持
「Chatwork」をこれまでとユーザー体験を損なうことなく、安定して提供し続けることができています。サポート切れ対応からの開放
フルマネージドなデータベースにリプレイスしたことで、将来的なサポート切れ対応から開放されました。サーバーコストの大幅削減
これは重視していなかった要素ではありますが、結果的にサーバーコストが 1/10 程度になりました。 偶然にも 2024/11からオンデマンドキャパシティの価格が引き下げられた ことも有利に働きました。DynamoDB Streams 活用の可能性
DynamoDB には Streams というデータが書き込まれたことをトリガーとして後続処理を行う機構がありますが、将来的に活用できる可能性があります。
導入時の苦労・悩み
DynamoDB 自体は社内の利用事例もあり、アプリケーションからの利用面で苦労した点はなかったのですが、現行データベースから全データ(100億件以上)を漏れ抜けなく移行する必要があり、その点で工夫が必要でした。
データ移行の方式として DynamoDB S3 Import が提供されていますが、今回のような大量データの移行においては、そもそも DynamoDB S3 Import が扱える入力データを用意するのが大変、いつ完了するのか途中経過や進捗がわからない、何かの問題が合った場合に途中から再開するといったことができない、期待したほど速くない、などの課題があり、総合的に見てこれを利用せずに独自のデータ移行プログラムを開発することにしました。
移行したデータに漏れ抜け誤りがないかの検証に工夫が必要でした。 というのも、DynamoDB は柔軟なクエリが書けないのでデータの検証にもそれが制約になりました。 今回はデータ移行プログラムを自前開発したので、そのプログラム中で検証に必要なログを出すようにしたり、AWSコンソール上で確認できる総アイテム数で漏れ抜けを確認しました。 他には DynamoDB Streams を使って検証用のデータを作成する、というような手段も考えられますが大掛かりにはなります。
導入に向けた社内への説明
上長・チームへの説明
まず、DynamoDB自体は社内でも利用事例の多いデータベース製品であったため、それ自体へのリスクや懸念はありませんでした。
「決め手になったポイント」にも挙げたように、今回のサポート切れ対応と言う目的に対して DynamoDB が必要十分なスペックを備えており、リスクも小さく、最も短期間で目的を達成できる選択肢であることを ADR(Architecture Decision Record)としてまとめ、合意を得ました。
活用方法
よく使う機能
今回の事例では単純に DynamoDB のテーブルだけを利用していますが、一般的に良く利用される DynamoDB の機能としては以下のようなものもあります。
インデックス
基本的にキーによるクエリのみ可能ですが、インデックスを追加することでキー以外の属性でのクエリも実現できます。(ただし、柔軟性には制約があります)DynamoDB Streams
データが書き込まれたことをトリガーに後続処理を実行する仕組みです。Amazon DynamoDB Accelerator (DAX)
DynamoDB の前段に置くキャッシュ機構です。DynamoDBは読み書き量に応じた従量課金がコストの主要因となるため、DAXのようなキャッシュ機構を導入することで、より高いパフォーマンス要件への対応やコスト削減が期待できます。
ツールの良い点
- 採用事例も多く、インターネット上で得られるノウハウ、経験のあるエンジニアも多い。
- レイテンシ、アベイラビリティが高いレベルで保証されている。
- サーバーコストは比較的安価であり、オンデマンドキャパシティやオートスケーリングといったコスト削減手段も豊富に提供されています。
- マネージドサービスなので原則メンテナンスフリー。
- DynamoDB Streams など、後続処理に繋げる仕組みが利用できる。
ツールの課題点
- KVS(Key Value Store)なので、柔軟なクエリ要件には対応しにくい。
- パーティションやキー設計など、特有な考慮が必要になる。
- APIやSDKには一部直感的でない部分があり、習熟に時間を要する場合がある。
- 瞬間的なトラフィック増(スパイク)があると読み書きリクエストが拒否される(スロットリングと呼ばれる)ため、アプリケーション側ではそれが起こることを前提としてリトライなどをする必要がある。
- トランザクションや強整合性読み取りなどの機能もあるが、トレードオフがあるためRDBMSと同じ感覚で利用すると問題になりやすい。
ツールを検討されている方へ
一般的なKVS(Key Value Store)の中でも非常にポピュラーであり、AWSを利用している環境であれば、最初に検討すべきデータベース製品の一つと言えるでしょう。
さまざまな特徴・利点がある一方で、RDBMS(リレーショナルデータベース)のような汎用性はなく、特にクエリの柔軟性には制約があるためアプリケーションの要件を十分に考慮し、DynamoDBが適しているかを見極めることが重要です。
CQRS(Command Query Responsibility Segregation)アーキテクチャとは非常に相性が良いです。
株式会社kubell / tsuji
EM / EM / 従業員規模: 501名〜1,000名 / エンジニア組織: 51名〜100名
株式会社kubell エンジニアリングマネージャー。 フリーランスとして基幹システムのアーキテクチャ設計・フレームワーク開発・標準化などを担当。 Java/Scalaを使ったドメイン駆動設計やレイヤー化アーキテクチャ、マイクロサービスアーキテクチャの導入。 2020年からChatwork株式会社(現株式会社kubell)に在籍。 Scalaエンジニア、プロダクトオーナーを経て現在は「Chatwork」のバックエンドシステムの開発・運用を担当する部署のマネジメントを担当。
よく見られているレビュー
株式会社kubell / tsuji
EM / EM / 従業員規模: 501名〜1,000名 / エンジニア組織: 51名〜100名
株式会社kubell エンジニアリングマ...
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法