クラウド インフラストラクチャの停止に対する障害復旧の設計

この記事は、Google Cloud の障害復旧(DR)について説明するシリーズのパート 6 です。このパートでは、Google Cloud を使用してワークロードを設計し、クラウド インフラストラクチャの障害から復旧するブロックを構築するプロセスについて説明します。

シリーズは次のパートで構成されています。

はじめに

ワークロードをパブリック クラウドに移行する場合は、オンプレミスで復元力の高いシステムを構築したときの知識や経験から離れ、Google Cloud などのクラウド プロバイダのハイパースケーリング インフラストラクチャの理解を深める必要があります。この記事では、RTO(リカバリ時間目標)や RPO(リカバリポイント目標)など、障害復旧に関する業界標準のコンセプトと Google Cloud インフラストラクチャの対応について説明します。

このドキュメントのガイダンスは、極めて優れたサービス可用性を実現する Google の重要な原則の 1 つ(障害に対する計画)に基づいています。Google Cloud は極めて信頼性の高いサービスを提供しますが、自然災害、ケーブル切断など、予測できないインフラストラクチャ障害でサービスが停止する可能性があります。サービス停止に対する計画を立てることで、Google Cloud プロダクトで「組み込み」の DR メカニズムを使用し、これらの予期しないイベントに対して耐障害性を備えたアプリケーションを作成できます。

障害復旧は包括的なトピックで、インフラストラクチャの障害だけでなく、ソフトウェアのバグやデータの破損なども含まれます。この記事では、DR 計画の一つである、クラウド インフラストラクチャの停止に耐障害性のあるアプリケーションを設計する方法に焦点を当てています。この記事の内容は以下のとおりです。

  1. Google Cloud インフラストラクチャ、Google Cloud の停止時として障害イベントを表す方法、停止の頻度と範囲を最小限に抑える Google Cloud の設計方法。
  2. アーキテクチャ計画ガイド。目的とする信頼性に基づいてアプリケーションを分類、設計するためのフレームワークを提供します。
  3. アプリケーションで使用可能な組み込み DR 機能を提供する Google Cloud プロダクトのリスト。

一般的な DR 計画の詳細と、オンプレミスの DR 戦略の一部として Google Cloud を使用する方法については、障害復旧計画ガイドをご覧ください。高可用性は障害復旧のコンセプトと密接に関連していますが、この記事では説明しません。高可用性の設計の詳細については、Google Cloud アーキテクチャ フレームワークをご覧ください。

用語に関する注意: この記事では、プロダクトに継続してアクセスし、使用できる状況を表す言葉として「可用性」という用語を使用しています。また、可用性だけでなく、耐久性や正確性という属性を含めた意味で「信頼性」という用語を使用しています。

Google Cloud で復元力を高める設計方法

Google データセンター

従来型のデータセンターでは、個々のコンポーネントの可用性を最大限に高める必要があります。クラウドでは、Google などの運用企業が仮想化テクノロジーを使用して多数のコンポーネントにサービスを分散させ、従来のコンポーネントを超える信頼性を提供しています。信頼性を考える基準が変わり、オンプレミスで問題になっていたことを心配する必要はありません。冷却装置や電源装置などの故障モードではなく、Google Cloud プロダクトとその信頼性の指標を評価し、計画を立てます。これらの指標には、基盤となるインフラストラクチャ全体の停止リスクが反映されています。これにより、インフラストラクチャの管理ではなく、アプリケーションの設計、デプロイ、運用に集中できます。

Google では、最新のデータセンターの構築と運営に関する豊富な経験に基づいて、高い可用性目標を満たすインフラストラクチャを設計しています。Google は、データセンター設計における世界的なリーダーとして位置づけられています。電源から冷却まで、それぞれのデータセンターの技術に対し、独自の冗長性と緩和策を実現しています(FMEA プランなど)。Google のデータセンターは、さまざまなリスクをバランスよく考慮し、Google Cloud プロダクトに対して期待される可用性を一貫して提供できるように構築されています。Google では、この経験に基づき、物理アーキテクチャと論理システム アーキテクチャ全体の可用性をモデル化し、データセンターの設計が期待どおり機能していることを確認しています。Google のエンジニアは、お客様の期待に応えるため、運用に多大な時間を費やしています。実際に測定された可用性は設計目標を大きく上回っています。

Google Cloud では、こうしたデータセンターのリスク対策をユーザー向けのプロダクトに組み込まれているので、データセンターの設計と運用を気にせず、Google Cloud のリージョンとゾーンの設計に重点を置くことができます。

リージョンとゾーン

Google Cloud プロダクトは、非常に多くのリージョンとゾーンにまたがって提供されています。リージョンとは、3 つ以上のゾーンから構成された物理的に独立した地理的なエリアです。ゾーンは、物理インフラストラクチャと論理インフラストラクチャの点で、他のリージョンからの高い独立性を持つリージョン内にある物理コンピューティング リソースのグループを表します。同じリージョン内の他のゾーンと高帯域幅で低レイテンシのネットワークで接続しています。たとえば、日本の asia-northeast1 リージョンには 3 つのゾーン(asia-northeast1-aasia-northeast1-basia-northeast1-c)があります。

Google Cloud プロダクトは、ゾーンリソース、リージョン リソース、マルチリージョン リソースに分類されます。

ゾーンリソースは、単一のゾーン内にホストされています。ゾーンでサービスが中断すると、そのゾーンのすべてのリソースが影響を受けます。たとえば、Compute Engine インスタンスは指定された単一ゾーンで実行されます。ハードウェア障害によってそのゾーンのサービスが中断した場合、復旧するまでその Compute Engine インスタンスを使用することはできません。

リージョン リソースは、リージョン内の複数のゾーンに重複してデプロイされます。そのため、リージョン リソースはゾーンリソースに比べて信頼性が高くなります。

マルチリージョン リソースは、リージョン内とリージョン間で分散されています。通常、マルチリージョン リソースはリージョン リソースよりも信頼性が高くなりますが、このレベルでは可用性、パフォーマンス、リソースの効率性を最適化する必要があります。そのためには、使用するマルチリージョン プロダクトのトレードオフを理解することが重要です。それぞれのトレードオフについては、このドキュメントの後半で説明します。

ゾーン、リージョン、マルチリージョンの Google Cloud プロダクトの例

ゾーンとリージョンによる信頼性の実現

Google SRE は、世界中のコンピューティング インフラストラクチャをシームレスに実現するさまざまな手法や技術を通じて、Gmail や Google 検索のような信頼性の高いグローバル ユーザー プロダクトの管理とスケーリングを行っています。たとえば、グローバル負荷分散を使用して、使用不能なロケーションからトラフィックをリダイレクトし、世界中のさまざまな場所で複数のレプリカを実行しています。また、ロケーション間でデータの複製を行っています。Google Cloud のお客様には、Cloud Load Balancing、Google Kubernetes Engine、Cloud Spanner などのプロダクトにより、これらの機能を提供しています。

Google Cloud では、ゾーンとリージョンに対して以下の可用性レベルを提供するプロダクトを設計しています。

リソース 可用性の設計目標 暗黙のダウンタイム
ゾーン Compute Engine、Persistent Disk 99.9% 8.75 時間/年
リージョン リージョンの Cloud Storage、複製された Persistent Disk、リージョンの Google Kubernetes Engine 99.99% 52 分/年

Google Cloud の可用性の設計目標と適切なダウンタイム レベルを比較し、適切な Google Cloud リソースを選択してください。従来の設計では、コンポーネントの可用性を向上させてアプリケーションの可用性を向上させることに重点を置いていますが、クラウドモデルの場合は、目標を達成するためにコンポーネントを構成することに重点を置く必要があります。Google Cloud の多くのプロダクトで、この方法を使用しています。たとえば、Cloud Spanner は 99.999% の可用性を提供するため、複数のリージョンを構成するマルチリージョン データベースを提供します。

構成は重要です。これがないと、アプリケーションの可用性は、使用する Google Cloud プロダクトの可用性を超えることができません。実際に、アプリケーションで障害が発生しない限り、基盤となる Google Cloud プロダクトよりも可用性は低くなります。このセクションの残りの部分では、ゾーン プロダクトとリージョン プロダクトの構成を使用して、単一のゾーンまたはリージョンで提供される可用性よりもアプリケーションの可用性を高める方法を説明します。次のセクションでは、これらの原則をアプリケーションに適用するための実践的なガイドを紹介します。

ゾーン停止のスコープに対する計画

インフラストラクチャの障害は、通常 1 つのゾーンでサービス停止を起こします。リージョン内では、ゾーンは他のゾーンとの相関的な障害のリスクを最小限に抑えるように設計されています。また、1 つのゾーンでサービスが中断しても、同じリージョン内の別のゾーンのサービスに影響することはありません。ゾーンをスコープとする停止が発生しても、ゾーン全体が使用できなくなるわけではありません。これは単にインシデントの境界を定義しているだけです。ゾーンが停止しても、そのゾーンの特定のリソースに影響が及ばないこともあります。

これはまれなことですが、1 つのリージョン内のあるポイントが停止し、結果的に複数のゾーンが停止することがあります。2 つ以上のゾーンでサービスが停止した場合は、以下のようにリージョン停止のスコープが適用されます。

リージョン リソースは、複数のゾーンの構成からサービスを提供することで、ゾーン停止に対する耐障害性を備えるように設計されています。リージョン リソースをバックアップするゾーンのいずれかでサービスが中断した場合、別のゾーンからリソースが利用できるようになります。詳細については、付録にあるプロダクトの機能説明をご覧ください。

Google Cloud から提供されるゾーンリソースは Compute Engine 仮想マシン(VM)と Persistent Disk だけです。ゾーンリソースを使用する場合は、複数のゾーンに配置されたゾーンリソース間のフェイルオーバーとリカバリを設計、構築、テストし、独自のリソース構成を使用する必要があります。以下のような戦略を実施します。

  • ヘルスチェックでゾーンの問題が検出されたときに、Cloud Load Balancing を使用して、トラフィックを別のゾーンの仮想マシンに迅速にルーティングします。
  • Compute Engine インスタンス テンプレートまたはマネージド インスタンス グループを使用して、複数のゾーンで同じ VM インスタンスを実行し、スケーリングします。
  • リージョン Persistent Disk を使用して、データをリージョン内の別のゾーンに同期的に複製します。詳細については、リージョン PD を使用した高可用性オプションをご覧ください。

リージョン停止のスコープに対する計画

リージョン停止とは、単一リージョン内の複数のゾーンに影響するサービスの中断です。これは大規模な停止ですが、発生する頻度は低く、自然災害や大規模なインフラストラクチャの障害が原因となります。

99.99% の可用性を提供するように設計されたリージョン プロダクトの場合、許容されるダウンタイムは年間で 1 時間程度になります。したがって、重要なアプリケーションでこのような停止期間が許容できない場合は、マルチリージョンの DR 計画を用意する必要があります。

マルチリージョン リソースは、複数のリージョンからサービスを提供することで、リージョンの停止に対する耐障害性を備えるように設計されています。前述のように、マルチリージョン プロダクトではレイテンシ、整合性、コストがトレードオフになります。最も一般的なトレードオフは、データのレプリケーションを同期で行うのか、非同期で行うのかです。非同期レプリケーションの場合、レイテンシは低くなりますが、停止時にデータが損失するリスクは高くなります。付録にあるプロダクト機能の説明で詳細を確認してください。

リージョン リソースを使用し、リージョンの停止に対する耐障害性を維持するには、複数のリージョンに存在するリージョン リソース間でフェイルオーバーと復元を設計、構築、テストし、独自のリソース構成を使用する必要があります。前述のゾーン戦略は複数のリージョン間にも適用できます。次のことを検討してください。

  • リージョン リソースは、Cloud Storage などのマルチリージョン ストレージ オプション、Anthos などのハイブリッド クラウド オプションを使用して、データをセカンダリ リージョンに複製する必要があります。
  • リージョン停止の対策を作成したら、それを定期的にテストします。単一リージョンに対する耐障害性だけでは、現実的な状況に対応することはできません。

Google Cloud の耐障害性と可用性のアプローチ

Google Cloud は定期的な評価で可用性の設計目標を達成していますが、このパフォーマンスが設計可能な最小の可用性になるわけではありません。アプリケーションに期待する信頼性を上回るように Google Cloud のプロダクトを選択する必要があります。たとえば、アプリケーションのダウンタイムと Google Cloud のダウンタイムを考慮することで、求めている結果を実現できます。

適切に設計されたシステムであれば、「ゾーンまたはリージョンが 1 分、5 分、10 分、30 分間停止した場合どうなるか」という質問に的確に回答できるはずです。この質問には、次のように多層的に答える必要があります。

  • 停止中にユーザーはどのような影響を受けるかのか。
  • 停止が発生していることを、どのように検知するのか。
  • 停止した場合、アプリケーションはどうなるのか。
  • 停止した場合、データはどうなるのか。
  • 依存関係のある他のアプリケーションにはどのような影響があるのか。
  • 復旧後に復元するには、どうすればよいのか。誰が行うのか。
  • 停止をどのタイミングで、いつまでに通知するのか。

Google Cloud でアプリケーションの障害復旧を設計するための設定ガイド

ここまでのセクションでは、Google がクラウド インフラストラクチャを構築している方法と、ゾーンとリージョンの停止に対処するいくつかの方法について説明しました。

このセクションでは、目的の信頼性に基づいてアプリケーションに構成の原則を適用するためのフレームワークを作成します。

ステップ 1: 既存の要件を収集する

最初のステップは、アプリケーションの可用性の要件を定義することです。ほとんどの企業では、この領域について設計上のガイダンスが存在しています。内部で開発している場合もあれば、規制や法的要件に基づいて作成している場合もあるでしょう。この設計上のガイダンスは通常、リカバリ時間目標(RTO)とリカバリ ポイント目標(RPO)の 2 つの主要な指標に基づいて作成されます。ビジネス上の用語では、RTO は「障害が発生してから稼働状態に戻るまでどのくらいの時間がかかるか」を意味します。RPO は「障害発生時に失われるデータの許容量」を意味します。

時間を表すスケール。イベントが中間で発生しています。この左側で「これらの書き込みは失われます」という部分までが RPO です。この右側で「通常のサービスの再開」という部分までが RTO です。

大規模な組織では、コンポーネントの障害から地震に至るまで、さまざまな障害イベントに対して RTO と RPO の要件を定義してきました。これは、プランナーがソフトウェアとハードウェア スタック全体を通して RTO / RPO の要件をマッピングする必要があるオンプレミス環境では意味のあることです。しかし、クラウド環境ではプロバイダがこのような処理を行うため、これほど細かい要件を定義する必要はありません。根本的な原因を明確に記述せず、損失のスコープ(ゾーン全体またはリージョン全体)だけで RTO と RPO の要件を定義できます。Google Cloud の場合、ゾーンの停止、リージョンの停止、複数のリージョンの停止(この状況が起きることはまずありませんが)の 3 つのシナリオで要件をまとめます。

すべてのアプリケーションが同じ重要性を持つわけではないので、アプリケーションを重要性の階層で分類し、それに特定の RTO / RPO 要件を適用します。つまり、RTO / RPO とアプリケーションの重要性を定義することにより、次の質問に答えることで特定のアプリケーションの設計を効率的に進めることができます。

  1. アプリケーションを同じリージョン内の複数のゾーンで実行する必要があるか。あるいは、複数のリージョンの複数のゾーンで実行する必要があるか。
  2. アプリケーションで使用できる Google Cloud プロダクトはどれか。

以下に、要件をまとめる際の例を示します。

Example Organization Co におけるアプリケーションの重要性ごとの RTO と RPO:

アプリケーションの重要性 アプリの割合 アプリの例 ゾーンの停止 リージョンの停止
階層 1

(最も重要性が高い)

5% グローバルまたは外部ユーザー向けのアプリケーション(リアルタイムの決済システム、e コマースのショーウィンドウなど)。 RTO ゼロ

RPO ゼロ

RTO 4 時間

RPO 1 時間

階層 2 35% 標準的なリージョン アプリケーション、または重要な内部アプリケーション(CRM、ERP など)。 RTO 4 時間

RPO ゼロ

RTO 24 時間

RPO 4 時間

階層 3

(最も重要性が低い)

60% 標準的なチームまたは部門用のアプリケーション(バックオフィス、休暇の申請、出張、会計、HR など)。 RTO 12 時間

RPO 24 時間

RTO 28 日

RPO 24 時間

ステップ 2: 利用可能なプロダクトと機能をマッピングする

次に、アプリケーションが使用する Google Cloud プロダクトの耐障害性を把握します。ほとんどの企業は、関連するプロダクトの情報を確認し、その機能と耐障害性の要件のギャップを埋めるためにアーキテクチャを変更する方法についてガイダンスを追加しています。このセクションでは、一般的な領域と、この領域におけるデータまたはアプリケーションの制限に関する推奨事項について説明します。

前述のように、Google の DR 対応プロダクトはリージョンとゾーンという 2 種類の停止スコープに対応しています。部分的な停止は、DR の完全停止と同じ方法で計画する必要があります。これにより、各シナリオのデフォルトに適したプロダクトの最初のリストをまとめることができます。

Google Cloud プロダクトの全般的な機能
(特定のプロダクト機能については、付録を参照)

すべての Google Cloud プロダクト ゾーン間の自動レプリケーションが可能なリージョン Google Cloud プロダクト リージョン間の自動レプリケーション機能を備えたマルチリージョンまたはグローバル Google Cloud プロダクト
ゾーン内のコンポーネントの障害 対象* 対象 対象
ゾーンの停止 対象外 対象 対象
リージョンの停止 対象外 対象外 対象

* プロダクトのドキュメントに記載されている特別なケースを除き、すべての Google Cloud プロダクトはコンポーネントの障害に耐障害性を備えています。これは、プロダクトがメモリやソリッド ステート ディスク(SSD)などの特殊ハードウェアへの直接アクセスまたは静的マッピングを提供する標準的なシナリオになります。

RPO によるプロダクトの選択

ほとんどのクラウド環境で、サービスのアーキテクチャについて考慮すべき最も重要な点はデータの整合性です。アプリケーションの中には RPO 要件をゼロにするもの、つまり、停止時のデータ損失をゼロにしなければならないものがあります。この要件を満たすには、データを別のゾーンまたはリージョンに同期的に複製する必要があります。同期レプリケーションにはコストとレイテンシのトレードオフがあります。Google Cloud プロダクトの多くはゾーン間で同期レプリケーションを行いますが、リージョン間でのみ行うプロダクトもあります。このコストと複雑さのトレードオフは、アプリケーション内のデータの種類によって RPO 値が変わることがまずないことを意味します。

RPO がゼロより大きいデータの場合は、アプリケーションで非同期レプリケーションを利用できます。非同期レプリケーションは、失われたデータの再作成が簡単な場合や、必要に応じて確実なソースから復元できる場合に使用します。また、ゾーンとリージョンで想定される停止時間を考慮してデータの損失量が許容範囲であれば、合理的な選択になる場合もあります。また、一時的な停止であれば、影響を受けるロケーションに書き込まれたデータが他のロケーションにまだ複製されていなくても、復旧後にデータが利用可能になることもあります。これは、データを完全に損失するリスクが、停止時にデータアクセスが失われるリスクよりも低いことを意味します。

重要なアクション: RPO をゼロに設定する必要があるかどうかを判断します。その場合は、データのサブセットを対象にできるかどうかを判断します。これにより、DR 対応サービスの範囲が大幅に広がります。Google Cloud で RPO ゼロを達成するには、アプリケーションで主にリージョン プロダクトを使用する必要があります。これらのプロダクトの場合、デフォルトでゾーンスケールに対する耐障害性は提供されますが、リージョン スケールの停止に対する耐障害性は提供されません。

RTO によるプロダクトの選択

クラウド コンピューティングの主な利点の 1 つは、インフラストラクチャをオンデマンドでデプロイできることですが、瞬時にデプロイできるわけではありません。アプリケーションの RTO 値は、アプリケーションで使用する Google Cloud プロダクトの RTO と、エンジニアまたは SRE が VM またはアプリケーション コンポーネントの再起動で行うアクションの両方を考慮して調整する必要があります。RTO を分単位で設定した場合、人手を介さずに障害から自動的に回復するか、フェイルオーバー用のボタンを押すなど、最小限の手順でアプリケーションを復元できるようにアプリケーションを設計する必要があります。これまで、このようなシステムの構築には多大なコストがかかり、複雑な設計を行う必要がありましたが、ロードバランサやインスタンス グループなどの Google Cloud プロダクトでは、こうした設計をはるかにシンプルかつ簡単に行うことができます。したがって、ほとんどのアプリケーションでは、自動フェイルオーバーとリカバリを検討する必要があります。リージョン間でこのようなホット フェイルオーバーを行うシステムの設計は複雑で、コストがかかるものですが、クリティカル サービスのわずかな部分でこの機能が保証されます。

ほとんどのアプリケーションの RTO は 1 時間から 1 日です。これにより、障害シナリオでワーム フェイルオーバーが可能になります。たとえば、アプリケーションの一部のコンポーネント(データベースなど)は常時スタンバイ モードで実行し、残りのコンポーネント(ウェブサーバーなど)は実際の障害が発生したときにスケールアウトされるようにします。このようなアプリケーションでは、スケールアウト イベントの自動化を検討する必要があります。RTO が 1 日であるサービスは重要性が最も低く、多くの場合、バックアップから復元するか、最初から作り直すことができます。

重要なアクション: リージョン フェイルオーバーで RTO をゼロに設定する必要があるかどうかを判断します。その場合は、データのサブセットを対象にできるかどうかを判断します。これにより、サービスの実行と維持にかかるコストが変わります。

ステップ 3: 独自のリファレンス アーキテクチャとガイドを作成する

最後の推奨ステップは、障害復旧に関するアプローチを標準化するため、会社固有のアーキテクチャ パターンを構築することです。Google Cloud を利用している大半の企業は、個々のビジネス レジリエンスの期待値を Google Cloud の 2 つの停止シナリオに合わせるため、開発チーム用のガイドを作成しています。これにより、重要性のレベルに適した DR 対応プロダクトを簡単に分類できます。

プロダクト ガイドラインの作成

前述の RTO / RPO の例をもう一度見てください。仮説に基づいて、それぞれの重要性の層においてデフォルトで許可されるプロダクトが設定されています。特定のプロダクトが適切でないことが判明した時点で、ゾーン間またはリージョン間の同期を可能にする独自のレプリケーション / フェイルオーバー メカニズムを追加できますが、この記事の範囲を超えるため、その方法については説明しません。これらの表には、各プロダクトの詳細を確認できるリンクも記載されています。ゾーンやリージョンの停止を管理する際に利用できる機能を確認してください。

Example Organization Co のサンプル アーキテクチャ パターン - ゾーンの停止に対する耐障害性:

Google Cloud プロダクト プロダクトが Example Organization のゾーン停止要件を満たしているか(適切なプロダクト構成を含む)
階層 1 階層 2 階層 3
Compute Engine はい
データフロー × × いいえ
BigQuery × × はい
Google Kubernetes Engine はい
Cloud Storage はい
Cloud SQL × はい
Cloud Spanner はい
Cloud Load Balancing

この表は、前述の仮定の階層に基づくサンプルです。

Example Organization Co のサンプル アーキテクチャ パターン - リージョンの停止に対する耐障害性:

Google Cloud プロダクト プロダクトが Example Organization のリージョン停止要件を満たしているか(適切なプロダクト構成を含む)
階層 1 階層 2 階層 3
Compute Engine はい
データフロー × × いいえ
BigQuery × × はい
Google Kubernetes Engine はい
Cloud Storage × × いいえ
Cloud SQL はい
Cloud Spanner はい
Cloud Load Balancing

この表は、前述の仮定の階層に基づくサンプルです。

これらのプロダクトがどのように使用されるのかを説明するため、以降のセクションでは、アプリケーションに仮定した重要性レベルごとにリファレンス アーキテクチャを示します。これらは、アーキテクチャ上の重要な決定を説明するためのもので、ソリューションの全体的な設計を説明するものではありません。

階層 3 アーキテクチャの例

アプリケーションの重要性 ゾーンの停止 リージョンの停止
階層 3
(最も低い重要性)
RTO 12 時間
RPO 24 時間
RTO 28 日
RPO 24 時間

Google Cloud プロダクトを使用した階層 3 のアーキテクチャ例

(グレー表示されたアイコンは、復元を有効にするインフラストラクチャを示しています)

このアーキテクチャは、従来のクライアント / サーバー型のアプリケーションを表しています。内部ユーザーは、コンピューティング インスタンス上で動作するアプリケーションに接続しています。このインスタンスは永続ストレージとしてデータベースを使用しています。

このアーキテクチャは必要以上の RTO と RPO 値をサポートしていることに注意してください。ただし、コストが増加する可能性がある場合や、信頼性が低くなる可能性がある場合は、人手による操作の削減をさらに検討する必要があります。たとえば、夜間のバックアップからデータベースを復元した場合、24 時間の RPO に対応できますが、このような作業にはデータベース管理者などの熟練したスタッフが必要になります。しかし、このようなスタッフを割り当てられるとは限りません。特に、複数のサービスが同時に影響を受けている場合はなおさらです。Google Cloud のオンデマンド インフラストラクチャでは、コスト増大のトレードオフを気にすることなく、こうした機能を構築できます。このアーキテクチャの場合、ゾーンの停止に手動によるバックアップと復元を行うのではなく、Cloud SQL HA を使用することにします。

ゾーン停止に対するアーキテクチャ上の重要な決定 - RTO 12 時間と RPO 24 時間

  • 内部ロードバランサは、ユーザーにスケーラブルなアクセス ポイントを提供し、別のゾーンへの自動フェイルオーバーを可能にするために使用しています。RTO は 12 時間ですが、IP アドレスや DNS の更新を手動で行う場合は、想定以上に時間がかかる場合があります。
  • リージョンのマネージド インスタンス グループは複数のゾーンから構成されていますが、リソースは最小限になっています。これにより、コストが最適化されます。また、仮想マシンをバックアップ ゾーンに迅速にスケールアウトできます。
  • 高可用性のある Cloud SQL 構成により、別のゾーンへの自動フェイルオーバーを可能にしています。Compute Engine 仮想マシンと比べると、データベースの再作成と復元は非常に困難な作業となります。

リージョン停止に対するアーキテクチャ上の重要な決定 - RTO 28 日と RPO 24 時間

  • リージョンが停止した場合、ロードバランサはリージョン 2 のみで構築されます。リージョン 2 のインフラストラクチャはリージョン停止時にのみ利用可能なため、Cloud DNS を使用して、オーケストレートされたリージョン フェイルオーバーを手動で行えるようにしています。
  • 新しいマネージド インスタンス グループは、リージョンが停止した場合にのみ構築されます。これによりコストが最適化されます。ほとんどのリージョンの停止は短時間になり、呼び出される可能性はほとんどなくなります。わかりやすくするため、この図には再デプロイに必要な関連ツールや Compute Engine イメージのコピーは含まれていません。
  • 新しい Cloud SQL インスタンスが再作成され、データがバックアップから復元されます。ここでも 1 つのリージョンが長期間停止するリスクは極めて低いため、コスト最適化のトレードオフになります。
  • これらのバックアップを保存するために、マルチリージョンの Cloud Storage が使用されます。これにより、RTO と RPO 内でのゾーンとリージョンの自動復元が可能となります。

階層 2 アーキテクチャの例

アプリケーションの重要性 ゾーンの停止 リージョンの停止
階層 2 RTO 4 時間
RPO ゼロ
RTO 24 時間
RPO 4 時間

Google Cloud プロダクトを使用した階層 2 のアーキテクチャ例

このアーキテクチャは、内部ユーザーがコンピューティング インスタンスの可視化レイヤに接続し、データの取り込み / 変換レイヤがバックエンド データ ウェアハウスにデータを送信するデータ ウェアハウスを表しています。

このアーキテクチャの個々のコンポーネントは、この階層に必要な RPO に直接対応していませんが、これらのコンポーネントを組み合わせて使用することで、全体的なサービスが RPO を満たすことになります。この場合、Dataflow はゾーン プロダクトのため、ゾーン停止中のデータ損失を防ぐための高可用性設計の推奨事項に従う必要があります。ただし、Cloud Storage レイヤはこのデータの確実なソースであり、RPO はゼロです。つまり、ゾーン a が停止した場合、失われたデータはゾーン b を介して BigQuery に取り込むことが可能です。

ゾーン停止に対するアーキテクチャ上の重要な決定 - RTO 4 時間と RPO ゼロ

  • ロードバランサは、ユーザーにスケーラブルなアクセス ポイントを提供し、別のゾーンへの自動フェイルオーバーを可能にするために使用しています。RTO は 4 時間ですが、IP アドレスや DNS の更新を手動で行う場合は、想定以上に時間がかかる場合があります。
  • データ可視化のコンピューティング レイヤのリージョン マネージド インスタンス グループは複数のゾーンから構成されていますが、リソースは最小限になっています。これにより、コストが最適化されます。また、仮想マシンを迅速にスケールアウトできます。
  • リージョンの Cloud Storage は、データの最初の取り込みのステージング レイヤとして使用され、ゾーンの自動復元を可能にします。
  • Dataflow は、Cloud Storage からデータを抽出し、BigQuery にデータを読み込む前に変換を行います。これはステートレス プロセスのため、ゾーンが停止しても別のゾーンで再開できます。
  • BigQuery は、データ可視化のフロントエンドに対するデータ ウェアハウス バックエンドです。ゾーンが停止した場合、失われたデータは Cloud Storage から取り込まれます。

リージョン停止に対するアーキテクチャ上の重要な決定 - RTO 24 時間と RPO 4 時間

  • 各リージョンのロードバランサを使用して、ユーザーにスケーラブルなアクセス ポイントを提供します。リージョン 2 のインフラストラクチャはリージョン停止時にのみ利用可能なため、Cloud DNS を使用して、オーケストレートされたリージョン フェイルオーバーを手動で行えるようにしています。
  • データ可視化のコンピューティング レイヤのリージョン マネージド インスタンス グループは複数のゾーンから構成されていますが、リソースは最小限になっています。ロードバランサが再構成されるまではアクセスできません。再構成後は手動による操作は不要です。
  • リージョンの Cloud Storage は、データの最初の取り込みでステージング レイヤとして使用されます。RPO の要件を満たすため、両方のリージョンで同時に読み込まれます。
  • Dataflow は、Cloud Storage からデータを抽出し、BigQuery にデータを読み込む前に変換を行います。リージョンが停止した場合、BigQuery に Cloud Storage から最新データが提供されます。
  • BigQuery は、データ ウェアハウスのバックエンドを提供します。通常のオペレーションでは、これは断続的に更新されます。リージョンが停止した場合、Dataflow 経由で Cloud Storage から最新のデータが取り込まれます。

階層 1 アーキテクチャの例

アプリケーションの重要性 ゾーンの停止 リージョンの停止
階層 1
(最重要)
RTO ゼロ
RPO ゼロ
RTO 4 時間
RPO 1 時間

Google Cloud プロダクトを使用した階層 1 のアーキテクチャ例

このアーキテクチャは、外部ユーザーが Google Kubernetes Engine 上の一連のマイクロサービスに接続するモバイルアプリのバックエンド インフラストラクチャを表します。Cloud Spanner はリアルタイム データ用のバックエンド データ ストレージ レイヤを提供します。履歴データが各リージョンの BigQuery データレイクにストリーミングされます。

このアーキテクチャの個々のコンポーネントは、この階層に必要な RPO に直接対応していませんが、これらのコンポーネントを併用することで、サービス全体で RPO を満たします。この場合、BigQuery が分析クエリに使用されています。各リージョンは Cloud Spanner から同時にフィードされます。

ゾーン停止に対するアーキテクチャ上の重要な決定 - RTO ゼロと RPO ゼロ

  • ロードバランサは、ユーザーにスケーラブルなアクセス ポイントを提供し、別のゾーンへの自動フェイルオーバーを可能にするために使用しています。
  • リージョンの Google Kubernetes Engine クラスタは、複数のゾーンにまたがるアプリケーション レイヤで使用されます。これにより、各リージョン内で RTO がゼロになります。
  • マルチリージョンの Cloud Spanner はデータ永続性レイヤとして使用され、ゾーンデータの自動復元とトランザクションの整合性を実現します。
  • BigQuery は、アプリケーションの分析機能を提供します。各リージョンは Cloud Spanner から独立してデータをフィードし、アプリケーションから独立してアクセスされます。

リージョン停止に対するアーキテクチャ上の重要な決定 - RTO 4 時間と RPO 1 時間:

  • 内部ロードバランサは、ユーザーにスケーラブルなアクセス ポイントを提供し、別のリージョンへの自動フェイルオーバーを可能にするために使用しています。
  • リージョンの Google Kubernetes Engine クラスタは、複数のゾーンにまたがるアプリケーション レイヤで使用されます。リージョンが停止した場合、追加の負荷に合わせて別のリージョンのクラスタが自動的にスケーリングされます。
  • マルチリージョンの Cloud Spanner はデータ永続性レイヤとして使用され、リージョン データの自動復元とトランザクションの整合性を実現します。これは、1 時間のクロスリージョン RPO を達成するための重要な要素です。
  • BigQuery は、アプリケーションの分析機能を提供します。各リージョンは Cloud Spanner から独立してデータをフィードし、アプリケーションから独立してアクセスされます。このアーキテクチャで BigQuery のコンポーネントを補完することで、アプリケーション全体の要件を達成できます。

付録: プロダクト リファレンス

このセクションでは、お客様のアプリケーションで最もよく利用され、DR 要件の実現に簡単に利用できる Google Cloud プロダクトのアーキテクチャと DR 機能について説明します。

共通のテーマ

多くの Google Cloud プロダクトは、リージョンまたはマルチリージョン構成を提供しています。リージョン プロダクトはゾーンの停止に対する耐障害性を備えています。また、マルチリージョン プロダクトとグローバル プロダクトはリージョンの停止に対して耐障害性を備えています。これは、停止中のアプリケーションの中断が最小限に抑えられることを意味します。Google では、上記のアーキテクチャの説明と同じく、一般的なアーキテクチャ アプローチによってこの結果を実現しています。

  • 冗長デプロイ: アプリケーションのバックエンドとデータ ストレージは、リージョン内の複数のゾーンにデプロイされています。さらに、マルチリージョン ロケーションの場合は、複数のリージョンにデプロイされます。
  • データ レプリケーション: プロダクトは、冗長なロケーション間で同期レプリケーションまたは非同期レプリケーションのいずれかを使用します。

    • 同期レプリケーションでは、アプリケーションが API 呼び出しを行い、プロダクトがデータの作成または変更を行ったときに、プロダクトが複数のロケーションでデータを完了した場合にのみ、成功のレスポンスが返されます。同期レプリケーションを使用している場合、Google Cloud インフラストラクチャが停止してもデータにアクセスできなくなることはありません。すべてのデータが使用可能なバックエンド ロケーションのいずれかに存在しているためです。

      この方法では、データの保護は最大限になりますが、レイテンシとパフォーマンスの点でトレードオフがあります。同期レプリケーションを使用するマルチリージョン プロダクトでは、このトレードオフが最大になります。通常、レイテンシが追加し、10 ミリ秒または 100 ミリ秒単位で遅延が発生します。

    • 非同期レプリケーションでは、アプリケーションが API 呼び出しを行い、プロダクトがデータを作成または変更したときに、プロダクトが 1 つのロケーションで書き込みを完了すると、成功のレスポンスが返されます。書き込みリクエストの後に、プロダクトは別のロケーションにデータを複製します。

      この方法では、同期レプリケーションよりも API のレイテンシが短くなり、スループットが向上しますが、データの保護という点では弱くなります。レプリケーションが完了する前にデータの書き込み先のロケーションで障害が発生すると、そのロケーションが復旧するまで、データにはアクセスできなくなります。

  • 負荷分散による対応: Google Cloud では、ソフトウェア負荷分散を使用して、適切なアプリケーション バックエンドにリクエストをルーティングしています。DNS の負荷分散などの場合と異なり、この方法ではシステム停止に対応するまでの時間が短くなります。Google Cloud のロケーションが停止すると、ロードバランサは、そのロケーションにデプロイしたバックエンドが「異常な状態」になったことを瞬時に検出し、すべてのリクエストを別の場所にあるバックエンドに転送します。これにより、ロケーションが停止している間でも、プロダクトはアプリケーションのリクエスト処理を続行できます。ロケーションが復旧すると、ロードバランサはそのロケーションにあるプロダクト バックエンドの可用性を確認し、トラフィックの送信を再開します。

Compute Engine

Compute Engine は Google Cloud の IaaS(Infrastructure-as-a-Service)です。世界各地にある Google のインフラストラクチャを使用して、お客様に仮想マシン(および関連サービス)を提供しています。

Compute Engine インスタンスはゾーンリソースのため、デフォルトではゾーンが停止しているインスタンスを使用できません。Compute Engine は、マネージド インスタンス グループ(MIG)を提供しています。これにより、事前構成のインスタンス テンプレートを使用して、リージョン内の単一ゾーンまたはソーン間で追加の VM を自動的にスケールアップできます。MIG は、ゾーン損失に対して強い耐障害性が必要で、ステートレスではないアプリケーションに適しています。ただし、構成とリソース計画が必要です。ステートレス アプリケーションのリージョンの耐障害性を実現するには、複数のリージョン MIG を使用できます。

ステートフル ワークロードを使用するアプリケーションでは、引き続きステートフル MIG(ベータ版)を使用できます。ただし、水平方向にスケーリングされないため、キャパシティ プランニングを行う際に注意が必要です。いずれの場合も、Compute Engine インスタンス テンプレートと MIG を適切に構成し、他のゾーンにフェイルオーバーされるように、事前にテストを行っておく必要があります。詳細については、上記のアーキテクチャ パターンをご覧ください。


Dataproc

Dataproc は、ストリーミングとバッチデータ処理の機能を提供します。Dataproc はリージョン コントロール プレーンとして設計され、ユーザーが Dataproc クラスタを管理できます。コントロール プレーンはリージョン内の個々のゾーンに依存しません。したがって、ゾーンが停止しても、Dataproc API へのアクセスは維持され、新しいクラスタの作成も可能です。

クラスタは Compute Engine で実行されます。クラスタはゾーンリソースのため、ゾーンが停止すると、クラスタが利用不能になるか破棄されます。Dataproc は、クラスタ ステータスのスナップショットを自動的に生成するわけではないため、ゾーンが停止すると、処理中のデータが失われる可能性があります。Dataproc はサービス内でユーザーデータを保持します。ユーザーは、多数のデータストアに結果を書き込むようにパイプラインを構成できます。その際、データストアのアーキテクチャを検討し、必要な障害復旧を行う選択する必要があります。

ゾーンが停止状態になった場合、別のゾーンを選択するか、Dataproc の自動プレースメント機能で利用可能なゾーンを自動的に選択することで、別のゾーンにクラスタの新しいインスタンスを別の再作成できます。クラスタが使用可能になると、データ処理を再開できます。また、高可用性モードを有効にして、クラスタを実行することもできます。これにより、ゾーンの一部停止がマスターノード、つまりクラスタ全員に影響を与える可能性を抑えることができます。


Dataflow

Dataflow は、ストリーミングとバッチ パイプライン用の Google Cloud のフルマネージド サーバーレス データ処理サービスです。Dataflow のジョブはゾーンリソースです。デフォルトの構成では、ゾーンの停止中にデータの中間計算結果を保持しません。こうしたデフォルトの Dataflow パイプラインの一般的な復旧方法は、別のゾーンまたはリージョンにあるジョブを再起動して、入力データを再処理する方法です。

高可用性のための Dataflow パイプラインの設計

ゾーンやリージョンが停止した場合、Pub/Sub トピックに同じサブスクリプションを再利用することで、データの損失を回避できます。1 回限りの保証の一環として、Dataflow は、メッセージが宛先に保持されている場合、またはグループ化 / 時間ウィンドウ処理によって受信したメッセージが Dataflow の耐久性パイプライン状態で保存された場合にのみ、Pub/Sub のメッセージを確認します。グループ化 / 時間処理のオペレーションがない場合、サブスクリプションを再利用して別のゾーンまたはリージョンの別の Dataflow ジョブにフェイルオーバーすることで、パイプライン出力データの損失を防ぐことができます。

パイプラインでグループ化または時間ウィンドウ処理を使用している場合、ゾーンまたはリージョンの停止の後に Kafka の Pub/Sub またはリプレイ機能を使用して、同じ検索結果になったデータ要素を再処理できます。パイプラインが使用するビジネス ロジックが停止前のデータに依存していない場合は、パイプライン出力のデータ損失を 0 要素に抑えることができます。パイプラインのビジネス ロジックが停止前に処理されたデータに依存している場合(たとえば、長いスライド ウィンドウが使用されている場合や、グローバル時間ウィンドウで表示にカウンタが使用されている場合など)は、Dataflow はスナップショット機能(現在プレビュー版)を使用し、パイプラインの状態のスナップショップをバックアップとして提供できます。


BigQuery

BigQuery は、ビジネスのアジリティを高めるように設計されたサーバーレスでスケーラビリティと費用対効果の高いデータ ウェアハウスです。BigQuery では、ユーザー データセットに対して 2 つの可用性関連の構成オプションをサポートしています。

単一リージョン構成

単一リージョン構成では、データは 1 つのリージョン内の 2 つのゾーンに冗長的に保存されます。BigQuery に書き込まれたデータは、最初にプライマリ ゾーンに書き込まれ、その後セカンダリ ゾーンに非同期で複製されます。これにより、リージョン内の単一のゾーンが使用不能になります。ゾーン停止時にプライマリ ゾーンに書き込まれてもセカンダリ ゾーンに複製されていないデータは、停止から復旧するまで使用できません。ゾーンが破棄された場合、そのデータは完全に失われる可能性があります。

マルチリージョン(米国 / EU)構成

単一リージョン構成と同様に、マルチリージョン構成(米国 / EU)でも、データは 1 つのリージョン内の 2 つのゾーンに冗長的に保存されます。また、BigQuery は、第 2 リージョンにデータのバックアップ コピーを保持します。プライマリ リージョンでサービスが停止すると、データはセカンダリ リージョンから提供されます。複製されていないデータは、プライマリ リージョンが復旧するまで使用できません。


Google Kubernetes Engine

Google Kubernetes Engine(GKE)は、Google Cloud にコンテナ化されたアプリケーションをストリーミングでデプロイすることで、Kubernetes マネージド サービスを提供します。リージョンまたはクラスタゾーンのトポロジを選択できます。

  • ゾーンクラスタを作成すると、GKE は選択したゾーンに 1 つのコントロール プレーン マシンをプロビジョニングします。また、同じゾーン内にワーカーマシン(ノード)をプロビジョニングします。
  • リージョン クラスタの場合、GKE は 3 つのコントロール プレーン マシンを、選択したリージョン内の 3 つの異なるゾーンにプロビジョニングします。デフォルトでは、ノードが 3 つのゾーンにまたがっていますが、1 つのゾーンのみにプロビジョニングされるノードを含むリージョン クラスタを作成することもできます。
  • マルチゾーン クラスタはゾーンクラスタに似ていますが、マスターマシンが 1 つ含まれているのため、複数のゾーンのノード間にまたがることもできます。

ゾーンの停止: ゾーンの停止を回避するには、リージョン クラスタを使用します。コントロール プレーンとノードは、リージョン内の 3 つの異なるゾーンに分散されます。ゾーンが停止しても、他の 2 つのゾーンにデプロイされているコントロール プレーンとワーカーノードに影響はありません。

リージョンの停止: リージョンの停止を回避するには、複数のリージョンにまたがるデプロイが必要になります。現在のところ、組み込みプロダクトの機能として提供されていませんが、マルチリージョン トポロジは GKE の複数のユーザーで現在採用されているアプローチで、手動での実装も可能です。複数のリージョン クラスタを作成して、複数のリージョンにワークロードを複製し、マルチクラスタの Ingress を使用してクラスタへのトラフィックを制御できます。


Cloud Key Management Service

Cloud Key Management Service(Cloud KMS)は、スケーラブルで耐久性に優れた暗号鍵リソースの管理機能を提供します。Cloud KMS では、すべてのデータとメタデータが Cloud Spanner データベースに保存され、同期レプリケーションによってデータの耐久性と可用性が高めることができます。

Cloud KMS リソースは、単一のリージョン、マルチリージョン、またはグローバルに作成できます。

ゾーンが停止しても、Cloud KMS は、同じまたは異なるリージョンの別のゾーンからのリクエストを中断なく処理します。データは同期的に複製されるため、データの損失や破損はありません。ゾーンが停止から復旧すると、完全な冗長性が復元されます。

リージョンが停止した場合、そのリージョンが再び使用可能になるまで、そのリージョン内のリソースはオフラインになります。1 つのリージョン内で、少なくとも 3 つのレプリカが別々のゾーンで管理されます。高可用性が必要な場合は、リソースをマルチリージョンまたはグローバル構成に保存する必要があります。マルチリージョン構成とグローバル構成は、複数のリージョンでデータを地理的に冗長化して提供することで、1 つのリージョンが停止しても、可能性を維持できるように設計されています。


Cloud Identity

Cloud Identity サービスは複数のリージョンに分散し、動的な負荷分散を使用します。Cloud Identity では、ユーザーがリソース スコープを選択することはできません。特定のゾーンまたはリージョンでサービスが停止した場合、トラフィックは他のゾーンまたはリージョンに自動的に分散されます。

ほとんどの場合、永続データは同期レプリケーションで複数のリージョンにミラーリングされます。一部のシステムは、キャッシュや多くのエンティティに影響を及ぼす変更などのパフォーマンス上の理由により、リージョン間で非同期に複製されます。最新のデータが保存されているプライマリ リージョンが停止すると、Cloud Identity は、プライマリ リージョンが使用可能になるまで別の場所からデータを提供しますが、これは最新のデータではありません。


Persistent Disk

Persistent Disk は、ゾーン構成とリージョン構成で使用できます。

ゾーンの Persistent Disk は単一ゾーンにホストされます。ディスクのゾーンが使用不能になると、そのゾーンが復旧するまで Persistent Disk は使用できなくなります。

リージョンの Persistent Disk の場合、リージョン内の 2 つのゾーン間でデータの同期レプリケーションが行われます。仮想マシンのゾーンが停止すると、ディスクのセカンダリ ゾーンの VM インスタンスにリージョン Persistent Disk を強制的にアタッチできます。このタスクを行うには、そのゾーンで別の VM インスタンスを起動するか、そのゾーン内でホット スタンバイ状態の VM インスタンスを維持する必要があります。


Cloud Storage

Cloud Storage は、グローバルに分散され、スケーラビリティと耐久性に優れたオブジェクト ストレージを提供します。Cloud Storage バケットは、大陸内の単一リージョン、デュアル リージョン、またはマルチリージョンに作成できます。

ゾーンが停止した場合、使用できないゾーン内のデータは、リージョン内の他のリージョンに自動的かつ透過的に送信されます。データとメタデータは、最初の書き込みからゾーン間で冗長に保存されます。ゾーンが使用不能になっても、書き込みは失われません。

リージョンが停止した場合、そのリージョンが復旧するまで、そのリージョンのリージョン バケットはオフラインになります。高可用性が必要な場合は、デュアルリージョン構成またはマルチリージョン構成にデータを保存することを検討してください。デュアルリージョンとマルチリージョンは、非同期レプリケーションを使用して複数のリージョンにデータを格納し、地理的な冗長性を保持することで、1 つのリージョンが停止しても可能性を維持できるように設計されています。

Cloud Storage は Cloud Load Balancing を使用して、複数のリージョンからデュアルリージョン バケットとマルチリージョン バケットを提供します。リージョンが停止してもサービスは中断されません。地域的な冗長性は非同期的に行われるため、最近書き込まれた一部のデータにアクセスできない場合があります。また、影響を受けたリージョンでデータが物理的に破壊され、失われる可能性もあります。


Container Registry

Container Registry は、Docker コンテナ イメージを安全かつ限定公開で保存するスケーラブルな Docker Registry を実装します。Container Registry は HTTP Docker Registry API を実装します。

Container Registry は、デフォルトで複数のゾーンまたはリージョンでイメージ メタデータを同期的に保存するグローバル サービスです。コンテナ イメージは Cloud Storage マルチリージョン バケットに保存されます。このストレージ戦略では、Container Registry はすべてのケースでゾーンの停止に対する耐障害性を提供します。Cloud Storage によって複数のリージョンに非同期で複製されたデータについては、リージョンの停止に対する耐障害性を提供します。


Pub/Sub

Pub/Sub は、アプリケーションの統合とストリーム分析で使用されるメッセージング サービスです。Pub/Sub トピックはグローバルです。つまり、これらのトピックは、Google Cloud のすべてのロケーションで表示し、アクセスできます。ただし、メッセージはパブリッシャーに最も近く、リソース ロケーション ポリシーで許可されている単一の Google Cloud リージョンに保存されます。したがって、1 つのトピックが Google Cloud 全体の複数のリージョンに保存されることがあります。Pub/Sub メッセージ ストレージ ポリシーにより、メッセージが保存されるリージョンを制限できます。

ゾーンの停止: Pub/Sub メッセージが公開されると、そのメッセージはリージョン内の 2 つ以上のゾーンのストレージに書き込まれます。したがって、1 つのゾーンが使用不能になっても、ユーザーに対する影響はありません。

リージョンの停止: リージョンが停止した場合、そのリージョン内に保存されているメッセージにはアクセスできません。トピックとサブスクリプションの作成や削除などを行う管理オペレーションはマルチリージョンで、単一の Google Cloud リージョンの停止に対して耐障害性があります。パブリッシュ オペレーションは、メッセージ ストレージ ポリシーで許可されているリージョンの少なくとも 1 つが使用可能であり、アプリケーションがグローバル エンドポイント(pubsub.googleapis.com)または複数のリージョン エンドポイントを使用いていれば、リージョンが停止しても使用できます。デフォルトでは、Pub/Sub はメッセージの保存場所を制限しません。

アプリケーションでメッセージの順序指定に依存している場合は、Pub/Sub チームからの詳細な推奨事項を確認してください。メッセージの順序指定の保証はリージョンごとに行われ、グローバル エンドポイントを使用すると中断される可能性があります。


Cloud Composer

Cloud Composer は、Google Cloud が管理する Apache Airflow の実装です。Cloud Composer はリージョン コントロール プレーンとして設計され、ユーザーが Cloud Composer クラスタを管理できます。コントロール プレーンはリージョン内の個々のゾーンに依存しません。したがって、ゾーンが停止しても、Cloud Composer API へのアクセスは維持され、新しいクラスタの作成も可能です。

クラスタは Google Kubernetes Engine で実行されます。クラスタはゾーンリソースのため、ゾーンが停止すると、クラスタが利用不能になるか破棄されます。停止時に実行されていたワークフローは完了前に停止する場合があります。つまり、停止が発生すると、部分的に実行されたワークフローの状態(ワークフローでユーザーが行った外部アクションも含む)が失われます。ワークフローによっては、外部との不整合が生じる場合があります。たとえば、外部データストアを変更するマルチステップの実行中にワークフローが停止すると、このような状況が発生します。したがって、Airflow ワークフローを設計する場合は、部分的に実行されていないワークフローの状態を検出し、部分的に変更されたデータを修復するなどの復旧プロセスを検討する必要があります。

ゾーンが停止した場合、Cloud Composer を使用して別のゾーンでクラスタの新しいインスタンスを開始できます。クラスタが使用可能になると、ワークフローを再開できます。必要に応じて、アイドル状態のレプリカ クラスタを別のゾーンで実行し、ゾーンが停止したときに、そのレプリカを切り替えることもできます。


Cloud SQL

Cloud SQL は、MySQL、PostgreSQL、SQL Server 用のフルマネージド リレーショナル データベース サービスです。Cloud SQL は、Compute Engine で管理された仮想マシンを使用してデータベース ソフトウェアを実行します。リージョン冗長性を実現する高可用性構成を提供し、ゾーンの停止からデータベースを保護します。クロスリージョン レプリカをプロビジョニングして、リージョンの停止からデータベースを保護できます。このプロダクトには、リージョンやゾーンの停止の影響を受けないゾーン オプションもあります。高可用性構成、クロスリージョン レプリカ、またはその両方を慎重に選択する必要があります。

ゾーンの停止: 高可用性オプションにより、1 つのリージョン内の 2 つのゾーンにプライマリ VM とスタンバイ VM インスタンスを作成します。通常のオペレーションでは、プライマリ VM インスタンスがすべてのリクエストを処理し、データベース ファイルをリージョン Persistent Disk に書き込みます。このファイルをプライマリ ゾーンとスタンバイ ゾーンに同期的に複製します。ゾーンの停止でプライマリ インスタンスに影響が生じた場合、Cloud SQL はフェイルオーバーを開始し、その間は Persistent Disk がスタンバイ VM にアタッチされ、トラフィックのルートが変更されます。

このプロセスでデータベースの初期化が必要になります。これには、トランザクション ログに書き込まれ、データベースに適用されていないトランザクションの処理も含まれます。未処理のトランザクションの数と種類によっては RTO 時間が増加する可能性があります。最近の書き込みが多いと、未処理のトランザクションのバックログにつながる可能性があります。RTO 時間は、(a)最近の書き込みアクティビティと(b)データベース スキーマに対する最近の変更によって大きく変わります。

最後に、ゾーンが復旧したら、プライマリ ゾーンでのサービスを再開するため、フェイルバック オペレーションを手動でトリガーします。

高可用性オプションの詳細については、Cloud SQL 高可用性のドキュメントをご覧ください。

リージョンの停止: クロスリージョン レプリカ オプションにより、他のリージョンでプライマリ インスタンスのリードレプリカを作成し、リージョンの停止からデータベースを保護します。クロスリージョン レプリケーションでは、非同期レプリケーションを使用します。これにより、プライマリ インスタンスは、レプリカで commit される前にトランザクションを commit できます。トランザクションがプライマリ インスタンスで commit されてからレプリカで commit されるタイミングの差をレプリケーション ラグといいます(これはモニタリング可能です)。この指標には、プライマリからレプリカに送信されていないトランザクションだけでなく、レプリカで処理されていない受信済みのトランザクションも反映されます。レプリカに送信されなかったトランザクションは、リージョンの停止時に使用できなくなります。レプリカで処理されていない受信済みのトランザクションは、次のようにリカバリ時間に影響します。

Cloud SQL では、レプリカを含む構成でワークロードのテストを行い、TPS(1 秒あたりのトランザクション)の安全な上限を設定することを推奨しています。この上限は、レプリケーション ラグが蓄積しない最長の TPS となります。ワークロードが TPS の安全な上限を超えると、レプリケーション ラグが蓄積され、RPO 値と RTO 値に悪影響を及ぼす可能性があります。一般的なガイダンスとして、小規模なインスタンス構成(1 個の vCPU コア、100 GB 未満のディスク、PD-HDD)は避けてください。この構成ではレプリケーション ラグの影響を受けやすくなります。

リージョンが停止した場合、リードレプリカを手動で昇格するかどうかを決定する必要があります。昇格はスプリット ブレインが発生するため、手動オペレーションになります。スプリット ブレイン状態になると、昇格時にプライマリ インスタンスで遅延が発生しているにもかかわらず、昇格したレプリカが新しいトランザクションを受け入れます。このため、リージョンが復旧したときに問題が発生した場合、プライマリ インスタンスからレプリカ インスタンスに伝播されていないトランザクションを調整する必要があります。これが要件に反する場合は、Cloud Spanner など、クロスリージョンの同期データベース プロダクトの使用を検討してください。

ユーザーが昇格プロセスをトリガーすると、高可用性構成でのスタンバイ インスタンスの有効化と同様の処理が行われます。リードレプリカはトランザクション ログを処理し、ロードバランサはトラフィックをリダイレクトする必要があります。トランザクション ログを処理すると、復元までの合計時間が長くなります。

クロスリージョン レプリカのオプションの詳細については、Cloud SQL のクロスリージョン レプリカのドキュメントをご覧ください。


Cloud Logging

Cloud Logging は、ログルーターと Cloud Logging ストレージの 2 つの部分から構成されています。

ログルーターはストリーミング ログイベントを処理し、ログを Cloud Storage、Pub/Sub、BigQuery、Cloud Logging ストレージに転送します。

Cloud Logging ストレージは、ログの保存、クエリ、コンプライアンスの管理を行うサービスです。開発、コンプライアンス対応、トラブルシューティング、プロアクティブなアラートなど、多くのユーザーやワークフローに対応しています。

ログルーターと受信ログ: ゾーンの停止中、Cloud Logging API がリージョン内の他のゾーンにログをルーティングします。通常、ログルーターから Cloud Logging、BigQuery、または Pub/Sub にルーティングされるログは、できるだけ早く最終的な宛先に書き込まれますが、Cloud Storage に送信されるログはバッファに格納され、1 時間ごとにまとめて書き込まれます。

ログエントリ: ゾーンまたはリージョンが停止すると、影響を受けるゾーンまたはリージョンのバッファに格納され、エクスポート先に書き込まれていないログエントリにはアクセスできなくなります。また、ログベースの指標はログルーターで計算され、同じ制約の対象になります。選択したエクスポート先に配信されると、宛先のサービスによってログが複製されます。Cloud Logging ストレージにエクスポートされたログは、リージョン内の 2 つのゾーンに同期的に複製されます。他の宛先タイプの複製動作については、この記事の関連セクションをご覧ください。Cloud Storage にエクスポートされたログは、1 時間ごとにバッチ処理され、書き込まれることに注意してください。そのため、Cloud Logging ストレージ、BigQuery、または Pub/Sub を使用して、サービス停止の影響を受けるデータ量を最小限に抑えることをおすすめします。

ログのメタデータ: シンクや除外構成などのメタデータはグローバルに保存されますが、リージョンのキャッシュに保存されます。停止した場合は、リージョンのログルーター インスタンスが動作します。1 つのリージョンが停止しても、それ以外のリージョンに影響はありません。

Cloud Spanner

Cloud Spanner は、リレーショナル セマンティクスを持つ、スケーラブルで可用性が高く、マルチバージョンで、同期的に複製され、強整合性を備えたデータベースです。

リージョンの Cloud Spanner インスタンスは、単一リージョン内の 3 つのゾーン間でデータを同期的に複製します。リージョン Cloud Spanner インスタンスへの書き込みは、3 つのレプリカすべてに同期的に送信され、少なくとも 2 つのレプリカ(3 つのうち 2 つの過半数のクォーラム)が書き込みを commit した後、クライアントに承認されます。これにより、最新の書き込みが保持され、書き込みの過半数のクォーラムが 2 つのレプリカで引き続き達成されるため、すべてのデータに対するアクセスを提供してゾーン障害に対する Cloud Spanner の復元性を高めることができます。

Cloud Spanner のマルチリージョン インスタンスには、3 つのリージョンにある 5 つのゾーンでデータが同期的に複製される書き込みクォーラムが含まれます(デフォルトのリーダー リージョンと別のリージョンにそれぞれ 2 つの読み取り / 書き込みレプリカ、ウィットネス リージョンに 1 つのレプリカ)。マルチリージョンの Cloud Spanner インスタンスへの書き込みは、少なくとも 3 つのレプリカ(5 つのうち 3 つの過半数のクォーラム)が書き込みを commit した後に確認されます。ゾーンまたはリージョンの障害が発生した場合、Cloud Spanner はすべてのデータ(最新の書き込みを含む)にアクセスし、読み取り / 書き込みリクエストを処理します。データは、クライアントへの書き込みが承認されたときに 2 つのゾーンの 3 つ以上のゾーンで保持されます。

これらの構成の詳細については、Cloud Spanner のインスタンスのドキュメントをご覧ください。また、Cloud Spanner レプリケーションの仕組みの詳細については、レプリケーションのドキュメントをご覧ください。