Xiaomi における RocketMQ のマルチシナリオ災害復旧実践事例

著者: 鄧志文、王範

01 なぜ災害復旧なのか?

Xiaomi 社内では、RocketMQ を使用して、ショッピングモールの注文、SMS 通知などのさまざまなオンラインビジネスにメッセージキューサービスを提供し、IoT デバイスから報告されたデータを収集することもできます。RocketMQ の可用性は、これらのオンラインビジネスの生命線であると言えます。サービス。ソフトウェア開発者として、私たちは通常、サービスが理想的な状態で実行されることを望みます。バグがないことを前提として、システムは通常のサービス機能を提供できます。

しかし、実際の運用保守の経験から、これは不可能であることがわかります。ハードウェア障害は、メモリ障害、ディスク障害などの非常に一般的な問題であり、さらにはコンピュータ室関連の障害 (専用線の障害、コンピュータ室のシャットダウンなど) も含まれます。）。したがって、サービスの高可用性を確保するには、データをバックアップし、複数のコピーを使用する必要があります。Apache RocketMQ は、マスター/スレーブアーキテクチャや DLedger 導入モードなど、マルチコピーおよびマルチノードの災害復旧をサポートするように設計されています。

Xiaomi 社内では、オンラインビジネスを指向しているため、サービスの回復速度が非常に重要であり、Raft プロトコルに基づく DLedger モードは第 2 レベルの RTO を達成できるため、2020 年初頭には基本的な展開モードとして DLedger アーキテクチャを選択しました。 5.0、マスター/スレーブモードでも自動フェイルオーバーを実現できます)。コンピュータルームのディザスタリカバリのサポートには追加のコストが必要です。次に、ディザスタリカバリの導入の実際の 3 つの事例を使用して、Xiaomi がコストと可用性の観点からディザスタリカバリをどのようにサポートしているかを説明します。

02 災害復旧はどのように行うのですか?

単一コンピュータールームの高可用性

実際の使用では、単一のコンピュータルームの可用性を高めることができる限り、コンピュータルームレベルでのディザスタリカバリを必要としない企業が多くあります。Apache RocketMQ 自体は分散メッセージキューサービスであり、同じコンピュータルーム内の複数のノードの高可用性を実現できます。以下では主に、Xiaomi がコストと可用性を比較検討するという前提の下で展開アーキテクチャをアップグレードおよび最適化する方法を共有します。

Raft プロトコルでは通常 3 つのノードが構成され、マシンの冗長性 + 自動マスター選択切り替えを使用することで高可用性の目標が達成されることがわかっています。したがって、Xiaomi が RocketMQ を導入したとき、1 つのブローカーグループが 3 つのブローカーノードをデプロイしました。同時に、クラスター内に常にマスターノードが存在するようにするために、通常、少なくとも 2 つのブローカーグループをデプロイします。簡単なデプロイメントアーキテクチャ図は次のとおりです。

これは非常に基本的な展開アーキテクチャであると言え、単一のコンピュータルームでは、複数のコピーと複数のブローカグループによって単一のコンピュータルームのディザスタリカバリが実現されます。しかし、そうすることには資源の無駄という深刻な問題があることに気づくのは難しくありません。RocketMQ のスレーブノードは、クライアントが古いデータを読み取るときのみスレーブリーダーの役割を果たし、それ以外の場合は単にコピーとして実行され、マシン使用率はわずか 33% であり、耐えられないほどです。

コストを考慮すると、既存のデプロイメントアーキテクチャを再考する必要があります。スレーブノードをどのように使用できるでしょうか? 非常に単純なアイデアは、ノードを混合することです。ブローカープロセスをスレーブノードにデプロイして、マスターとして機能できるようにします。偶然にも、コミュニティは当時ブローカーコンテナの概念も提案しました. ソリューションの原則は、RocketMQ ブローカー上でコンテナの役割を抽象化することです. コンテナはブローカーの追加、削除、変更、クエリを管理するために使用され、複数のブローカーの目的、具体的なアーキテクチャ図は次のとおりです。

コンテナがプロセスとして実行され、元のブローカーがコンテナの一部として抽象化されていることがわかります。同じ 3 台のマシン上で 9 つのブローカーノードを実行して、3 つのブローカーグループを形成できます。各サービスにはマスターノードがあります。コンテナーがブローカーピアツーピアをデプロイした後、各サービスホストが利用され、理論的には同じ数のマシンで 3 倍のパフォーマンスを提供できます。

コンテナはデプロイメントの良いアイデアです。マスター/スレーブノードはピアツーピアでデプロイされ、すべてのマシンを最大限に活用します。このスキームを直接使用しようとしましたが、いくつかの問題が発生しました。

コンテナは本質的にプロセスです。実行されているブローカーの数に関係なく、再起動する限り、コンテナ内のブローカーに関連するすべてのブローカーグループに影響があり、アップグレードはより深刻な影響を及ぼします。
コンテナはブローカーのオンラインとオフラインを維持し、Xiaomi の内部展開ツールと組み合わせて使用することはできません。

したがって、コンテナは内部的には Xiaomi には適していませんが、Broker Container からインスピレーションを得て、別の同様の展開ソリューション、つまり複数のインスタンスを持つ単一マシンを提案します。いわゆる単一マシンのマルチインスタンスとは、複数の Broker インスタンスが 1 つのホストにデプロイされていることを意味します。サービスホストはコンテナであり、Broker はプロセスとして実行されます。このようにして、各 Broker は以前は相互に影響しません。また、社内導入ツールと完全に組み合わせることができます。単純なデプロイメントアーキテクチャは次のようになります。

これまでのところ、Xiaomi は RocketMQ 導入アーキテクチャの最初のアップグレードを内部で完了しており、クラスター内のノード数は 2/3 に直接削減されました。コストの最適化を前提として、99.95% の可用性保証を提供します。

マルチルーム災害復旧-Ⅰ

サービスへの継続的なアクセスに伴い、一部のサービスではコンピューター室の災害復旧の需要が高まっています。コンピュータ室での障害は発生確率が極めて低いものの、一度発生するとその影響は非常に大きくなります。たとえば、コンピュータ室の障害により RocketMQ が利用できなくなり、トラフィックエントリとして依存するすべてのサービスに影響を及ぼします。

複数のコンピュータ室でのディザスタリカバリに関して、私たちはまず、他の社内サービスの導入経験に基づいて、マルチクラスタおよびマルチアクティブのアプローチを提案しました。つまり、各アベイラビリティゾーンにクラスタをデプロイし、ビジネスのディザスタリカバリ用に複数のクラスタを提供します。ソリューション展開アーキテクチャは次のとおりです。

ユーザーには 3 つの独立したクラスターが表示されます。同じコンピュータルーム内の RocketMQ クラスターに対して読み書きするには、クライアントを同じアベイラビリティゾーンに展開する必要があります。例: アベイラビリティーゾーン 1 のクライアントは通常、アベイラビリティーゾーン 1 の RocketMQ クラスター Cluster-1 にアクセスします。Cluster-1 に障害が発生した場合、ユーザーはクライアントの接続アドレスを手動で変更してクラスターを切り替え、トラフィックを転送する必要があります。クラスター内の他のコンピューター室へ。ユーザーは構成を通じてホットアップデート接続アドレスを送信したり、構成を変更してクライアントを再起動して切り替えたりできますが、これらすべての操作の前提として、企業は RocketMQ クラスターの障害を認識する必要があり、手動でトリガーできます。

▷メリット

リージョン間でデータを同期する必要がなく、低レイテンシ (P99 書き込み 10ms) および高スループット (単一ブローカーグループ書き込み TPS 最大 100K)
シンプルな導入アーキテクチャと高い安定性

▷ デメリット

クラスターは、障害が発生したときに、生き残ったクラスターが障害が発生したクラスターのすべてのトラフィックを確実に伝送できるように、ディザスターリカバリーバッファーを予約する必要があります。
ビジネスは独自にクラスターを手動で切り替える必要がありますが、柔軟性が十分ではありません
消費が蓄積している場合、障害のあるクラスタのメッセージは消費されない可能性がありますが、回復後に消費できるようになります。

▷ 時間のかかる制作

マルチルーム災害復旧-Ⅱ

上記の方法でサービスにアクセスする場合、特定の適応作業を行う必要があることがわかりますが、このソリューションはトラフィックが多いサービスアクセスに適しています。ただし、低コストでアクセスできるようにしたい企業もあります。調整なしで SDK を直接使用してにアクセスし、DLedger の自動切り替え機能を組み合わせ、コンピュータルーム障害サービスの自動フェイルオーバーモードを実験的に導入しました。導入アーキテクチャは次のとおりです。

ユーザーに表示されるのは独立した RocketMQ クラスターであり、調整を行わなくても SDK を使用して通常どおりアクセスできます。コンピュータルームに障害が発生した場合、DLedger を利用してトラフィックスイッチングのためにマスターに自動的に切り替えます。

▷メリット

導入が簡単で、RocketMQ のネイティブ機能を最大限に活用できます。
自動マスター選択、便利なサービスアクセス、トラフィックを手動で切り替える必要なし

▷ デメリット

コンピューター室全体に展開されるため、ネットワークの変動に対して脆弱であり、クラスターのジッターが発生する可能性が高くなります。
コンピュータールーム全体に展開すると、書き込み遅延が増加し、クラスターのスループットが低下します。

▷ 時間のかかる制作

複数のコンピュータ室の災害復旧 - PLUS

現在、RocketMQ サービスは Xiaomi にうまく実装されており、毎日のメッセージ量は1,000 億の規模に達しているようですが、上記の 2 つのソリューションを注意深く観察した結果、フェールオーバーが発生しても、コンピュータ室の広さは達成できますが、どちらにも一定の欠点があります。概要は次のとおりです。

複数のコンピュータルームのディザスタリカバリ - I: 同じコンピュータルームからのリクエストは待ち時間が短いですが、クラスタ間で手動で切り替える必要があります。
複数のコンピュータ室のディザスタリカバリ - II: 自動フロー切り替えと履歴データの消費、ただし専用回線の負荷が高いため、展開には 3 つのリージョンが必要

ソリューションには常に不完全な点がありますが、サービス開発者であってもビジネスユーザーであっても、次の目標を達成することを前提としてディザスタリカバリを実現したいと考えています。

1) 低コスト: デュアルリージョンを展開できます。

2) 時間の消費が少ない: ネットワークの時間の消費を減らすために、できるだけ同じコンピュータルームからリクエストするようにしてください。

3) 自動フローカット：コンピュータ室に障害が発生した場合、自動的に通常のコンピュータ室にフローを切り替えることができます。

上記の要件を達成するために、RocketMQ 独自のアーキテクチャから始めて、最小限の変換コストで災害復旧をサポートしたいと考えています。クライアントは、Namesrv から返されたメタデータに基づいて生成および消費することがわかりました。クライアントがコンピュータルームで障害を起こしても、メタデータに従ってトラフィックを自動的に遮断できます。端末にはディザスタリカバリ機能がサポートされています。

すべての RocketMQ ブローカーは自身を Namesrv に登録します。ブローカーグループが失敗すると、その情報は Namesrv から削除され、クライアントはそのようなブローカーグループにメッセージを送信またはプルできなくなります。上記のロジックに基づいて、ブローカーグループを異なるコンピュータルームに展開する限り、コンピュータルームレベルで災害復旧効果を達成できます。導入アーキテクチャは次のとおりです。

上記のソリューションの実現可能性を説明するために実際の例を使用してみましょう。トピック A には 2 つのアベイラビリティゾーンにパーティションがあり、SDK は使用時に独自のリージョンを構成する必要があります。

プロデューサーの場合、クライアントは同じアベイラビリティゾーン内のパーティションにのみメッセージを送信します。例: アベイラビリティーゾーン 1 のクライアントは、アベイラビリティーゾーン 1 にのみメッセージを送信します。アベイラビリティーゾーン 1 に障害が発生すると、アベイラビリティーゾーン 1 には書き込み可能なパーティションがないため、アベイラビリティーゾーン 2 へのメッセージの送信が開始され、それによって本番側の自動送信が実現されます。切り落とす。コンシューマもリージョンを構成する必要があります。すべての消費インスタンスは、最初にアベイラビリティゾーンに従って再バランスされます。最初に、同じアベイラビリティゾーン内のコンシューマによってパーティションが割り当てられ、消費されます。アベイラビリティーゾーン 1 に障害が発生した場合、プロデューサーがトラフィックを遮断しているため、コンシューマーは消費フローを自動的に遮断するために特別な変更を行う必要はありません。

このソリューションは企業向けのオプションです。企業は災害復旧モードを有効にするかどうかを決定できるため、より柔軟です。前の 2 つのコンピュータルーム災害復旧ソリューションの利点を組み合わせていると言えますが、まだ課題があります。クラスターの障害期間中は、履歴メッセージを消費できず、ソリューションの最適化のためのフォローアップが継続されます。

03 まとめを作ろう！

この記事では、さまざまなビジネスニーズに応じて異なる展開モードを提供する 4 つの展開モードを紹介します。概要は次のとおりです。

現時点では、上記のソリューションは Xiaomi 内で特定のビジネスシナリオを持っており、メッセージ量が全体の約 90% を占めていますが、将来的には、残りのトラフィックに関連するすべてのクラスターがコンピュータールームのディザスタリカバリクラスターに段階的にアップグレードされる予定です。 99.99% の可用性サービス機能を提供します。