不一致は、カスタムコンテンツと同様、予想よりも速く成長し続けています。 ユーザーが多いほど、チャットメッセージが多くなります。 7月に1日4,000万通のメッセージを発表し 、12月に1億通を発表し 、1月中旬に1億2000万通を超えました。デバイス。 これは大量のデータであり、そのフローと量は増え続けており、それらすべてにアクセスできる必要があります。 これをどうやってやるの？ カサンドラ！

私たちは何をしましたか

Discordのオリジナルバージョンは、2015年初頭の2か月よりも早く書かれました。 おそらく、高速反復に最適なDBMSの1つはMongoDBです。 Discordのすべては、MongoDBの単一のレプリカセットに特別に格納されていましたが、新しいDBMSへの単純な移行のためにすべてを準備しました（その複雑さと未知の安定性のため、MongoDBシャーディングを使用しないことを知っていました）。 実際、それは私たちの企業文化の一部です。迅速に開発して新しい製品機能を体験しますが、常により信頼性の高いソリューションに焦点を当てています。



メッセージは、 channel_id



およびcreated_at



単一の複合インデックスとともにMongoDBコレクションに保存されました。 2015年11月ごろ、データベース内のメッセージが1億行に達しました。それから、データとインデックスがRAMに収まらず、遅延が予測不可能になるという問題を理解し始めました。 より適切なDBMSに移行する時が来ました。

適切なDBMSの選択

新しいDBMSを選択する前に、既存の読み取り/書き込みパターンと、現在のソリューションに問題があった理由を理解する必要がありました。

• 読み取り操作が非常にランダムであり、読み取り/書き込み比率が約50/50であることがすぐに明らかになりました。
• Heavy Discordボイスチャットサーバーはほとんどメッセージを送信しませんでした。 つまり、数日ごとに1つまたは2つのメッセージを送信しました。 1年で、このタイプのサーバーは1000メッセージのマイルストーンに到達する可能性は低いです。 問題は、そのような少数のメッセージにもかかわらず、このデータをユーザーに配信するのがより難しいことです。 ユーザーに50個のメッセージを返すだけで、多くのランダムなディスク検索が行われ、ディスクキャッシュが強制的に削除されます。
• Heavy Discordのプライベートテキストチャットサーバーは、適切な量のメッセージを送信します。これは、年間100,000〜100万メッセージの範囲内です。 通常、最新のデータのみを要求します。 問題は、これらのサーバーの参加者が通常100人未満であるため、データ要求の速度が遅く、ディスクキャッシュに存在する可能性が低いことです。
• 大規模なパブリックDiscordサーバーは、大量のメッセージを送信します。 1日に数千のメッセージを送信する数千の参加者がいます。 年間数百万のメッセージが簡単に入力されます。 彼らはほとんど常に最後の1時間に送信されたメッセージを要求し、これは頻繁に起こります。 したがって、データは通常ディスクキャッシュにあります。
• 来年、ユーザーはランダムな読み取り値を生成する方法がさらに増えることを知っていました。これは、過去30日間の言及を表示し、履歴のその時点でスキップし、添付メッセージを表示して移動し、全文で検索する機能です。 これはすべて、さらにランダムな読み取りを意味します！

次に、要件を決定しました。

• 線形のスケーラビリティ -後でソリューションを修正したり、データを別のシャードに手動で転送したりする必要はありません。
• 自動回復力 -私たちは夜寝て、Discordを可能な限り自己回復させるのが好きです。
• 少しサポート -インストールするとすぐに動作するはずです。 データが大きくなったときにノードを追加するだけです。
• 実績あり -私たちは新しいテクノロジーを試すのが大好きですが、それほど新しいものではありません。
• 予測可能なパフォーマンス -95％の場合のAPIの応答時間が80ミリ秒を超えると、メッセージが送信されます。 また、RedisまたはMemcachedでメッセージをキャッシュする必要に直面したくありません。
• BLOBストレージではありません-BLOBを連続的にデシリアライズしてデータを添付する必要がある場合、1秒あたり数千のメッセージの記録はうまく機能しません。
• オープンソース -私たちは自分自身の運命を制御し、サードパーティの会社に依存したくないと考えています。

Cassandraは、すべての要件を満たした唯一のDBMSでした。 スケーリング時にノードを追加するだけで、アプリケーションに影響を与えることなくノードの損失に対処できます。 NetflixやAppleなどの大企業には、数千のCassandraノードがあります。 関連データはディスクの近くに保存され、最小限の検索操作とクラスター全体への簡単な分散を提供します。 DataStaxでサポートされていますが、オープンソースで配布されており、コミュニティを活用しています。



選択をした後、彼が本当に正当化されたことを証明する必要がありました。

データモデリング

Cassandraの新参者を記述する最良の方法は、略語KKVです。 2つの文字「K」には主キーが含まれます。 最初の「K」はパーティションキーです。 データが存在するノードとディスク上のどこにあるかを判断するのに役立ちます。 セクション内には多くの行があり、2番目の「K」はセクション内の特定の行-クラスタリングキーを定義します。 セクション内で主キーとして機能し、行のソート方法を決定します。 セクションは、順序付けられた辞書として想像できます。 これらすべての特性を組み合わせることで、非常に強力なデータモデリングが可能になります。



MongoDBのメッセージはchannel_id



とcreated_at



を使用してインデックス付けされたことを覚えていますか？ チャネルですべてのメッセージが機能するため、 channel_id



がセクションキーになりましたが、2つのメッセージを同時に作成できるため、 created_at



は適切なクラスタリングキーを提供しません。 幸いなことに、すべてのDiscord IDは実際にはSnowflakeで作成されます。つまり、時間順に並べられます。 したがって、それらを使用することができました。 主キーが(channel_id, message_id)



に変わりましたmessage_id



はSnowflakeです。 これは、チャネルをロードするときに、メッセージを検索する正確な範囲をCassandraに伝えることができることを意味します。



メッセージテーブルの簡略図を次に示します（約10列をスキップします）。

 CREATE TABLE messages ( channel_id bigint, message_id bigint, author_id bigint, content text, PRIMARY KEY (channel_id, message_id) ) WITH CLUSTERING ORDER BY (message_id DESC);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Cassandraのスキーマはリレーショナルデータベーススキーマに似ていますが、簡単に変更でき、一時的なパフォーマンスへの影響はありません。 ブロブストレージとリレーショナルストレージを最大限に活用しました。



Cassandraへの既存のメッセージのインポートが開始されるとすぐに、100 MBを超えるパーティションが見つかったことを警告ログですぐに確認しました。 まあ？ 結局のところ、Cassandraは2 GBパーティションのサポートを宣言しています！ どうやら、可能性はそれが行われるべきという意味ではありません。 大きなセクションは、クラスターの圧縮、拡張などの際に、Cassandraのガベージコレクターに大きな負荷をかけます。 大きなパーティションが存在するということは、その中のデータをクラスター全体に分散できないことも意味します。 一部のDiscordチャネルは何年も存在し、常にサイズが増加する可能性があるため、パーティションのサイズを何らかの方法で制限する必要があることが明らかになりました。



私たちは、時間をかけてバケットにメッセージを配信することにしました。 Discordの最大のチャネルを調べ、約10日間のブロックでメッセージを保存すると、100 MBの制限に快適に投資できると判断しました。 ブロックは、 message_id



またはタイムスタンプから受信する必要があります。

 DISCORD_EPOCH = 1420070400000 BUCKET_SIZE = 1000 * 60 * 60 * 24 * 10 def make_bucket(snowflake): if snowflake is None: timestamp = int(time.time() * 1000) - DISCORD_EPOCH else: # When a Snowflake is created it contains the number of # seconds since the DISCORD_EPOCH. timestamp = snowflake_id >> 22 return int(timestamp / BUCKET_SIZE) def make_buckets(start_id, end_id=None): return range(make_bucket(start_id), make_bucket(end_id) + 1)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Cassandraパーティションキーはコンポジットである場合があるため、（新しい((channel_id, bucket), message_id)



プライマリ、キー((channel_id, bucket), message_id)



新しいプライマリキーです。

 CREATE TABLE messages ( channel_id bigint, bucket int, message_id bigint, author_id bigint, content text, PRIMARY KEY ((channel_id, bucket), message_id) ) WITH CLUSTERING ORDER BY (message_id DESC);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

チャネル内の最近のメッセージを要求するために、現在の時間からchannel_id



までの範囲のブロックを生成しました（これは時系列でSnowflakeとしてソートされ、最初のメッセージより古い必要があります）。 次に、十分なメッセージを収集するまでセクションを順番にポーリングします。 この方法の裏側は、アクティブなDiscordインスタンスが、時間の経過とともに十分なメッセージを収集するために、多くの異なるブロックをポーリングする必要がある場合があることです。 実際には、Discordのアクティブなインスタンスの最初のセクションには通常十分なメッセージがあり、そのほとんどがそうであるため、すべてが正常であることが判明しました。



Cassandraへのメッセージのインポートはスムーズに進み、本番環境でテストする準備が整いました。

重い打ち上げ

新しいシステムを実稼働環境に投入することは常に怖いので、ユーザーに影響を与えずにテストすることをお勧めします。 MongoDBとCassandraで読み取り/書き込み操作を複製するようにシステムを構成しました。



起動直後に、 author_id



がゼロであるというエラーauthor_id



バグトラッカーでauthor_id



ました。 どうしてゼロにできますか？ これは必須フィールドです！

最終的にコンセンサス

CassandraはAPタイプのシステムです。つまり、ここではアクセシビリティのために保証された整合性が犠牲になります。 Cassandraでは、特定の列のみが提供される場合でも、書き込み前の読み取りは禁忌です（読み取り操作はより高価です）。したがって、Cassandraは更新と挿入（アップサート）のみを行います。 また、任意のノードに書き込むことができ、各列のセマンティクス「最後のレコードが優先」を使用して競合を自動的に解決します。 それで、これは私たちにどのような影響を与えましたか？





競合状態の編集/削除の例



ユーザーがメッセージを編集し、別のユーザーが同じメッセージを削除した場合、Cassandraは更新と挿入のみを記録するため、主キーとテキストを除いて、データが完全に欠落している行がありました。 この問題には2つの解決策があります。

1. メッセージの編集中にメッセージ全体を書き戻します。 その後、削除されたメッセージを復活させる可能性があり、競合の可能性が他の列の同時エントリに追加されます。
2. 破損したメッセージを特定し、データベースから削除します。

2番目のオプションを選択するには、必要な列（この場合はauthor_id



）を定義し、空の場合はメッセージを削除します。



この問題を解決すると、書き込み操作には非常に効果がないことがわかりました。 Cassandraは最終的に合意されているため、このようなデータを取得してすぐに削除することはできません。 彼女は削除を他のノードに複製する必要があり、これはノードが一時的に利用できない場合でも実行する必要があります。 Cassandraは、削除を「tombstone」と呼ばれる独特の記録形式と同一視することでこれを行います。 読み取り操作中、彼女は単に途中で発生する「墓石」をすり抜けます。 「墓石」の寿命は調整され（デフォルトでは10日間）、期限が過ぎた場合、基本圧縮中に永久に削除されます。



列の削除と列へのゼロの書き込みはまったく同じです。 どちらの場合も、「墓石」が作成されます。 Cassandraのすべてのエントリは更新および挿入であるため、最初にゼロを書き込んでも「墓石」を作成します。 実際には、完全な通信スキームは16列で構成されていましたが、平均メッセージには4つの設定値しかありませんでした。 通常は理由もなく、Cassandraで12個の「墓石」を記録しました。 この問題の解決策は簡単でした。ゼロ以外の値のみをデータベースに書き込みます。

性能

Cassandraは読み取りではなく書き込み操作を実行することが知られており、まさにそれを観察しました。 書き込み操作は1ミリ秒未満の間隔で発生し、読み取り操作は5ミリ秒未満で発生しました。 このような指標は、アクセスされるデータの種類に関係なく観察されました。 1週間のテストの間、パフォーマンスは変化しませんでした。 当然のことながら、私たちは期待どおりのものを手に入れました。





ログからのデータに応じた読み取り/書き込み遅延



高速で信頼性の高い読み取りパフォーマンスと一致して、数百万のメッセージがあるチャネルで1年前のメッセージに切り替える例を次に示します。

大きな驚き

すべてが順調に進んだため、Cassandraをメインデータベースとして展開し、MongoDBを1週間無効にしました。 彼女は完璧に仕事を続けました...約6か月間、彼女が応答しなくなるまで。



Cassandraはガベージコレクション中に10秒間継続して停止することに気付きましたが、その理由はまったくわかりませんでした。 彼らは掘り始め、Discordチャネルを見つけました。ロードに20秒かかりました。 原因は、 Puzzles＆Dragons subredditのパブリックDiscordサーバーでした。 公開されているので、参加しました。 驚いたことに、チャンネルにはメッセージが1つしかありませんでした。 その瞬間、APIを介して数百万のメッセージが削除され、チャネルに1つのメッセージしか残されていないことが明らかになりました。



注意深く読んだ場合、Cassandraが「廃棄」を使用して削除を処理する方法を覚えておいてください（「長期的な一貫性」の章で説明）。 ユーザーがこのチャネルをダウンロードすると、少なくとも1つのメッセージがあり、Cassandraは何百万もの「墓石」のメッセージを効果的にスキャンする必要があります。 次に、JVMが収集できるよりも速くガベージを生成します。



この問題を次のように解決しました。

• 毎晩、メッセージクラスターでCassandraの修復 （反エントロピープロセス）を開始するため、墓石の寿命が10日間から2日間に短縮されました。
• 要求コードを変更して、チャネル上の空のブロックを追跡し、将来それらを回避します。 これは、ユーザーが再びこのリクエストを開始した場合、最悪の場合、Cassandraは最新のブロックのみをスキャンすることを意味します。

未来

現在、レプリケーション係数が3の12ノードのクラスターがあり、必要に応じて新しいCassandraノードを追加し続けます。 このアプローチは長期的には有効であると考えていますが、Discordが成長するにつれて、1日あたり数十億のメッセージを保存する必要がある場合、遠い未来が見えます。 NetflixとAppleには数百のノードを持つクラスターがあるため、現時点では心配する必要はありません。 ただし、いくつかのアイデアを用意しておく必要があります。

近い将来

• メッセージクラスターをCassandra 2からCassandra 3にアップグレードします。Cassandra3の新しいストレージ形式により、ストレージを50％以上削減できます。
• Cassandraの新しいバージョンは、各ノードでより多くのデータを処理するのに適しています。 現在、それぞれに約1 TBの圧縮データを保存しています。 この制限を2 TBに増やすことで、クラスター内のノードの数を減らすことは安全だと思います。

遠い未来

• Explore Scyllaは、C ++で記述されたCassandra互換のDBMSです。 通常の操作では、Cassandraノードは実際にいくつかのCPUリソースを消費しますが、Cassandraの修復時（オフエントロピープロセス）のオフピーク時に、それらはCPUに大きく依存し、修復時間は最後の修復以降に記録されたデータ量に応じて増加します。 Scyllaは、修理の速度を大幅に向上させることを約束します。
• Google Cloud Storageに未使用のチャンネルをアーカイブし、それらをオンデマンドでダウンロードするシステムを作成します。 私たちはこれを避けたいし、これをしなければならないとは思わない。

おわりに

Cassandraへの移行から1年以上が経過し、 「大きな驚き」にもかかわらず、穏やかな水泳でした。 生産性と安定性を維持しながら、1日あたり合計1億通を超えるメッセージから1億2000万通を超えるメッセージに移行しました。



このプロジェクトの成功により、私たちはその後、本番環境にある他のすべてのデータをCassandraに転送し、また成功しました。



この記事の続きでは、何十億ものメッセージに対して全文検索を実行する方法を探ります。



専門のDevOpsエンジニアはまだいません（バックエンドエンジニアは4人のみです）ので、心配する必要のないシステムがあるのはとてもクールです。 私たちは従業員を募集していますので、そのようなタスクがあなたの想像力をくすぐる場合はご連絡ください 。