Google Cloud における信頼性の構成要素

Last reviewed 2023-09-01 UTC

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.9%)。

複数クラスタ

次の図は、マルチクラスタのルーティングで、単一リージョン内の複数のゾーンにあるマルチクラスタ Bigtable インスタンスを示しています(最小稼働時間 SLA: 99.99%)。

マルチクラスタのルーティングで、単一リージョン内の複数のゾーンにあるマルチクラスタ Bigtable インスタンス(最小稼働時間 SLA: 99.99%)。

複数クラスタ

次の図は、マルチクラスタのルーティングで、3 つのリージョンにあるマルチクラスタ Bigtable インスタンスを示しています(最小稼働時間 SLA: 99.999%)。

マルチクラスタのルーティングで、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 層インフラストラクチャ スタックの予想される総可用性は、次の式を使用して計算できます。

$$ tier1\_availability * tier2\_availability * tierN\_availability $$

たとえば、3 層スタックのすべての階層が 99.9% の可用性を提供するように設計されている場合、スタックの総可用性は約 99.7%(0.999 x 0.999 x 0.999)になります。つまり、多層スタックの総可用性は、可用性が最も低い階層の可用性よりも低くなります。

スタック内に相互依存する階層の数が増えると、次の表のようにスタックの総可用性は低下します。この表のスタックの例はそれぞれ階層の数が異なります。簡単に比較できるように、すべての階層で 99.9% の可用性が提供されていると想定しています。

ティア