紹介
- 2017年、DiscordはMongoDBからCassandraへデータベースを移行し、メッセージを保存する方法を共有した
- Cassandraは拡張性、耐障害性、保守のしやすさを提供したが、時間の経過とともに性能問題と運用負担が増加した
- 2022年、DiscordはデータベースをScyllaDBへ再移行した
Cassandraでの問題点
- メッセージ保存構造: メッセージは
channel_idとbucketでパーティショニングされて保存される
- ホットパーティション問題: 特定のチャンネルにトラフィックが集中すると、データベース全体のレイテンシが増加する
- 保守上の問題: SSTableの圧縮作業とJVMのガベージコレクション問題により性能低下が発生した
アーキテクチャ変更
- ScyllaDB導入: C++で書かれたCassandra互換データベースで、ガベージコレクション問題を解決した
- データサービス: APIとデータベースの間に中間サービスを置き、トラフィックを調整して性能を向上させた
- Rustの利用: 安全で高速な並行コードを書くためにRustを使用した
データサービス
- リクエストのマージ: 複数のユーザーが同じデータを要求したとき、データベースには一度だけクエリし、結果を共有する
- 一貫性ハッシュベースのルーティング: 同じチャンネルのリクエストを同じサービスインスタンスへルーティングし、データベース負荷を減らす
大規模マイグレーション
- ScyllaDBクラスター構築: ローカルSSDとRAIDを使って高速かつ耐久性のあるストレージを構成
- データマイグレーション: Rustで書かれたデータマイグレーターを使って迅速にデータを移行した
- 自動データ検証: 2つのデータベースに少量の読み取りリクエストを送り、結果を比較してデータ整合性を確認した
数か月後
- 性能向上: Cassandraより少ないノードでより良い性能を提供した
- レイテンシ低下: メッセージ取得および挿入性能が大幅に向上した
- 新しい製品ユースケース: 性能改善のおかげで新機能を実装できるようになった
# GN⁺のまとめ
- DiscordはCassandraの性能問題を解決するため、データベースをScyllaDBへ移行した
- Rustで書かれたデータサービスとScyllaDBによってトラフィックを効果的に管理し、性能を向上させた
- データマイグレーションの過程では高速かつ効率的な方法を用い、ダウンタイムなしで移行を完了した
- この記事は大規模データベースマイグレーションの課題と解決過程を扱っており、大規模システム運用に関心のある人にとって有益である
1件のコメント
Hacker Newsのコメント
ブログ記事はGCを非難しているが、実際にはCassandraの使い方、あるいはCassandraが大量削除を処理する方法に問題がある
分散チャットプロトコルを使っていれば、こうした問題はなかったはず
ScyllaDB共同創業者による追加コメント
tombstone_gc=repairモードがあるサービスレイヤーはVarnish Cacheを思い起こさせる
古いメッセージを削除するのはほぼ不可能
とてもよく書かれた記事
Discordのメッセージ保存ノード数は予想より少ない
データを保存することとデータマイニングを行うことは別問題
ScyllaDBチームは性能向上を優先し、逆方向クエリを実装した
「How Discord Stores Trillions of Messages」についての議論