Google Cloud デプロイ アーキタイプ ガイドのこのセクションでは、ゾーン デプロイ アーキタイプについて説明します。
基本的なゾーンデプロイ アーキタイプを使用するクラウド アーキテクチャでは、次の図のように、アプリケーションは単一の Google Cloud ゾーンで実行されます。
ゾーンの停止から復旧するには、次の図に示すようにデュアルゾーン アーキテクチャを使用します。デュアルゾーン アーキテクチャでは、アプリケーション スタックのパッシブ レプリカが 2 番目の（フェイルオーバー）ゾーンにプロビジョニングされます。
プライマリ ゾーンでサービスが停止した場合は、スタンバイ データベースをプライマリ（書き込み）データベースに昇格させて、フェイルオーバー ゾーンのフロントエンドにトラフィックを送信するようにロードバランサを更新できます。
ユースケース
ゾーン デプロイ アーキタイプが適切なユースケースの例を次に示します。
- クラウド開発環境とテスト環境: ゾーン デプロイ アーキタイプを使用すると開発とテスト用に低コストの環境を構築できます。
- 高可用性を必要としないアプリケーション: ダウンタイムを許容できるアプリケーションには、ゾーン デプロイ アーキタイプで十分な場合があります。
- アプリケーション コンポーネント間の低レイテンシ ネットワーキング: 単一ゾーンのアーキテクチャは、コンピューティング ノード間で低レイテンシかつ高帯域幅のネットワーク接続を必要とするアプリケーション（バッチ コンピューティングなど）に適しています。
- 日常的なワークロードの移行: ゾーン デプロイ アーキタイプは、コードを制御できなかったり、基本的なアクティブ / パッシブ トポロジを超えるアーキテクチャに対応できない日常的なオンプレミス アプリのクラウド移行パスを提供します。
- ライセンス制限のあるソフトウェアの実行: 一度に複数のインスタンスを実行するのが、コストがかかりすぎるか、許可されていないライセンス制限のあるシステムには、ゾーン デプロイ アーキタイプが適している可能性があります。
設計上の考慮事項
ゾーン デプロイ アーキタイプに基づくアーキテクチャを構築する場合は、ゾーンの停止とリージョンの停止で想定されるダウンタイムを考慮してください。
ゾーンの停止
アプリケーションがフェイルオーバー ゾーンのない単一ゾーンで実行される場合、ゾーンが停止するとアプリケーションはリクエストを処理できません。この状況を回避するには、同じリージョン内の別の（フェイルオーバー）ゾーンにインフラストラクチャ スタックのパッシブ レプリカを維持する必要があります。プライマリ ゾーンでサービスが停止した場合、フェイルオーバー ゾーンのデータベースをプライマリ データベースに昇格させて、受信トラフィックがフェイルオーバー ゾーンのフロントエンドに転送されるようにできます。Google が停止を復旧した後は、プライマリ ゾーンにフェイルバックするか、フェイルオーバー ゾーンにするかを選択できます。
リージョンの停止
リージョンが停止した場合、Google が停止を復旧するまで待ち、アプリケーションが想定どおりに動作することを確認する必要があります。リージョンの停止に対する堅牢性が必要な場合は、マルチリージョン デプロイ アーキタイプの使用を検討してください。
リファレンス アーキテクチャ
Compute Engine VM にゾーンデプロイを設計する際に使用できるリファレンス アーキテクチャについては、Compute Engine でのシングルゾーン デプロイをご覧ください。