Google Cloud プロダクトは、特定のリージョン障害発生ドメインから提供され、サービスレベル契約でフルサポートされます。そのため、アプリケーション アーキテクチャは Google Cloud の構造内で設計できます。
Google Cloud インフラストラクチャ サービスは、北米、南米、ヨーロッパ、アジア、オーストラリアのロケーションでご利用いただけます。これらのロケーションは、「リージョン」と「ゾーン」に分けられます。アプリケーションのロケーションとして、レイテンシ、可用性、耐久性の要件が満たされるところを選ぶことができます。
使ってみる
Google Cloud を初めて使用する場合は、アカウントを作成して、実際のシナリオでの Google プロダクトのパフォーマンスを評価してください。新規のお客様には、ワークロードの実行、テスト、デプロイができる無料クレジット $300 分を差し上げます。
無料で開始リージョンとゾーン
「リージョン」は、「ゾーン」で構成された、独立した地理エリアです。ゾーンとリージョンは、1 つ以上の物理データセンターで提供される、基盤となる物理リソースの論理的な抽象化です。これらのデータセンターは、Google が所有し、Google Cloud のロケーション ページに掲載されているか、サードパーティのデータセンターのプロバイダからリースされている場合があります。Google Cloud のデータセンターのすべてのロケーションについては、ISO/IEC 27001 証明書をご覧ください。データセンターが所有されているかリースされているかにかかわらず、Google Cloud はデータセンターを選択し、均一なパフォーマンス、セキュリティ、信頼性を提供するようにインフラストラクチャを設計します。
「ゾーン」は、リージョン内にある Google Cloud リソースのデプロイエリアです。ゾーンは、リージョン内の単一の障害ドメインとみなすことができます。可用性の高いフォールト トレラントなアプリケーションをデプロイし、予期せぬ障害を防ぐためには、リージョン内の複数のゾーンにアプリケーションをデプロイする必要があります。
自然災害によってリージョン全体が喪失した場合に備えて、障害復旧計画を策定し、主要なリージョンが喪失するという予期せぬ事態が発生した場合にアプリケーションを立ち上げるノウハウを用意しておく必要があります。詳しい情報については、アプリケーション デプロイの留意点をご覧ください。
それぞれのロケーション オプションで使用できるリソースについて詳しくは、クラウドのロケーションをご覧ください。
Google Cloud のサービスとリソースは、ゾーン内、リージョン内、複数のリージョンで Google が管理のいずれかになります。これらのオプションがデータにとってどのような意味を持つのかについては、データの地理的管理をご覧ください。
Google Cloud では、すべての汎用リージョンで少なくとも 3 つのアベイラビリティ ゾーン（物理的および論理的に異なるゾーン）を提供する予定です。
ゾーンリソース
ゾーンリソースは、単一のゾーン内で動作します。ゾーンが停止すると、そのゾーンのリソースの一部または全部に影響する可能性があります。ゾーンリソースの例としては、特定のゾーン内に存在する Compute Engine Virtual Machine（VM）インスタンスがあります。
リージョン リソース
リージョン リソースとは、App Engine アプリケーションなど、リージョン内の複数のゾーンに重複してデプロイされるリソース、またはリージョン マネージド インスタンス グループのことです。そのため、リージョン リソースはゾーンリソースに比べて可用性が高くなります。
マルチリージョン リソース
複数の Google Cloud サービスが Google により管理され、リージョン内およびリージョン間で冗長化および分散されます。これらのサービスでは、可用性、性能、リソースの効率性が最適化されます。その結果、これらのサービスではレイテンシと整合性モデルの間でトレードオフが生じます。このトレードオフは、プロダクトごとに文書化されています。
次のサービスには、リージョンのロケーションに加え、1 つ以上のマルチリージョンのロケーションが存在します。
- Artifact Registry
- Bigtable
- Cloud DLP
- Cloud Healthcare API
- Cloud KMS
- Container Registry
- Spanner
- Cloud Storage
- Database Migration Service
- Datastore
- Firestore
これらのマルチリージョン サービスは、単一のリージョンが消失した後でも機能するように設計されています。
詳細については、ロケーション別のプロダクト提供状況と各プロダクトのドキュメントをご覧ください。
グローバル サービス
Google Cloud は、ゼロからグローバルに運用できるように設計されており、お客様にご不便をおかけすることのないよう、24 時間年中無休でメンテナンスとアップグレードを継続的に実施しています。Google のグローバル バックボーンは、負荷分散に優れた柔軟性を実現し、相互接続を近くに配置することで、エンドユーザーのレイテンシを短縮します。Google のグローバル クラウド管理プレーンは、マルチリージョン開発の管理を簡素化します。
内部サービス
Google Cloud サービスを利用されているお客様を支え、サポートしているのは、Spanner、Colossus、Borg、Chubby などの実績のある一連の内部サービスです。
これらの内部サービスは、複数のリージョンにわたってグローバルに負荷分散されるか、これらのサービスが利用できる各リージョン専用となります。サービスが複数のリージョンで負荷分散されている場合、リージョンごとに更新を段階的にデプロイすることで、サービスの使用に影響を与えることなく問題を検出し、対処できます。これらの内部サービスは、単一の論理データセンターまたは単一リージョンに限定されていません。
グローバル内部サービスは、次のクラウド リージョンで実行または複製できます。
南北アメリカ
- southamerica-west1
- us-central1
- us-east1
- us-east4
- us-west1
- us-west4
ヨーロッパ
- europe-north1
- europe-west1
- europe-west4
アジア
- asia-east1
- asia-southeast1
サービスの依存関係
一般に、Google Cloud サービスの場合、1 つのリージョンで障害が発生すると、そのリージョンのお客様のみが影響を受けます。マルチリージョン プロダクトをご利用のお客様には影響しません。Google Cloud は、リージョン間の連動障害を防ぐために、重要なアーキテクチャを備えています。
すべての Google Cloud サービスは、ネットワーク（データセンターの内外）、データセンターへのアクセス、ID 認証システムなどの基本的なサービスを提供するためにコア内部ツールに依存しています。これらのツールは、リージョンの停止に対する耐障害性を備え、他のリージョンが使用不能になっても、あるリージョンは影響を受けないことを目的としています。
Google Cloud は、特に使用頻度の高い Google Cloud プロダクト（Compute Engine、BigQuery、Pub/Sub などのサービス）で必要なレベルの復元力を実現するために、お客様がアプリケーションを設計する方法を Google の公開ウェブサイトにて明確に示しています。
Google の主な依存関係を以下に示します。すべてのサービスに共通する依存関係から示しますが、下位レベルの実装の詳細は変更される場合があります。
すべてのサービスに共通する依存関係
- 認証と認可に使用する ID データプレーン
- ロギング、メタデータ ストレージ、ワークフロー管理を提供する内部サービス
- Google Cloud APIs へのアクセスは、DNS、グローバル分散のロードバランサ、接続拠点（PoP）に依存します。
- グローバル リソースの構成: IAM ポリシー、グローバル ファイアウォール ルール、グローバル ロードバランサの構成、Pub/Sub トピックなどは、複製されるデータベースに保存されます。
- Google Cloud サービスが、お客様が管理するエンドポイント（顧客鍵を取得する Cloud EKM や、メッセージ配信のための Pub/Sub など）にリクエストを送信する場合、これらのリクエストは、Google のグローバル ネットワーク インフラストラクチャを使用してお客様が管理するエンドポイントにアクセスします。
追加の依存関係を使用するサービス
- Compute Engine サービス
- Google Cloud VM と Persistent Disk のデータプレーンは、下位レベルの Compute Engine サービスと Cloud Storage サービス（Borg、Colossus など）に依存します。
- Google Cloud と、Spanner、Bigtable、Cloud Storage などのストレージ サービスのインフラストラクチャは、以下に依存します。
- お客様向けの暗号化と鍵管理のインフラストラクチャ（Cloud KMS / Cloud EKM）と Google 所有の鍵向けの内部インフラストラクチャ
- データアクセスのロギングと監査を提供する内部サービス
- 内部データ レプリケーション サービス。このサービスでは、データを複数のリージョンで利用できることを想定しています。
- 明示的に構成されたバックアップおよびクロスリージョン ネットワーキングに依存するその他のリージョンへのレプリケーション
- メッセージング サービス
- Pub/Sub は Google のグローバル ネットワーク インフラストラクチャを利用して、お客様が管理するエンドポイントにアクセスします。
- ネットワーク サービス
- リージョン間でのグローバルな負荷分散、DNS、フェイルオーバーはすべて、物理ネットワーキング インフラストラクチャに依存します。
- DDoS のような攻撃を防ぐには、下位レベルの Compute Engine インフラストラクチャに依存します。
- GKE や Cloud SQL などのマネージド ホストサービス
- Compute Engine および VM イメージ用の Container Registry または Artifact Registry に依存します。
- 自己完結型の下位レベルのインフラストラクチャ
- Borg やネットワーク ファブリックなどの、Google の内部クラスタレベルのコントロール プレーン
- Colossus などのクラスタレベルのストレージ
- 暗号化と鍵管理のインフラストラクチャ
可用性と復元力の維持と向上
サイト信頼性エンジニアリング（SRE）は、可用性、レイテンシ、パフォーマンス、処理能力を向上させるための Google の内部組織です。サービスの停止や使用不能は、新しいコードのデプロイまたは環境の変更と相関します。SRE は、業界のベスト プラクティスを使用することにより、必要な変更がダウンタイムを引き起こす可能性があることを理解したうえで、新しいソフトウェアをリリースする必要性と、環境を安全に保つことのバランスを取ります。
お客様と協力して復元力の高いサービスを構築する
ミッション クリティカルなニーズがあり、復元力と障害復旧を設計する必要がある場合、Google の SRE / CRE および PSO チームは、お客様と協力して複数のリージョンおよびゾーンをブリッジするアプリケーションを設計し、高可用性（HA）システムを設計するためのご支援をいたします。
ブラックフライデー / サイバーマンデーなど、特定の日の前後に可用性要件が高まった場合、お客様は Google Cloud が提供するプログラムを利用して、Google Cloud で実行されている特定のアプリケーションを確認および検証し、アプリケーションと Google のサービス間の予期しないサービスの依存関係を特定できます。
ポイント オブ プレゼンス（POP）
Google では、ピアリング拠点を結ぶグローバル ネットワークを運用しています。お客様のトラフィックは、宛先に近づくまで Google のネットワーク内を移動できるため、ユーザー エクスペリエンスとセキュリティが向上します。詳細については、ネットワーク エッジのロケーションをご覧ください。
データの地理的管理
Google Cloud サービスにおけるデータの局所性は、サービス固有の規約を含む利用規約に定められています。Google では、それぞれお客様に独自のセキュリティおよびコンプライアンス上のニーズがあることを理解しています。お客様の要件を満たせるよう、Google Cloud セールスチームがお手伝いをいたします。
リージョンまたはゾーンで保存されているリソースを使用するときには、障害復旧のために、データを他のリージョンに複製するか、Multi-Regional Storage リソースにスナップショットを作成することを強く推奨いたします。
アプリケーション デプロイの留意点
- ゾーンが利用不可能になった場合も耐えられる、可能性の高いサービスとアプリケーションを作成するには
以下の対象を使用します。
- リージョン リソース（App Engine アプリケーションなど）、リージョン マネージド インスタンス グループ、またはマネージドのマルチリージョン リソース（Cloud Storage、Datastore、Firestore、Spanner など）。
- ゾーンリソース（Compute Engine 仮想マシンなど）。ただし、ゾーンまたはリージョンをまたいでコンピューティングとストレージの冗長性をご自身で管理する必要があります。
- リージョン全体が幅広く喪失した場合に耐えられる、障害復旧が可能なアプリケーションを作成するには
データの場合、次のうちの 1 つまたは複数の戦略を使います。
- マネージドのマルチリージョン ストレージ サービス（Cloud Storage、Datastore、Firestore、Spanner など）を使用する。
- ゾーンリソースまたはリージョン リソースを使用する一方で、マルチリージョン リソース（Cloud Storage、Datastore、Firestore、Spanner など）にデータのスナップショットを作成する。
- ゾーンリソースまたはリージョン リソースを使用し、データは他の 1 つまたは複数のリージョンに複製されるようにする。
コンピューティングの場合、次の戦略を使います。
- ゾーンリソースまたはリージョン リソース（Compute Engine や App Engine など）を使用しますが、データがマネージドのマルチリージョン リソースにない場合は、プライマリ データのコピーを参照し、（リージョンの障害の場合は）他のリージョンでアプリケーションを手動または自動で立ち上げます。
サービスの依存関係について詳しくは、お問い合わせをご覧ください。
追加のソリューションとチュートリアル
次のソリューションとチュートリアルは、アプリケーションの可用性を高め、停止にも耐えられるようにするためのガイダンスとなります。
スケーラブルで復元性が高いアプリのためのパターン
Google Cloud を使用して、ウェブ アプリケーションに広く適用されるパターンや手法を使用して、スケーラブルで復元性の高いアプリケーション アーキテクチャを構築する方法を学習します。
HTTPS ロードバランサの作成
複数のリージョンで Compute Engine のインスタンスを構成し、HTTP 負荷分散によってリージョンを横断してトラフィックを分散させることで、リージョン間での可用性を向上させ、サービス停止の場合にもフェイルオーバーができるようになります。
堅牢なシステムの設計
障害、ネットワーク中断、予期せぬ災害に対して堅牢でいられるように、Compute Engine のサービスを設計します。
Cloud Storage を使用した Cassandra のバックアップと復元
Cloud Storage でデータのバックアップと復元を行うことで、Cassandra インストール環境で基本的な障害復旧を可能にする方法を学習します。
障害復旧計画ガイド
Google Cloud で障害復旧計画を設計、テストするための一般的な原則です。