Google Cloud インフラストラクチャ サービスはグローバルなロケーションで稼働しています。ロケーションは、リージョンとゾーンと呼ばれる障害発生ドメインに分割されます。これらは、クラウド ワークロード用の信頼性の高いインフラストラクチャを設計するための基本的な構成要素です。
障害発生ドメインとは、他のリソースとは独立して障害が発生する可能性のあるリソースまたはリソースのグループのことです。スタンドアロンの Compute Engine VM は、障害発生ドメインであるリソースの一例です。Google Cloud のリージョンまたはゾーンは、リソースのグループで構成される障害発生ドメインの一例です。アプリケーションが障害発生ドメイン間で冗長的に分散されている場合、各障害発生ドメインによって提供される可用性よりも集約されたレベルの可用性を実現できます。
Google Cloud インフラストラクチャ信頼性ガイドのこのパートでは、Google Cloud の信頼性の構成要素と、それらがクラウド リソースの可用性に与える影響について説明します。
リージョンとゾーン
Google Cloud のリージョンは、独立した地理的なロケーションです。各 Google Cloud リージョンには複数のゾーンが含まれています。1 つのゾーンで障害が発生しても、他のゾーンのインフラストラクチャに影響する可能性はほとんどありません。グローバル ネットワーク バックボーンは、Google Cloud のすべてのゾーンとリージョンに高帯域幅で低レイテンシの接続を提供します。
プラットフォームの可用性
Google Cloud インフラストラクチャは、障害を許容し、障害から復旧するように設計されています。Google は、Google Cloud の信頼性を維持し、改善するために、革新的なアプローチに継続的に投資しています。Google Cloud インフラストラクチャの次の機能は、クラウド ワークロードで信頼性の高いプラットフォームを提供するために役立ちます。
- グローバル サービスに対する自然災害やリージョンの停止の影響を軽減する地理的に離れたリージョン。
- 単一障害点を回避するためのハードウェアの冗長性とレプリケーション。
- メンテナンス イベント中のリソースのライブ マイグレーション。たとえば、インフラストラクチャの計画的なメンテナンス中に、ライブ マイグレーションを使用して、Compute Engine VM を同じゾーンの別のホストに移動できます。
- Google Cloud が実行される物理インフラストラクチャとソフトウェアのための安全性を重視して設計されたインフラストラクチャ基盤と、データとワークロードを保護する運用面のセキュリティ管理。詳細については、Google インフラストラクチャのセキュリティ設計の概要をご覧ください。
- 適切にスケーリングされる一貫性のあるパフォーマンスを実現するために、エッジ キャッシング サービスを使用して、ネットワーク管理に対して高度なソフトウェア定義ネットワーキング（SDN）方式を使用する、高パフォーマンス バックボーン ネットワーク。
- 継続的なモニタリングとレポート。Google Cloud Service Health ダッシュボードを使用すると、すべてのロケーションの Google Cloud サービスのステータスを確認できます。
- 年 1 回の全社的な障害復旧テスト（DiRT）イベント。障害発生時に Google Cloud サービスと社内の事業運営を継続できるようにします。
Google Cloud インフラストラクチャは、ほとんどのお客様のワークロードで次の目標レベルの可用性をサポートするように設計されています。
| デプロイするロケーション | 可用性（稼働時間）% | 推定最大ダウンタイム |
|---|---|---|
| シングルゾーン | スリーナイン: 99.9% | 1 か月（30 日間）で 43.2 分 |
| 1 つのリージョン内の複数のゾーン | フォーナイン: 99.99% | 1 か月（30 日間）で 4.3 分 |
| 複数のリージョン | ファイブナイン: 99.999% | 1 か月（30 日間）で 26 秒 |
上の表の可用性の割合は目標です。特定の Google Cloud サービスの稼働時間のサービスレベル契約（SLA）は、これらの可用性目標とは異なる場合があります。たとえば、Bigtable インスタンスの稼働時間 SLA は、クラスタの数やロケーション間の分散、および構成するルーティング ポリシーによって異なります。
マルチクラスタのルーティング ポリシーが構成されている場合、3 つ以上のリージョンにクラスタを持つ Bigtable インスタンスの最小稼働時間の SLA は 99.999% です。ただし、単一クラスタのルーティング ポリシーが構成されている場合、クラスタの数とその分散に関係なく、最小稼働時間の SLA は 99.9% です。
このセクションの図では、クラスタサイズが異なる Bigtable インスタンスと、それに伴う稼働時間 SLA の違いを示しています。
単一クラスタ
次の図は、最小稼働時間の SLA が 99.9% の単一クラスタの Bigtable インスタンスを示しています。
複数クラスタ
次の図は、マルチクラスタのルーティングで、単一リージョン内の複数のゾーンにあるマルチクラスタ Bigtable インスタンスを示しています（最小稼働時間 SLA: 99.99%）。
複数クラスタ
次の図は、マルチクラスタのルーティングで、3 つのリージョンにあるマルチクラスタ Bigtable インスタンスを示しています（最小稼働時間 SLA: 99.999%）。
総インフラストラクチャ可用性
Google Cloud でアプリケーションを実行するには、VM やデータベースなどのインフラストラクチャ リソースを使用します。これらのインフラストラクチャ リソースがまとまって、アプリケーションのインフラストラクチャ スタックを構成します。
次の図は、Google Cloud のインフラストラクチャ スタックと、スタック内の各リソースの可用性 SLA の例を示しています。
このインフラストラクチャ スタックの例には、次の Google Cloud リソースが含まれています。
- リージョン外部アプリケーション ロードバランサは、ユーザー リクエストを受信して応答します。
- リージョン マネージド インスタンス グループ（MIG）は、リージョン外部アプリケーション ロードバランサのバックエンドです。MIG には、異なるゾーンに 2 つの Compute Engine VM が含まれています。各 VM はウェブサーバーのインスタンスをホストします。
- 内部ロードバランサは、ウェブサーバーとアプリケーション サーバー インスタンス間の通信を処理します。
- 2 番目のリージョン MIG は内部ロードバランサのバックエンドです。この MIG には、異なるゾーンに 2 つの Compute Engine VM があります。各 VM はアプリケーション サーバーのインスタンスをホストします。
- HA 向けに構成された Cloud SQL インスタンスは、アプリケーションのデータベースです。プライマリ データベース インスタンスは、スタンバイ データベース インスタンスに同期して複製されます。
上の例のようなインフラストラクチャ スタックから予想可能な総可用性は、次の要因によって決まります。
Google Cloud の SLA
インフラストラクチャ スタックで使用する Google Cloud サービスの稼働時間の SLA は、スタックから予想可能な最小総可用性に影響します。
次の表に、一部のサービスの稼働時間 SLA の比較を示します。
| コンピューティング サービス | 月単位の稼働時間の SLA | 1 か月（30 日間）の推定最大ダウンタイム |
|---|---|---|
| Compute Engine VM | 99.9% | 43.2 分 |
| 複数のゾーンにある GKE Autopilot の Pod | 99.9% | 43.2 分 |
| Cloud Run サービス | 99.95% | 21.6 分 |
| データベース サービス | 月単位の稼働時間の SLA | 1 か月（30 日間）の推定最大ダウンタイム |
|---|---|---|
| Cloud SQL for PostgreSQL インスタンス（Enterprise エディション） | 99.95% | 21.6 分 |
| AlloyDB for PostgreSQL インスタンス | 99.99% | 4.3 分 |
| Spanner マルチリージョン インスタンス | 99.999% | 26 秒 |
他の Google Cloud サービスの SLA については、Google Cloud サービスレベル契約をご覧ください。
上の表に示すように、インフラストラクチャ スタックの各階層に選択した Google Cloud サービスは、インフラストラクチャ スタックから予想可能な全体的な稼働時間に直接影響します。Google Cloud リソースにデプロイされたワークロードの想定される可用性を向上させるには、次のセクションで説明するように、リソースの冗長インスタンスをプロビジョニングします。
リソースの冗長性
リソースの冗長性とは、リソースの 2 つ以上の同一インスタンスをプロビジョニングし、グループ内のすべてのリソースに同じワークロードをデプロイすることを意味します。たとえば、アプリケーションのウェブ層をホストするには、複数の同じ Compute Engine VM を含む MIG をプロビジョニングする場合があります。
複数の障害ドメイン（たとえば、2 つの Google Cloud ゾーン）にリソースのグループを冗長的に分散させる場合は、そのグループから予想されるリソースの可用性が、そのグループの各リソースの稼働時間 SLA よりも高くなります。このように可用性が高いのは、グループ内のすべてのリソースで同時に障害が発生する可能性が、1 つの障害発生ドメイン内のリソースが調整された障害で発生する可能性よりも低いためです。
たとえば、リソースの可用性 SLA が 99.9% の場合、リソースが失敗する確率は 0.001（1 引く SLA）です。別の障害発生ドメインでプロビジョニングされたこのリソースの 2 つのインスタンスにワークロードを分散した場合、両方のリソースで同時に障害が発生する確率は 0.000001（つまり 0.001 x 0.001）です。この障害の確率は、2 つのリソースのグループに対して 99.9999% の理論的可用性に相当します。ただし、予想可能な実際の可用性は、デプロイするロケーションの目標可用性に限定されます。リソースが単一の Google Cloud ゾーンにある場合は 99.9%、マルチゾーン デプロイの場合は 99.99%、冗長リソースが複数のリージョンに分散されている場合は 99.999% になります。
スタックの深さ
インフラストラクチャ スタックの深さは、スタック内の個別の階層（またはレイヤ）の数です。インフラストラクチャ スタックの各階層には、アプリケーションに個別の機能を提供するリソースが含まれています。たとえば、3 層スタックの中間層は、Compute Engine VM または GKE クラスタを使用してアプリケーション サーバーをホストします。通常、インフラストラクチャ スタック内の各階層は、隣接する階層と緊密に相互依存しています。つまり、スタックの任意の階層が使用不可能になると、スタック全体が使用できなくなります。
N 層インフラストラクチャ スタックの予想される総可用性は、次の式を使用して計算できます。
たとえば、3 層スタックのすべての階層が 99.9% の可用性を提供するように設計されている場合、スタックの総可用性は約 99.7%（0.999 x 0.999 x 0.999）になります。つまり、多層スタックの総可用性は、可用性が最も低い階層の可用性よりも低くなります。
スタック内に相互依存する階層の数が増えると、次の表のようにスタックの総可用性は低下します。この表のスタックの例はそれぞれ階層の数が異なります。簡単に比較できるように、すべての階層で 99.9% の可用性が提供されていると想定しています。
| ティア | スタック A | スタック B | スタック C |
|---|---|---|---|
| フロントエンド | 99.9% | 99.9% | 99.9% |
| アプリケーション階層 | 99.9% | 99.9% | 99.9% |
| 中間層 | – | 99.9% | 99.9% |
| データ階層 | – | – | 99.9% |
| スタックの総可用性 | 99.8% | 99.7% | 99.6% |
| 1 か月（30 日間）のスタックの推定最大ダウンタイム | 86 分 | 130 分 | 173 分 |
設計上の考慮事項の概要
アプリケーションを設計する際は、Google Cloud インフラストラクチャ スタックの総可用性を考慮します。
- インフラストラクチャ スタック内の各 Google Cloud リソースの可用性は、スタックの総可用性に影響します。Google Cloud サービスを選択してインフラストラクチャ スタックを構築する場合は、サービスの可用性 SLA を検討します。
- リソースが提供する機能（コンピューティングやデータベースなど）の可用性を向上させるために、リソースの冗長インスタンスをプロビジョニングできます。冗長なリソースを使用してアーキテクチャを設計する場合は、可用性のメリットのほかに、運用の複雑さ、レイテンシ、費用に対する潜在的な影響も考慮する必要があります。
- インフラストラクチャ スタックの階層数（つまり、スタックの深さ）は、スタックの総可用性とは逆の関係です。スタックを設計または変更するときにこの関係を考慮します。
総可用性の計算例については、次のセクションをご覧ください。
- 計算例: シングルゾーン デプロイ
- 計算例: マルチゾーン デプロイ
- 計算例: リージョン ロード バランシングによるマルチリージョン デプロイ
- 計算例: グローバル ロード バランシングによるマルチリージョン デプロイ
ロケーション スコープ
Google Cloud リソースのロケーション スコープにより、インフラストラクチャの障害がリソースに及ぼす影響の程度が決まります。Google Cloud でプロビジョニングするほとんどのリソースには、ゾーン、リージョン、マルチリージョン、グローバルのいずれかのロケーション スコープがあります。
一部のリソースタイプのロケーション スコープは固定されています。つまり、ロケーション スコープを選択または変更することはできません。たとえば、Virtual Private Cloud（VPC）ネットワークはグローバル リソースで、Compute Engine 仮想マシン（VM）はゾーンリソースです。特定のリソースについては、リソースのプロビジョニング中にロケーション スコープを選択できます。たとえば、Google Kubernetes Engine（GKE）クラスタを作成する場合は、ゾーンまたはリージョンの GKE クラスタの作成を選択できます。
以下のセクションでは、ロケーション スコープについて詳しく説明します。
ゾーンリソース
ゾーンリソースは、Google Cloud リージョン内の単一ゾーンにデプロイされます。ゾーンリソースの例を次に示します。このリストはすべてを網羅したものではありません。
- Compute Engine VM
- ゾーン マネージド インスタンス グループ（MIG）
- ゾーン永続ディスク
- シングルゾーン GKE クラスタ
- Filestore Basic インスタンスとゾーン インスタンス
- Dataflow ジョブ
- Cloud SQL のインスタンス
- Compute Engine 上の Dataproc クラスタ
ゾーンで障害が発生すると、そのゾーン内でプロビジョニングされているゾーンリソースに影響する可能性があります。ゾーンは、リージョン内の他のゾーンとの相関障害のリスクを最小限に抑えるように設計されています。通常、1 つのゾーンで障害が発生しても、リージョン内の他のゾーンのリソースには影響しません。また、ゾーンに障害が発生しても、そのゾーンのすべてのインフラストラクチャが使用できなくなるわけではありません。このゾーンは、障害の影響について予想される境界を定義するだけです。
ゾーンリソースを使用するアプリケーションをゾーン インシデントから保護するには、複数のゾーンまたはリージョンにリソースを分散または複製します。詳細については、Google Cloud のワークロードに適した信頼性の高いインフラストラクチャを設計するをご覧ください。
リージョン リソース
リージョン リソースは、リージョン内の複数のゾーンに冗長的にデプロイされます。リージョン リソースの例を次に示します。このリストはすべてを網羅したものではありません。
- リージョン MIG
- リージョン Cloud Storage バケット
- リージョン永続ディスク
- デフォルト（マルチゾーン）構成のリージョン GKE クラスタ
- VPC サブネット
- リージョン外部アプリケーション ロードバランサ
- リージョン Spanner インスタンス
- Filestore Enterprise インスタンス
- Cloud Run サービス
リージョン リソースは、特定のゾーン内のインシデントに対して復元力があります。リージョンが停止すると、そのリージョン内でプロビジョニングされたリージョン リソースの一部またはすべてに影響する可能性があります。このような停止は、自然災害や大規模なインフラストラクチャの障害が原因で発生する可能性があります。
マルチリージョン リソース
マルチリージョン リソースは特定のリージョンに分散されます。マルチリージョン リソースの例を次に示します。このリストはすべてを網羅したものではありません。
- デュアルリージョンとマルチリージョンの Cloud Storage バケット
- マルチリージョンの Spanner インスタンス
- マルチクラスタ（マルチリージョン）Bigtable インスタンス
- Cloud Key Management Service のマルチリージョン キーリング
マルチリージョン構成で使用できる Google サービスの一覧については、ロケーション別のプロダクト提供状況をご覧ください。
マルチリージョン リソースには、特定のリージョンとゾーンのインシデントに対する復元力があります。複数のリージョンで発生するインフラストラクチャの停止は、影響を受けるリージョンでプロビジョニングされたマルチリージョン リソースの一部またはすべての可用性に影響する可能性があります。
グローバル リソース
グローバル リソースは Google Cloud のすべてのロケーションで使用できます。グローバル リソースの例を次に示します。このリストはすべてを網羅したものではありません。
プロジェクト。Google Cloud リソースをフォルダとプロジェクトに整理するためのガイダンスとベスト プラクティスについては、Google Cloud ランディング ゾーンのリソース階層を決定するをご覧ください。
VPC ネットワーク（関連ルート、ファイアウォール ルールを含む）
Cloud DNS ゾーン
グローバル外部アプリケーション ロードバランサ
Cloud Key Management Service のグローバル キーリング
Pub/Sub トピック
Secret Manager のシークレット
グローバルで利用可能な Google サービスの一覧については、グローバル プロダクトをご覧ください。
グローバル リソースにはゾーンとリージョンのインシデントに対する復元力があります。これらのリソースは、特定のリージョンのインフラストラクチャに依存しません。Google Cloud には、グローバルなインフラストラクチャ停止のリスクを最小限に抑えることができるシステムとプロセスがあります。また、Google はインフラストラクチャを継続的にモニタリングし、グローバルなサービス停止を迅速に解決しています。
次の表は、アプリケーションとインフラストラクチャの問題に対する、ゾーン、リージョン、マルチリージョン、グローバル リソースの相対的な復元力をまとめたものです。また、これらのリソースの設定に必要な作業と、停止の影響を軽減するための推奨事項についても説明します。
| リソース スコープ | 復元力 | インフラストラクチャの停止の影響を軽減するための推奨事項 |
|---|---|---|
| ゾーン | 低 | 複数のゾーンまたはリージョンにリソースを冗長的にデプロイします。 |
| リージョン | 中 | リソースを複数のリージョンに冗長的にデプロイします。 |
| マルチリージョンまたはグローバル | 高 | 変更を慎重に管理し、可能であれば多層防御のフォールバックを使用します。詳細については、グローバル リソースが停止リスクを管理するための推奨事項をご覧ください。 |
グローバル リソースの停止リスクを管理するための推奨事項
ゾーンとリージョンの停止に対するグローバル リソースの復元力を利用するには、アーキテクチャで特定のグローバル リソースを使用することを検討してください。グローバル リソースの停止リスクを管理するために、次のアプローチをおすすめします。
グローバル リソースの変更の慎重な管理
グローバル リソースには物理的な障害に対する復元力があります。このようなリソースの構成のスコープはグローバルです。したがって、複数のリージョン リソースを運用するよりも、単一のグローバル リソースを設定して構成するほうが簡単です。ただし、グローバル リソースの構成に重大なエラーがあると、単一障害点（SPOF）になる可能性があります。たとえば、地理的に分散したアプリケーションのフロントエンドとしてグローバル ロードバランサを使用できます。グローバル ロードバランサは、多くの場合、このようなアプリケーションに適しています。ただし、ロードバランサの構成にエラーがあると、すべての地域でロードバランサが使用できなくなる可能性があります。このリスクを回避するには、グローバル リソースの構成変更を慎重に管理する必要があります。詳細については、グローバル リソースの変更を管理するをご覧ください。
多層防御フォールバックとしてのリージョン リソースの使用
非常に高い可用性の要件があるアプリケーションの場合、リージョンの多層防御フォールバックにより、グローバル リソースの停止の影響を最小限に抑えることができます。グローバル ロードバランサをフロントエンドとして持つ、地理的に分散したアプリケーションの例について考えてみましょう。グローバル ロードバランサがグローバルな停止の影響を受ける場合でもアプリケーションにアクセスできるようにするには、リージョン ロードバランサをデプロイします。グローバル ロードバランサを優先し、グローバル ロードバランサが使用できない場合は最も近いリージョン ロードバランサにフェイルオーバーするようにクライアントを構成できます。
ゾーンリソース、リージョン リソース、グローバル リソースを使用したアーキテクチャの例
次の図に示すように、クラウド トポロジには、ゾーンリソース、リージョン リソース、グローバル リソースの組み合わせを含めることができます。次の図は、Google Cloud にデプロイされた多層アプリケーションのアーキテクチャの例を示しています。
上の図のように、グローバル外部 HTTP/S ロードバランサはクライアント リクエストを受信します。ロードバランサはバックエンドにリクエストを分散します。バックエンドは、2 つの Compute Engine VM を持つリージョン MIG です。VM で実行されるアプリケーションは、Cloud SQL データベースに対してデータの書き込みと読み取りを行います。データベースは HA 向けに構成されています。データベースのプライマリ インスタンスとスタンバイ インスタンスは別々のゾーンにプロビジョニングされ、プライマリ データベースはスタンバイ データベースに同期的に複製されます。また、データベースは Cloud Storage のマルチリージョン バケットに自動的にバックアップされます。
次の表は、上記のアーキテクチャの Google Cloud リソースと、ゾーンとリージョンの停止に対する各リソースの復元力をまとめたものです。
| リソース | サービス停止に対する復元力 |
|---|---|
| VPC ネットワーク | 関連ルート、ファイアウォール ルールを含む VPC ネットワークはグローバルなリソースです。これらは、ゾーンとリージョンの停止に対する復元力を備えています。 |
| サブネット | VPC サブネットはリージョン リソースです。これらは、ゾーンの停止に対する復元力を備えています。 |
| グローバル外部 HTTP/S ロードバランサ | グローバル外部 HTTP/S ロードバランサは、ゾーンとリージョンの停止に対する復元力を備えています。 |
| リージョン MIG | リージョン MIG は、ゾーンの停止に対する復元力を備えています。 |
| Compute Engine VM | Compute Engine VM はゾーンリソースです。ゾーンが停止した場合、個々の Compute Engine VM が影響を受ける可能性があります。ただし、ロードバランサのバックエンドはスタンドアロン VM ではなくリージョン MIG であるため、アプリケーションは引き続きリクエストを処理できます。 |
| Cloud SQL のインスタンス | このアーキテクチャの Cloud SQL デプロイは HA 用に構成されています。つまり、デプロイにはプライマリとスタンバイのデータベース インスタンスのペアが含まれます。プライマリ データベースは、リージョン永続ディスクを使用して、スタンバイ データベースに同期的に複製されます。
|
| マルチリージョンの Cloud Storage バケット | マルチリージョンの Cloud Storage バケットに保存されるデータは、単一リージョンの停止に対する復元力を備えています。 |
| 永続ディスク | 永続ディスクはゾーンまたはリージョンのいずれかです。リージョン永続ディスクは、ゾーンの停止に対する復元力を備えています。リージョンの停止から復旧する準備として、永続ディスクのスナップショットをスケジュールし、マルチリージョンの Cloud Storage バケットに保存できます。 |