微博広告情報の流れ（微博技術の解読（第1部））

マイクロブログ技術の解読（パート 1）

コラム終了後、多くの学生がWeiboのインフラに関する知識を話して欲しいとメッセージを残してくれました。そこで、Weiboテクノロジー解読シリーズの次回では、情報フローアーキテクチャ、ストレージミドルウェアなどにおけるWeiboの経験を共有し、皆さんにインスピレーションと助けをお届けできればと思います。

今日はまずWeiboの情報フローアーキテクチャ、つまりWeiboのフィードがどのように構築されているかを見てみましょう。まず、フィードとは何でしょうか?私の理解によれば、Feed はインターネット 2.0 時代の産物です。インターネット 1.0 時代の製品であるポータル Web サイトとの最大の違いは、Feed ではユーザーが情報を取得するためにさまざまなセクション間を行ったり来たりする必要はなく、さまざまな情報を集約してユーザーが継続的にアクセスできる点です。ここで関係する問題は 2 つあります。1 つは情報を保存する方法、もう 1 つは情報を集約する方法です。これが今日私がシェアしたい主な内容でもあります。ストレージアーキテクチャの観点からWeibo Feedがどのように保存されるかを説明し、次にビジネスアーキテクチャの観点からWeibo Feedがどのように集約されるかを説明します。

ご存知のとおり、Weibo フィードはフォローしている人の Weibo 投稿で構成されているため、各人の Weibo 投稿を保存するには、ストレージ アーキテクチャを設計する際に次の 3 つの問題に注意する必要があります。

• 1 秒あたりに書き込まれるデータの量、つまり 1 秒あたりのブログ投稿数。
• 1秒あたりのデータアクセス量、つまり1秒あたりのWeiboリクエスト数。
• ホットデータとコールドデータの区別はありますか?つまり、Weibo リクエストには時間的な特性があるのでしょうか?

Weiboのビジネスシナリオに基づいて、上記の3つの質問に答えます。 1 つ目は 1 秒あたりの投稿数です。ここでは極端な状況を考慮する必要があります。たとえば、元旦の深夜には、大量のユーザーが瞬時にブログを投稿し、QPS が数万に達します。 1秒あたりのWeiboリクエスト数を見てみましょう。また、「春節祝賀会」などの人気イベント時には、多数のユーザーがWeiboにアクセスし、リクエスト量が数万QPSに達することも考慮する必要があります。各ユーザーは複数のユーザーをフォローしています。平均フォロワー数を200人と仮定すると、Weiboデータのリクエスト量は数百万QPSになります。さらに、Weibo の訪問には時間的な特徴もあります。一般的に、ユーザーは1週間前に投稿された投稿よりも新しく投稿されたWeiboの投稿にアクセスする可能性が高いため、Weiboのデータはホットとコールドに分けることもできます。

これら 3 つの問題を組み合わせることで、Weibo のストレージ アーキテクチャをどのように設計すべきかが決まります。 Weibo のストレージ アーキテクチャについて説明する前に、まず業界内でより成熟したストレージ ソリューションを見てみましょう。これらは主に次のタイプに分けられます。

• MySQL に代表されるリレーショナル データベース。主に、比較的固定された構造を持つデータを保存するために使用されます。ディスク ストレージが使用されるため、書き込み機能とアクセス機能は主にディスクの読み取り機能と書き込み機能に依存します。ディスクは主に SAS ディスクと SSD ディスク、つまり機械式ディスクとソリッド ステート ディスクに分けられます。両者の読み書き能力には一定の差があります。 SSD ディスクの読み取りおよび書き込み機能は SAS ディスクの約 3 倍ですが、QPS は数千になります。ディスクストレージの特徴は、データが失われにくく、永続的に保存できることです。
• Memcached や Redis に代表されるメモリ ストレージ。サーバーのメモリ サイズは一般にディスクのメモリ サイズよりもはるかに小さく、数十 GB から数百 GB の範囲ですが、ディスクは通常 TB レベルです。メモリストレージの利点は、読み取り速度と書き込み速度が速いことです。読み取りおよび書き込み機能は数十万 QPS に達し、これはディスク ストレージよりもはるかに優れています。ただし、データはメモリに保存されるため、プロセスがクラッシュしたり、マシンが再起動したりすると、メモリ内のデータはクリアされます。
• HBase に代表される分散ストレージ。非固定データ構造を特徴とする非リレーショナルデータベースなので、非構造化データの保存に適しています。さらに、分散ストレージを採用し、基盤となるファイルストレージシステムとして HDFS を使用しているため、大量のデータを保存でき、書き込みパフォーマンスが非常に高くなります。

この時点で、前述の Weibo のビジネス シナリオと組み合わせて、ストレージ アーキテクチャをどのように設計すべきだとお考えですか?

Weiboの実際のビジネス状況に応じて、ユーザーのWeibo投稿は永久に保存、つまり永続的に保存される必要があります。さらに、Weibo のデータ構造は固定されているため、リレーショナル データベースが好まれます。したがって、MySQL が選択肢となります。しかし、MySQLサーバ単体の読み取り容量の上限は1万QPS未満であり、Weiboのデータリクエスト量は数百万QPSであることを考えると、MySQLだけで対応しようとすると数千台のサーバが必要となり、非常にコストがかかります。もう1つのポイントは、Weiboデータに対するリクエストがホットタイプとコールドタイプに分かれていることです。 1 週間外のデータにアクセスする可能性は、1 週間内のデータにアクセスする可能性よりもはるかに低くなります。上記の点を考慮すると、ユーザーの完全なマイクロブログ データは MySQL に永続的に保存しながら、Memcached を使用して過去 1 週間以内のマイクロブログを保存するなど、MySQL ストレージの前に別のキャッシュ レイヤーを追加できます。ユーザーが 1 週間以内に Weibo にアクセスする確率が 99% であると仮定すると、キャッシュへのリクエスト数は数百万 QPS ですが、データベースへのリクエスト数は数万 QPS にすぎません。キャッシュの読み取りおよび書き込み容量は数十万 QPS です。比較すると、データベースのみを使用する場合と比べて、必要なマシンの数ははるかに少なくなります。

これまでの説明で、MySQL + Memcached の 2 層ストレージ アーキテクチャを使用して Weibo のストレージ問題を解決したと仮定すると、次に直面する問題は、フォローしている人々の Weibo の保存データを、ユーザーがアクセスできる継続的な情報ストリームに集約する方法です。

私の経験によれば、情報フロー集約には一般に、プッシュ モード、プル モード、プッシュ プルの組み合わせという 3 つのアーキテクチャがあります。以下では、これら 3 つのアーキテクチャについて詳しく説明します。

1. プッシュモード

プッシュモードは、その名の通り、フォローしている人のWeibo投稿をファンに積極的にプッシュするモードです（下の図を参照）。プッシュ モードは受信トレイを持つことと同じです。あなたがフォローしている誰かがWeiboに投稿すると、このWeiboはすべてのファンの受信トレイにプッシュされます。こうすることで、フォローしている人の数に関係なく、その人の Weibo 投稿があなたの受信トレイに積極的にプッシュされるようになります。受信トレイにアクセスするだけで、フォローしているすべての人の Weibo の投稿を取得できます。

2. プルモード

プル モードはプッシュ モードの逆です。図に示すように、誰もが送信トレイを持っており、Weiboが投稿されると、そのWeiboは送信トレイに保存されます。このように、あなたがフォローしているすべての人のWeibo投稿を取得したい場合は、あなたがフォローしている人々の送信​​トレイリストを走査し、あなたがフォローしているすべての人の送信トレイを取り出し、それらを時系列順に集約する必要があります。

まず、どのアーキテクチャが Weibo フィードに適しているかを比較してみましょう。まず、プッシュモードを見てみましょう。シンプルな集約が特徴です。誰でも自分の受信トレイを確認することで、フォローしている人が送信したWeiboの投稿をすべて受け取ることができます。ただし、欠点は、ファンがフィードをリクエストしない場合でも、各Weibo投稿をすべてのファンにプッシュする必要があるため、書き込み量が非常に多くなることです。特に、何億人ものファンがいるユーザーの場合、Weibo に投稿するには、この Weibo の投稿を何億人ものファンの受信トレイにプッシュする必要があります。この書き込み量は非常に大きく、プロセッサとデータベースにかかる負担は想像に難くありません。さらに、同じWeibo投稿のコピーが複数保存されるため、多くのストレージスペースを占有します。また、Weibo の投稿を変更または削除する必要がある場合は、すべてのファンの受信トレイにリクエストする必要があります。 Weibo は数千万人のフォロワーを持つユーザーが多いパブリック ソーシャル メディア プラットフォームであることを考慮すると、プッシュ モデルを採用すると、ストレージ コストとデータ更新コストが非常に高くなり、更新用に多数のキャッシュ、データベース、キュー マシンが必要になります。初期の頃、Twitter のフィードはプッシュ モデルを採用しており、大量の書き込みによる大きな負荷のために更新の遅延が頻繁に発生していました。

プルダウンモードを見てみましょう。集計ロジックが複雑であるという特徴があります。誰もがフォローしている人が送信した Weibo の投稿をすべて表示したい場合は、フォロワーのリストを走査してすべての Weibo の投稿を取得し、それらを時間別に集約する必要があります。集約によってもたらされるデータ要求の量と計算量は、プッシュ モードよりもはるかに多くなります。ただし、各ユーザーの Weibo は自分の送信トレイ リストにのみ存在するため、ストレージ コストはプッシュ モードよりもはるかに小さく、データの変更があった場合でも自分の送信トレイ リストを変更するだけで済みます。

3. プッシュプルコンビネーション

プッシュ モードとプル モードの長所と短所を比較すると、プッシュとプルを組み合わせて両方の利点を生かすことができるのではないかという新しいアイデアが自然に浮かび上がります。プルモードはフォロワー数の多いユーザー向けに使用され、一般ユーザーの場合、フォロワー数は限られているため、プッシュモードは大きな問題にはなりません。このように、ユーザーがフォローしているすべての人のWeiboを取得したい場合、一方ではフォロワー数の多いフォローしている人の送信トレイリストを要求する必要があり、他方では自分の受信トレイリストを要求する必要があります。そして、その 2 つを集約することで、完全なフィードを得ることができます。

プッシュとプルの組み合わせはより合理的であるように思われますが、結果としてビジネスの複雑さは比較的高くなります。ユーザーのファンの数は常に変化するため、どのユーザーがプッシュ モードを使用し、どのユーザーがプル モードを使用するかを管理するコストは非常に高くなります。そこで、総合的に検討した結果、Weibo Feed はプル モデルを採用しました。

前述したように、プル モードを使用する場合は、フォローしているすべての人の送信ボックスをプルする必要があります。フォローしている人が数十人、数百人しかいない場合でも、獲得効率は非常に高くなります。しかし、フォロワーが何千人もいると、時間がかかります。 4,000 人以上のユーザーの送信トレイを検証して取得するには数百ミリ秒かかり、ロングテール リクエスト (つまり、1 つのリクエストに 1 秒以上かかるリクエスト) の可能性も大幅に増加します。何千人ものフォロワーを持つユーザー向けのフィードを取得する際の効率が低い問題を解決するために、分割統治の考え方を採用しました。プルする前に、ユーザーのフォロワーをいくつかのグループに分けて、並行してプルしました。このように、1 回の集約計算操作を複数の集約計算操作に分解し、最終的に複数の集約計算操作の結果をまとめて集約するという、MapReduce の考え方に似ています。実際の検証では、この方法により、何千人ものフォロワーを持つユーザーのフィード取得にかかる時間を効果的に短縮でき、ロングテールリクエストの数も大幅に削減できることがわかっています。

今日はWeibo Feedのストレージアーキテクチャとビジネスアーキテクチャの選択について説明しました。最終的なソリューションは、Weibo のビジネス シナリオと当時のストレージの成熟度に基づいて選択されたことがわかります。 Weibo は 2009 年に誕生し、2010 年にプラットフォームの変革を経て、現在のストレージとビジネス アーキテクチャを確立しました。当時のストレージの成熟度により、MySQL + Memcached の組み合わせが最適なソリューションであると判断され、Redis や HBase などのより高度なデータベースは使用されませんでした。同時に、Weibo Feedのビジネス特性により、プルモードのビジネスアーキテクチャが選択され、プル方式は数千人のフォロワーがいるシナリオに最適化され、実践でも効果的な手段であることが証明されました。

検討すべき質問

Weibo のストレージ アーキテクチャの設計を依頼された場合、MySQL + Memcached 以外にどのようなストレージ オプションを使用できると思いますか?