Google Cloud リージョン デプロイ アーキタイプ

Last reviewed 2024-01-31 UTC

Google Cloud デプロイ アーキタイプ ガイドのこのセクションでは、リージョン デプロイ アーキタイプについて説明します。

リージョン デプロイ アーキタイプを使用するクラウド アーキテクチャでは、アプリケーションのインスタンスが単一の Google Cloud リージョン内の複数のゾーンで実行されます。すべてのアプリケーション インスタンスは、一元管理された構成ファイルの共有リポジトリを使用します。アプリケーション データは、アーキテクチャ内のすべてのゾーン間で同期的に複製されます。

次の図は、単一の Google Cloud リージョン内の 3 つのゾーンで独立して実行される高可用性アプリケーションのクラウド トポロジを示しています。

リージョン デプロイ アーキタイプ。

上の図は、Google Cloud リージョンの 3 つのゾーンで独立して実行されるフロントエンドとバックエンドのコンポーネントを持つアプリケーションを示しています。外部ロードバランサは、ユーザー リクエストをいずれかのフロントエンドに転送します。内部ロードバランサは、フロントエンドからバックエンドにトラフィックを転送します。このアプリケーションは、ゾーン間で複製されるデータベースを使用しています。ゾーンが停止した場合、データベースは別のゾーンのレプリカにフェイルオーバーします。

上の図のトポロジは、ゾーンの停止には堅牢ですが、リージョンの停止に対しては耐性がありません。リージョンの停止から復旧するには、次の図のように、アプリケーションのパッシブ レプリカを 2 つ目の(フェイルオーバー)リージョンにデプロイしておく必要があります。

フェイルオーバー リージョンのあるリージョン デプロイ アーキタイプ。

プライマリ リージョンでサービスが停止した場合、フェイルオーバー リージョンのデータベースを昇格させ、DNS ルーティング ポリシーによってフェイルオーバー リージョンのロードバランサにトラフィックをルーティングする必要があります。

フェイルオーバー インフラストラクチャの費用を最適化するには、デプロイするリソースの数を減らし、フェイルオーバー リージョンをより少ない容量で運用します。

ユースケース

次のセクションでは、リージョン デプロイ アーキタイプが適切なユースケースの例を示します。

地域内のユーザーが使用する高可用性アプリケーション

ゾーンの停止に対する堅牢性が必要で、リージョンの停止によるダウンタイムを許容できるアプリケーションには、リージョン デプロイ アーキタイプをおすすめします。アプリケーション スタックのいずれかの部分で障害が発生しても、すべての層に十分な容量を持つ正常なコンポーネントが 1 つ以上存在すれば、アプリケーションの実行が継続されます。ゾーンが停止しても、アプリケーション スタックは引き続き他のゾーンで実行されます。

アプリケーション ユーザーに対する低レイテンシ

アプリケーション ユーザーが 1 つの国などの地域内にいる場合、リージョン デプロイ アーキタイプを使用すると、ユーザーから見たアプリケーションのパフォーマンスを向上させることができます。ユーザーに最も近い Google Cloud リージョンにアプリケーションをデプロイすることで、ユーザー リクエストのネットワーク レイテンシを最適化できます。

アプリケーション コンポーネント間の低レイテンシ ネットワーキング

単一リージョン アーキテクチャは、コンピューティング ノード間で低レイテンシかつ高帯域幅のネットワーク接続を必要とするバッチ コンピューティングなどのアプリケーションに適しています。すべてのリソースは単一の Google Cloud リージョン内にあるため、リソース間のネットワーク トラフィックはリージョン内に残ります。リソース間のネットワーク レイテンシは低く、リージョン間のデータ転送の費用は発生しません。リージョン内のネットワークの費用は引き続き適用されます。

データ所在地と主権の要件を遵守する

リージョン デプロイ アーキタイプでは、データ所在地と運用主権に関する規制要件を満たすことができます。たとえば、ヨーロッパのある国では、その国に物理的に配置されたデータセンターですべてのユーザーデータを保存し、アクセスすることが義務付けられている場合があります。この要件を満たすには、アプリケーションをヨーロッパの Google Cloud リージョンにデプロイします。

設計上の考慮事項

リージョン デプロイ アーキタイプに基づいてアーキテクチャを構築する場合は、次の設計要素を考慮してください。

リージョン停止中のダウンタイム

リージョンが停止すると、アプリケーションが停止します。別の Google Cloud リージョンでインフラストラクチャ スタックのパッシブ(フェイルオーバー)レプリカを維持することで、リージョンの停止によるダウンタイムを短縮できます。プライマリ リージョンでサービスが停止した場合は、フェイルオーバー リージョンでスタックを有効にして、DNS ルーティング ポリシーを使用してフェイルオーバー リージョンのロードバランサにトラフィックをルーティングします。

冗長リソースのコスト

通常、マルチゾーン アーキテクチャには単一ゾーン デプロイよりも多くのクラウド リソースがあります。アーキテクチャを構築する場合は、これらのクラウド リソースの費用を考慮してください。ゾーンの停止に対する堅牢性が求められるアプリケーションの場合、マルチゾーン アーキテクチャの可用性を利用することにより、コストの増加を上回るメリットが得られます。

リファレンス アーキテクチャ

Compute Engine VM でのリージョン デプロイの設計に使用できるリファレンス アーキテクチャについては、Compute Engine でのリージョン デプロイをご覧ください。