100万レベルの接続、iQiyi WebSocketゲートウェイはどのように構成されていますか?

目の前で言った

40 歳の建築家 Nien の読者コミュニティ(50 歳以上) では、多くの友人が Alibaba、NetEase、Youzan、Xiyin、Baidu、Didi などの一流インターネット企業の面接資格を取得しています。

最近、ニエンは友人の履歴書を案内し、「高同時実行ゲートウェイプロジェクト」を書きました。このプロジェクトのおかげで、この男はByte/Alibaba/Weibo/Autohome から面接の招待状を得ることができました。つまり、これは素晴らしいプロジェクトです。

より多くの面接機会を獲得し、大手企業からより多くの内定を得るために、

Nien は、このプロジェクトのアーキテクチャと実際の操作を紹介するビデオの章「第 33 章: 10Wqps の高同時実行 Netty ゲートウェイのアーキテクチャと実際の操作」を 9 月に公開することを決定し、今月末にリリースされる予定です。そして、マンツーマンで履歴書指導を行い、あなたの履歴書を輝かせ、完全に変えます。

「第 33 章: 10Wqps の高同時実行 Netty ゲートウェイのアーキテクチャと実際の運用」ポスターは次のとおりです。

「第 33 章: 10Wqps の高同時実行 Netty ゲートウェイのアーキテクチャと実際の運用」と併せて、Nien はアーキテクチャおよび設計資料として、いくつかの産業グレードおよびプロダクショングレードのゲートウェイケースを整理します。

前に整理しました

上記の 3 つのケースに加えて、ここで Nien はもう 1 つの美しい実稼働レベルのケースを見つけました。

「iQiyi WebSocket リアルタイムプッシュゲートウェイ技術実践」、

注意してください。これは、もう 1 つの非常に優れた産業グレードおよび生産グレードのゲートウェイケースです。

これらのケースは Nien 独自のものではありません。これらの事例は、誰もが学び、コミュニケーションできるように、「第 33 章: 10Wqps の高同時実行性 Netty ゲートウェイのアーキテクチャと実際の運用」のコースの準備中に、インターネットで情報を検索しているときに Nien が収集したものです。

『Nien Architecture Notes』、『Nien High Concurrency Trilogy』、『Nien Java Interview Guide』の PDF は、公式アカウント [Technical Freedom Circle] から入手してください。

記事ディレクトリ

100Wレベルの接続、iQiyi WebSocketプッシュゲートウェイアーキテクチャ

原作者: iQiyi 技術チーム

HTTP プロトコルは、ステートレスな TCP ベースの要求/応答モデルプロトコルです。

HTTP プロトコルでは、クライアントのみがリクエストを開始でき、サーバーが応答します。

ただし、多くの場合、このリクエスト/レスポンスプルモデルで十分です。

ただし、リアルタイム通知(IM でのオフラインメッセージプッシュが最も一般的です) やメッセージプッシュアプリケーションシナリオなどの特定の状況では、データをリアルタイムでクライアントにプッシュする必要があり、そのためにはサーバーにデータをアクティブにプッシュする機能。

どうやって押し込むのか？

ショートポーリングやロングポーリングなどの従来の Web サーバープッシュ技術はこの問題をある程度解決できますが、適時性やリソースの無駄などの問題もあります。

HTML5 標準によって導入されたWebSocket 仕様はこの状況を根本的に変え、現在のサーバー側メッセージプッシュテクノロジの主流になりました。

この記事では、Netty に基づいた WebSocket 長時間接続リアルタイムプッシュゲートウェイの実装プロセスにおける iQiyi の実際の経験と概要を共有します。

1. 古いソリューションの技術的な問題点

当社のコンテンツエコシステムの重要な部分である iQiyi アカウントは、フロントエンドシステムとしてユーザーエクスペリエンスに対する高い要件を備えており、クリエイターの創造的な熱意に直接影響します。

現在、iQiyi アカウントは、次のような複数のビジネスシナリオで WebSocket リアルタイムプッシュテクノロジを使用しています。

1)ユーザーコメント: コメントメッセージをリアルタイムでブラウザにプッシュします。

2)実名認証: 契約前にユーザーは実名認証を受ける必要があり、ユーザーは QR コードをスキャンして第三者認証ページに入り、認証完了後、ブラウザに非同期で通知されます。認証ステータス。

3)生存認証：実名認証と同様に、生存認証が完了すると非同期でブラウザに結果が通知されます。

実際のビジネス開発において、WebSocketのリアルタイムプッシュ技術の利用にはいくつかの課題があることが分かりました。

これらの質問は次のとおりです。

1)第一に、WebSocket テクノロジースタックは統一されておらず、一部は Netty に基づいて実装され、一部は Web コンテナに基づいて実装されており、開発と保守に困難をもたらしています。

2)第二に、WebSocket の実装はさまざまなプロジェクトに散在しており、ビジネスシステムと密接に結合しているため、他の企業が WebSocket を統合する必要がある場合、開発の繰り返し、コストの無駄、効率の低下というジレンマに直面することになります。

3) 3番目: WebSocket はステートフルプロトコルであり、クライアントがサーバーに接続するときは、クラスター内の 1 つのノードにのみ接続し、データ送信中にこのノードとのみ通信します。WebSocket クラスターは、セッション共有の問題を解決する必要があります。単一ノードの展開のみを使用する場合、この問題は回避できますが、より高い負荷をサポートするために水平方向に拡張することはできず、単一点障害が発生するリスクがあります。

4)最後に: 監視と警報が不足している WebSocket のロング接続数は Linux Socket 接続数から大まかに推定できますが、その数は正確ではなく、ユーザー数などを知ることは不可能ですビジネス上重要な指標データであるため、統合された監視と警報を実現するために既存のマイクロサービス監視統合と比較することはできません。

2. 新しいソリューションの技術的目標

前述したように、古いソリューションに存在する問題を解決するには、統合された WebSocket の長時間接続のリアルタイムプッシュゲートウェイを実装する必要があります。

この新しいゲートウェイのセットには、次の特性が必要です。

1)長期接続管理とプッシュ機能を一元化: 統合されたテクノロジースタックを採用し、機能の反復とメンテナンスを容易にする基本機能として長期接続を促進します。

2)ビジネスからの切り離し: ビジネスロジックを長期接続通信から分離することで、ビジネスシステムは通信の詳細を気にする必要がなくなり、開発の繰り返しが回避され、研究開発コストが節約されます。

3)使いやすさ: さまざまな開発言語へのアクセスを容易にする HTTP プッシュチャネルを提供します。ビジネスシステムは、データをプッシュするために単純な呼び出しを行うだけでよいため、研究開発の効率が向上します。

4)分散アーキテクチャ: ビジネスの成長によってもたらされる課題に対応するための水平拡張をサポートするマルチノードクラスターを構築します。ノード障害はサービスの全体的な可用性に影響を与えず、高い信頼性を保証します。

5)複数端末のメッセージ同期: ユーザーが複数のブラウザまたはタブを使用して同時にオンラインにログインし、メッセージが確実に同時に送信されるようにします。

6)多次元監視と警報：既存のマイクロサービス監視システムにカスタム監視指標を接続し、問題発生時にタイムリーに警報を発し、サービスの安定性を確保します。

3. 新しいソリューションの技術選定

数多くの WebSocket 実装の中で、パフォーマンス、スケーラビリティ、コミュニティサポートなどの側面を比較検討した結果、最終的に Netty に落ち着きました。

Netty は、多くの有名なオープンソースプロジェクトで広く使用されている、高性能、イベント駆動型、非同期、ノンブロッキングのネットワーク通信フレームワークです。

WebSocket は HTTP のステートレスな特性とは異なるステートフルな特性を備えているため、HTTP のようなクラスタリングによる負荷分散を実現できません。長時間接続が確立されると、サーバー上のノードとのセッションが維持されるため、クラスター環境では、セッションがどのノードに属しているかを判断することが困難になります。

上記の問題を解決するには、一般に 2 つの技術的解決策があります。

1) 1 つは、マイクロサービスレジストリに似たテクノロジを使用して、グローバルセッションマッピング関係を維持することです。

2) もう 1 つはイベントブロードキャストを利用し、セッションを保持するかどうかを各ノードが判断する方法です。これら 2 つのオプションの比較を以下の表に示します。

WebSocket クラスターソリューション:

プラン	アドバンテージ	欠点がある
登録センター	セッションマッピングの関係は明確であり、クラスターサイズが大きい場合により適しています。	実装は複雑で、登録センターに大きく依存しており、追加の運用コストと保守コストがかかります。
イベント放送	実装がシンプルで軽量	ノードが多い場合、すべてのノードがブロードキャストされるため、リソースが無駄になります。

実装コストとクラスターサイズを考慮して、軽量のイベントブロードキャストソリューションを選択しました。

RocketMQ ベースのメッセージブロードキャスト、Redis ベースのパブリッシュ/サブスクライブ、ZooKeeper ベースの通知など、ブロードキャストを実装する方法は多数あります。

これらのオプションの長所と短所を以下の表で比較します。スループット、リアルタイム、永続性、実装の容易さなどの要素を考慮した結果、最終的に RocketMQ を選択しました。

ブロードキャスト実装ソリューションの比較:

プラン	アドバンテージ	欠点がある
RocketMQ に基づく	高スループット、高可用性、保証された信頼性	リアルタイムのパフォーマンスは Redis ほど良くありません
Redis ベース	高いリアルタイム性とシンプルな実装	信頼性が保証されていない
ZooKeeper に基づく	実装が簡単	書き込みパフォーマンスが低いため、頻繁に書き込みを行うシナリオには適していません

4. 新計画実現に向けた考え方

4.1 システムアーキテクチャ

ゲートウェイの全体的なアーキテクチャを次の図に示します。

注: 画像をクリックすると鮮明な画像が表示されます。

ゲートウェイの全体的なプロセスは次のとおりです。

**1)** クライアントがゲートウェイのいずれかのノードとの長い接続を確立すると、ノードはその接続をメモリ内の長い接続キューに追加します。クライアントは定期的にハートビートメッセージをサーバーに送信します。設定した時間が経過してもハートビートメッセージが受信されない場合は、クライアントとサーバー間の長時間の接続が切断されたとみなされ、サーバーは接続を閉じてメッセージをクリアします。記憶の中のセッション。

2)ビジネスシステムがクライアントにデータをプッシュする必要がある場合、データはゲートウェイが提供するHTTP インターフェイスを介してゲートウェイに送信されます。

3)プッシュリクエストを受信した後、ゲートウェイはメッセージを RocketMQ に書き込みます。

4)コンシューマとして、ゲートウェイはブロードキャストモードでメッセージを消費し、すべてのノードがメッセージを受信できます。

5)メッセージを受信した後、ノードはプッシュされたメッセージターゲットがメモリに保持されている長い接続キューにあるかどうかを判断します。存在する場合、データは長い接続を通じてプッシュされ、それ以外の場合は直接無視されます。

ゲートウェイは複数のノードを通じてクラスターを形成し、各ノードは負荷分散を実現するために長い接続の一部を担当します。多数の接続に直面する場合は、ノードを追加して圧力を分散し、水平方向の拡張を実現することもできます。

同時に、ノードに障害が発生すると、クライアントはサービス全体の可用性を確保するために、他のノードとの長い接続を再確立しようとします。

4.2 セッション管理

WebSocket の長時間接続が確立されると、セッション情報が各ノードのメモリに保存されます。

SessionManager コンポーネントはセッションの管理を担当し、内部でハッシュテーブルを使用して UID と UserSession の間の関連付けを維持します。

UserSession はユーザーレベルのセッションを表します。ユーザーは同時に複数の永続的な接続を持つことができるため、UserSession は内部でハッシュテーブルを使用して、Channel と ChannelSession の間の関連付けも維持します。

ユーザーが際限なく長い接続を作成することを防ぐため、UserSession 内の ChannelSession の数が一定数を超えると、最も早く確立された ChannelSession を閉じてサーバーリソースの占有を軽減します。

SessionManager、UserSession、ChannelSession の関係を次の図に示します。

SessionManager コンポーネント:

注: 画像をクリックすると鮮明な画像が表示されます。

4.3 監視と警報

クラスター内で確立された長時間接続の数と含まれるユーザーの数を把握するために、ゲートウェイは基本的な監視機能とアラーム機能を提供します。

ゲートウェイはMicrometerに接続され、接続数とユーザー数がPrometheusが収集するカスタムインジケーターとして公開されるため、既存のマイクロサービス監視システムとの統合が実現します。

Grafanaでは、接続数、ユーザー数、JVM、CPU、メモリなどの指標データを簡単に表示して、現在のサービス能力とゲートウェイの負荷を把握できます。データが異常な場合に Qixin (内部アラームプラットフォーム) アラームをトリガーするアラームルールを Grafana で設定することもできます。

5. 新しいソリューションのパフォーマンスストレステスト

圧力試験の準備：

1) 4 コアと 16G で構成された 2 つの仮想マシンを選択し、それぞれサーバーとクライアントとして機能します。
2) ストレステスト中に、ゲートウェイに対して 20 のポートを開き、同時に 20 のクライアントを起動します。
3) 各クライアントは 1 つのサーバーポートを使用して 50,000 の接続を確立し、数百万の接続を同時に作成できます。

接続数 (百万) とメモリ使用量を次の図に示します。

[root@sy-dev-1de4f0c2a target]# ss -s ; free -h
Total: 1002168 (kernel 1002250)
TCP: 1002047 (estab 1002015, closed 4, orphaned 0, synrecv 0, timewait 4/0), ports 0
Transport Total   IP      IPv6
*         1002250 -       -
RAW       0       0       0
UDP       4       2       2
TCP       1002043 1002041 2
INET      1002047 1002043 4
FRAG      0       0       0

          total   used    free  shared  buff/cache  available
Mem:      15G     4.5G    4.5G  232K    6.5G        8.2G
Swap:     4.0G    14M     4.0G

次の図に示すように、単一のスレッドを使用して数百万の長い接続にメッセージを同時に送信する場合、サーバーが送信を完了するまでにかかる平均時間は約 10 秒です。

サーバープッシュには時間がかかります:

2021-01-25 20:51:02.614 INFO [mp-tcp-gateway,54d52e7e4240b65a,54d52e7e4240b65a,false]
[600ebeb62@2559f4507adee3b316c571/507adee3b316c571] 89558 --- [nio-8080-exec-6]
c.i.m.t.g.controller.NotifyController: [] [UID:] send message ...
2021-01-25 20:51:11.973 INF0 [mp-tcp-gateway,54d52e7e4240b65a,54d52e7e4240b65a,false]
[1600ebeb62@2559f4507adee3b316c571/507adee3b316c571] 89558 --- [nio-8080-exec-6]
c.i.m.t.g.controller.NotifyController: [] [UID:] send message to 1001174 channels

一般に、同じユーザーが同時に確立する長い接続の数は 1 桁です。

以下の図に示すように、10 個の長い接続を例にとると、同時実行数 600、継続時間 120 秒の条件下では、プッシュインターフェイスの TPS は約 1600+ になります。

長時間接続 10、同時実行数 600、継続時間 120 秒のストレステストデータ:

現在のパフォーマンス指標は実際のビジネスシナリオを満たしており、将来のビジネスの成長をサポートできます。

6. 新たなソリューションの実践事例

最適化の効果をより鮮明に示すために、記事の最後では、カバー画像にフィルター効果を追加する例を取り上げ、新しい WebSocket ゲートウェイソリューションを使用した iQiyi アカウントの例を紹介します。

iQiyi セルフメディアがビデオを公開する場合、ユーザーがより高品質のカバーを提供できるように、カバー画像にフィルター効果を追加することを選択できます。

ユーザーがカバー画像を選択すると、非同期バックグラウンド処理タスクが送信されます。

非同期タスクが完了すると、さまざまなフィルター効果を適用して処理された画像が WebSocket 経由でブラウザに返されるビジネスシナリオは次の図のようになります。

研究開発効率の観点から、WebSocketを業務システムに組み込む場合、開発期間は少なくとも1～2日かかります。

新しいWebSocketゲートウェイのプッシュ機能を直接利用することで、シンプルなインターフェース呼び出しでデータプッシュを実現でき、開発時間を数分に短縮し、研究開発効率を大幅に向上させます。

運用保守コストの観点から見ると、ビジネスシステムにはビジネスロジックに関係のない通信の詳細が含まれなくなり、コードの保守性が向上し、システムアーキテクチャがシンプルになり、運用保守コストが大幅に削減されます。

7. まとめ

WebSocket はサーバーサイドプッシュの主流のテクノロジーであり、適切に使用すると、システムの応答性が効果的に向上し、ユーザーエクスペリエンスが向上します。

WebSocket の長時間接続ゲートウェイを介して、システムにデータプッシュ機能を迅速に追加し、運用とメンテナンスのコストを効果的に削減し、開発効率を向上させることができます。

長い接続ゲートウェイの値は次のとおりです。

1) WebSocket 通信の詳細をカプセル化し、ビジネスシステムから切り離します。これにより、長時間接続のゲートウェイとビジネスシステムが独立して最適化および反復できるようになり、繰り返しの開発が回避され、開発とメンテナンスが容易になります。
2) ゲートウェイは、シンプルで使いやすい HTTP プッシュチャネルを提供し、複数の開発言語へのアクセスをサポートし、システムの統合と使用を容易にします。
3) ゲートウェイは分散アーキテクチャを採用しており、水平方向の拡張、負荷分散、サービスの高可用性を実現できます。
4) ゲートウェイは監視と警報を統合しており、システムが異常な場合にはタイムリーに警告を発し、サービスの健全性と安定性を確保します。

現在、新しい WebSocket 長時間接続リアルタイムゲートウェイは、iQiyi アカウント画像フィルター結果通知や MCN 電子署名などの複数のビジネスシナリオに適用されています。

メッセージの再送信と ACK、WebSocket バイナリデータのサポート、マルチテナントのサポートなど、将来的に検討する必要がある側面は数多くあります。

最後に: 質問がある場合は、古いアーキテクチャにアドバイスを求めることができます。

建築の道は山あり谷あり

アーキテクチャは高度な開発とは異なります。アーキテクチャに関する質問はオープン/オープンであり、アーキテクチャに関する質問に対する標準的な回答はありません。

このため、多くの友人は多大なエネルギーとお金を費やしたにも関わらず、残念ながら一生のうちにアーキテクチャのアップグレードを完了することができません。

したがって、アーキテクチャのアップグレード/変革のプロセスにおいて、どうしても効果的な解決策が見つからない場合は、40 歳の建築家 Nien に助けを求めることができます。

少し前に、専攻を超えて Java に取り組んでいた友人がいて、現在、アーキテクチャの切り替えの問題に直面していますが、Nien からの数回の指導の後、無事 Java アーキテクト + ビッグデータアーキテクトの内定を獲得しました。したがって、キャリア上で困難に直面した場合は、経験豊富な建築家に助けを求める方がスムーズです。