著者: vivo インターネットサーバーチーム - Yu Quan

本稿では、プッシュ型ディザスタリカバリ構築と主要な技術ソリューション、実践プロセスにおける考え方や課題について紹介します。

1. プッシュシステムの導入

vivo プッシュプラットフォームは、vivo が開発者に提供するメッセージプッシュサービスであり、クラウドとクライアントの間に安定した信頼性の高い長期接続を確立することで、開発者にクライアントアプリケーションへのリアルタイムプッシュメッセージサービスを提供します。数十億件の通知/メッセージプッシュが数秒でモバイルユーザーに到達します。

プッシュシステムは主にアクセスゲートウェイ、論理プッシュノード、永続接続で構成され、永続接続はユーザーの携帯電話端末との接続を確立し、適時に携帯端末にメッセージを送信する役割を果たします。

プッシュシステムは、高い同時実行性、大量のメッセージ、および高い配信適時性を特徴としています。

vivoプッシュシステムの現状では、最大プッシュ速度は140w/s、1日の最大メッセージ量は200億、エンドツーエンドの2次オンライン配信率は99.9％となっている。一方で、プッシュ方式は、事前に予測できない突発的な大トラフィックが発生するという特徴を持っています。プッシュシステムの高い同時実行性、高い適時性、バースト性の高いトラフィック特性を考慮すると、システムの可用性をどのように確保するか? この記事では、システムアーキテクチャ、ストレージディザスタリカバリ、トラフィックディザスタリカバリの 3 つの側面から、プッシュシステムがディザスタリカバリを行う方法について説明します。

2. システムアーキテクチャの災害復旧スキーム

2.1 長い接続層の災害復旧

永続的接続は、プッシュシステムの最も重要な部分です。永続的接続の安定性は、プッシュシステムのプッシュ品質とパフォーマンスに直接影響します。そのため、永続的接続には災害復旧機能とリアルタイムスケジューリング機能を提供する必要があります。層。

独自のプッシュシステムアーキテクチャでは、長期接続層が中国東部に配置され、すべての vivo IDC 論理ノードが VPC を介して中国東部のブローカーと接続を確立し、モバイル端末は長期接続を通じて中国東部のブローカーと通信します。接続。この展開方法には次のような問題があります。

問題 1:中国北部と南部の携帯電話は中国東部のブローカーに接続する必要があり、地理的範囲が広く、ネットワークの安定性と長期接続の適時性が比較的劣ります。
質問 2:論理層は VPC で華東の Broker と接続されていますが、ビジネスの発展に伴いプッシュトラフィックが増加し、帯域がボトルネックとなり過剰なパケットロスが発生するリスクがあります。さらに、VPC に障害が発生すると、ネットワーク全体のメッセージが配信されなくなります。

注: 長い接続層ノードの名前は Broker です。

元の長い接続アーキテクチャ図:

上記のアーキテクチャの問題点に基づいて最適化され、Broker は中国北部、中国東部、中国南部の 3 か所にそれぞれ配置されました。

中国北部、中国東部、中国南部のユーザーは、最も近いアクセス方法を使用します。

最適化されたアーキテクチャは、長時間接続ネットワークの安定性と適時性を保証するだけではありません。同時に、強力な災害復旧機能を備えており、華東および華南のブローカーはクラウドネットワークを介して華北のブローカーに接続され、華北ブローカーは VPC を介して vivo IDC に接続されます。中国北部、中国東部、または南部の地域でブローカークラスターまたはパブリックネットワークに障害が発生しても、ネットワーク全体のデバイスによるメッセージの送受信には影響しません。ただし、この方法には依然として問題があり、特定のエリアでブローカークラスタまたはパブリックネットワークに障害が発生した場合、そのエリアの一部のデバイスがプッシュメッセージを受信できなくなります。

3 か所に展開した後のアーキテクチャ図:

上記のような単一エリアの異常により、このエリアの一部の端末がプッシュメッセージを受信できなくなる問題に対し、リアルタイムのトラフィックスケジューリングとスイッチングを実現するトラフィックスケジューリングシステムを設計しました。グローバルスケジューラノードは、ポリシーのスケジューリングと管理を担当します。

Vivo Phone が登録されると、ディスパッチャーは複数の地域の IP アドレスを配信し、デフォルトでは最も近い接続が確立されます。複数の接続に失敗した後は、他の IP への接続を試みます。リージョン内のブローカーに長時間接続のボトルネックがある場合、または VPC に障害が発生した場合、グローバルスケジューラーノードは、障害のあるリージョン内のデバイスがディスパッチャーから新しい IP セットの IP を取得できるようにするポリシーを発行できます。他のリージョンのブローカーとの長い接続を確立し、ノードは再接続されたブローカーにメッセージを送信します。エリアが回復したら、ストラテジーを再発行してコールバックを行うことができます。

フロースケジューリングシステム図:

2.2 論理層の災害復旧

長い接続層が災害復旧を行った後、論理層も対応する災害復旧を行う必要があります。以前は、ロジック層が 1 つのコンピュータルームに展開されており、コンピュータルームのようなディザスタリカバリ機能がなかったため、1 つのコンピュータルームで停電のリスクが発生すると、サービス全体が利用できなくなりました。「同一都市内アクティブ・アクティブ」展開計画の転換。

ロジック層のシングルアクティブアーキテクチャ:

ロジック層はそれぞれ生体内 IDC1 と生体内 IDC2 に展開され、ゲートウェイ層は一定の比率に従ったルーティングルールに従ってトラフィックを 2 つの IDC に分散し、ロジックの同じ都市でのデュアルアクティブを実現します。層。データセンターはまだ 1 つだけであり、これは in vivo IDC1 に展開されていることがわかりましたが、複数のデータセンターのコスト、収益、データ同期の遅延を考慮すると、当面はデータセンターは依然として 1 つのデータセンターが主流です。

ロジック層のアクティブ/アクティブアーキテクチャ:

3. 交通災害復旧ソリューション

システムアーキテクチャの災害復旧機能が適切に機能した後、プッシュシステムのゲートウェイ層は、突発的なトラフィックに対処し、トラフィック制御を適切に実行し、システムの安定性を確保するために対応する措置を講じる必要があります。これまで、ホットスポットやニュース速報イベントにより、同時プッシュトラフィックが膨大になり、その結果、異常なサービスが発生し、可用性が低下しました。

突然の大規模なトラフィックにどのように対処し、突然のトラフィックの状況でもシステムの可用性が変わらないことを保証し、同時にパフォーマンスとコストを考慮する方法。この目的を達成するために、次の 2 つのスキームをそれぞれ比較して設計しました。

従来のソリューションは、バーストトラフィックに対処するために、過去の推定に基づいて多数の冗長マシンを展開することでした。この方法だけではコストが高く、バーストトラフィックは 5 分以内しか持続しないため、5 分間のバーストトラフィックに対応するには、システムに多数の冗長マシンを導入する必要があります。トラフィックが導入マシンが耐えられる上限を超えると、容量を時間内に拡張できなくなり、可用性の低下や雪崩現象が発生する可能性があります。

従来のソリューションの下でアーキテクチャをプッシュします。

では、コストを管理し、突然の大規模なトラフィックに直面しても容量を柔軟に拡張し、メッセージが漏洩しないようにし、プッシュパフォーマンスを考慮できるソリューションを設計するにはどうすればよいでしょうか?

最適化ソリューション：独自のアーキテクチャをベースに、アクセス層にバッファチャネルを追加し、トラフィックのピークが到来すると、システムが処理できる上限を超えたトラフィックをバッファキューに投入します。メッセージキューの形式では、メッセージキューの消費速度を制限するためにバイパスアクセス層が追加されます。トラフィックのピークが過ぎたら、バイパス消費速度を上げ、キャッシュされたキューメッセージを処理します。バイパスアクセスレイヤーは Docker を通じてデプロイされ、動的な拡張と縮小をサポートし、デフォルトでクラスターを最小化します。メッセージキューのバックログがあり、ダウンストリームがそれらを処理する能力がある場合、消費速度が向上します。バイパスは容量を動的に拡張します。 CPU 負荷に応じてメッセージキューを急速に消費します。加工後の動的収縮。

メッセージキュー：スループットの大きなKAFKAミドルウェアを選択し、リソースを最大限に活用できるオフラインコンピューティングのKAFKAクラスタと共有します。

バイパスアクセスレイヤー: Docker を使用してデプロイされ、CPU の負荷と時間に応じた動的な拡張と縮小をサポートします。デフォルトの最小限のクラスター展開。既知のトラフィックのピーク時間については、サービスを事前に拡張して、高速なトラフィック処理を確保できます。未知の時間帯にトラフィックがピークに達した場合、アクセス層をバイパスし、CPU 負荷に応じて容量を動的に拡張および縮小できます。

キャッシュキューを追加した後のプッシュアーキテクチャ:

上記の変換後も、アクセス層でグローバル速度制御をどのように実装するかという問題がまだ残っています。当社では、下流のプッシュノードのプッシュトラフィックを収集し、例えばトラフィックがシステムが耐えられる上限の80％に達した場合、速度制限コマンドを発行してアクセス層のプッシュ速度を調整する方法を採用しています。最初にメッセージをメッセージキューにバックログさせ、ダウンストリームトラフィックが減少した後でレート制限を解放するコマンドを発行し、バイパスアクセス層がメッセージキューの消費を加速してプッシュできるようにします。

速度制御を追加した後のプッシュアーキテクチャ:

最適化されたスキームと従来のスキームの比較:

4. ストレージ災害復旧ソリューション

同時トラフィック制御を適切に実行した後は、ホットスポットを事前に解放する良い方法になる可能性があります。Push システム内では、Redis クラスターを使用してメッセージをキャッシュするため、Redis クラスターの障害によりメッセージの配信が間に合わないという問題が発生していました。したがって、システムが時間内にメッセージをプッシュし、Redis クラスターの障害時にメッセージが失われないようにするために、Redis クラスターに関連する災害復旧ソリューションの設計を検討します。

プッシュメッセージ本文は Redis クラスターにキャッシュされ、プッシュ時に Redis からメッセージ本文が取得されます。Redis クラスターがクラッシュしたり、メモリ障害が発生した場合、オフラインメッセージ本文は失われます。

元のメッセージフロー:

解決策 1:別のピアツーピア Redis クラスターを導入し、プッシュ二重書き込み方式を採用し、2 つの Redis クラスターを二重書き込みします。このソリューションには、同じ規模のスタンバイ Redis クラスターの冗長デプロイが必要です。プッシュシステムでは、Redis の二重書き込み操作が必要です。

解決策 2:元の Redis クラスターは、RDB+AOF を使用して別のスタンバイ Redis クラスターに同期されます。このソリューションでは、プッシュシステムの二重書き込み Redis 変換は必要なくなり、元の Redis クラスターデータを直接使用して、別のスタンバイ Redis クラスターに同期されます。同じ規模の冗長 Redis クラスターをデプロイすることも必要です。データ同期に遅延が発生し、プッシュが失敗する可能性があります。

解決策 3: Redis プロトコルと互換性があり、永続化機能を備えた別の分散ストレージシステムであるディスク KV を適用します。メッセージ本文が失われないことが保証されます。ただし、コストを節約するために、Redis クラスターのピアリソースは直接使用されなくなりました。しかし、プッシュの特性に応じて、プッシュは単一プッシュとグループプッシュに分けられます。シングルプッシュは 1 対 1 のプッシュであり、ユーザーごとに 1 つのメッセージ本文が含まれます。グループプッシュは 1 対多のプッシュであり、1 つのメッセージ本文が複数のユーザーに対応します。グループツイートは多くの場合、タスクレベルのプッシュです。したがって、比較的小さなディスク KV クラスターを使用します。これは、主に冗長ストレージとグループプッシュメッセージ本文、つまりタスクレベルのメッセージに使用されます。単一プッシュの場合、冗長ストレージなしで Redis にのみ保存されます。

Redis クラスターに障害が発生した場合、単一のプッシュメッセージについては、プッシュシステムがメッセージ本文を搬送してダウンストリームにプッシュし、メッセージの配信を継続できるようにします。グループプッシュメッセージの場合、メッセージ本文がディスク KV に冗長的に保存されるため、Redis クラスターに障害が発生した場合、ディスク KV を読み取るためにダウングレードできます。

解決策 3 にはまだ問題があり、ディスクの書き込みパフォーマンス KV (特に待ち時間) が Redis クラスターの書き込みパフォーマンスと同じ桁ではなく、平均ディスク KV は約 5 ミリ秒です。Redis クラスターは 0.5 ミリ秒です。プッシュシステムでグループプッシュメッセージ本文を二重に書き込んだ場合。この遅れは容認できません。したがって、ディスク KV に非同期に書き込む方法のみが使用可能です。ここでは、グループプッシュメッセージ本体がバックアップされ、最初にメッセージミドルウェア KAFKA に書き込まれ、バイパスノードは KAKFA を消費してディスク KV に非同期に書き込みます。このようにして、ディザスタリカバリディスク KV リソースの使用量が少ないことを前提として、プッシュシステムの高い同時実行能力が保証されると同時に、グループプッシュメッセージ本体が失われることはありません。メッセージにはプッシュするメッセージ本文が含まれており、グループプッシュメッセージ本文が読み取られます。ディスク KV を取得します。

ストレージ災害復旧ソリューションの比較:

V. まとめ

本稿では、プッシュ型システムのディザスタリカバリ構築プロセスを、システムアーキテクチャディザスタリカバリ、トラフィックディザスタリカバリ、ストレージディザスタリカバリの3つの側面から説明します。システムの災害復旧は、ビジネスの展開、費用対効果、実装の難易度に基づいて検討する必要があります。

現在、長期接続層は 3 か所に展開されており、論理層は同じ都市内にアクティブ/アクティブがあり、データセンターは単一のデータセンターです。今後もデータセンターのデュアル化の検討・計画を継続し、2箇所に3センターを展開し、プッシュ型システムの災害復旧機能を段階的に強化していきます。

災害復旧構築とvivo Pushシステムの実践