ビジネスチャットサービス 大規模DBでのDynamoDB採用事例

背景

当社が提供するビジネスチャットサービス「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を採用できた決め手の一つと言えます。

• Amazon EMR (HBase on S3)
• TiDB

重要視しなかった点

今回は既存データベースのEOL対応が目的であったため、限られた期間内での対応を最優先とし、追加要件や将来的な機能拡張性は意図的に検討範囲から除外しました。

• クエリの柔軟性
  今回対象のデータベースはその役割が明確であり、求められるユースケースはキーを使った１件取得、範囲指定による複数件取得だけでした。 また、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 を使って検証用のデータを作成する、というような手段も考えられますが大掛かりにはなります。

一般的なKVS（Key Value Store）の中でも非常にポピュラーであり、AWSを利用している環境であれば、最初に検討すべきデータベース製品の一つと言えるでしょう。

さまざまな特徴・利点がある一方で、RDBMS（リレーショナルデータベース）のような汎用性はなく、特にクエリの柔軟性には制約があるためアプリケーションの要件を十分に考慮し、DynamoDBが適しているかを見極めることが重要です。

CQRS（Command Query Responsibility Segregation）アーキテクチャとは非常に相性が良いです。