数百万人が参加するオンラインライブインタラクティブプラットフォーム向けのDockerベースのマイクロサービスアーキテクチャプラクティス

[51CTO.com からのオリジナル記事] この記事では、特定のプロジェクト例から始まり、迅速にスケーラブルなマイクロサービスアーキテクチャをゼロから構築する方法について説明します。

2017年12月1日から2日にかけて、51CTO主催のWOTDグローバルソフトウェア開発技術サミットが深セン中州マリオットホテルで盛大に開催されました。

このサミットのテーマはソフトウェア開発でした。 Sina Weibo R&D Centerのプラットフォームのシニアシステム開発エンジニアであるWen Qing氏は、マイクロサービスとコンテナテクノロジーのセッションで「Dockerに基づくWeiboライブインタラクティブマイクロサービスアーキテクチャ」をテーマに素晴らしい講演を行いました。

この記事では、次のトピックを中心に、ライブインタラクティブブロードキャストのマイクロサービスアーキテクチャ設計について説明します。

現在非常に人気のあるライブ放送シーンを考慮して、ライブメッセージのインタラクティブ配信をサポートする安定したメッセージインタラクションシステムをどのように設計するか。
サービスがますます複雑になるにつれて、システムを合理的にコンポーネントに分割し、マイクロサービスの形で独立した展開とアップグレードを実現するにはどうすればよいでしょうか。
ハイブリッドクラウドシステムでは、トラフィックが急増し、監視する人がいない場合にサービスの自動的な伸縮自在なスケーリングを実現するために、Docker テクノロジとパブリッククラウドの伸縮性を最大限に活用して、ハイブリッドクラウドに基づく伸縮自在なアーキテクチャを設計するにはどうすればよいでしょうか。

Weiboライブインタラクティブプラットフォームの背景と課題

2017年はライブストリーミングにとって大きな年でした。 Sina Weiboは独自のアプリでライブストリーミングサービスを開始し、Taobao、Yizhibo、Hongdouなどのプラットフォームとのやり取りも開始しました。

技術的に言えば、ライブ放送は一般的に 2 つの部分に分かれています。

ストリーミングメディアの送信部分を含むビデオストリーム。
コメント、いいね、ギフト、その他の部分を含むライブ放送のインタラクション。

ライブブロードキャストの特徴は、室内に多数の人がいるため、ライブブロードキャストプラットフォームは、数百万のユーザーが同時にオンラインになるシナリオをサポートできる必要があることです。

Weiboライブプラットフォームの特徴

ライブインタラクティブシステムの基本モデルはメッセージ転送システムです。つまり、ユーザーがメッセージを送信し、他のユーザーがそのメッセージを受信し、対応する保存を実行します。

メッセージングシステムには一般に、リアルタイム性、信頼性、一貫性という 3 つの基本的な評価基準があります。ライブブロードキャストのようなメッセージングシステムの場合、信頼性と一貫性に対する要件は高くありませんが、リアルタイムパフォーマンスに対する要件は非常に高くなります。

ユーザーがアンカーにギフトを送信すると、アンカーは 10 秒後または 1 分後に受信して返信します。これは受け入れられません。したがって、「第 2 レベル」でのリアルタイムパフォーマンスが必要になります。

Weiboライブストリーミングインタラクションの特徴：

通常、トラフィック量はそれほど多くありませんが、訪問者が多い場合はトラフィック量が大幅に増加します。
トラフィックの急増は、大量のメッセージプッシュに反映されます。一般的に、1 秒あたり数千万件のメッセージをプッシュできます。
一般的な短い接続リクエストの場合、ユーザーはインターフェースに入るためにリクエストを 1 回送信するだけで、通常はその後他の操作は実行されないため、サーバーにかかる負荷はそれほど大きくなりません。

ライブインタラクティブシナリオは異なります。ユーザーがルームに参加した後、何も操作をしなくても、多くのプッシュ通知が届きます。この非常にリアルタイムなプッシュ方式は、サーバーに継続的な負荷をかけます。

Weiboライブストリーミングプラットフォームが直面する課題

ライブ放送の需要が大きく、ゲームプレイも多様化しているため、私たちは次の 3 つの側面から課題に直面しています。

いかに迅速に反復し、ニーズに迅速に対応するかが、ビジネスとシステムの尺度となります。
フルプッシュによって発生するトラフィックピークに対処する方法。
コストを最大化する方法、つまり、限られたリソースを使用してピークと谷の交互に対処する方法。

Weiboライブインタラクティブプラットフォームのマイクロサービスアーキテクチャの進化

上記 3 つの課題に対応するため、私たちはライブインタラクティブ放送用の独自のマイクロサービスアーキテクチャを構築しました。上の図はライブインタラクティブのアーキテクチャ図です。ビジネス層を、ディスカバリーサービス、サードパーティプラットフォームサービス、プッシュサービスなどのさまざまなマイクロサービスを含むモジュール部分に分割しました。

アーキテクチャの選択

アーキテクチャの選択に関しては、まず従来のモノリシックモデルを見てみましょう。モノリスは多くのシナリオに適しており、特にアジャイル開発に適しています。

Weibo のやり取りのトラフィックが膨大で、システムが比較的複雑なため、次のような問題が発生します。

オンライン化のコストは高く、反復速度は遅いです。モノリシックモデルでは、すべてのサービスを 1 つにまとめ、それらをまとめて展開し、オンラインまたはオフラインにすることができます。したがって、小さな変更を行うにはオンラインに戻る必要があります。
起こりうるサービスの問題を排除するために、通常は完全な回帰テストを実施します。この遅い反復速度は私たちにとって受け入れられないことがわかります。
スケーラビリティが低い。サービスを横展開していくと、サービス数が増えるにつれて、RedisとDB間の接続数も徐々に増加していきます。ただし、各リソースには特定の接続ボトルネックがあります。サービスが一定数まで成長すると、それ以上水平展開できなくなります。

堅牢性が低い。システムにバグがあると、他のサービス、あるいはサービス全体が麻痺してしまいます。

マイクロサービスとモノリスの違いは、マイクロサービスではいくつかの共通機能を分割し、その分割に基づいて各モジュールが独自の DB とリソースを維持できることです。

したがって、マイクロサービスの利点は次のように反映されます。

各サービスは独立して開発および展開され、反復速度が大幅に向上します。すべてをテストする必要はなく、開発したサービスだけをテストすればよいのです。
単一のサービスが依存するリソースが削減され、拡張速度が大幅に向上しました。特に軽量なサービスの場合、30 ～ 40 秒以内に拡張が完了し、開始されることを保証できます。
RDC または関連呼び出しを通じて、一部のプッシュサービスの DB および Redis への直接的な依存を排除し、接続数の問題を解決します。
無関係なサービスの問題によって発生する全体的なダウンタイムを回避し、バグを 1 つのモジュールに制限するために、各サービスを個別にデプロイします。

マイクロサービスの問題

マイクロサービスの導入により、いくつかの新たな問題も生じます。

以前のモノリシックモデルでは、さまざまなモジュールを詳細に検討することなく混在させていました。マイクロサービスを導入した今、それを合理的にどのように分割すればよいのでしょうか?
以前はローカル呼び出しだけでしたが、現在はマイクロサービスに変更されていますが、どのように通信するのでしょうか?ネットワークのオーバーヘッドをどのように考慮すればよいでしょうか?
サービスがデプロイされた後、マイクロサービスはどのように問題を発見するのでしょうか?

問題1: サービスの分割

マイクロサービスの分割に関して、誰もが最も懸念する問題は、分割の強度です。私たちは次のようなシンプルなアプローチを採用しました。これは、皆さんのプロジェクトでも参考にしていただけます。

分割方法がわからない場合は、コアサービスと非コアサービスに分割するだけで済みます。利点は、サービスを適切に分離できることです。

たとえば、サーバーが足りない場合、コアサービスのみが保護され、コア以外のサービスはコアサービスに影響を与えません。そのため、事業の重要度に応じて分割する方法です。

サービスガバナンスにより、コア以外のサービスをいつでもダウングレードできます。コアサービスをサポートするために、限られたマシンリソースを使用します。

基本的な分割が完了したら、ビジネスシナリオに応じてコアサービスをさらに分割できます。

Short Service には、Wesync と呼ばれるプライベートプロトコルパーサーがあります。通常、コードを変更することはなく、このプロトコルの解析は普遍的であるため、分割して個別に展開します。
ルームやメッセージなど、ビジネス関連のサービスはすべてBiz Serviceというサービスに展開しています。この部分のコード量は非常に多くなりますが、コード量はサービスを分割するかどうかの基準にはなりません。複雑な業務を処理するプレッシャーは大きくないため、グループ化することができます。
プッシュサービスを分割することで、ユーザーとの長期的な関係を維持し、メッセージプッシュのリアルタイム性を確保できます。さらに、サーバー側の「プッシュ」方式は、ユーザー側の「プル」方式よりもリアルタイムです。

プッシュサービスを分割した理由は次のとおりです。

大量のメッセージプッシュにより、プッシュサービスがサービス全体のボトルネックになっています。 10 万人の人がいる部屋で、10 人が 1 秒以内にクライアントにメッセージを送信すると、システムは 1 秒あたり 100 万件のプッシュメッセージを生成すると想像してください。

同様に、部屋に 100 万人がいれば、プッシュは 1,000 万回発生します。メッセージ量の大きさが非常に大きいため、プッシュサービスは頻繁に拡張する必要があるサービスであることがわかります。

設計時には、プッシュサービスをできるだけシンプルにし、リソースへの依存を減らすことを目指しています。

ビジネスの観点から、非コアサービスを次のように単純に分割します。

弾幕サービス: ライブ放送の再訪問機能と履歴メッセージの取得が含まれます。
サードパーティサービス: サードパーティプラットフォームへのアクセスサービス。

Barrage サービスを分割する理由を見てみましょう。このサービスは、履歴メッセージを一括で取得するために使用される外部に公開されたサービスであるため、履歴メッセージを一括で取得すると、必然的に大量の帯域幅が消費されます。

したがって、次の最適化手法を採用する必要があります。

Gzip 圧縮技術を使用してインターフェースと返されたデータを圧縮し、帯域幅の消費を削減します。
CPU やその他のハードウェアのパフォーマンスを最大限に活用します。
マルチレイヤーキャッシュ戦略を追加することで、DB またはメッセージキャッシュからロードすることなくローカルに直接ロードできるため、外部とのやり取りが削減されます。

上の図に示すように、マイクロサービスに分割する前は、サービスが無秩序に混在しており、まとめてデプロイする必要がありました。そのため、さまざまな戦略に基づいて、上記の方法に従ってサービスを分割します。

問題2: サービス通信

同時に、同期と非同期の観点からサービス間の通信も分割します。

同期操作: REST API メソッド + RPC メソッド。
非同期操作: 主にメッセージキューを中心に展開されます。

コアサービスと非コアサービス間の通信の相互作用に関するシナリオ分析を実施しました。上図に示すように、サードパーティサービス（サードサービス）には次の 2 つの側面が含まれます。

青い線は、サードパーティのサーバーがメッセージを当社のシステムにプッシュしていることを示しています。サードパーティからのメッセージをよりリアルタイム (同期) にアプリのフロントエンドに表示できるようにしたいため、RPC タイプの Push メソッドを使用します。
赤い線は、Weibo アプリからメッセージを生成し、それをサードパーティのサーバーに渡して、プル方式でメッセージを取得できることを示しています。他のサービス、後続のサービス、およびコア以外のサービスがコアサービスの機能に影響を与えないようにするため、非同期分離、つまり Queue 型の Pull メソッドを使用して実装します。

Barrage サービスでは、共有データベースアプローチを採用しています。メッセージのバッチ再生は大量のメッセージ帯域幅を消費するサービスであるため、システムリソースの提供を確実にするために、データベースを共有し、データベースから直接読み込みます。

問題3: サービス検出

プッシュサービスタイプのサービス検出では、DNS に依存して DNS にサービス検出を行わせるという従来の方法を廃止し、代わりに独自に作成したディスパッチサービスを採用しました。

その動作メカニズムは次のとおりです。

ユーザーが部屋に参加する前に長い接続を確立するために、Dispatch を送信して Push サービスとの対応する接続を確立します。メッセージが生成されると、プッシュサービスを通じてプッシュされます。
ディスパッチサービスは、ユーザーが属するサーバーとリージョンに基づいて、戦略に応じて適切な選択を動的に行うことができます。
この戦略は、プッシュサービスの水平拡張をサポートできます。つまり、拡張後は、古いプッシュサービスにトラフィックをプッシュしたり、対応する IP を返したりすることはなくなり、代わりにすべてのトラフィックが新しいプッシュサービスに送信されます。

RPC タイプのサービス検出では、レジストリが利用可能なサービスのリストを提供し、サーバーがサービスを提供し、クライアントがサービスを検出して使用するという、一般的な SOA アーキテクチャを使用します。そのため、Motan RPC を使用して、さまざまなニーズに迅速に対応し、検出を完了します。

マイクロサービスの概要

要約すると、マイクロサービスは次の 4 つの問題を解決します。

独立した開発とテストにより反復がスピードアップします。
サービスを分割することで、無関係なサービス間の影響が軽減されます。
リソースへの依存度を減らすことで、サービスの拡張速度が向上します。
もちろん、サービスの導入や運用・保守の難易度も高まります。

急速な拡大に対応できる体制をとっているため、運用・保守要員の参加・配置が必要です。次に、ライブインタラクティブ放送の弾性スケーリング戦略について説明します。

Weibo ライブインタラクティブプラットフォームの弾力的なスケーリング

Docker ベースのハイブリッドクラウドアーキテクチャ

Weibo の使用は典型的なトラフィック急増のシナリオであるため、盲目的にサーバーを購入するという従来のソリューションを採用すると、全体的な負荷飽和の不均衡が発生します。

たとえば、人々は通常、日中や深夜にWeiboをチェックしないため、サーバーとネットワークの利用率は比較的低くなります。爆発的な負荷は夕方のピーク時にのみ生成されます。

そのため、当社は、パブリッククラウド上のさまざまな高速かつ弾力性のあるスケーラブルなリソースサービスを利用するという、急速で弾力性のある拡張と縮小の戦略を採用しました。

しかし、これまでのプライベートクラウド環境は完全に弊社の管理下にあったため、パブリッククラウドの導入により環境の違いが生じています。そこで、業界で一般的なソリューションを参考にして、Docker を採用しました。

Docker のネットワークモデルの選択には、通常、ブリッジ、コンテナ、ホストの実装が含まれます。

当初、テスト環境では Docker のデフォルト設定であるブリッジモードを使用しました。
Docker は、デーモン経由で起動すると、Docker0 と呼ばれる仮想イーサネットブリッジを持ちます。
Docker のデーモンは仮想化に veth ペアテクノロジを使用します。つまり、コンテナとホストマシンの間に仮想ネットワークカード接続が確立され、対応するメッセージ転送がコンテナの外部で実行されます。
問題: コンテナーは仮想 IP アドレスを使用するため、仮想 IP を使用して RPC サービスを登録します。ただし、起動後、クライアントは実際には仮想 IP にアクセスできません。

そのため、私たちはホストモードを採用しました。

ホストモードでは同じ eth0 を共有できるため、両者はホストのネットワーク名前空間を共有できます。

同時に、さまざまなルーティングのオーバーヘッドが節約されるため、ブリッジモードよりも高速になります。

Dockerの利点はシンプルで軽量であり、Weiboのアプリケーションシナリオに非常に適していることがわかります。さらに、パブリッククラウドのリソースと組み合わせて、Docker ベースのハイブリッドクラウドアーキテクチャが形成されます。これを DockerDCP と呼びます。

DCP がオープンソース化されていることは注目に値します。 GitHub に Open DCP のサービス図があり、検索することができます。

DCPの役割は、「三大祭り」期間中のトラフィックの急増に対応するために、容量を拡張し、10分以内に1,000台のマシンを展開できるようにすることです。

その結果、毎日 6,000 億回の API 呼び出しと数兆回の RPC 呼び出しが発生します。

ライブインタラクションやDCPの自動運用保守展開や拡張・縮小を実現するため、SLB(負荷分散)にメッセージを都度プッシュし、Push Serviceのプッシュサービスを通じてネットワーク間サービス展開を実施します。

容量拡張を実現するには、まず機器の供給元を知る必要があります。 DCP は、イントラネットとエクストラネット (パブリッククラウド) 上のさまざまなマシンを区別するのに役立ちます。

たとえば、イントラネット内の 3 つのビジネスパーティ (A、B、C) はそれぞれ独自のサーバーを所有しており、それらを「共有プール」として設定しています。

ビジネス C は、トラフィックのピーク時にプール内の 3 つのサーバーを申請し、ビジネスがアイドル状態のときにリソースをプールに戻します。これにより、プライベートクラウドとパブリッククラウド上での急速な容量拡張を自由に実現することができ、これを「デュアルクラウド拡張」と呼びます。

自動スケーリングプロセス

私たちのライブインタラクティブ自動スケーリングプロセスは、おおまかに次のように分かれています。

監視指標を確立します。つまり、拡張操作を開始する前に、特定の監視指標のしきい値を設定します。通常はストレステストを通じて取得されます。
監視指標の収集方法と収集する指標を含む監視指標の収集。
データは容量決定システムに流れ、容量を拡張するかどうかを決定します。
一連のサービスを拡張するための標準的なプロセスを上の図に示します。

容量を縮小するプロセスは、前述の容量を拡大するプロセスと似ているため、ここでは詳細には触れません。

上記の監視指標は、次の 2 つのカテゴリに分類されます。

ビジネスパフォーマンス指標はビジネスによって異なります。 API サービスによっては、1,000 QPS (Query Per Second) をサポートできるものもあれば、200 QPS しかサポートできないものもあります。そのため、ビジネスに応じて、収集および監視するパフォーマンス指標も異なります。
マシンパフォーマンス指標は、帯域幅、PPS、CPU、パフォーマンス、IOPS などの一般的なマシンパフォーマンス指標に重点を置いています。いずれかの領域でボトルネックが見つかった場合は、できるだけ早く容量を拡張する必要があります。

同様に、監視指標を指定するためのプロセスは、パフォーマンスシステムに対して対応するストレステストを実行する > サービスのボトルネックポイントを検出する > ボトルネックポイントを分析する > 監視指標を策定する、というものです。

現在、機械学習による自動監視の実現にも取り組んでいます。当社では通常、さまざまなサービスに対して毎週または定期的にストレステストを実行し、サービスのボトルネックをタイムリーに特定します。

新しく導入されたマシンによって全体的なパフォーマンスに不一致が生じる可能性があり、サービス需要とコード量が増加すると、サービス全体のボトルネックもそれに応じて他の場所に移動する可能性があります。そこで、ストレステストの進化版により、ボトルネックのリアルタイム把握を実現しました。

プッシュサービス指標の監視に関しては、ストレステスト中に監視するビジネスパフォーマンスには次のものが含まれます。

ユーザーデータの長さ。単一のマシンで何千ものユーザーの長時間接続をサポートできるからです。
メッセージのプッシュ量。一部のビジネスシナリオでは、長い通話はそれほど多くないかもしれませんが、メッセージのプッシュ量は非常に多くなります。そのため、さまざまな側面から監視を実施する必要があります。

マシンのパフォーマンス指標には、帯域幅、PPS、CPU、メモリ、IOPS なども含まれます。

監視指標の収集に関しては、次の 2 つの側面に分けられます。

業務のパフォーマンス指標は、各業務システムごとに収集されます。
機械のパフォーマンス指標は、運用保守監視サービスによって一元的に収集されます。

弾性膨張と収縮の概要

まとめると、弾性膨張と収縮に関しては、次の 3 つの点を達成しました。

コンテナ技術を使用した Docker 化されたサービスは、環境の違いの問題を解決します。より高速な拡張と縮小を実現するだけでなく、仮想化全体の標準化も実現します。
DCP は、ハイブリッドクラウドアーキテクチャを通じて、リソースの弾力的なスケーリングの問題を解決します。
アーキテクチャが構築された後、自動拡張と縮小により無人ライブストリーミングが実現しました。

典型的なケースの共有

以下は、スケーリングアーキテクチャを実装する前と実装した後の 2 つのライブブロードキャストケースの比較です。

自動膨張・収縮を実現する前に、神舟宇宙船の回収の様子を生中継しました。午前 3 時頃に発生し、ネットワーク上の誰にも通知されていなかったため、トラフィックがどの程度表示されるか分からないまま、メッセージ全体をプッシュしました。

翌日の事後分析により、サービストラフィックがボトルネックポイントに達し、多くのアラームが表示されたことがわかりました。幸いにも、勤務員がいたので、故障は起きませんでした。

メンテナンスチームの疲弊とサービス保証の観点から、自動スケーリングの実装を開始することにしました。

上図の通り、自動スケーリングを実装した後のライブ放送です。左図の青い線の各谷は、容量拡張操作を表します。

谷が最小の長い接続数にある場合、多数のマシンが自動的に拡張されるため、その時点ではトラフィックは流入せず、接続数は基本的にゼロになります。

その後、接続数が急増し、サービスは 30 分以内に 4 回の急速な自動拡張を実行しました。これらの自動容量拡張は、容量の拡張または縮小時に電子メールによるリマインダーが送信されることを除き、運用および保守担当者には透過的です。

[[228125]]

Wen Qing 氏は Sina Weibo のシニアシステム開発エンジニアであり、Weibo のビデオおよびコミュニケーション関連システムの開発に従事しています。現在、Weibo ライブメッセージインタラクションシステムの研究開発を担当し、高可用性、弾力的なスケーラビリティ、低結合のマイクロサービスアーキテクチャ設計を提唱しています。技術的には、メッセージ通信に長けており、システムがトラフィックの急増や高い同時実行性に対処する方法について豊富な実践経験を持っています。

[51CTO オリジナル記事、パートナーサイトに転載する場合は、元の著者とソースを 51CTO.com として明記してください]

<<: クラウドストレージの価格: 主要プロバイダーの比較

>>: ハイブリッドクラウドセキュリティの 5 つの主要戦略