プラットフォームの可用性で説明したように、Google Cloud インフラストラクチャは、単一のゾーンにデプロイされたワークロードに対して 99.9% の可用性目標をサポートするように設計されています。ターゲットの可用性は、マルチゾーン デプロイで 99.99%、マルチリージョン デプロイで 99.999% です。1Google Cloud インフラストラクチャの信頼性ガイドのこのパートでは、リソース、ゾーン、リージョンレベルの障害に対するワークロードの保護に役立つデプロイ ガイダンス、アーキテクチャの例、設計手法について説明します。
単一障害点の回避
通常、アプリケーションは相互に依存する複数のコンポーネントで構成され、それぞれが特定の機能を実行するように設計されています。これらのコンポーネントは通常、実行する機能と他のコンポーネントとの関係に基づいて階層にグループ化されます。たとえば、コンテンツ提供アプリケーションには 3 つの階層があります。ロードバランサとウェブサーバーを含むウェブ階層、アプリケーション サーバーのクラスタがあるアプリ階層、永続性のためのデータ階層です。このアプリケーション スタックのいずれかのコンポーネントが単一のインフラストラクチャ リソースに依存している場合、そのリソースの障害がスタック全体の可用性に影響する可能性があります。たとえば、アプリ階層が単一の VM で実行されていて、その VM がクラッシュすると、スタック全体が実質的に使用できなくなります。このようなコンポーネントは、単一障害点（SPOF）です。
アプリケーション スタックには複数の SPOF が存在することがあります。次の図に示す多層アプリケーション スタックについて考えてみましょう。
上の図に示すように、この例のアーキテクチャには、1 つのロードバランサ、2 つのウェブサーバー、1 つのアプリサーバー、1 つのデータベースが含まれています。この例のロードバランサ、アプリサーバー、データベースは SPOF です。これらのコンポーネントのいずれかで障害が発生すると、アプリケーションへのユーザー リクエストが失敗する可能性があります。
アプリケーション スタックから SPOF を削除するには、ロケーション間でリソースを分散し、冗長リソースをデプロイします。
リソースの分散と冗長性の作成
アプリケーションの信頼性要件に応じて、次のデプロイ アーキテクチャから選択できます。
| アーキテクチャ | ワークロードの推奨事項 |
|---|---|
| マルチリージョン | 小売アプリケーションやソーシャル メディア アプリケーションなど、ビジネス クリティカルで高可用性が不可欠なワークロード。 |
| 複数のゾーン | ゾーンの停止に対する復元力が求められるが、リージョンの停止に起因するダウンタイムを許容できるワークロード。 |
| シングルゾーン | ダウンタイムを許容できるワークロード、または必要に応じて最小限の労力で別のロケーションにデプロイできるワークロード。 |
費用、レイテンシ、運用に関する考慮事項
冗長リソースを使用する分散アーキテクチャを設計する場合は、アプリケーションの可用性要件だけでなく、運用の複雑さ、レイテンシ、費用への影響も考慮する必要があります。
分散アーキテクチャでは、より多くのリソースをプロビジョニングして管理します。クロスロケーション ネットワーク トラフィックの量が増加します。また、より多くのデータを保存し、複製できます。その結果、分散アーキテクチャのクラウド リソースのコストは高くなり、このようなデプロイメントの運用はより複雑になります。ビジネス クリティカルなアプリケーションの場合、分散アーキテクチャの可用性の利点が、コストの増加と運用の複雑さを上回る場合があります。
ビジネス クリティカルでないアプリケーションの場合、分散アーキテクチャが提供する高可用性は必須ではない場合があります。アプリケーションによっては、可用性よりも重要な他の要件があります。たとえば、バッチ コンピューティング アプリケーションでは、VM 間の低レイテンシかつ高帯域幅のネットワーク接続が必要です。シングルゾーン アーキテクチャが、このようなアプリケーションには適している場合があり、データ転送の費用も削減できます。
デプロイ アーキテクチャ
このセクションでは、Google Cloud でワークロードのインフラストラクチャを構築するための次のアーキテクチャ オプションについて説明します。
シングルゾーン デプロイ
次の図は、各コンポーネントで実行される機能の可用性を高めるために、各階層に冗長性を備えたシングルゾーン アプリケーション アーキテクチャを示しています。
上の図に示すように、このサンプル アーキテクチャには、次のコンポーネントが含まれています。
- ユーザー リクエストを受信して応答するリージョン外部 HTTP/S ロードバランサ。
- HTTP/S ロードバランサのバックエンドとしてのゾーン マネージド インスタンス グループ（MIG）。MIG には 2 つの Compute Engine VM があります。各 VM はウェブサーバーのインスタンスをホストします。
- ウェブサーバーとアプリサーバー インスタンス間の通信を処理する内部ロードバランサ。
- 内部ロードバランサのバックエンドとしての 2 番目のゾーン MIG。この MIG には 2 つの Compute Engine VM が含まれています。各 VM はアプリケーション サーバーのインスタンスをホストします。
- アプリケーションがデータを読み書きする Cloud SQL データベース インスタンス（Enterprise エディション）。データベースは、同じゾーン内の 2 番目の Cloud SQL データベース インスタンスに手動で複製されます。
総可用性: シングルゾーン デプロイ
次の表に、上のシングルゾーン アーキテクチャ図の各階層の可用性を示します。
| リソース | SLA |
|---|---|
| 外部ロードバランサ | 99.99% |
| ウェブ階層: 単一ゾーン内の Compute Engine VM | 99.9% |
| 内部ロードバランサ | 99.99% |
| アプリケーション階層: 単一ゾーン内の Compute Engine VM | 99.9% |
| Cloud SQL インスタンス（Enterprise エディション） | 99.95% |
上の表に一覧表示されている Google Cloud インフラストラクチャ リソースにより、以下の総可用性と、月間推定最大ダウンタイムが提示されます。
- 総可用性: 0.9999 x 0.999 x 0.9999 x 0.999 x 0.9995 = 99.73%
- 月間推定最大ダウンタイム: 約 1 時間 57 分
この計算では、上のアーキテクチャ図に示されているインフラストラクチャ リソースのみが考慮されます。Google Cloud でのアプリケーションの可用性を評価するには、次のような他の要素も考慮する必要があります。
- アプリケーションの内部設計
- アプリケーション、依存関係、Google Cloud インフラストラクチャの構築、デプロイ、メンテナンスに使用される DevOps プロセスとツール
詳細については、アプリケーションの信頼性に影響を与える要因をご覧ください。
サービス停止の影響と復旧のためのガイダンス
シングルゾーン デプロイ アーキテクチャでは、いずれかのコンポーネントに障害が発生した場合、各階層に十分な容量を持つ機能するコンポーネントが 1 つ以上含まれていれば、アプリケーションはリクエストを処理できます。たとえば、ウェブサーバー インスタンスに障害が発生した場合、ロードバランサはユーザー リクエストを他のウェブサーバー インスタンスに転送します。ウェブサーバーまたはアプリサーバー インスタンスをホストする VM がクラッシュした場合、MIG により新しい VM が自動的に作成されます。データベースがクラッシュした場合は、2 つ目のデータベースを手動で有効にし、アプリサーバー インスタンスを更新してデータベースに接続する必要があります。
1 つのゾーンまたはリージョンの停止は、シングルゾーン デプロイの Compute Engine VM と Cloud SQL データベース インスタンスに影響します。このアーキテクチャのロードバランサは、リージョン リソースであるため、1 つのゾーンの停止の影響は受けません。ただし、利用可能なバックエンドがないため、ロードバランサはトラフィックを分散できません。ゾーンが停止した場合、Google が停止を解決するまで待ち、アプリケーションが想定どおりに動作することを確認する必要があります。
次のセクションでは、複数のゾーンにリソースを分散するために使用できるアーキテクチャ アプローチについて説明します。このアプローチは、ゾーン停止に対するアプリケーションの復元力の向上に役立ちます。
マルチゾーン デプロイ
シングルゾーン デプロイでは、ゾーンが停止した場合、問題が解決するまでアプリケーションはリクエストを処理できない可能性があります。ゾーンの停止に対するアプリケーションの復元力を高めるために、2 つ以上のゾーンにゾーンリソース（Compute Engine VM など）のインスタンスを複数プロビジョニングできます。リージョン スコープのリソースをサポートするサービス（Cloud Storage バケットなど）の場合は、リージョン リソースをデプロイできます。
次の図は、アプリケーション スタックの各階層のコンポーネントが 2 つのゾーンに分散された高可用性クロスゾーン アーキテクチャを示しています。
上の図に示すように、このサンプル アーキテクチャには、次のコンポーネントが含まれています。
- リージョン外部 HTTP/S ロードバランサは、ユーザー リクエストを受信して応答します。
- リージョン MIG は HTTP/S ロードバランサのバックエンドです。MIG には、異なるゾーンに 2 つの Compute Engine VM が含まれています。各 VM はウェブサーバーのインスタンスをホストします。
- 内部ロードバランサは、ウェブサーバーとアプリサーバー インスタンス間の通信を処理します。
- 2 番目のリージョン MIG は TCP ロードバランサのバックエンドです。この MIG には、異なるゾーンに 2 つの Compute Engine VM があります。各 VM は、アプリサーバーのインスタンスをホストします。
- HA 向けに構成された Cloud SQL インスタンス（Enterprise エディション）は、アプリケーションのデータベースです。プライマリ データベース インスタンスは、スタンバイ データベース インスタンスに同期して複製されます。
総可用性: マルチゾーン デプロイ
次の表に、上のデュアルゾーン アーキテクチャ図の各階層の可用性を示します。
| リソース | SLA |
|---|---|
| 外部ロードバランサ | 99.99% |
| ウェブ層: 個別のゾーン内の Compute Engine VM | 99.99% |
| 内部ロードバランサ | 99.99% |
| アプリケーション階層: 個別のゾーン内の Compute Engine VM | 99.99% |
| Cloud SQL インスタンス（Enterprise エディション） | 99.95% |
上の表に一覧表示されている Google Cloud インフラストラクチャ リソースにより、以下の総可用性と、月間推定最大ダウンタイムが提示されます。
- 総可用性: 0.9999 x 0.9999 x 0.9999 x 0.9999 x 0.9995 = 99.91%
- 月間推定最大ダウンタイム: 約 39 分
この計算では、上のアーキテクチャ図に示されているインフラストラクチャ リソースのみが考慮されます。Google Cloud でのアプリケーションの可用性を評価するには、次のような他の要素も考慮する必要があります。
- アプリケーションの内部設計
- アプリケーション、依存関係、Google Cloud インフラストラクチャの構築、デプロイ、メンテナンスに使用される DevOps プロセスとツール
詳細については、アプリケーションの信頼性に影響を与える要因をご覧ください。
サービス停止の影響と復旧のためのガイダンス
デュアルゾーン デプロイでは、いずれかのコンポーネントに障害が発生した場合、各階層に十分な容量を持つ正常なコンポーネントが 1 つ以上含まれていれば、アプリケーションでリクエストを処理できます。たとえば、ウェブサーバー インスタンスに障害が発生した場合、ロードバランサはユーザー リクエストを他のゾーンのウェブサーバー インスタンスに転送します。ウェブサーバーまたはアプリサーバー インスタンスをホストする VM がクラッシュした場合、MIG により新しい VM が自動的に作成されます。プライマリ Cloud SQL データベースがクラッシュすると、Cloud SQL は自動的にスタンバイ データベース インスタンスにフェイルオーバーします。
次の図は、前の図と同じアーキテクチャと、ゾーンの停止がアプリケーションの可用性に及ぼす影響を示しています。
上の図に示すように、いずれかのゾーンで停止が発生しても、このアーキテクチャのロードバランサはリージョン リソースであるため、影響を受けません。ゾーンの停止は、個々の Compute Engine VM といずれかの Cloud SQL データベース インスタンスに影響する可能性があります。ただし、VM はリージョン MIG にあり、Cloud SQL データベースは HA 用に構成されているため、アプリケーションは引き続き利用可能で応答性があります。MIG により新しい VM が自動的に作成され、最小構成の VM 数が維持されます。プライマリ Cloud SQL データベース インスタンスがゾーン停止の影響を受ける場合、Cloud SQL は他のゾーンのスタンバイ インスタンスに自動的にフェイルオーバーします。Google がサービス停止を解決したら、アプリケーションがデプロイされているすべてのゾーンで想定どおりに動作することを確認する必要があります。
注: メキシコ、モントリオール、大阪の各リージョンには、1 つまたは 2 つの物理データセンター内に 3 つのゾーンがあります。これらのリージョンは、少なくとも 3 つの物理データセンターに拡張されています。詳細については、クラウドのロケーションと Google Cloud Platform SLA をご覧ください。ワークロードの信頼性を向上させるには、マルチリージョン デプロイを検討してください。このアーキテクチャの両方のゾーンが停止した場合、アプリケーションは使用できなくなります。ロードバランサは、リージョン全体の停止が発生しない限り、引き続き使用できます。ただし、利用可能なバックエンドがないため、ロードバランサはトラフィックを分散できません。マルチゾーンまたはリージョンの停止が発生した場合は、Google が停止を解決するまで待ち、アプリケーションが想定どおりに動作することを確認する必要があります。
以降のセクションでは、マルチゾーンの停止やリージョンの停止からアプリケーションを保護するためのアーキテクチャ オプションについて説明します。
リージョン ロード バランシングによるマルチリージョン デプロイ
シングルゾーンまたはマルチゾーンのデプロイでは、リージョンが停止した場合、問題が解決するまでアプリケーションはリクエストを処理できません。リージョンの停止からアプリケーションを保護するために、Google Cloud リソースを 2 つ以上のリージョンに分散できます。
次の図は、アプリケーション スタックの各階層のコンポーネントが複数のリージョンに分散された高可用性クロスリージョン アーキテクチャを示しています。
上の図に示すように、このサンプル アーキテクチャには、次のコンポーネントが含まれています。
- 2 つの Google Cloud リージョンにトラフィックを転送するルーティング ポリシーを含む Cloud DNS の一般公開ゾーン。
- 各リージョンのリージョン外部 HTTP/S ロードバランサ。ユーザー リクエストを受信して応答します。
- 各リージョン HTTP/S ロードバランサのバックエンドはリージョン MIG です。各 MIG には、異なるゾーンに 2 つの Compute Engine VM が含まれています。これらの各 VM は、ウェブサーバーのインスタンスをホストします。
- 各リージョンの内部ロードバランサが、ウェブサーバー インスタンスとアプリサーバー インスタンス間の通信を処理します。
- リージョン MIG の 2 番目のペアは、内部ロードバランサのバックエンドです。これらの MIG のそれぞれには、異なるゾーンに 2 つの Compute Engine VM が含まれています。各 VM は、アプリサーバーのインスタンスをホストします。
- アプリケーションは、マルチリージョンの Spanner インスタンスに対してデータの書き込みと読み取りを行います。このアーキテクチャ（
eur5）で使用されるマルチリージョン構成には、4 つの読み取り / 書き込みレプリカが含まれています。読み取り / 書き込みレプリカは、2 つのリージョンと別個のゾーンに均等にプロビジョニングされます。マルチリージョンの Spanner 構成には、3 番目のリージョンにウィットネス レプリカも含まれています。
総可用性: リージョン ロード バランシングを使用したマルチリージョン デプロイ
上の図に示されるマルチリージョン デプロイでは、ロードバランサと VM が 2 つのリージョンに冗長的にプロビジョニングされています。DNS ゾーンはグローバル リソースであり、Spanner インスタンスはマルチリージョン リソースです。
このアーキテクチャに示されている Google Cloud インフラストラクチャの総可用性を計算するには、まず各リージョンにあるリソースの総可用性を計算してから、複数のリージョンにまたがるリソースを検討する必要があります。次のプロセスを使用します。
- リージョン単位のインフラストラクチャ リソースの総可用性を計算します。つまり、DNS リソースとデータベース リソースを除外します。
リソースと SLA SLA 外部ロードバランサ 99.99% ウェブ層: 個別のゾーン内の Compute Engine VM 99.99% 内部ロードバランサ 99.99% アプリケーション階層: 個別のゾーン内の Compute Engine VM 99.99% リージョンごとの総可用性: 0.9999 x 0.9999 x 0.9999 x 0.9999 = 99.96%
ロードバランサと Compute Engine VM のデュアルリージョン冗長性を考慮して、インフラストラクチャ リソースの総可用性を計算します。
理論的な可用性は 1-(1-0.9996)(1-0.9996) = 99.999984% です。ただし、予想可能な実際の可用性は、マルチリージョン デプロイのターゲット可用性（99.999%）に限定されます。
Cloud DNS と Spanner のリソースを含むすべてのインフラストラクチャ リソースの総可用性を計算します。
- 総可用性: 0.99999 x 1 x 0.99999 = 99.998%
- 月間推定最大ダウンタイム: 約 52 秒
この計算では、上のアーキテクチャ図に示されているインフラストラクチャ リソースのみが考慮されます。Google Cloud でのアプリケーションの可用性を評価するには、次のような他の要素も考慮する必要があります。
- アプリケーションの内部設計
- アプリケーション、依存関係、Google Cloud インフラストラクチャの構築、デプロイ、メンテナンスに使用される DevOps プロセスとツール
詳細については、アプリケーションの信頼性に影響を与える要因をご覧ください。
サービス停止の影響と復旧のためのガイダンス
このマルチリージョン デプロイのいずれかのコンポーネントで障害が発生しても、各階層に十分な容量を持つ正常なコンポーネントが 1 つ以上ある場合、アプリケーションは引き続き機能します。たとえば、ウェブサーバー インスタンスに障害が発生した場合、リージョン外部 HTTP/S ロードバランサはユーザー リクエストをリージョン内の他のウェブサーバー インスタンスに転送します。同様に、いずれかのアプリサーバー インスタンスがクラッシュすると、内部ロードバランサはもう一方のアプリサーバー インスタンスにリクエストを送信します。いずれかの VM がクラッシュした場合、MIG により新しい VM が自動的に作成され、最小構成の VM 数が維持されます。
1 つのゾーンでサービスが停止してもロードバランサには影響しません。ロードバランサはリージョン リソースであり、ゾーンの停止に対する耐障害性があるためです。ゾーンが停止すると、個々の Compute Engine VM に影響する可能性があります。ただし、VM がリージョン MIG の一部であるため、ウェブサーバーとアプリサーバーのインスタンスは引き続き使用できます。MIG により新しい VM が自動的に作成され、最小構成の VM 数が維持されます。このアーキテクチャの Spanner インスタンスはマルチリージョン構成を使用しているため、ゾーンの停止に対する耐障害性があります。
Spanner のマルチリージョン レプリケーションの仕組みについては、リージョンとマルチリージョンの構成、Cloud Spanner のマルチリージョン構成の理解をご覧ください。
次の図は、前の図と同じマルチリージョン アーキテクチャと、単一リージョンの停止がアプリケーションの可用性に与える影響を示しています。
上の図に示すように、各リージョンに独立したアプリケーション スタックがデプロイされているため、いずれかのリージョンの両方のゾーンでサービスが停止した場合でも、アプリケーションは引き続き利用できます。DNS ゾーンは、停止の影響を受けないリージョンにユーザー リクエストを転送します。マルチリージョンの Spanner インスタンスには、リージョンの停止に対する復元力があります。Google がサービス停止を解決したら、停止が発生したリージョンでアプリケーションが想定どおりに動作していることを確認する必要があります。
このアーキテクチャのリージョンのいずれか 2 つが停止している場合、アプリケーションは使用できなくなります。Google がサービス停止を解決するのを待ちます。次に、アプリケーションがデプロイされているすべてのリージョンで想定どおりに動作することを確認します。
マルチリージョン デプロイでは、リージョン ロードバランサを使用する代わりに、グローバル ロードバランサの使用を検討してください。次のセクションでは、グローバル ロードバランサを使用するマルチリージョン デプロイ アーキテクチャについて説明し、その方法のメリットとリスクについて説明します。
グローバル ロード バランシングによるマルチリージョン デプロイ
次の図は、リージョン ロードバランサの代わりにグローバル ロードバランサを使用する別のマルチリージョン デプロイを示しています。
上の図に示すように、このアーキテクチャでは、グローバル外部 HTTP/S ロードバランサ（Cloud CDN が有効）を使用して、ユーザー リクエストを受信して応答します。ロードバランサの各転送ルールでは、単一の外部 IP アドレスを使用します。リージョンごとに個別の DNS レコードを構成する必要はありません。グローバル外部 HTTP/S ロードバランサのバックエンドは 2 つのリージョン MIG です。ロードバランサは、ユーザーに最も近いリージョンにリクエストを転送します。
このアーキテクチャのその他のコンポーネントはすべて、リージョン ロード バランシングによるマルチリージョン デプロイに示されているアーキテクチャと同じです。
マルチリージョン デプロイでのグローバル ロード バランシングの利点とリスク
複数のリージョンに分散されたアプリケーションに外部トラフィックをロードバランスするには、グローバル ロードバランサまたは複数のリージョン ロードバランサを使用します。
グローバル ロードバランサを使用するアーキテクチャの利点は次のとおりです。
- 管理する必要があるのは 1 つのロードバランサだけです。
- グローバル ロードバランサは、単一のエニーキャスト IP アドレスを使用して、Google Cloud リージョン間でロード バランシングを行います。
- グローバル ロードバランサはリージョンの停止に対する復元力があり、リージョン間の自動フェイルオーバーを提供します。
- グローバル ロードバランサは、デプロイの信頼性の向上に役立つ次の機能をサポートしています。
- Cloud CDN を使用したエッジ キャッシング
- 耐久性の高い Cloud Storage バケットをバックエンドとして使用する機能
- Google Cloud Armor セキュリティ ポリシー
グローバル ロードバランサを使用するアーキテクチャには、次のリスクがあります。
- グローバル ロードバランサの構成変更に誤りがあると、ユーザーがアプリケーションを使用できない可能性があります。たとえば、グローバル ロードバランサのフロントエンドを更新する際に、転送ルールを誤って削除した場合、ロードバランサはユーザー リクエストの受信を停止します。リージョン ロードバランサを使用するマルチリージョン アーキテクチャの場合、このリスクの影響は小さくなります。これは、いずれかのリージョンのリージョン ロードバランサが構成エラーの影響を受けた場合でも、他のリージョンのロードバランサは引き続き機能するためです。
- グローバル リソースに影響するインフラストラクチャの停止により、グローバル ロードバランサが使用できなくなる場合があります。
これらのリスクを軽減するには、グローバル ロードバランサへの変更を慎重に管理し、可能であれば多層防御のフォールバックの使用を検討してください。詳細については、 グローバル リソースが停止リスクを管理するための推奨事項をご覧ください。
総可用性: グローバル負荷分散を使用したマルチリージョン デプロイ
上の図のマルチリージョン デプロイでは、VM と内部ロードバランサが 2 つのリージョンに冗長的に分散されています。外部ロードバランサはグローバル リソースであり、Spanner インスタンスはマルチリージョン リソースです。
このデプロイの総可用性を計算するには、まず各リージョンにあるリソースの総可用性を計算してから、複数のリージョンにまたがるリソースを考慮します。
- 外部ロードバランサとデータベースを除いて、リージョンごとのインフラストラクチャ リソースの総可用性を計算します。
リソース SLA ウェブ層: 個別のゾーン内の Compute Engine VM 99.99% 内部ロードバランサ 99.99% アプリケーション階層: 個別のゾーン内の Compute Engine VM 99.99% リージョンごとの総可用性: 0.9999 x 0.9999 x 0.9999 = 99.97%
内部ロードバランサと Compute Engine VM のデュアルリージョンの冗長性を考慮して、インフラストラクチャ リソースの総可用性を計算します。
理論的な可用性は 1-(1-0.9997)(1-0.9997) = 99.999991% です。ただし、予想可能な実際の可用性は、マルチリージョン デプロイのターゲット可用性（99.999%）に限定されます。
グローバル ロードバランサと Spanner リソースを含む、すべてのインフラストラクチャ リソースの総可用性を計算します。
- 総可用性: 0.99999 x 0.9999 x 0.99999 = 99.988%
- 月間推定最大ダウンタイム: 約 5 分 11 秒
この計算では、上のアーキテクチャ図に示されているインフラストラクチャ リソースのみが考慮されます。Google Cloud でのアプリケーションの可用性を評価するには、次のような他の要素も考慮する必要があります。
- アプリケーションの内部設計
- アプリケーション、依存関係、Google Cloud インフラストラクチャの構築、デプロイ、メンテナンスに使用される DevOps プロセスとツール
詳細については、アプリケーションの信頼性に影響を与える要因をご覧ください。
サービス停止の影響と復旧のためのガイダンス
このアーキテクチャのいずれかのコンポーネントで障害が発生しても、各階層に十分な容量を持つコンポーネントが 1 つ以上存在すれば、アプリケーションは機能し続けます。たとえば、ウェブサーバー インスタンスで障害が発生した場合、グローバル外部 HTTP/S ロードバランサはユーザー リクエストを他のウェブサーバー インスタンスに転送します。アプリサーバー インスタンスがクラッシュすると、内部ロードバランサはもう一方のアプリサーバー インスタンスにリクエストを送信します。いずれかの VM がクラッシュした場合、MIG により新しい VM が自動的に作成され、最小構成の VM 数が維持されます。
いずれかのリージョンのゾーンのいずれかで停止が発生しても、ロードバランサは影響を受けません。グローバル外部 HTTP/S ロードバランサは、ゾーンとリージョンの停止に対する復元力があります。内部ロードバランサはリージョン リソースです。ゾーンの停止に対して復元力があります。ゾーンが停止すると、個々の Compute Engine VM に影響する可能性があります。ただし、VM がリージョン MIG の一部であるため、ウェブサーバーとアプリサーバーのインスタンスは引き続き使用できます。MIG により新しい VM が自動的に作成され、最小構成の VM 数が維持されます。このアーキテクチャの Spanner インスタンスはマルチリージョン構成を使用しているため、ゾーンの停止に対する耐障害性があります。
次の図は、前の図と同じマルチリージョン アーキテクチャと、単一リージョンの停止がアプリケーションの可用性に与える影響を示しています。
上の図に示すように、各リージョンに独立したアプリケーション スタックがデプロイされているため、いずれかのリージョンの両方のゾーンでサービスが停止した場合でも、アプリケーションは引き続き利用できます。グローバル外部 HTTP/S ロードバランサは、停止の影響を受けないリージョン内のアプリケーションにユーザー リクエストを転送します。マルチリージョンの Spanner インスタンスには、リージョンの停止に対する復元力があります。Google がサービス停止を解決したら、停止が発生したリージョンでアプリケーションが想定どおりに動作していることを確認する必要があります。
Spanner のマルチリージョン レプリケーションの仕組みについては、リージョンとマルチリージョンの構成、Cloud Spanner のマルチリージョン構成の理解をご覧ください。
このアーキテクチャのリージョンのいずれか 2 つが停止している場合、アプリケーションは使用できなくなります。グローバル外部 HTTP/S ロードバランサは使用可能ですが、使用可能なバックエンドがないため、トラフィックを分散できません。Google がサービス停止を解決するのを待ちます。次に、アプリケーションがデプロイされているすべてのリージョンで想定どおりに動作することを確認します。
マルチリージョン デプロイは、最も重要なビジネス アプリケーションの高可用性を確保するのに役立ちます。障害イベントの発生時にビジネス継続性を確保するには、アプリケーションを複数のリージョンにデプロイするだけでなく、特定の追加手順を行う必要があります。たとえば、キャパシティ プランニングを行い、すべてのリージョンで十分な容量を予約するか、緊急の自動スケーリングに伴うリスクを許容できるようにする必要があります。また、DR テスト、インシデント管理、インシデント発生後のアプリケーション ステータスの検証、事後検証の実施のための運用プラクティスも導入する必要があります。
-
メキシコ、モントリオール、大阪の各リージョンには、1 つまたは 2 つの物理データセンター内に 3 つのゾーンがあります。これらのリージョンは、少なくとも 3 つの物理データセンターに拡張されています。詳細については、クラウドのロケーションと Google Cloud Platform SLA をご覧ください。ワークロードの信頼性を向上させるには、マルチリージョン デプロイを検討してください。 ↩