この記事は、Huawei Cloud コミュニティ「リモート マルチアクティブ シナリオにおける Sermant の実践」、著者: Huawei Cloud Open Source から共有されたものです。
Sermant コミュニティは、リモート マルチアクティブ シナリオにおけるフロー切断とデータ整合性保護の問題を解決するために、メッセージ キュー消費禁止プラグインをバージョン 1.3.0で、データベース書き込み禁止プラグインをバージョン 1.4.0 で順次リリースしました。この記事では、リモートのマルチアクティビティ シナリオにおける Sermant の実践を分析します。
1. もっと違う場所に住もう
1.1 異なる場所に住むとは何ですか?
ソフトウェア システムの場合、システムに障害が発生しても、通常どおり外部にサービスを提供できることが望まれます。このソフトウェア システムの機能は高可用性と呼ばれ、リモート マルチアクティブ アーキテクチャは高可用性の問題を解決するために使用されます。 。
初期のシステム アーキテクチャは一般に単一マシン アーキテクチャであり、データベースに障害が発生すると、ビジネスが長期間中断される可能性があります。この問題を解決するために、データベースはマスター データベースとスレーブ データベースで構成され、マスター データベースは読み取りと書き込みの操作を担当し、スレーブ データベースはマスター データベースのデータのみを提供します。データの一貫性と整合性を維持するために、リアルタイムでスレーブ データベースに同期されます。メインライブラリに問題が発生した場合、スレーブライブラリはメインライブラリに切り替えて動作を継続します。ただし、これらのサービスは同じコンピュータ ルームまたは同じキャビネットに展開されており、コンピュータ ルームに障害が発生すると、システムは通常の外部サービスを提供できなくなります。
現時点では、1 つの都市に 2 つのコンピュータ室を配置し、同じソフトウェア環境を展開してサービスを提供する、同じ都市内でのアクティブ/アクティブが適切なソリューションとなっています。いずれかのコンピュータ ルームに障害が発生した場合、トラフィックを別のコンピュータ ルームに切り替えて実行を継続し、システムの高可用性を確保できます。図 1 に示すように、コンピュータ ルーム 1 のデータベースはメイン データベースであり、2 つのコンピュータ ルームのすべての書き込み操作はコンピュータ ルーム 1 のメイン データベースで実行され、読み取り操作はこのコンピュータ ルームのデータベースを読み取ることができます。 2 つのコンピュータ ルーム間の物理的な距離は比較的近いため、2 つのコンピュータ ルームはネットワーク接続に専用回線を使用できるため、異なるコンピュータ ルームからのサービス呼び出しのネットワーク遅延は低くなります。コンピュータ室 2 からコンピュータ室 1 のデータベースまでは許容範囲内です。
図 1: 同じ都市内のデュアルアクティブ アーキテクチャ図
同じ都市内のアクティブ/アクティブ アーキテクチャにより、ソフトウェア システムの高可用性の問題は解決されますが、地震や洪水などの自然災害が都市で発生した場合、同じ都市に展開されているすべてのコンピュータ ルームは依然として残ります。破損し、サービスの提供を停止する場合があります。また、これらの災害は非常に破壊的なものであるため、システムの修復サイクルは比較的長くなり、企業の通常の業務運営に重大な影響を与えることになります。この場合、これらのコンピュータ室を異なる地域に配置する必要があることは明らかですが、同時に、これらの地域の地理的距離は、自然災害のリスクに耐えられるように十分に離れている必要があります。これが、その起源と価値です。リモートマルチアクティブアーキテクチャ。
上の図に示すように、コンピュータ ルーム 1 とコンピュータ ルーム 2 が 2 つの都市に配置されている場合、リスクに対抗するために、コンピュータ ルームを複数の地域に配置することができます。 active-active はリモートの active-active にアップグレードされます。
リモート マルチアクティブのアーキテクチャ図を図 2 に示します。クライアント トラフィックは、ルーティング層を通じて、実行のためにさまざまな地域のコンピュータ ルームに分散されます。同一都市のアクティブ/アクティブ アーキテクチャとの違いは、異なる地域のコンピュータ ルームが物理的に離れていることです。そのため、専用のネットワーク回線を導入するコストは膨大であり、異なるコンピュータ ルーム間のアクセスのネットワーク遅延は無視できません。データベースはローカルのコンピュータ室で操作する必要があります。コンピュータ室を越えて操作することはできません。マルチアクティブリモートアーキテクチャでは、各コンピュータ室のデータベースがメインデータベースであり、異なるコンピュータ室のデータは中央コンピュータ室に同期され、次に中央コンピュータ室から他のコンピュータ室に同期されます。すべてのコンピュータ ルームのデータベースに書き込むことができるため、異なるコンピュータ ルームが同じデータを変更すると、必然的にデータの競合が発生します。データの競合を解決するために、ルーティング層のフラグメンテーション ポリシーに従って、一部のトラフィックを特定のコンピュータ ルームに固定的に転送できます。トラフィック フラグメンテーション ポリシーは、ビジネス タイプまたは地理的位置に基づいています。トラフィック シャーディングにより、同じユーザーからの関連リクエストが同じコンピューター ルームにルーティングされてすべての業務が完了することが保証され、コンピューター ルーム内のトラフィックはローカル コンピューター ルーム内でのみ流れることが保証され、ネットワーク遅延が短縮されます。
図 2: リモート マルチアクティブ アーキテクチャ図
1.2 異なる場所での複数のアクティビティの一般的なシナリオ
リモートマルチアクティブアーキテクチャは、異なる地域にコンピュータルームを配置し、自然災害によるリスクに対抗する外部サービスを提供するための有効な手段です。ただし、リモート マルチアクティブ アーキテクチャはシステムをより複雑にし、障害遮断とデータの一貫性の点で新しい要件を導入します。
- クラウド サービスのシナリオでは、可用性ゾーンで障害が発生した場合、障害ゾーンのコンシューマーは消費するメッセージのプルを停止する必要があり、同時に、割り当てられたメッセージ キューは、処理のために通常の可用性ゾーンのコンシューマーに再バランスされます。ビジネス例外の発生を避けるため。
- リモート マルチアクティブは、トラフィックをシャーディングすることでデータの一貫性の問題を効果的に解決できます。ただし、製品数量などのグローバルデータについては、データ書き込みの際、中央計算機室のグローバルデータベースのみ操作が許可されます。一般に、グローバル データを操作するためのトラフィックは中央コンピュータ ルームにルーティングされる必要があり、他のコンピュータ ルームはデータベースの読み取りのみが許可されます。トラフィックが誤ってルーティングされると、中央ではないコンピューター室のデータベースにトラフィックが書き込まれ、データの競合が発生する可能性があります。現時点では、グローバル データベースに保護を追加し、中央コンピュータ室以外での書き込み操作の実行を禁止する必要があります。
上記 2 つの代表的な問題に対し、サーマントではメッセージキュー消費禁止プラグインとデータベース書き込み禁止プラグインを開発し、それらに対応したプラグインを以下に詳しく紹介します。
2. メッセージキューはプラグインの使用を禁止します
2.1 メッセージキュー消費禁止プラグインの紹介
メッセージ キュー消費禁止プラグインを使用すると、実行状態での実際のニーズに応じて、マイクロサービスがコンシューマーによるメッセージ キュー ミドルウェアの消費動作を動的に調整できるようになり、異常な環境や状態においてもビジネス処理プロセス内のメッセージが適切に管理され、不要なメッセージが回避されるようになります。ビジネスへの影響。たとえば、リモートのマルチアクティブ アーキテクチャ システムで、地域的な障害が発生し、トラフィックを遮断する必要がある場合、障害が発生したアベイラビリティ ゾーンでメッセージ キューの消費禁止機能を有効にし、通常のアベイラビリティ ゾーンのコンシューマを許可できます。ビジネスを処理し、障害領域がトラフィックを消費してビジネス異常を引き起こすことを回避し、システムの高可用性を確保します。障害が処理された後、消費を再開できます。
メッセージ キュー消費禁止プラグインは現在、Kafka と RocketMQ の 2 つのメッセージ ミドルウェアをサポートしています。 Kafka 側では、プラグインはトピックレベルの消費禁止と回復機能を実装します。 RocketMQ の場合、消費制御の粒度はコンシューマ インスタンス レベルです。 Sermant は、構成センターを通じて使用を禁止する必要があるメッセージ キュー タイプと特定のトピックの発行をサポートしています。
消費キュー禁止プラグイン、設定手順、シーンデモの詳細については、公式 Web サイトのドキュメントメッセージキュー消費禁止 を参照してください。
2.2 メッセージキュー消費禁止プラグイン障害およびフロー遮断シナリオの適用
アプリケーション シナリオ: ソフトウェア システムは Kafka をメッセージ キューとして使用し、プロデューサーはトピック テスト トピックへのメッセージを生成します。トピック メッセージには 4 つのパーティションが含まれます。アベイラビリティーゾーン A とアベイラビリティーゾーン B にはそれぞれ、テストコンシューマーグループに参加してトピックテストメッセージを消費する 2 つのコンシューマーがあり、アベイラビリティーゾーン A とアベイラビリティーゾーン B は異なるリージョン、つまり異なる場所に分散されます。コンピューター室がさらに 2 つあります。以下に示すように。
このシナリオでは、コンシューマ サービスが Sermant のメッセージ キューをマウントして消費プラグインの実行を無効にした後、コンシューマが消費するトピックをリアルタイムで制御できるため、ビジネス処理プロセス内のメッセージが確実に適切に管理されます。異常な環境や状態。
アベイラビリティ ゾーン A に障害が発生した場合、アベイラビリティ ゾーン A のコンシューマは消費を停止する必要があります。アベイラビリティーゾーン A でグローバル構成を発行して、コンシューマー A とコンシューマー B がトピックテストトピックを使用することを禁止し、割り当てられたメッセージキューを解放します。
メッセージキュー消費禁止プラグインの構成は以下の通りです。enableKafkaProhibitionはKafkaキュー消費禁止機能を有効にすることを意味し、kafkaTopicsは消費を禁止するサブスクリプショントピックを指定します。設定の配信方法については、公式 Web サイトのドキュメント「メッセージ キューの使用を禁止する」を参照してください。
EnableKafka禁止: true 頭蓋骨トピック: - トピックテスト
構成が配信された後、次の図に示すように、アベイラビリティ ゾーン A のコンシューマは消費を停止し、アベイラビリティ ゾーン B のコンシューマはトピック - テスト トピックのパーティションを再割り当てします。
アベイラビリティー・ゾーン A が通常に戻った後、動的構成センターを介して構成を再度発行して、コンシューマー A と B がトピック・テスト・トピックを使用できるようにすることができます。消費構成の配信を有効にすると、Kafka によって再バランスがトリガーされ、可用性ゾーン A および B のコンシューマーにパーティションが再割り当てされます。
メッセージキュー消費禁止プラグインは、リモートマルチアクティブシナリオにおけるメッセージキューの障害遮断機能を実現し、システムの可用性を確保します。
3. データベース書き込み禁止プラグイン
3.1 メッセージキュー消費禁止プラグインの紹介
データベース書き込み禁止プラグインをマウントしてサービスを開始すると、指定したデータベースに対する書き込み禁止機能を動的に有効または無効にできます。リモートのマルチアクティブ シナリオでは、ユーザーは個別またはすべてのデータベースへの書き込み操作を停止し、データの読み取りのみを許可して、データベース システムのデータの整合性、一貫性、セキュリティを確保したいと考えています。たとえば、ビジネス データベースへのグローバル データの書き込みは、中央コンピュータ ルームでのみ許可されます。データベース書き込み禁止プラグインを有効にすると、複数の拠点にある非中央コンピュータ ルームのデータベースへのルーティング異常トラフィックの書き込みは失敗します。マルチ書き込みシナリオの場合、ストリームのコンピュータ ルームは、まずデータベースへの書き込みを禁止し、他のコンピュータ ルームでのデータ同期が完了するのを待ってからストリームを切断します。上記のシナリオでデータベース書き込み禁止プラグインを使用すると、データベース データの整合性が保証されます。
データベース書き込み禁止プラグインは現在、MySQL、MongoDB、PostgreSQL、OpenGauss データベースをサポートしています。マイクロサービスの実行中に、書き込み禁止のデータベースの種類と名前を構成センターを通じて発行できます。書き込み禁止に対応した具体的な書き込み操作やプラグインの使用方法については、公式サイトのドキュメントデータベース書き込み禁止を参照してください。
3.2 データベース書き込み禁止プラグインによるデータ整合性アプリケーションの保護
アプリケーション シナリオ: マルチアクティブ リモート アーキテクチャでは、ビジネス マイクロサービスを使用して製品在庫などのグローバル データを変更します。同時に、グローバル データは global という名前の MySQL データベースに保存されます。このグローバル データについては、中央コンピュータ ルームのグローバル データベースに対してのみ書き込み操作が許可され、他のコンピュータ ルームにあるグローバル データベースはデータの読み取りのみが可能です。データの一貫性を確保するために、グローバル データが変更されると、トラフィックはルーティング層で実行するために中央のコンピューター ルームにルーティングされ、他の読み取り操作は、次の図に示すように任意のコンピューター ルームにルーティングできます。
ルーティング層がグローバル データを書き込むトラフィックに対してルーティング エラーを発生し、それを非中央コンピュータ ルームで実行する場合、中央コンピュータ ルームと非中央コンピュータ ルームが同じ製品の数量を同時に変更すると、データ競合が発生する可能性があるため、ビジネス マイクロサービスは Sermant のデータベース書き込み禁止プラグインをマウントして、中央以外のコンピュータ ルームのグローバル データベースへの書き込みを禁止できます。
グローバル データベースへの書き込みは、中央コンピュータ室以外では禁止されており、次の構成は動的構成センターを通じて発行する必要があります。
EnableMySqlWriteProhibition: true mySqlデータベース: - グローバル
このうち、enableMySqlWriteProhibition は MySQL データベースへの書き込みを禁止する機能を有効にすることを意味し、mySqlDatabases は特定の書き込み禁止データベースの名前を指定するために使用されます。この例はグローバル データベースです。
構成発行後、非中央計算機室のグローバルデータベースに異常なルーティングのトラフィックが書き込まれると、データベース書き込み禁止プラグインがビジネスマイクロサービスにjava.sql.SQLException例外をスローし、データベースへの書き込みを禁止します。 。ビジネス システムは、システムの正常な動作を保証するために、実行のためにトラフィックを中央コンピュータ ルームに再ルーティングするための再試行操作を追加するなど、この例外を処理する必要があります。実行ロジックを次の図に示します。
データベース書き込み禁止プラグインは、リモート マルチアクティブ シナリオでの指定されたデータベースへの書き込みを無効にします。これにより、異常なトラフィック書き込み操作を防止し、異なるコンピューター ルームのデータベースでのデータの一貫性を確保できます。
4. まとめ
リモート マルチアクティブ シナリオでは、Sermant のメッセージ キュー消費禁止プラグインは、可用性ゾーンに障害が発生した場合のメッセージ キュー フローの遮断の問題を認識し、通常の可用性ゾーンのコンシューマがデータベース書き込み禁止プラグインでデータを消費できるようにします。指定されたデータベースへの書き込みを禁止するために使用され、データの競合を防ぐためのデータベースの読み取りには影響しません。
Sermant は、リモートのマルチアクティビティ シナリオで豊富なサービス ガバナンス機能を実現しました。今後も、より完全なサービス ガバナンス機能システムを徐々に構築するために努力を続けます。
サービス ガバナンスの分野に焦点を当てたバイトコード拡張フレームワークとして、Sermant は、高パフォーマンス、スケーラブル、アクセスしやすく、機能が豊富なサービス ガバナンス エクスペリエンスを提供することに尽力し、パフォーマンス、機能、エクスペリエンスに配慮します。どのバージョンでも、どなたでも広くご参加いただけます。
- サーマント 公式サイト：https://sermant.io
- GitHub ウェアハウスのアドレス: https://github.com/huaweicloud/Sermant
クリックしてフォローし、できるだけ早くHuawei Cloudの新しいテクノロジーについて学びましょう~
1990 年代生まれのプログラマーがビデオ移植ソフトウェアを開発し、1 年足らずで 700 万以上の利益を上げました。結末は非常に罰的でした。 高校生が成人式にオープンソースプログラミング言語を自作―ネチズンの鋭いコメント： 詐欺横行でRustDesk依存、国内サービスの タオバオ（taobao.com）は国内サービスを一時停止、ウェブ版の最適化作業を再開 Java最も一般的に使用されている Java LTS バージョンは 17 、Windows 11 は減少し続ける Open Source Daily | Google がオープンソースの Rabbit R1 を支持、Microsoft の不安と野心; Electricがオープンプラットフォームを閉鎖 AppleがM4チップをリリース GoogleがAndroidユニバーサルカーネル(ACK)を削除 RISC-Vアーキテクチャのサポート Yunfengがアリババを辞任し、将来的にはWindowsプラットフォーム用の独立したゲームを制作する予定