Blueskyの損失のあるタイムライン・Jazのブログ

2025年2月19日

多くの場合、システムを設計するときは、データの一貫性、可用性、遅延などの完璧さを目指しています。

システム設計の最も難しい部分は、完全な一貫性、完璧な可用性、信じられないほど低いレイテンシ、信じられないほど高いスループットを持つシステムを設計することが（不可能ではないにしても）難しいことです。

代わりに、システム設計にアプローチする場合、これらの各プロパティをさまざまな軸上のポイントとして扱うことをお勧めします。これは、サポートしているアプリケーションの「適切」を見つけるためにバランスを取ります。

私は最近、のデザインでいくつかの主要なトレードオフをしました ブルースキー フィード/タイムラインに従って、ユーザーに悪影響を及ぼさないが、P99を96％以上削減する方法で一貫性を犠牲にして書き込みのパフォーマンスを改善しました。

タイムラインファンアウト

BlueSkyに関する投稿を作成すると、投稿はシステムによってインデックス付けされ、データベースに固執し、API応答で水分補給してサービスを提供できるようにします。

さらに、投稿への参照は、フォロワーに「ファンアウト」され、タイムラインでそれを見ることができます。

このプロセスには、すべてのフォロワーを検索し、投稿を参照して逆の時系列に新しい行を逆のタイムラインテーブルに挿入することが含まれます。

ユーザーがタイムラインをロードすると、投稿参照のページを取得し、その後、投稿/アクターを同時に水分補給してAPI応答をすばやく作成し、従う人からの最新のコンテンツを表示させます。

タイムラインテーブルはユーザーによってシャードされています。これは、各ユーザーが独自のタイムラインパーティションを取得し、水平方向にスケーラブルなデータベース（SCYLLADB）のシャード間にランダムに配布され、複数のシャードを横切って高可用性のために複製します。

タイムラインは、書かれたときに定期的にトリミングされ、ターゲットの長さに近づき、スペースを節約するために古い投稿参照をドロップします。

お住まいの地域のホットな破片

Blueskyは現在周りにあります 3,200万人のユーザー また、タイムラインデータベースは数百の破片に分割されています。

このような少数の破片で何百万ものパーティションをサポートするために、各ユーザーのタイムラインパーティションには、他の何万人ものユーザーのタイムラインがコロークされています。

通常の状況では、すべてのユーザーがうまく振る舞うと、個々のタイムラインの作業が十分に小さく、シャードが重度の課税なしに何万人もの作業を処理できるため、これは問題を提示しません。

残念ながら、多数のユーザーを使用すると、一部のユーザーは、他の何十万人ものユーザーをフォローしているような異常なことを行います。

一般的に、これはポリシーとモデレートを介して対処して、虐待的なユーザーがシステムの大音量の負荷を引き起こすのを防ぎますが、これらのプロセスには時間がかかり、不完全になる可能性があります。

ユーザーが他の数十万人に従うと、彼らのタイムラインは、大幅に上昇したレートでの書き込みとトリミングが発生することで過活動になります。

この負荷は、個々の操作をユーザーのタイムラインに遅らせます。これは、動作の悪いユーザーにとっては問題ありませんが、他の何万人ものユーザーに問題を引き起こします。

私たちは通常、この状況を「ホットシャード」と呼びます。シャードの居住者の中には、他の人よりもはるかに高いレートで書かれている、または読み取られている「ホット」データがあります。シャード上のデータは数回のみ複製されているため、データベースの水平スケールを効果的に活用して、このすべての追加作業を処理することはできません。

代わりに、「ホットシャード」は、単一のパーティションで作業を行うために多くの時間を費やすことになり、コロケートされたパーティションの操作も遅くなります。

スタッキングレイテンシ

ファンアウトプロセスに戻って、ユーザーのファンアウトのケースとその後の2,000,000人の他のユーザーが考えてみましょう。

通常の状況では、単一のタイムラインへの書き込みには平均で約600マイクロ秒かかります。ユーザーのフォロワーのタイムラインに順次書き込む場合、この投稿をファンアウトするために、せいぜい20分間座っています。

代わりに、一度に1,000のタイムラインに同時にファンアウトする場合、このファンアウトジョブを約1.2秒で完了することができます。

それはシステムの重要な特性を単純化しすぎていることを除いて、素晴らしいように聞こえます。 テールレイテンシー。

平均 書き込みのレイテンシは〜600マイクロ秒ですが、いくつかの書き込みははるかに短い時間がかかり、一部はもっと時間がかかります。実際、タイムラインクラスターへのP99の書き込みは、15ミリ秒ほど高い場合があります。

これは私たちのファンアウトにとって何を意味しますか？まあ、一度に1,000のタイムラインに同時に書き込む場合、統計的には、15ミリ秒より遅い、または遅い10の書き込みが表示されます。

タイムラインの場合、フォロワーの各「ページ」は10,000人のユーザーが大きく、次のページを取得する前に各「ページ」をファンアウトする必要があります。

これは、私たちの最も遅い書き込みが、次のページのフェッチとファンアウトを保持することを意味します。これは予想されるファンアウト時間にどのように影響しますか？

各「ページ」は、P99レイテンシよりも遅いか遅い〜100個の書き込みを行います。不運になった場合、彼らはすべて1つのルーチンに積み重ねて、ファンアウトの1ページを1.5秒に減速させることができました。

最悪の場合、2,000,000人のフォロワーの有名人にとって、彼らのポストファンアウトは5分もかかる可能性があります！

これは、P99.9とP99.99のレイテンシーを考慮していないため、1秒以上になる可能性があります。

これが20,000,000人以上のフォロワーを持つユーザーにとってこれがどれほど悪いか想像してみてください！

では、どのように問題を解決しますか？もちろん、欠陥を受け入れることによって！

喪失したタイムライン

他の何十万人ものユーザーをフォローしているユーザーを想像してください。彼らのタイムラインは、数百秒間に数百倍に書かれており、たとえそれがフルタイムの仕事であっても、タイムライン全体に追いつくことは人間的に不可能になるでしょう。

特定のユーザーには、それを超えるしきい値があります 不合理 彼らがタイムラインに追いつくことができるように。この点を超えて、彼らはおそらく他のさまざまなフィードを通してコンテンツを消費し、主に次のフィードを使用しません。

さらに、この点を超えて、そうです 合理的 私たちは、彼らが従う何千人ものユーザーによって投稿されたすべてのすべての完全な年表を必ずしも持っているわけではありませんが、タイムラインに常に新しいものがあるほど十分なコンテンツを提供します。

この場合、「合理的」という用語を使用して、ソーシャルメディアサービスとして、単一のユーザーに対して行うと予想される作業量に制限があるに違いないことを大まかに伝えることに注意してください。

タイムラインの正確性を減らして、単一のタイムラインがDBシャードに配置できる作業の量に制限があるようにメカニズムを導入した場合はどうなりますか。

私たちはaを主張することができます reasonable limit フォローの数の場合、ユーザーは健康でアクティブなタイムラインを持つ必要があり、その後、タイムラインの「喪失」を増やして、その制限を超えて進む必要があります。

a loss_factor として定義できます min(reasonable_limit/num_follows, 1) ホットな破片を防ぐために、確率的にタイムラインに書き込みをドロップするために使用できます。

ファンアウトでページを書く直前に、間にランダムなフロートを生成できます 0 そして 1、次にそれを比較します loss_factor ページ内の各ユーザーの。ユーザーの場合 loss_factor 生成されたフロートよりも小さいので、ユーザーをページからフィルタリングし、タイムラインに書き込みません。

現在、ユーザーはすべて、ファンアウトの「フォローする価値」と同じ数の「フォロー」を持っています。たとえば、 reasonable_limit 2,000人のうち、他の4,000人に従うユーザーが loss_factor の 0.5 書面の半分のタイムラインが削除されることを意味します。他の8,000人をフォローしているユーザーにとって、彼らの損失因子 0.25 書き込みの75％をタイムラインに落とします。

したがって、各ユーザーは、タイムラインのために行われたファンアウト作業の量に効果的な上限を持っています。

の制限を指定することにより 合理的 ユーザーの行動とそれを超えているユーザーの不完全性を受け入れると、システムのスケーラビリティを犠牲にすることなく、ユーザーの期待に応えるサービスを提供し続けることができます。

キャッシングはさておき

私たちは、1日の忙しい部分で1秒に100万回以上の速度でタイムラインに書き込みます。特定のユーザーのフォローの数を調べる前に、それらに扇動する前に、プライマリデータベースクラスターに1秒あたり100万件以上の追加読み取りが必要になります。この追加の負荷はデータベースに好評を博し、追加のコストは、より速いタイムラインファンアウトのペイオフに値しません。

代わりに、Redisソートセットでハイフォローアカウントをキャッシュするアプローチを実装し、ファンアウトサービスの各インスタンスは、30秒ごとにメモリに更新されたバージョンをメモリにロードします。

これにより、緊張サービスインスタンスごとに何百万回ものハイフォローアカウントのフォローカウントを検索することができます。

この場合、正しく機能する必要がない値をキャッシュすることにより、サービスの機能を損なうことなくパフォーマンスとスケーラビリティを改善するために、システムの欠陥を再度受け入れることができます。

結果

数週間前に生産システムにLossy Timelinesを実装し、タイムラインデータベースクラスターでホットシャードが劇的に減少しました。

実際、クラスターにホットな破片がまったくないように見え、ファンアウト作業のページのP99は90％以上削減されています。

さらに、書き込みP99Sの削減により、完全なファンアウトのP99期間は96％以上削減されました。大規模なアカウントに5〜10分かかっていた仕事が今すぐ取る

不完全になっても大丈夫な場所を知ることで、システムの他の望ましい側面とより高く拡大するために一貫性を交換できます。

タイムラインアーキテクチャには改善する他の場所がたくさんありますが、このステップは、Blueskyのタイムラインのスループットとスケーラビリティを改善するための大きなものでした。

これらの種類の問題に興味があり、BlueSkyにパワーするコアデータサービスの構築を支援したい場合は、チェックしてください このジョブリスト。

Blueskyの他のオープンポジションに興味がある場合は、それらを見つけることができます ここ。