クラウドネイティブ時代のエンタープライズマルチアクティブ災害復旧システムを構築するためのアイデアとベストプラクティス

[[409884]]

クラウド ネイティブの概念を解釈するときに、マイクロサービスやコンテナについてよく耳にします。では、これらのテクノロジーと企業の災害復旧にはどのような関係があるのでしょうか?実際、災害復旧の需要はあらゆる分野に存在します。例えば、金融業界でも災害復旧に対する需要は強いです。しかし、災害復旧機能とマルチアクティブ機能をどのように構築するかは、実際にはすべての企業が慎重に検討する必要があることです。この共有が、あなたにとって関連性のあるアイデアを提供できることを願っています。

災害復旧システム機能の進化

今日お話ししているマルチアクティブ システムは、実際には災害復旧システムの一部です。災害復旧システム アーキテクチャ全体の進化を見てみましょう。

ディザスタリカバリ 1.0: 元のアプリケーション システムの構築中、ビジネス システムは従来のアーキテクチャに基づいてコンピュータ ルームに展開されました。では、適切な緊急対策やトラブルシューティング方法は何でしょうか?この期間中は、主にコールド バックアップの形式で、データのバックアップのみが検討されました。サービスを提供するコンピュータ室に加えて、災害シナリオを考慮して追加のコンピュータ室が構築される場合があります。システム構築の観点からは、別のコンピュータ ルームを使用して別のコンピュータ ルームにデータを同期し、コールド バックアップや問題発生時の切り替えを行うこともできます。しかし、現実には、コンピュータルームを変更することを選択する人は多くありません。毎年、災害復旧システムの定期的な訓練を実施している金融業界でさえ、生産プロセス中にシステム障害が発生すると、切り替えに消極的になります。

ディザスタリカバリ 2.0: アプリケーションをさらに考慮します。たとえば、クラウド ネイティブや従来の IOE システムの上位アプリケーションでは、切り替えは元のコールド スタンバイ データをロードするための単純な切り替えではなく、切り替え時にアプリケーションを別のコンピュータ ルームですばやく引き上げることができることが期待されます。あまり遅延せずにデータ層でのレプリケーションを実現するには、通常、デュアルアクティブ要件があります。ただし、アクティブ/アクティブ展開には通常、いくつかの要件があります。たとえば、同じ都市内でのアクティブ/アクティブ展開は、一定の距離範囲内でのみ実現できます。アクティブ/アクティブは、AQ モードでより一般的に使用されます。つまり、すべてのサービスは運用側で実行され、その他のサービスは別のコンピューター ルームで実行されます。

ディザスタリカバリ 3.0: 複数のアクティブ/アクティブ ロケーションを実現したいと考えています。さらに何がありますか?つまり、コンピュータ ルームは 2 つに限定されず、3 つ以上必要になります。たとえば、アリババのビジネスは複数のコンピューター ルームに分散されています。外部のビジネスサポートを同時に提供するには、対応する技術サポートが必要です。マルチサイト アクティブ アクティブの意味は、今日のコンピュータ ルームが全国に展開されているため、200 キロメートルや同じ都市などの距離に限定されません。

事業継続性と災害復旧の概要

実際には、ビジネス継続性に対する体系的なアプローチがあり、これは災害復旧システムの構築において長年にわたって蓄積されてきた仕様とガイダンスを参照します。いくつかの次元があります:

1. マルチアクティブ サービスは、別のコンピュータ ルームにある同じサービスを直接引き継ぐという本来の災害復旧とは異なり、価値のあるサービスを選択するものです。災害復旧システムの構築において、コスト面、技術面から、すべての業務に対してマルチアクティブ性を実現することは非常に困難です。

2. リアルタイム性を確保するためには、コンピュータ室の停電などさまざまな理由によりコア業務が停止しないようにする必要があります。

3. Mはセキュリティシステムを表します。現在、あらゆる分野にはそれぞれ異なる手段や管理方法がありますが、アリババが提供するのは、これらのものをテクノロジー、ツール、製品に変換することで、将来誰もがマルチアクティブ機能を構築するときに、この一連の方法と製品に基づいてマルチアクティブビジネスを迅速に構築できるようにすることです。

BCM システムと IT 災害復旧機能は、実用的なガイド フレームワークです。完全性という点では、事業継続性が最優先の目標であり、その下にさまざまな実装方法があります。下部には、例えばIT計画や事業継続において発生する特殊な問題への対処計画などが表示されます。これらは災害復旧の際に考慮されていましたが、マルチアクティブの観点から製品システムでも考慮されています。

ここで説明したいくつかの災害復旧方法は、実際には非常に一般的です。同じ都市でのコールド スタンバイからアクティブ/アクティブ、同じ都市でのアクティブ/アクティブに加えて別の場所でのコールド スタンバイ (2 つの場所に 3 つのセンター) などです。これらは業界では比較的標準化された方法です。マルチサイト アクティブ/アクティブは、2 つの場所にある 3 つのセンターの 3 つのコンピューター ルームでマルチサイト アクティブ機能を提供するようなものです。これは以前のものに基づいていますが、従来の災害復旧とは多少異なります。マルチアクティブの建設コストも従来のものとは異なります。たとえば、異なる場所にマルチアクティブを構築する場合の建設コストは、従来のもの（同じ都市にデュアルアクティブ、2 つの場所に 3 つのセンターなど）よりも高くなります。

マルチアクティブ機能を構築する際には、実際のビジネス状況が実際に考慮されます。例えば、業種が異なったり、多能性の観点から両面読み取りのみが必要な場合、構築コストや業務切り替えにかかる時間などが状況によって異なってきます。水平タイムラインの観点から見ると、マルチサイトのアクティブ/アクティブ機能は数分で切り替えることができますが、コールド スタンバイに基づいている場合は、切り替えに数日かかる場合があります。

アリババはなぜそんなに多くの仕事をするのでしょうか?

Alibaba のビジネス モデルにおいて、複数のアクティビティを実行する必要がある理由は、上記で述べたものと同様です。前述の同一都市コールドスタンバイの場合、マルチアクティブを採用しないと、別のコンピュータ室を構築する必要があり、そのコンピュータ室は日常的なデータ同期にのみ使用され、稼働していないため、非常にコストがかかります。この期間中、本番システムと災害復旧システムの対応するバージョンを継続的に更新する必要があります。しかし、実際には、元のコールドスタンバイまたは 2 サイト 3 センター システムに障害が発生した場合、切り替えた後に元に戻せない可能性が非常に高いため、人々はあえて切り替えません。

より多くの作業を行うための主な要求は 3 つあります。

1. リソース。今日のビジネスの急速な発展により、単一サイトのリソース容量は限られています。クラウド ネイティブとクラウド コンピューティングは、高可用性と災害復旧機能を提供することがわかっています。ただし、クラウド コンピューティングは異なるコンピュータ ルームに展開されます。地域間マルチアクティブ機能自体には、基盤となるインフラストラクチャのサポートが必要です。当社は、物理的なコンピュータルームの制限を超えて事業を拡大し、複数のコンピュータルームで同時に業務を処理できるようにしたいと考えています。

2. ビジネスには多様なニーズがあり、ローカルまたはリモートでの展開が必要です。

3. 災害復旧イベント用。例えば、光ケーブルが掘り起こされたり、気象条件によりコンピュータ室の電源や放熱に問題が生じたりした場合、単一のコンピュータ室で障害が発生する可能性があります。今日の需要は、単一のコンピュータルームに限定されるものではなく、ビジネスモデルに応じて柔軟に調整できる、全国各地にさまざまな形態で複数のコンピュータルームを展開することです。

こうした需要にはマルチアクティブ機能に対する緊急の必要性があるため、アリババは自社のビジネスニーズと技術力に基づいてマルチアクティブソリューションと製品を開発しました。

マルチアクティブアーキテクチャの解体

マルチアクティブアーキテクチャの解体

1. リモート バックアップ: 今日、クラウド ネイティブの素晴らしさやクラウド コンピューティングの素晴らしさについて、誰もが話題にしています。マルチアクティブ機能がなければ、これらのテクノロジーは実際にはアイドル状態になります。コールドスタンバイ状態では動作せず、コールドスタンバイに切り替える状態は主に人間の判断に依存します。報告のエスカレーションはビジネスに大きな影響を与えるため、より成熟した顧客は、どのような影響や障害がこのような切り替えを必要とするかなど、何らかの緊急時対応計画を立てますが、実際には、コールド スタンバイ モードに基づいて、あえて切り替えを行わないのが一般的です。

2. 同一都市内でのアクティブ-アクティブモード：一定の距離制限があります。上位層では共通のアクティブ-アクティブ モードが適用されます。たとえば、クラウドネイティブの PaaS レイヤーを両方のコンピュータ ルームに分散できます。データレベルでは、同じ都市にあるため、バックアップ方式を使用できます。メインコンピュータ室に問題が発生した場合、データベースはバックアップコンピュータ室に切り替えられます。ただし、両方のコンピュータ ルームのマシンとリソースがアクティブな状態にあるという利点があります。また、コンピュータルームがアクティブな状態であれば、本番バージョンとバックアップコンピュータルームバージョンの違いを気にする必要がなく、切り替えを恐れる必要もありません。

3. 2つの拠点と3つのセンター：同じ都市でサービスを提供するという課題を考慮すると、障害への対応力が強化されます。コールドスタンバイコンピュータルームは別の場所に構築されます。これは最初のコールド スタンバイ ソリューションに似ています。コールド スタンバイ コンピュータ ルームは通常は使用されず、他の同期が行われる場合があります。切り替えは障害が発生した場合にのみ行われます。

4. マルチサイト アクティブ-アクティブ: 複数のデータセンターが同時に外部にサービスを提供することができます。距離の制限により、データ レベルでのレプリケーションがネットワークによって制限され、遅延の問題が発生する可能性があります。北京データセンターから上海データセンターに素早く切り替える方法や、物理的な制限により基盤となるデータが完全に同期されていない場合にどのように切り替えるかなど、解決すべき技術的な問題が数多くあります。私たちの運用モードは、元の災害復旧方法に切り替えるようなものではなく、多くの準備作業とその後のデータ補償プロセスを実行する必要があります。このシステムを製品システムに統合します。物理的な限界を突破することはできないため、アーキテクチャモデルを使用して最適化します。

プログレッシブマルチアクティブ災害復旧アーキテクチャ

重要なコアビジネスについては、複数のアクティブなシステムやプロジェクトに取り組む際に、実際にビジネスの整理を行います。今日は単位ベースのソートについてお話します。

プログレッシブマルチアクティブ災害復旧アーキテクチャ

二重読み取り、2 つの場所、3 つのセンター。一般的に言えば、2 つのコンピューター ルームは最大で均等に分割できます。これは最も簡単な方法です。このモデルによれば、銀行がカード番号やユーザーの所在地に応じて業務を半分に分割するのと同じように、ユーザー番号に応じて業務を分割するためのルールを見つけることができます。マルチアクティブ構成では、柔軟に構成できることを期待しています。たとえば、コンピュータ ルームの処理能力と発生した障害の種類に基づいて、トラフィックを 50%、60% などの比率に調整できます。トラフィック アクセスを均一に分散できる複数のコンピュータ ルームでも同様です。

技術的には、リモート相互バックアップは一方向のデータ複製であり、リモート アクティブ アクティブは双方向のデータ複製です。双方向とは、2 つのコンピュータ ルームのいずれかで問題が発生した場合に、2 つのコンピュータ ルーム間で切り替えることができることを意味します。ここで非常に重要な側面は技術的な実装です。デジタルレベルでは、循環複製の問題を回避する方法を見つける必要があります。データが同期されると、別のコンピューター ルームはそれを新しいデータだと認識してコピーし直すことができなくなります。複数のコンピュータ室がある場合、従来の方法はデータベース内のシリアル番号を使用することです。マルチアクティブ システムでは、シリアル番号はグローバルに一意であるルールに従って生成する必要があり、単一のコンピュータ ルームではなくクラスター全体に基づきます。複数のコンピュータ ルームで生成されたシリアル番号は重複できないことを考慮する必要があり、この問題を解決するには製品にいくつかのルールが必要です。

マルチアクティブ災害復旧ソリューション

マルチアクティブ製品ソリューションのアーキテクチャ図

1. アクセス層:マルチアクティブで最初に解決する必要があるのは、非常に重要なトラフィック アクセス層です。アクセス層はアクセスルールを非常に細かく制御できます。業務セグメンテーションのルールに従って、下位層の各コンピュータ ルームに正確にマッピングする必要があります。トラフィックが流入したら、トラフィック ユーザーにどのコンピュータ ルームでサービスを提供するかを決定する必要があります。これは実際にはどのように達成されるのでしょうか?

従来の方法はドメイン名の切り替えです。たとえば、フロントエンド ドメイン名には 2 つのコンピューター ルームがあります。切り替える場合はドメイン名アドレスが切断されます。すると、業務全体はもともとコンピュータルーム A に接続されていましたが、ドメイン名を介して別のコンピュータルーム B に切り替えることができます。このアプローチの問題点は、実行中のビジネスに影響を及ぼすことです。たとえば、コンピュータ室で問題が発生した場合、すぐに別のコンピュータ室に業務を切り替える必要があります。ドメイン名が切り替わると、最下層で継続中の業務に影響が出てしまいます。さらに、この最下位レベルの切り替えは、クラウドネイティブの PaaS レイヤー全体とリンクすることはできません。上位層が切り替わっても下位層はそれを認識できず、以前のトラフィックが別のコンピュータ ルームに切り替わったことを認識しません。途中の通話は、元のコンピュータ ルーム ユニット内で行われる可能性があります。これは実際にビジネスの継続性に大きな影響を与えます。このモデルは、極端なケースではいくつかの問題を解決できます。たとえば、1 つのコンピュータ ルームで業務を処理できず、バックアップ コンピュータ ルームがある場合は、ドメイン名をそのコンピュータ ルームに切り替えることが 1 つの解決策です。

もう 1 つの方法は、クラウドネイティブのマイクロサービスを使用することです。マイクロサービス内のトラフィックをマークし、そのマークをクラウドネイティブのマイクロサービス テクノロジー システムに渡すことができます。リクエストが特定のユニットまたはコンピュータ ルームで行われたように見せかけ、他のコンピュータ ルームにジャンプしないようにします。

2. アプリケーション層:この中間層のアクセス ルーティング仕様には、サービス ルーティング コンポーネントが含まれており、当社の製品システムで個別に提供できます。たとえば、ソリューションの中間層で使用されているすべてのオープンソース コンポーネントを所有しているため、完全なソリューションは使用したくないが、マルチアクティブ機能も実現したいというお客様もいます。次に、上位層はマルチアクティブ制御フロー全体を使用して、論理ユニットの数を正確に定義し、中間呼び出し用の API を提供できます。グローバルに一意のシリアル番号、ルーティング ルール、およびシャーディング ルールはすべて、前のレイヤーによって提供されます。これらのうち、ラベル付けとトラフィックの識別は比較的簡単なようです。実際、たとえば、マルチアクティブ シナリオでは、分割と分離で使用される一部の分散メッセージや、アーキテクチャで使用されるメッセージが、特定のコンピュータ ルームで完全に消費されずに切り替えられた場合、どのようにして別のコンピュータ ルームに同期できるでしょうか。このような問題は、クラウド ネイティブの助けを借りて解決する必要があります。

3. データ層:コピーと書き込みのロジックが含まれます。私たちのソリューションの書き込みブロック制御にはデータベース上のロジックがあり、つまり、フロントエンドで切り替えが発生すると、コードが自動的に生成されます。例えば、切り替え先のコンピュータ室のデータが復元されると、タイムコードが自動的に生成され、データが復元された場合にのみ書き込みアクションが再度解除されます。書き込みを禁止することでデータベースの保護とデータベース遅延の判定を確実に行います。基盤となるデータ同期機能が十分に強力でない場合、切り替えとほとんどの業務は引き続き実行できますが、データベースが書き込みブロック ルールによって制限されるため、多くの書き込み業務が実行できない可能性があります。さらに、複数のデータセンターのロジックに基づくデータ同期ルールとレプリケーション要件には、より高度な全体的な制御ルールがあります。

ソリューションシステム全体に基づいて、私たちはコンセプトを提案しました（上図参照）。4文字の略語MSHAは、今日のクラウドネイティブでマルチアクティブ製品を提供する能力を表しています。私たちは、0、1、5、10 分の予防という 4 つの数字に少しでも貢献したいと考えています。

一つ目は、0分予防です。前述のように、トラフィックの切り替えは、2 つのコンピュータ ルームにブルーグリーン リリース環境を展開することで実行できます。これは一つの方法です。同じコンピュータ室であっても、制御コンソールのロジックで 2 つのユニットを定義でき、同じコンピュータ室でブルーグリーンリリースを迅速に実行できます。コンピュータ ルームでのブルーグリーン リリースは、技術製品のサポートによって制限されます。このコンポーネントは、どのリソースが 1 つのユニットに属し、どのリソースが別のユニットに属しているかを明確に区別し、このユニットに対してブルーグリーン リリースを迅速に実装できます。

2番目、 5分の場所。たとえば、同じ都市内でコールド スタンバイの災害復旧テクノロジを使用すると、意思決定が非常に困難になることが多く、切り替えを行った側がその結果を負わなければなりません。このプラットフォームに基づいて、今日の障害の影響、アプリケーションを復元するために関係する関係者が実行する必要があるアクションや操作を直感的に把握できることを願っています。障害が発生した場合、このシステムは障害の問題を迅速に特定できます。たとえば、5 分以内に問題を特定した後、フローを切り替えるかどうかの決定を開始できます。

3番目は10分間の回復です。最後に、このモデルを通じて、業務再開のプロセス全体を10 分以内に復旧できることを願っています。

アクティブ-アクティブ災害復旧のベストプラクティス

以下は、Alibaba が外部企業に提供するアプリケーションの例です。このマルチアクティブ災害復旧機能は、パブリック クラウドでのみ利用できるわけではありません。クラウドでは、アプリケーションがクラウドに展開されたときに、すべての高可用性がクラウドによって自然に提供されるわけではないためです。リソースを使用すると、クラウドには実際にはさまざまなリージョンがあり、同じリージョンに異なる可用性ゾーンが含まれていることがわかります。パブリッククラウド上で利用する場合は、実際の状況を考慮する必要があります。たとえば、ほとんどの顧客は南側にいる可能性があるので、最初に南側のコンピューター ルームにノードが開かれることがあります。そうすると、Alibaba のコンピュータ ルームで問題が発生すると、顧客のビジネスにもそれに応じた影響が生じます。顧客は対応する業務をクラウド上に展開し、クラウド上の製品も高可用性を提供しますが、障害シナリオがコンピュータ ルームに関係すると、対応する業務は依然として影響を受けます。したがって、提供されるソリューションは、マルチアクティブ機能をクラウドだけでなく、商用ソフトウェアのようにコンピュータ ルームにも展開できるというものです。

ケース1: 同じ都市でのアクティブ-アクティブ

物流クライアントは実際に同じ市内でマルチアクティブを使用しています。従来の技術を使用しても大きな問題はありませんが、マルチアクティブを使用する利点は、対応する SDK に反映されており、自動的に識別できるため、あまりビジネス変革を必要とせず、ラベル付けされたリクエストを自動的に渡すことができます。災害復旧機能が完成した後、RTO は以前よりも大幅に高速化されました。

ケース2: リモートデュアルリーディング

異なる場所での二重読み取りのこのケースの難しさは、場所が 1,000 キロメートル以上離れているという事実にあります。この距離制限では、読み取りと書き込みの両方が困難になり、データの複製自体に遅延が発生します。この製品セットを使用するロジックは、管理レベルとトラフィック レベルから、どのビジネスが読み取り対象であるか、どのビジネスが読み取り対象コンピュータ ルームにインポートされているか、およびレプリケーション ステータスが何であるかを明確に把握することです。従来に比べて分単位のRTOが大幅に向上し、オンラインで動的に柔軟にサービスを切り替えることができます。

ケース3: リモート アクティブ-アクティブ

リモート アクティブ/アクティブを使用しているこのエンタープライズ顧客は現在 2 つのデータ センターを所有しており、将来的に拡張される可能性があります。このソリューションを実装する際には、製品の適応性開発に多くの労力を費やしました。なぜなら、読み取りを実現するために、元の製品の基本機能では中間層に多くの作業が必要だったからです。全体のプロセスは、マルチアクティブ製品開発からアプリケーションシナリオの適応、そしてビジネスの包括的な変革まででした。肝心なのは事業継続性なので、今後すべての事業所でコンピュータルームのマルチアクティブ化が採用されるわけではなく、重要な事業所のみに採用されることになります。たとえば、毎年11月の大晦日には、注文に影響が及ばないようにすることが当社の主な業務です。したがって、デカップリングやその他の手段により、物流は事業継続の観点から受注取引ほど優先度が高くなくなるでしょう。重要なポイントは、マルチアクティブディメンションで切り替える際に、コアトランザクションリンクに含まれるサービスと製品がうまく動作しないことをどのように保証するかです。

このマルチアクティブ管理および制御プラットフォームを実際に体験してみることをお勧めします。コンソールに 2 つ以上のユニットを定義した後、コンピュータ ルームの 1 つに障害が発生した場合、マルチアクティブを通じてそのアプリケーションを別のコンピュータ ルームにすばやく切り替えることを期待します。切り替えの前提条件は、コントロール コンソール内のポイントを定義することです。単一のコンピュータ ルームの論理ポイントであっても、複数の物理的なコンピュータ ルームのポイントであっても、それらをマルチアクティブ制御プラットフォームにマッピングする必要があります。コントロール コンソールで、統合サービスへのアクセス、アクセス トラフィックをセグメント化するためのディメンション、ID 形式でのマーク付けなどのいくつかのルールを構成します。トラフィックを切り替える際に、どの次元のトラフィックが別のコンピュータ ルームに向けられているかを動的に表示するため、障害が発生した場合でも、すぐに対応することができ、比較的簡単です。

現在、お客様の機能導入を支援する際には、トラフィックの切り替えやシステム内のコンソールのドリルダウンを実行し、コンピュータ ルームが影響を受けているかどうかを確認することがよくあります。これは、システム全体に、障害訓練や、これらの障害に対応してアプリケーションを別のコンピュータ ルームに切り替えるなどの他のソリューションも備わっているためです。

要約する

マルチアクティブ災害復旧機能はアリババ社内の業務で長年実践されてきたが、製品として進化させるには長い時間を要した。目標は、今日の製品とソリューションのセットが、企業が 30 日以内に独自のマルチアクティブ機能を構築できるように支援することです。特に、すでにパブリッククラウド上に製品を展開している企業も多く、実際に構築にかかる時間は短くなります。この製品とソリューションのセットのマルチアクティブ機能により、企業が障害切り替えを迅速に実装し、数分以内にマルチアクティブ機能を構築できるようになることを願っています。