マイクロサービスの高可用性災害復旧アーキテクチャ設計

OSC があなたをパーティーにご招待します! 1028蘇州園創立協会、AI時代の宝物を探しましょう

導入

過去のモノリシックまたは SOA アーキテクチャと比較して、マイクロサービスアーキテクチャの構築に依存するコンポーネントが変化したため、高可用性の災害復旧アーキテクチャソリューションを分析および設計するためのアイデアも変化しました。この記事では、マイクロサービスアーキテクチャの実装におけるいくつかの一般的な問題について説明します。 . 災害復旧および高可用性ソリューションの分析。

著者について

Liu Guanjun は、Tencent クラウドミドルウェアセンターアーキテクチャグループの責任者であり、
IT 業界で 15 年の経験を持つエキスパートエンジニアであり、最初の勤務先は IBM 中国研究所で、かつては IBM メインフレームミドルウェアの研究開発ディレクターを務めていました。現在、彼は Tencent Cloud のエキスパートエンジニアであり、ミドルウェアセンターアーキテクチャチームの責任者であり、ミドルウェア製品センターアーキテクトチームと PaaS プラットフォーム製品のプリセールス業務を担当しています。合計 16 件の特許認可を取得しており、トランザクション処理、Web サービス、マイクロサービス、メッセージキュー、銀行アーキテクチャに関する豊富な経験を持ち、国内外の多くの大規模および中規模の顧客をサポートしてきました。

概要

SOA アーキテクチャと比較して、マイクロサービスアーキテクチャは分散型アプローチを使用してビジネスアプリケーションを編成します。サービス間の通信はバスを経由する必要はありません。サービスルーティングのロジックは各マイクロサービスに送信されて、それ自体で完了します。一方で、マイクロサービスアーキテクチャは、サービスガバナンス、アプリケーションの展開、監視などの機能を実装するための集中コンポーネントとも切り離すことができず、マイクロサービスシナリオでのアクティブ/スタンバイやマルチアクティブなどの高可用性災害復旧ソリューションの設計には、次のことが必要です。総合的な検討。

複雑な災害復旧アーキテクチャを分析する前に、明確な結論を得るために、まず問題を明確に定義し、問題を分解し、サブ問題を分解し、さまざまな側面から個別に議論する必要があります。アクティブ/スタンバイやアクティブ/アクティブなどの高可用性モードについて説明する場合、異なる高可用性モードはアプリケーション、データベース、登録センターなどのコンポーネントに対して異なる意味を持ちますが、各コンポーネントは相互に関連しています。著者の意見では、完全なマイクロサービスアーキテクチャコンポーネントには次の 3 つの側面が含まれています。

マイクロサービス管理および制御層: 分散アーキテクチャによってもたらされる複雑さのため、関連する分散サポートコンポーネントを導入する必要があります。

アプリケーションライフサイクル管理コンポーネント: アプリケーションのリリース、ロールバック、柔軟なスケーリング、およびフェイルオーバーを担当します。マイクロサービスアーキテクチャには、展開、運用および保守機能に対するより高い要件があり、企業は配信機能を自動化する必要があります。これらのコンポーネントは、ビジネスの実行時間にほとんど影響を与えません。
サービスガバナンスコンポーネント: サービス登録の検出、サービス構成、サービスルーティングなどの分散ガバナンス機能を担当します。最もよく知られているコンポーネントはサービス登録センターです。登録センターは、サービスのヘルスチェックを実行し、サービス内の異常なインスタンスを削除する責任を負います。したがって、災害復旧モードでは、ネットワーク要件が比較的高くなります。ネットワークが不安定な場合、ヘルスチェックが不正確になりやすくなります。大規模なサービスインスタンスの変更通知が頻繁に発生すると、システムの安定性に影響を及ぼします。
監視コンポーネント: 可観測性の 3 つの主要コンポーネント (トレース、ログ、メトリクス) の収集を担当します。最下層では ES または時系列データベースがよく使用されます。このコンポーネントによって要求されるデータ量が比較的大きいため、ネットワークトラフィックのコストは高くなります。計画と展開の際に考慮してください。

アプリケーション層: 導入の難しさを軽減するために、アプリケーションは可能な限りステートレスである必要があります。
データ層: 現在、ほとんどのアプリケーションはリレーショナルデータベースを使用しています。リレーショナルデータベースの現在の技術レベルでは、複数のインスタンスと複数の書き込みを十分にサポートできないため、データベースのアクティブモードとスタンバイモードについてのみ議論できます。重要な点は、アクティブモードとスタンバイモードの自動化です。スタンバイスイッチングとデータレプリケーションの遅延により、障害回復の RTO と RPO がそれぞれ短縮されます。

メインとバックアップが同じ都市にある

同じ都市内のアクティブ/スタンバイはデュアル AZ で展開されることが多く、AZ 間の距離は規制要件を満たす必要があります。デュアル AZ では、1 つのプライマリ AZ のみが外部にサービスを提供し、もう 1 つのスタンバイ AZ はバックアップとして使用されるため、多くの場合、少量のリソースの導入のみが必要になります。

導入計画:

マイクロサービス管理および制御層: TSF には 1 つのマスターと 1 つのバックアップがあり、サービスの登録と検出、アプリケーションのリリース、監視などはすべて AZ の閉ループです。
アプリケーション層: アプリケーションにはマスターとバックアップが 1 つあり、バックアップセンターにはメインセンターのすべての論理アプリケーションが含まれており、アプリケーションのコピー数を削減できます。
データベース層: 1 つのマスターと複数のスレーブ、強力な同期レプリケーション、TDSQL を使用した RPO と RTO は 0 に達し、アプリケーションを意識せずに切り替えることができます。

アプリケーション層の異常分析

アプリケーション層でいくつかの異常なシナリオを分析します。

1. 単一のマイクロサービスインスタンスの障害: マイクロサービスは複数のインスタンスでデプロイする必要があり、単一の AZ でフォールトトレラントにすることができます。

2. 特定のマイクロサービスのすべてのインスタンスが失敗する考えられる理由は 2 つあります。

アプリ自体のコードに問題があります。アプリをロールバックするか、修正してください。
特定のマイクロサービスのすべての物理インスタンスが失敗する: IaaS レイヤーノードのアンチアフィニティを使用して、インスタンスをラック間で可能な限り分散してデプロイします。

3. AZ 全体のすべてのインスタンスが失敗します。この場合、バックアップ AZ が全体として有効になり、ユーザートラフィックが切り替えられます。

マイクロサービス管理と制御層の異常分析

TSF マイクロサービスの管理および制御層は、次の 2 つのレベルに分割できます。

リリース時コンポーネント: 主にアプリケーションのリリース機能に影響します。コンポーネントの障害は、アプリケーションのリリースとロールバックに影響しますが、アプリケーションの動作には影響しません。TSF コンポーネント自体はステートレスであり、アプリケーションの動作に影響を与えることなく複数のインスタンスにデプロイできます。最下層は MySQL データベースのマスター/スレーブ展開に依存しており、単一障害点を回避するために AZ 全体に個別に展開できます。
ランタイムコンポーネント: 2 つのレベルに分かれています

監視コンポーネントとログ記録コンポーネント: すべての障害は監視データの収集に影響しますが、アプリケーションの動作には影響しません。コンポーネント自体はステートレスであり、複数のインスタンスにデプロイできます。基盤となる ES/Redis は非リレーショナルデータベースで、アクティブ/スタンバイ/シャーディングモードでデプロイできます。単一障害点を回避するために AZ 全体に個別にデプロイできます。
サービス登録センター: この障害は、新しいサービスの登録と構成配信に影響します。TSF はアプリケーション内でローカルにキャッシュメカニズムを設計しました。登録センターが利用できない場合でも、アプリケーションはサービス間呼び出しを開始できます。コンポーネントは、1 つのマスターと複数のスレーブモードで consul クラスターを使用してデプロイされます。

TSF 制御側の高可用性の詳細な分析については、後続の一連の特別記事を参照してください。

データベース層の異常分析

データベースがシングルポイントであるため、単一の AZ 内で単一ポイントのダウンタイムが発生する可能性がありますが、障害が発生した場合は、同じ AZ または同じ都市のバックアップノードに切り替えることができます。 - TDSQL のマルチスレーブモードでは、TDSQL は自動 IP フェイルオーバーを実装することもできます。アプリケーションは認識しません。

同じ都市内でのライブアクティブサービス

ユーザーのすべての業務システムは2つのデータセンターで同時に稼働し、同時にユーザーにサービスを提供しており、一方のAZのアプリケーションシステムに障害が発生した場合でも、別のAZのアプリケーションがサービスを提供し続けます。

導入計画:

マイクロサービス管理および制御層: TSF アクティブ/アクティブ展開。グローバルに統合された登録センターがあり、ネットワーク遅延の要件があります。
データベース層: 1 つのマスターと複数のスレーブ。マスターノードは 1 つの AZ にのみ存在するため、データベースにアクセスするアプリケーションは AZ をまたぐ可能性があります。そのため、データスキューによるパフォーマンスの消費を削減するには、AZ 間のネットワーク遅延を低くする必要があります。
アプリケーション層: ステートレスサービスは、同時に外部の世界にサービスを提供します。アクティブ-アクティブの前提は、マイクロサービス管理層と制御層がアクティブ-アクティブであり、データベースのクロス AZ レイテンシーが低いことです。

データベース層の高可用性展開モードは依然として 1 つのマスターと複数のスレーブであり、後でデータベース層で例外分析が実行されることはありません。

アプリケーション異常分析

アプリケーション層でいくつかの異常なシナリオを分析します。

1. AZ 全体がダウンしている: GSLB やクロス AZ LB などのテクノロジーを使用して別の IP に切り替え、同時にこの機能層により負荷分散を実現できます。
2. マイクロサービス間の呼び出しの災害復旧: TSF は、AZ 内の最近接ルーティングと、AZ 内のインスタンスが使用できない場合の AZ 間の呼び出しをサポートします。

マイクロサービス管理と制御層の異常分析

現在、TSF は、クロス AZ VIP (顧客または TCS/TCE によって提供される) に基づいて、登録センターなどのコンポーネントを別の AZ に自動的に切り替える機能を実装しており、単一の AZ に障害が発生した場合、アプリケーションは何もせずに別の AZ の制御側を自動的に切り替えます。意識。

2 つの場所と 3 つのセンター

2か所3センターは、同一市内アクティブ/アクティブ+遠隔ディザスタリカバリを基本として構築されており、高可用性と災害バックアップ機能を兼ね備えています。デュアルセンター向け遠隔都市データバックアップ自然災害やその他の理由によりデュアルセンターに障害が発生した場合、リモートの災害復旧センターはバックアップデータを使用してビジネスを復旧できます。

全体的なアーキテクチャは、同じ都市内でアクティブ/アクティブとアクティブ/スタンバイを組み合わせたものです。

導入計画:

マイクロサービス管理および制御レイヤー: 同じ都市でのアクティブ/アクティブ展開と遠隔地での災害復旧それぞれのデータを同期する必要はなく、独自のサービスの管理と制御のみを担当します。
データベース層: 1 つのマスターと複数のスレーブ、同じ都市での TDSQL の強力な同期、異なる場所での非同期レプリケーション。
アプリケーション層: ステートレスサービスは外部へのサービスも同時に提供し、メインセンターに障害が発生すると、イングレスルートをリモートのバックアップセンターに切り替えます。

もっと違う場所に住もう

異なる場所でのマルチアクティビティの前提は、アーキテクチャが 2 つの場所で 3 つのセンターを実現でき、水平シャーディングがデータベースレベルで行われ、ビジネスアプリケーションがグループ内のデータベースシャードにバインドされることです。遠隔地でのマルチアクティブ化により、障害の範囲が 1 つのシャードに縮小され、データベースの複雑さが軽減されます。このアーキテクチャは通常、非常に大量のデータを扱う国立銀行/保険会社に使用されます。

ソリューションはリモート相互バックアップとユニット化の2種類に分かれており、以下に分けて紹介します。

リモートでの準備

データベースレベルは 2 つのインスタンスシャードに水平に分割されます。たとえば、リージョンごとに北と南に分割できます。

導入計画:

マイクロサービス管理層と制御層: 同じ都市内でアクティブ/アクティブサービスを提供しますが、異なる場所では相互運用できません。
アプリケーション層: 異なるデータシャードを持つアプリケーションは遠隔地でアクティブ/アクティブになり、同じデータシャードを持つアプリケーションは同じ都市でアクティブ/アクティブになり、リモートの災害復旧が提供されます。
データベース層: データシャーディングには 1 つのマスターと複数のスレーブがあり、異なるシャードが異なる場所にレプリケートされます。

災害復旧切り替え戦略: 南部の都市全体に障害が発生した場合、入り口で DNS が実行され、南部のユーザーのアクセス IP が北部に切り替えられます。

ユニット化

一般に、データ量が大きすぎて、データベースシャーディングモードを使用するだけでは問題を解決できない場合は、ユニット化されたアーキテクチャの使用を検討できます。まず、ユニットの定義を明確にします。ユニットとは、コンピューティングリソースのグループとデータリソースのグループを論理的に結合したものです。設計の重要なポイントは次のとおりです。

1. シャーディング: ボリュームとビジネスを考慮し、パーティション化戦略を選択し、ユニット間の呼び出しを避けるようにしてください。
2. 導入ユニットの設計: 災害復旧設計を検討し、ユニットをデータベースシャードにバインドし、同じ都市にアクティブ/アクティブユニットを配置し、遠隔地に災害復旧ユニットを導入します。
3. ルーティング: TSF は、ゲートウェイ入口またはサービス入口でユニット化されたルールを計算し、リクエストを識別し、条件に従って後続のリクエストを同じユニットにルーティングし、ユニットをまたぐときにゲートウェイ経由でそれらのリクエストを呼び出す機能を提供します。

導入計画:

マイクロサービス管理および制御層: ゲートウェイはユニット化される場合があるため、グローバルサービス登録センターが必要です。
アプリケーション層: 各リージョンにはすべてのユニットシャードが含まれます。異なるデータシャードを持つアプリケーションは、異なる場所でアクティブ/アクティブにすることができます。同じデータシャードを持つアプリケーションは、同じ都市でアクティブ/アクティブにすることができ、リモートの災害復旧が可能です。
データベース層: データシャーディングには 1 つのマスターと複数のスレーブがあり、異なるシャードが異なる場所にレプリケートされます。

ユニット例外分析:

リージョン全体のフェイルオーバー: トラフィック全体が別のリージョンに切り替えられます。
リージョン内の単一ユニットのフェイルオーバー: アプリケーションコード自体の問題は別として、ユニットは物理的に同じ都市内の複数のセンターに展開されているため、都市内のすべてのユニットがダウンすることは基本的に不可能です。

ユニット化に基づく遠隔地での複数の活動

異なる場所での複数の生活の概念の明確化:

問題の原因: ユニット化されたアーキテクチャにおけるもう 1 つの中心的な考慮事項は、異なる場所での複数のアクティビティの実現を容易にすることです。従来のローカルアクティブ/アクティブおよびリモートディザスタリカバリアーキテクチャには、広く批判されている問題があります。それは、リモートディザスタリカバリリソースが、実際にはほとんどの時間ビジネスに役立っていないということであり、購入して展開した後も、しばらくアイドル状態のままであるということです。長い間戦いに参加していない戦士のようなもので、国の軍人給の無駄遣いだ。リソースの利用率を向上させるために、多くの顧客、特に金融顧客は、遠隔地にあるリソースがトラフィックの一部を共有し、ビジネスを正常に処理できるように、さまざまな場所でのマルチアクティブ構造をさらに追求しています。
ここで私たちは、異なる場所に住むという概念を正しく理解することに注意を払う必要があります。異なる場所での複数のアクティビティは、すべてのサービス (すべてのアプリケーションとすべてのデータを含む) が同時にリージョン A とリージョン B に存在できることを意味するわけではありません (2 つの場所は数百キロメートル離れており、災害復旧の規制要件を満たしています)。、これは、一部のビジネスの処理がリージョン A で行われ、その一部がリージョン B で処理されていることを意味します。完全にアイドル状態のリージョンはありません。なぜなら、前者のアプローチは技術的にも経済的コストの点でも高価すぎるからです。
ユニット化は、さまざまな場所でのマルチアクティビティをサポートします。ユニット化アーキテクチャでは、データが単位で断片化されて処理されるため、異なるユニットが異なる領域で処理されます。当然のことながら、異なる場所で複数のアクティビティを実行し、マシンリソースを最大限に活用するという上記の目標は達成されます。各地域は個別のユニットでビジネスを処理しますが、アプリケーションとデータのリモート災害復旧機能を他のリモートユニットに提供する災害復旧センターとしても機能します。

現在、TSF 製品はユニット化機能を実現していますが、同時にユニット化とリモートマルチアクティビティの需要を達成するために、TSF は最新バージョンでクロスリージョンのマルチクラスタ相互検出と相互アクセスの機能を実装しています。、下の図に示すように。

TSF の現在の登録センターはまだ Consul であり、Consul クラスタは CP モードであるため、実装原則は地域をまたいだグローバル登録センターに基づいていません。CP モードには情報同期の遅延に関する高い要件があり、 Consul クラスターは、マルチノードの高可用性を備えた同じ都市にのみ展開できます。リモートに展開することはできません。したがって、現在の TSF のリモートアクセスでは、ユニットゲートウェイアドレッシングモードが採用されており、ユニットゲートウェイは、リモートサービスが配置されている別のユニットゲートウェイを探し、それを Consul アクセス (ステートレスフロント) に基づいてクラスタの Consul 登録センターにプルします。エンドレイヤー). サービスノードを取得して、リージョン間のサービスアクセスを実現します。ゲートウェイ経由の転送の利点は、ユニットが十分に密閉され、アクセスリンクが明確で、問題を簡単に追跡できることです。欠点は、サービスジャンプの数が増加し、応答時間が増加することです。
将来的には、TSF 登録センターは、情報を保存するためのデータベースマスター/スレーブ方式に基づく AP モード登録センターである Polaris 登録センターに統合され、地域を越えたグローバル登録センターとしてより適切に機能できるようになります。

要約する

上記はマイクロサービスアーキテクチャに基づいており、各層の高可用性ソリューションを分析しています。各層の高可用性アーキテクチャの設計は相互に補完的です。各高可用性ソリューションの下にある層の機能が不足している可能性があります。望ましい目標を達成できません。TSF は、これまでにご紹介したさまざまな高可用性アーキテクチャをさまざまな業界のお客様に導入し、豊富な経験を蓄積してきました。一般に、アーキテクチャ設計はトレードオフの問題です。完璧な解決策はありません。一方で、シンプルさの原則に従う必要があります。アーキテクチャ設計がシンプルであればあるほど、実装は容易になり、操作のコストは低くなります。法規制要件や導入状況、業務データ量などの需要と客観的な条件を組み合わせて、適切な選定を行います。解決。