Discordは、何兆ものメッセージレコードを Apache Cassandraから ScyllaDBに移行。最大のクラスタのサイズをのCassandraノードの177からScyllaDBノードの72まで縮小し、読み取りと書き込みのテールレイテンシを削減した。この移行により、データベースの安定性とパフォーマンスが向上したため、新しい製品のユースケースが生まれた。
Discordが成長するにつれ、増え続けるデータ量に対応できるスケーラブルなデータベースを探していたため、2017年にデータをMongoDBからCassandraに移行した。当初、Cassandraクラスタは12ノードで構成され、数十億のメッセージを保存していた。それでも5年後、クラスターは177ノードとなり、パフォーマンス問題が頻繁に発生するようになったため、チームは運用コストが高すぎる保守運用の一部を縮小せざるを得なくなった。
一部のパフォーマンス問題は、パーティショニングがDiscordのチャンネルとタイムバケットに基づいていたテーブルスキーマ設計に起因するホットパーティションが原因だった。DiscordのシニアソフトウェアエンジニアであるBo Ingram氏は、ホットパーティションがデータベースクラスタに与えた影響について説明している。
ホット・パーティションが発生すると、データベース・クラスタ全体のレイテンシに頻繁に影響が出ました。あるチャネルとバケットのペアが大量のトラフィックを受け、ノードがトラフィックに対応しようと懸命になり、どんどん遅れをとることで、ノードのレイテンシが増大します。[…]クォーラム一貫性レベルで読み取りと書き込みを行っているため、ホットパーティションにサービスを提供するノードへのすべてのクエリが待ち時間の増加に見舞われ、その結果、エンドユーザーへの影響が拡大しました。
社内で行われた実験とテストに基づき、チームはすべてのクラスタデータをScyllaDBへ移行することを決定した。ScyllaDBを選択したのは、主にCassandraで経験したガベージコレクション関連の問題を回避するなど、パフォーマンスを向上させるためだった。また、ScyllaDBチームと協力して、リバースクエリなど、彼らが必要としていたいくつかのユースケースを改善した。
2020年までにすべての小規模クラスタを移行した後、チームは何兆ものメッセージを含む最大のクラスタの移行を準備した。ホットパーティション問題を最小化するために、彼らはデータサービスという新しい中間サービスレイヤーをアーキテクチャに作成した。このアーキテクチャはRustで書かれ、gRPC APIを介してインターフェースされている。
データ・サービスの重要な責務のひとつは、リクエストの合体であり、多くのユーザーが同じメッセージをリクエストした場合に、複数のデータベース呼び出しを回避することだ。次に、チャンネルIDのようなルーティング・キーに基づくデータ・サービス・インスタンスへの一貫したハッシュ・ベースのルーティングを実装した。これらの変更により、ホット・パーティションの問題が大幅に減少し、Discordは大規模なマイグレーションに備えるための余分な時間を得ることができた。
/filters:no_upscale()/news/2023/06/discord-cassandra-scylladb/en/resources/1discord-1687293898138.jpeg)
出典: https://discord.com/blog/how-discord-stores-trillions-of-messages
移行自体は、ScyllaDBのApache Sparkマイグレータの使用を検討したが、最終的にはチェックポイントにSQLiteを使用するRust製の特注ソリューションを導入した。いくつかの小さな不具合に対処した後、移行完了を検証し、2022年5月にScyllaDBに切り替えた。それ以来、新しいクラスタは安定し、一貫したパフォーマンスを提供していることが証明され、データ・サービス・レイヤとともに、ワールドカップで発生した余分なトラフィックのスムーズな処理を可能にした。