Best Practices for Disaster Recovery and Multi location Mobility Across Availability Zones on the Cloud

2022 年 7 月 4 日、「Observable, Reliable - CloudOps Series Salon for On cloud Automation Operation and Maintenance 第 1 弾」が正式にスタートしました。4 日間にわたり、4 つのテーマで共有が行われました。最後の講演者は、Alibaba Cloud のエラスティックコンピューティング技術の専門家である Deng Qinglin 氏で、「クラウドアベイラビリティゾーン間のディザスタリカバリと遠隔地マルチアクティブ」をテーマに共有しました。以下に、講演の内容をまとめます。

01 システムディザスタリカバリ

ディザスタリカバリといえば、必ず障害が関連します。一般的な障害の種類には、変更ミス、ハードウェア障害、停電、自然災害などがあり、発生頻度はこの順に低くなります。しかし、発生頻度が低いからといって重要でないわけではありません。停電や自然災害による障害は、致命的な結果を招くことが多いからです。

2021 年 3 月 10 日、ヨーロッパ最大のクラウドサービスプロバイダーである OVH のフランスにあるデータセンターで火災が発生しました。この火災によりデータセンターが全焼し、350 万件のウェブサイトがオフラインになり、一部の顧客データが永久に失われ、復旧できませんでした。OVH の CEO は、Twitter での火災に関する説明の中で、顧客に自社のディザスタリカバリ対策を有効化するよう促しました。このことから、アプリケーションをクラウドにデプロイしても、停電や極端な自然災害によるインフラ障害を完全には回避できないことがわかります。そのため、対応するディザスタリカバリ計画を事前に準備しておく必要があります。

現在、ディザスタリカバリの主な種類は以下の 3 つのカテゴリに分類できます。

① ローカル（クロスゾーン）：主にローカルディザスタリカバリ、ローカルデュアルアクティブ、ローカルマルチアクティブがあります。

② ノンローカル（クロスリージョン）：主にノンローカルデュアルリード、ノンローカルアプリケーションデュアルアクティブ、ノンローカルデュアルアクティブに分けられます。

③ その他：二地三中心、二地三アクティブ、ユニット化などがあります。

あらゆるシナリオに適用できるディザスタリカバリ方式は存在しません。実際のビジネスの成長動向、ビジネスシステムの特徴、投資可能なリソースコストを総合的に評価し、最も適切なディザスタリカバリアーキテクチャを選択する必要があります。

02 主流なディザスタリカバリアーキテクチャ

ディザスタリカバリ能力は主に RPO と RTO で測定されます。

RPO は、障害発生時に許容できるデータ損失の最大範囲を指します。システムが重要なほど、小さな RPO が求められます。データバックアップを行う場合、RPO が小さいほどデータバックアップの頻度が高くなります。たとえば、通常のシステムは 1 日 1 回のバックアップですが、非常に重要なシステムは 1 時間ごとにバックアップを行う場合があります。データ同期を行う場合、RPO が小さいほどデータ同期リンクの高い信頼性または低遅延が求められ、本番環境とネットワークへの負荷が増大し、コストも増加します。

RTO は、アプリケーションが障害発生から復旧するまでに許容できる最大時間を指します。システムが重要なほど、小さな RTO が求められます。

前述の図の右側は、国家情報化委員会が定めたディザスタリカバリ能力レベルを示しており、1〜6 の 6 段階に分けられています。其中、レベル 6 が最も厳格で、RTO は数分、RPO は 0、つまりシステムデータの損失は許容されないことを意味します。

前述の図は、4 つの主流なディザスタリカバリアーキテクチャの比較です。

1. ローカルディザスタリカバリ

同一都市内に少なくとも 2 つのデータセンターを配備します。スタンバイ側のデータセンターは通常サービス能力を提供せず、主にプライマリデータセンターのバックアップとして機能します。プライマリとスタンバイ間のデータは一方向で同期されます。

メリットは、デプロイがシンプルなことです。同じアーキテクチャを別のデータセンターに完全に複製でき、データは一方向同期で、ビジネス改修はほとんどありません。

デメリットは、スタンバイデータセンターのリソースの無駄です。いざという時にトラフィックを切り替える勇気がなく、バージョンやパラメータ、OS などの不整合が発生しやすくなります。RTO は 10 分以上かかります。

ローカルディザスタリカバリアーキテクチャでディザスタリカバリの切り替えを行う場合、まずアクティブ/スタンバイのデータベースを切り替える必要があります。コールドスタンバイの場合は、アプリケーションサービスを起動し、トップレベル DNS の名前解決を切り替える必要があり、全体で 10 分以上かかります。

2. 同一都市デュアルアクティブ

2 つのデータセンターが同時に外部サービスを提供します。データ整合性のため、スタンバイデータセンターのデータ層に関わるすべての操作はプライマリデータセンターに返されます。そのため、2 つのデータセンター間の距離は 50km 未満、RT は 2ms 未満が求められます。リクエストがスタンバイデータセンターで処理された場合、クロスデータセンターの操作が含まれます。クロスデータセンターの RT が大きいと、プライマリとスタンバイでのデータリクエストのパフォーマンス差が大きくなり、良好なユーザー体験を提供できません。このアーキテクチャのデータは一方向同期を採用しています。

メリットは、スタンバイデータセンターのリソース無駄の問題を解決し、通常からサービス状態を維持しているため、障害時はいつでも切り替えが可能です。アクティブ/スタンバイのデータベース切り替えのみで済み、RTO は分単位です。

デメリットは、同一都市内に限定され、距離に制約があることです。

3. 遠隔地アプリケーションデュアルアクティブ（疑似リモートデュアルアクティブ）

同一都市デュアルアクティブと多くの共通点があります。唯一の違いは、スタンバイデータセンターの読み取りと書き込みが分離されていることです。読み取り操作はスタンバイデータセンターから直接読み取り、書き込み操作はプライマリデータセンターのデータベースに送信され、データ整合性を確保します。2 つのデータセンター間の距離は 100km 未満、RT は 7ms 未満が必要です。2 つのデータセンター間の距離が遠すぎると、リクエストのパフォーマンス差が大きくなります。このアーキテクチャは、読み取りが多く書き込みが少ないシステムに適しています。

メリットは、リージョンレベルでのディザスタトレランス能力を持つことです。このアーキテクチャが求める距離は 100km 未満ですが、ほとんどの地級市にとって 100km は既に 2 つの地級市をカバーでき、RTO も分単位です。

デメリットは、ビジネスシステムがクロスデータセンターのネットワーク遅延をある程度許容できる必要があることです。また、リード/ライト分離の面でビジネスをある程度改修する必要があります。ディザスタトレランスの距離はまだ限られているため、「疑似リモートデュアルアクティブ」と呼ばれます。

4. リモートデュアルアクティブ

真のリモートデュアルアクティブシステムは、2 つのデータセンター間の距離が 1,000km 以上、RT が 10ms 以上でも許容できます。前述の 2 つのデータセンター間のパフォーマンス差を解決するために、ユニット化ソリューションを採用しました。ユニット化とは、リクエストがあるユニットに振り分けられた後、そのリクエストのすべての操作がユニット内で閉ループで処理され、クロスデータセンターの操作を回避することを意味します。そのため、どのデータセンターにリクエストを送っても、基本的に一貫した処理効率と良好なユーザー体験を確保できます。ユニット化を実現するには、各データセンター間で双方向のデータ同期が必要です。

メリットは、ディザスタリカバリ能力が非常に強く、距離にほぼ制限がなく、RTO は分単位です。

デメリットは、デプロイが複雑なことです。データベースだけでなく、Redis キャッシュ、RocketMQ、ステートフルミドルウェアなどを含む双方向データ同期が必要です。ビジネス改修のコストも非常に高く、ユニットやアクセス層などのディメンションが関係します。

03 エラスティックコンピューティングのディザスタリカバリ実践

前述の図は、同一都市デュアルアクティブの元アーキテクチャです。

ユーザーがドメイン名にアクセスすると、リクエストはパブリック SLB に送られます。SLB は 2 つのゾーン間でプライマリ/スタンバイのディザスタリカバリ能力を持ち、いずれかのゾーンにルーティングされます。ゾーン内の SLB はリクエストを具体的なビジネスサーバーに転送します。ビジネスサーバーはすべてのデータ操作をプライマリデータセンターに送信し、プライマリとスタンバイ間のデータは一方向で同期されます。基盤システムはすべてのリージョンのクラウドプロダクトを操作します。

この時点で、システムはクロスゾーンレベルのディザスタリカバリ能力を持ち、RPO は 100ms 未満、RTO は 10 分未満です。アプリケーションのパフォーマンスを向上させ、クロスデータセンターの RPC コールを可能な限り回避するため、同一データセンター内の RPC コールを優先する戦略も設計しました。

このアーキテクチャのデメリットは、リージョンレベルのディザスタリカバリ能力がないことです。次に、システムはすべてのリージョンのクラウドプロダクトを操作するため、システムに障害が発生すると、すべてのリージョンのクラウドプロダクト操作に影響が及び、その影響は非常に大きくなります。また、システムが中国にデプロイされているため、海外ユーザーのアクセス速度は遅く、越境問題が発生し、深刻な場合はページが開けないこともあります。

前述の課題を解決するため、第 2 版アーキテクチャを導入しました。コアはユニット化です。ユニット化とは、各リージョンの運用システムをそのリージョン内にデプロイし、リージョン A のサービスはリージョン B のリソース操作を含まないことを意味します。リージョン内部はデュアルゾーンのディザスタリカバリ能力です。

このアーキテクチャと元バージョンの唯一の違いは、クラウドプロダクトを操作する際に自リージョンのクラウドプロダクトのみを操作する点です。障害が発生した場合、影響範囲は比較的制御しやすく、そのリージョンのみに影響し、他のリージョンには影響せず、障害の影響範囲を縮小できます。

このバージョンのユニットは引き続きクロスゾーンレベルのディザスタリカバリ能力を持ち、RPO は 100ms 未満、RTO は 10 分未満です。同一データセンター内の RPC コール優先ポリシーも維持されています。

デメリットは、ディザスタリカバリレベルでまだリージョンレベルのディザスタリカバリ能力がないことです。次に、ユーザー体験が非常に悪い点です。たとえば、システム上でクラウドプロダクトリソースを操作する際、リージョン切り替えが伴うと、ページ全体を更新する必要があります。さらに、越境アクセスの遅さの問題も依然として存在します。

前述の問題を解決するため、アーキテクチャを第 3 版に進化させました。コアはグローバル化で、本質的には遠隔地マルチアクティブアーキテクチャです。ユニット化された各ユニットには外部サービスを提供するドメイン名があります。グローバル化後、すべてのドメイン名は 1 つのドメイン名に統合され、トップレベル DNS がインテリジェントな最寄り名前解決を行います。

リージョン内は引き続きゾーンレベルのディザスタリカバリです。グローバルに複数のリージョンがデプロイされていますが、リージョンはメインリージョンとユニットリージョンに分けられます。すべてのデータ書き込みはプライマリセンターに返され、ユニットリージョンの書き込みはメインリージョンに返されます。書き込み操作がセンターに戻った後、センターのデータはそのユニットリージョンへ一方向に同期されます。双方向同期にすると、同期のトポロジーが非常に複雑なメッシュ状になるため、一方向同期を採用しています。

このアーキテクチャはリージョンレベルのディザスタリカバリ能力を持ち、インテリジェントな最寄り名前解決機能を提供します。ユーザー体験も向上し、複数のドメイン名間でのリダイレクトが不要になりました。

リージョンデプロイメント数が多い分、データ同期には時間がかかります。RPO は 10 秒未満、RTO は 10 分未満を保証できるのみです。リージョン内のユニットは引き続き同一データセンター内の RPC コール優先ポリシーを維持しています。障害発生時は、リクエストを別のリージョンにルーティングします。

このアーキテクチャはデプロイが複雑で、データ同期も伴うため、システムにある程度の改修が必要です。たとえば、書き込み操作はセンターに返す必要があり、データ変更後にキャッシュが更新されます。さらに、すべての書き込み操作はセンターにフローバックする必要があるため、書き込み操作は依然としてクロスゾーンのディザスタリカバリであり、真のクロスリージョンディザスタリカバリは実現できていません。

04 クラウド上のディザスタリカバリ構築

クラウド上のディザスタリカバリ構築は主に 3 つの段階に分けられます。分析フェーズ、設計フェーズ、実装フェーズです。

分析フェーズでは、ビジネスにディザスタリカバリが必要かどうか、どの程度のレベルが必要かを検討する必要があります。たとえば、システム初期段階ではユーザー数に注目しがちですが、ユーザー数が一定レベルに達してからシステムの安定性を考慮し、最後にディザスタトレランス能力を検討します。また、ディザスタリカバリではシステムビジネスを整理し、コアビジネスかどうか、どのような RPO が許容できるかを明確にする必要があります。

設計フェーズでは、分析フェーズで得たデータに基づいて設計を行います。

実装フェーズでの実装プロセスには、組織レベルでのチーム協力とリソース投入、そして実際の障害後にどのようにリカバリするかに関する詳細設計が含まれます。さらに、定期的なディザスタリカバリ訓練とディザスタリカバリシステムのメンテナンス、スタッフトレーニングも必要です。

Alibaba Cloud は、ユーザーが効率的かつ迅速にディザスタリカバリを完了できるよう、多くのクラウドプロダクトとサービスを提供しています。

システムがまだクラウドにデプロイされていない場合は、Server Migration Center (SMC) を利用してシステム全体を迅速にクラウドへ移行できます。SMC は複数のプラットフォームや環境からの移行をサポートし、ソースサーバーの基盤環境に依存しません。無停止移行もサポートしており、すべての操作はコンソール上の GUI 設定で完了できます。データ転送には十分なセキュリティ保証があり、ブレークポイントからの継続転送と増分移行をサポートしています。

システムが既にクラウド上にある場合は、Alibaba Cloud がオーケストレーション機能も提供しています。フィルター条件を決定した後、システムを別のリージョン/ゾーンに迅速に複製できます。

サービスデプロイ後は、Data Transmission Service (DTS) を使用してデータ同期やデータバックアップを行えます。DTS は非常に強力で、同種または異種データソース間の移行と無停止移行をサポートします。データソース間で一方向同期と双方向同期もサポートしています。

マルチアクティブディザスタリカバリの MSHA はビジネスを改修し、DTS などのデータ同期製品を内部的に統合することで、ビジネスの総合的なディザスタリカバリ能力を迅速に構築できます。シングルリージョンからマルチリージョン、シングルクラウドからマルチクラウド、プライマリ/スタンバイからマルチアクティブへの移行を含みます。

さらに、MSHA はパブリッククラウド、プライベートクラウド、ハイブリッドクラウドなど、豊富な実践経験を蓄積しています。ディザスタリカバリ管理と切り替えを完了できるコンソールも提供しています。

Alibaba Cloud DNS は、インテリジェント DNS 名前解決に基づく最寄りアクセスを提供します。現在、主流の DNS 名前解決サービスは、州レベル、地域レベル、国レベルなど、よりインテリジェントな名前解決ラインを提供できます。

ApsaraDB は、ApsaraDB RDS の高可用性バージョンと ApsaraDB for Redis のデュアルゾーンバージョンの両方で、ゾーンレベルのアクティブ/スタンバイ機能を提供するため、ユーザーが自分で対応する必要はありません。

遠隔地シナリオでの異なるリージョン間のネットワークには、Cloud Enterprise Network (CEN) を使用して複数の Virtual Private Cloud (VPC) ベースのネットワークを接続できます。

Q&A リンク、参加者からの質問

Q1：ゾーンディザスタリカバリと従来のディザスタリカバリの主な違いは何ですか？

A：従来のディザスタリカバリはローカルディザスタリカバリを指します。バックアップデータセンターは通常外部サービスを提供せず、主にバックアップとして機能します。メリットはビジネス改修が非常に少なく、デプロイがシンプルなことです。デメリットはリソースの無駄が多く、通常サービスを提供していないため、いざという時にトラフィックを切り替える勇気がないことです。また、二地三中心のような組み合わせ形態もあります。これは、1 つの都市に 2 つのゾーンレベルデータセンターがあり同時に外部サービスを提供し、別の都市では主にディザスタリカバリ用に通常サービスを提供しない構成です。これは複数の都市間での同一都市デュアルアクティブと同一都市ディザスタリカバリの組み合わせに似ています。

Q2：遠隔地マルチアクティブのデータ同期はどのように保証されますか？

A：データベース自体に同期能力があります。クラウドでは DTS などの関連プロダクトも提供されており、ユーザーがより簡単に同期できるようサポートしています。Redis や RocketMQ などのミドルウェアにも、DTS は同期能力を提供しています。オープンソース業界にも多くのソリューションがありますが、運用とメンテナンスが必要です。

Q3：遠隔地マルチアクティブのデータ同期と同一都市マルチアクティブのデータ同期の違いは何ですか？

A：同一都市マルチアクティブの場合、クラウド上の ApsaraDB RDS や ApsaraDB for Redis を直接使用でき、高可用性バージョンとデュアルゾーンバージョンが同一都市レベルでのディザスタトレランスを直接提供するため、ユーザー自身がデータ同期構築を行う必要はありません。一方、遠隔地マルチアクティブやデュアルアクティブはクロスリージョンに関わるため、ApsaraDB RDS や ApsaraDB for Redis では対応する能力を提供できません。そのため、DTS などのデータ転送サービスで同期リンクを構築するか、独自のデータ同期コンポーネントを実装する必要があります。クラウドプロダクトは非常に豊富なディザスタリカバリ機能を提供していますが、主にリージョン内に限定されています。

Q4：国際化の場合、各地からのアクセスはすべて元のマスターセンターに返されますか、それとも DB への書き込みのみが元のマスターセンターに返されますか？

A：書き込みとは、主にアプリが保持するデータの読み書きを指します。すべてのリージョンの書き込み操作はセンターリージョンに切り替えられます。センターリージョンがデータベースに書き込んだ後、DTS の同期機能を通じて各リージョンにデータが同期されます。同時に、DTS は binlog のメッセージ機能を提供しており、各ユニットはプライマリデータセンターの DTS binlog メッセージサービスをサブスクライブすることで、キャッシュをいつ破棄または更新するかを把握できます。

Q5：どのようなシステムの改修が必要ですか？

A：一部のシステムはユニット化改修を完了できますが、在庫サービスのように在庫控除に強力なグローバル整合性が必要なシステムは、ユニット化デプロイを実現できません。そのため、分析フェーズで、システムがユニット化改修の要件を受け入れられるか、システムの RTO と RPO の要件を満たせるかを判断する必要があります。異なるビジネスシステムとシナリオにはそれぞれ異なるディザスタリカバリアーキテクチャがあり、実際のビジネスシナリオに合わせて選択する必要があります。