Compute Engine でのマルチリージョン デプロイ

このドキュメントでは、 Google Cloudの複数のリージョンにある Compute Engine VM 上で実行される、多層アプリケーションのリファレンス アーキテクチャについて説明します。このリファレンス アーキテクチャを使用すると、アプリケーションの変更を最小限に抑えながら、オンプレミス アプリケーションをクラウドへ効率的に再ホスト（リフト＆シフト）できます。このドキュメントでは、クラウド アプリケーションのマルチリージョン アーキテクチャを構築する際に考慮すべき設計要素についても説明します。このドキュメントは、クラウド アーキテクトを対象としています。

アーキテクチャ

次の図は、2 つの Google Cloud リージョンにまたがってデプロイされた分離スタックで、アクティブ / アクティブ モードで実行されるアプリケーションのアーキテクチャを示しています。各リージョンのアプリケーションは、3 つのゾーンで独立して実行されます。このアーキテクチャは、Google Cloud マルチリージョン デプロイ アーキタイプと一致します。これにより、 Google Cloud トポロジがゾーンとリージョンの停止に対して堅牢になり、アプリケーション ユーザーのレイテンシも短縮されます。

このアーキテクチャは、Infrastructure as a Service（IaaS）クラウドモデルに基づいています。必要なインフラストラクチャ リソース（コンピューティング、ネットワーキング、ストレージ）を Google Cloudでプロビジョニングするのは、ユーザー側の作業となります。また、オペレーティング システム、ミドルウェア、アプリケーション スタックの上位レイヤについては、ユーザーが完全に制御し、責任を負います。IaaS や他のクラウドモデルの詳細については、PaaS、IaaS、SaaS、CaaS の違いをご覧ください。

この図には、次のコンポーネントが含まれています。

コンポーネント	目的
グローバル外部ロードバランサ	グローバル外部ロードバランサは、ユーザーのリクエストを受信してアプリケーションに分散します。グローバル外部ロードバランサは単一のエニーキャスト IP アドレスをアドバタイズしますが、Google Front End（GFE）では多数のプロキシとして実装されます。クライアント リクエストは、クライアントに最も近い GFE に転送されます。
ウェブ階層のリージョン マネージド インスタンス グループ（MIG）	アプリケーションのウェブ階層は、リージョン MIG の一部である Compute Engine VM にデプロイされます。これらの MIG は、グローバル ロードバランサのバックエンドです。 各 MIG は、3 つの異なるゾーン内の Compute Engine VM で構成されています。これらの各 VM は、アプリケーションのウェブ階層の独立したインスタンスをホストします。
リージョン内部ロードバランサ	各リージョンの内部ロードバランサは、ウェブ階層 VM からのトラフィックを、このリージョンのアプリケーション階層 VM に分散します。
アプリケーション階層のリージョン MIG	アプリケーション階層は、リージョン MIG の一部である Compute Engine VM にデプロイされます。各リージョンの MIG は、そのリージョン内の内部ロードバランサのバックエンドです。 各 MIG は、3 つの異なるゾーン内の Compute Engine VM で構成されています。各 VM には、アプリケーション階層の独立したインスタンスがホストされます。
Compute Engine VM にデプロイされたサードパーティ データベース	このドキュメントのアーキテクチャは、2 つのリージョンの Compute Engine VM にデプロイされたサードパーティ データベース（PostgreSQL など）を示しています。データベースにクロスリージョン レプリケーションを設定し、各リージョンのデータベースが他のリージョンのデータベースにフェイルオーバーするように構成できます。レプリケーションとフェイルオーバーの機能は、使用するデータベースによって異なります。 サードパーティ データベースをインストールして管理するには、レプリケーション、更新の適用、モニタリング、可用性の確保のため、追加の労力と運用コストがかかります。マルチリージョンの Spanner インスタンスなどのフルマネージド データベースを使用することで、サードパーティ データベースのインストールと管理のオーバーヘッドを回避し、組み込みの高可用性（HA）機能を利用できます。
Virtual Private Cloud ネットワークとサブネット	アーキテクチャ内のすべての Google Cloud リソースは、2 つのリージョンにそれぞれサブネットを持つ、単一の VPC ネットワークを使用します。 要件に応じて、複数の VPC ネットワークとサブネットを使用するアーキテクチャを構築できます。詳細については、複数の VPC ネットワークを作成するかどうかを決定するをご覧ください。
Cloud Storage デュアルリージョン バケット	データベースのバックアップは、デュアルリージョンの Cloud Storage バケットに保存されます。また、Backup and DR サービスを使用して、データベースのバックアップを作成、保存、管理することもできます。

使用するプロダクト

このリファレンス アーキテクチャでは、次の Google Cloud プロダクトを使用します。

• Compute Engine: Google のインフラストラクチャで VM を作成して実行できる、安全でカスタマイズ可能なコンピューティング サービス。
• Cloud Load Balancing: 高パフォーマンスでスケーラブルなグローバル ロードバランサとリージョン ロードバランサのポートフォリオ。
• Cloud Storage: 低コストで無制限のオブジェクト ストア。さまざまなデータ型に対応しています。データには Google Cloudの内部および外部からアクセスでき、冗長性を確保するために複数のロケーションに複製されます。
• Virtual Private Cloud（VPC）: Google Cloud ワークロードにグローバルでスケーラブルなネットワーキング機能を提供する仮想システム。VPC には、VPC ネットワーク ピアリング、Private Service Connect、プライベート サービス アクセス、共有 VPC が含まれます。

ユースケース

このセクションでは、Compute Engine のマルチリージョン デプロイが適切となるユースケースについて説明します。

オンプレミス アプリケーションの効率的な移行

このリファレンス アーキテクチャを使用すると、アプリケーションの変更を最小限に抑えながら、オンプレミス アプリケーションをクラウドに再ホスト（リフト＆シフト）する Google Cloud トポロジを構築できます。このリファレンス アーキテクチャでは、アプリケーションのすべての階層が Compute Engine VM でホストされます。このアプローチでは、オンプレミスのアプリケーションをクラウドに効率的に移行でき、 Google Cloudが実現する費用面のメリット、信頼性、パフォーマンス、運用の簡素化を活用できます。

地理的に分散したユーザーに対する高可用性

ビジネス クリティカルで、リージョンの停止に対する高可用性と堅牢性が重要となるアプリケーションには、マルチリージョン デプロイをおすすめします。1 つのリージョンがなんらかの理由で利用できなくなった場合でも（自然災害による大規模な停止が発生した場合でも）、アプリケーションのユーザーにダウンタイムは発生しません。トラフィックは、使用可能な他のリージョンのアプリケーションにルーティングされます。データが同期的に複製される場合、目標復旧時間（RTO）はほぼゼロになります。

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

ユーザーが大陸などの特定の地域内にいる場合は、マルチリージョンのデプロイを使用して、可用性とパフォーマンスの最適なバランスを実現できます。いずれかのリージョンが停止すると、グローバル ロードバランサは、そのリージョンから送信されたリクエストを別のリージョンに送信します。これらのリージョンは 1 つの地域内にあるため、ユーザーはパフォーマンスに大きな影響が出ているとは感じません。

代替案の設計

上のアーキテクチャでは、Cloud CDN を使用したエッジ キャッシングなど、デプロイの信頼性を高めるために役立つ特定の機能をサポートするグローバル ロードバランサを使用しています。このセクションでは、リージョン ロードバランサと Cloud DNS を使用する代替アーキテクチャについて説明します。この代替アーキテクチャは、次の追加機能をサポートします。

• 指定したリージョンでの Transport Layer Security（TLS）終端。
• 指定したリージョンからのコンテンツの提供。ただし、このリージョンは、その時点で最もパフォーマンスの高いリージョンではない可能性もあります。
• パススルー ネットワーク ロードバランサを使用する場合の、幅広い種類の接続プロトコル。

リージョン ロードバランサとグローバル ロードバランサの違いについては、グローバル ロード バランシングとリージョン ロード バランシングと運用モードをご覧ください。

上の図の代替アーキテクチャは、ゾーンとリージョンの停止に対して堅牢です。Cloud DNS 一般公開ゾーンは、ユーザー リクエストを適切なリージョンに転送します。リージョン外部ロードバランサは、受信したユーザー リクエストを、各リージョン内のアプリケーションのウェブ階層インスタンス全体に分散します。このアーキテクチャの他のコンポーネントは、グローバル ロードバランサ ベースのアーキテクチャのコンポーネントと同じです。

設計上の考慮事項

このセクションでは、このリファレンス アーキテクチャを使用して、システム設計、セキュリティ、信頼性、運用効率、費用、パフォーマンスに関する特定の要件を満たすアーキテクチャを開発するためのガイダンスを示します。

ワークロードのアーキテクチャを構築する際は、Google Cloud Well-Architected Framework のベスト プラクティスと推奨事項を検討してください。

システム設計

このセクションでは、マルチリージョン デプロイに使用する Google Cloud リージョンの選択と、適切な Google Cloudサービスの選択に役立つガイダンスを示します。

リージョンの選択

アプリケーションをデプロイする Google Cloud リージョンを選択する場合は、次の要素と要件を考慮してください。

• 各リージョンでの Google Cloud サービスの可用性。詳細については、ロケーション別のプロダクト提供状況をご覧ください。
• 各リージョンで使用できる Compute Engine マシンタイプ。詳細については、リージョンとゾーンをご覧ください。
• エンドユーザーのレイテンシ要件。
• Google Cloud リソースの費用。
• リージョン間でのデータ転送の費用。
• 規制要件。

これらの要素や要件の中には、トレードオフを伴うものもあります。たとえば、費用対効果の最も高いリージョンが、温室効果ガス排出量が最も少ないリージョンとは限りません。詳細については、Compute Engine のリージョン選択に関するベスト プラクティスをご覧ください。

コンピューティング インフラストラクチャ

このドキュメントのリファレンス アーキテクチャでは、アプリケーションの特定の階層に Compute Engine VM が使用されています。アプリケーションの要件に応じて、他の Google Cloud コンピューティング サービスを選択できます。

• コンテナ: Google Kubernetes Engine（GKE）クラスタでは、コンテナ化されたアプリケーションを実行できます。GKE は、コンテナ化されたアプリケーションのデプロイ、スケーリング、管理を自動化するコンテナ オーケストレーション エンジンです。
• サーバーレス: インフラストラクチャ リソースの設定や運用ではなく、データとアプリケーションに IT の労力を集中させたい場合は、Cloud Run などのサーバーレス サービスを使用します。

VM、コンテナ、サーバーレス サービスのどれを使用するかの決定には、構成の柔軟性と管理上の労力とのトレードオフが伴います。VM とコンテナは比較的柔軟に構成できますが、リソースの管理責任はユーザーにあります。サーバーレス アーキテクチャでは、必要となる管理作業が最も少ない事前構成されたプラットフォームにワークロードをデプロイします。Google Cloudのワークロードに適したコンピューティング サービスの選択の詳細については、 Google Cloudでのアプリケーションのホスティングをご覧ください。

ストレージ サービス

このドキュメントで紹介する各アーキテクチャでは、すべての階層でリージョン Persistent Disk ボリュームを使用します。永続ディスクは、リージョン内の 2 つのゾーン間でデータの同期レプリケーションを行います。

Google Cloud Hyperdisk は、Persistent Disk よりもパフォーマンス、柔軟性、効率性に優れています。Hyperdisk Balanced を使用すると、IOPS とスループットを個別にかつ動的にプロビジョニングできるため、さまざまなワークロードに合わせてボリュームを調整できます。

複数のロケーションに複製される低コストのストレージが必要な場合は、Cloud Storage リージョン バケット、デュアルリージョン バケット、マルチリージョン バケットを使用できます。

• リージョン バケット内のデータは、リージョン内のゾーン間で同期的に複製されます。
• デュアルリージョン バケットまたはマルチリージョン バケット内のデータは、少なくとも 2 つの地理的に離れた場所に冗長的に保存されます。メタデータはリージョン間で同期的に書き込まれ、データは非同期で複製されます。デュアルリージョン バケットの場合は、ターボ レプリケーションを使用できます。これにより、15 分の目標復旧時点（RPO）で、オブジェクトがリージョンペア間で複製されます。詳細については、データの可用性と耐久性をご覧ください。

リージョン内の複数の VM（ウェブ階層やアプリケーション階層のすべての VM など）間で共有されるデータを保存するには、Filestore リージョン インスタンスを使用します。Filestore リージョン インスタンスに保存されたデータは、リージョン内の 3 つのゾーン間で同期してレプリケートされます。このレプリケーションにより、ゾーンの停止に対する高可用性と堅牢性が確保されます。Filestore インスタンスには、共有構成ファイル、一般的なツールとユーティリティ、一元化されたログを保存し、そのインスタンスを複数の VM にマウントできます。 リージョンの停止に対する堅牢性を確保するには、Filestore インスタンスを別のリージョンにレプリケートします。詳細については、インスタンス レプリケーションをご覧ください。

データベースが Microsoft SQL Server の場合は、Cloud SQL for SQL Server の使用をおすすめします。Cloud SQL が構成要件をサポートしていない場合や、オペレーティング システムにアクセスする必要がある場合は、Microsoft SQL Server フェイルオーバー クラスタ インスタンス（FCI）をデプロイできます。このシナリオでは、フルマネージドの Google Cloud NetApp Volumes を使用して、データベースに継続的可用性（CA）SMB ストレージを用意できます。

ワークロードのストレージを設計する場合は、機能特性、復元力の要件、パフォーマンスの期待値、費用目標を考慮します。詳細については、クラウド ワークロードに最適なストレージ戦略の設計をご覧ください。

データベース サービス

このドキュメントのリファレンス アーキテクチャでは、Compute Engine VM にデプロイされたサードパーティ製データベースを使用しています。サードパーティ製データベースのインストールと管理には、更新の適用、モニタリングと可用性の確保、バックアップの実行、障害からの復旧などの運用に労力と費用がかかります。

フルマネージド データベース サービス（Cloud SQL、AlloyDB for PostgreSQL、Bigtable、Spanner、Firestore など）を使用すると、サードパーティ製データベースをインストールして管理する労力とコストを回避できます。こうした Google Cloud データベース サービスには、稼働時間のサービスレベル契約（SLA）が用意されており、スケーラビリティとオブザーバビリティのためのデフォルト機能を備えています。

ワークロードに Oracle データベースが必要な場合は、Compute Engine VM にデータベースをデプロイするか、Oracle Database@Google Cloud を使用できます。詳細については、 Google Cloudの Oracle ワークロードをご覧ください。

マルチリージョン デプロイ用にデータベースを選択して設定する場合は、リージョン間のデータ整合性に関するアプリケーションの要件を考慮し、パフォーマンスとコストのトレードオフに注意してください。

• アプリケーションに強整合性が必要な場合は（常にすべてのユーザーが同じデータを読み取る必要がある場合）、アーキテクチャ内のすべてのリージョン間でデータを同期的に複製する必要があります。ただし、同期レプリケーションでは、書き込まれたすべてのデータが、リージョン間でリアルタイムに複製してからでないとデータの読み取りオペレーションに使用できないため、コストの上昇とパフォーマンスの低下につながる可能性があります。
• 結果整合性を許容できるアプリケーションの場合は、データを非同期で複製できます。この場合は、データをリージョン間で同期的に複製する必要がないため、パフォーマンスを向上させることができます。しかし、リクエスト時にデータが完全に複製されていない可能性が生じるため、リージョンの異なるユーザーが異なるデータを読み込んでしまう可能性があります。

ネットワーク設計

ビジネス要件と技術要件を満たすネットワーク設計を選択します。単一の VPC ネットワークだけでなく、複数の VPC ネットワークを使用することもできます。詳細については、以下のドキュメントをご覧ください。

• 複数の VPC ネットワークを作成するかどうかを決定する
• Google Cloud ランディング ゾーンのネットワーク設計を決定する

セキュリティ、プライバシー、コンプライアンス

このセクションでは、このリファレンス アーキテクチャを使用して、ワークロードのセキュリティ、プライバシー、コンプライアンスの要件を満たすマルチリージョン トポロジをGoogle Cloud で設計し、構築する際に考慮すべき要素について説明します。

外部の脅威からの保護

分散型サービス拒否（DDoS）攻撃やクロスサイト スクリプティング（XSS）などの脅威からアプリケーションを保護するには、Google Cloud Armor セキュリティ ポリシーを使用します。個々のポリシーは、評価すべき特定の条件と、その条件が満たされた場合に実行するアクションを指定する一連のルールです。たとえば、受信トラフィックの送信元 IP アドレスが特定の IP アドレスまたは CIDR 範囲と一致する場合は、トラフィックを拒否しなければならないと、ルールで指定できます。事前構成されたウェブ アプリケーション ファイアウォール（WAF）ルールを適用することもできます。詳細については、セキュリティ ポリシーの制限をご覧ください。

VM に対する外部アクセス

このドキュメントで説明するリファレンス アーキテクチャでは、Compute Engine VM がインターネットからのインバウンド アクセスを必要としません。これらの VM には、外部 IP アドレスを割り当てないでください。プライベートの内部 IP アドレスしか持たない Google Cloud リソースであっても、Private Service Connect またはプライベート Google アクセスを使用して、特定の Google API やサービスにアクセスできます。詳細については、サービスのプライベート アクセス オプションをご覧ください。

このリファレンス アーキテクチャの Compute Engine VM など、プライベート IP アドレスのみを持つ Google Cloud リソースからの安全なアウトバウンド接続を可能にするには、Secure Web Proxy または Cloud NAT を使用します。

サービス アカウントの権限

アーキテクチャの Compute Engine VM では、デフォルトのサービス アカウントを使用するのではなく、専用のサービス アカウントを作成して、サービス アカウントがアクセスできるリソースを指定することをおすすめします。デフォルトのサービス アカウントには、必要のない可能性がある権限も含め、幅広い権限が付与されています。専用のサービス アカウントを作成すれば、必要な権限のみを持つように調整できます。詳細については、サービス アカウントの権限を制限するをご覧ください。

SSH セキュリティ

アーキテクチャ内の Compute Engine VM に対する SSH 接続のセキュリティを強化するには、Identity-Aware Proxy（IAP）と Cloud OS Login API を実装します。IAP を使用すると、ユーザー ID と Identity and Access Management（IAM）ポリシーに基づいてネットワーク アクセスを制御できます。Cloud OS Login API を使用すると、ユーザー ID と IAM ポリシーに基づいて Linux SSH アクセスを制御できます。ネットワーク アクセスの管理の詳細については、SSH ログイン アクセスを制御するためのベスト プラクティスをご覧ください。

ディスクの暗号化

デフォルトでは、Persistent Disk ボリュームに保存されるデータはGoogle-owned and Google-managed encryption keysを使用して暗号化されます。追加の保護レイヤとして、Cloud Key Management Service（Cloud KMS）により、所有して管理する鍵で Google-owned and managed key を暗号化することもできます。詳細については、Hyperdisk ボリュームのディスク暗号化についてと顧客管理の暗号鍵でデータを暗号化するをご覧ください。

ネットワーク セキュリティ

アーキテクチャのリソース間のネットワーク トラフィックを制御するには、適切な Cloud Next Generation Firewall（NGFW）ポリシーを構成する必要があります。

データ所在地に関する検討事項

リージョン ロードバランサを使用すると、データ所在地の要件を満たすために役立つマルチリージョン アーキテクチャを構築できます。たとえば、ヨーロッパのある国では、ヨーロッパ内に物理的に設置されたデータセンターにすべてのユーザーデータを保存し、ここにアクセスすることが義務付けられているとします。この要件を満たすには、リージョン ロードバランサに基づくアーキテクチャを使用します。このアーキテクチャでは、アプリケーションはヨーロッパのGoogle Cloud リージョンで実行されます。また、ジオフェンス ルーティング ポリシーとともに Cloud DNS を使用して、リージョン ロードバランサ経由でトラフィックをルーティングします。データベース階層のデータ所在地の要件を満たすには、リージョン間でレプリケーションするのではなく、シャーディング アーキテクチャを使用します。このアプローチでは、各リージョンのデータは分離されますが、データベースにリージョン間の高可用性とフェイルオーバーを実装することはできません。

セキュリティ上のその他の考慮事項

ワークロードのアーキテクチャを構築する際は、エンタープライズ基盤のブループリントと Google Cloud Well-Architected Framework: セキュリティ、プライバシー、コンプライアンスで提供されているプラットフォーム レベルのセキュリティのベスト プラクティスと推奨事項を検討してください。

信頼性

このセクションでは、このリファレンス アーキテクチャを使用して、 Google Cloudでのマルチリージョン デプロイ用に信頼性の高いインフラストラクチャを構築して運用する際に考慮すべき設計要素について説明します。

インフラストラクチャの停止に対する堅牢性

マルチリージョン デプロイメントでは、インフラストラクチャ スタック内の個々のコンポーネントに障害が発生しても、各階層に十分な容量を持つ正常なコンポーネントが 1 つ以上存在すれば、アプリケーションはリクエストを処理できます。たとえば、ウェブサーバー インスタンスに障害が発生した場合、ロードバランサは、利用可能な他のウェブサーバー インスタンスにユーザー リクエストを転送します。ウェブサーバーやアプリサーバー インスタンスをホストする VM がクラッシュすると、MIG は VM を自動的に再作成します。

ロードバランサは、リージョン リソースであるため、ゾーンが停止しても影響を受けません。ゾーンが停止すると、個々の Compute Engine VM が影響を受ける可能性があります。しかし、VM はリージョン MIG 内にあるため、アプリケーションは引き続き利用可能であり、応答可能な状態です。リージョン MIG を使用すると、新しい VM が自動的に作成され、最小構成の VM 数が維持されます。Google がゾーンのサービス停止を解決した後、アプリケーションがデプロイされているすべてのゾーンで想定どおりに動作することを確認する必要があります。

一方のリージョンのすべてのゾーンが停止した場合や、リージョン全体が停止した場合、もう一方のリージョンのアプリケーションは引き続き利用可能であり、応答可能な状態です。グローバル外部ロードバランサは、停止の影響を受けていないリージョンにトラフィックを転送します。Google によりリージョンの停止が解決されたら、停止したリージョンでアプリケーションが想定どおりに動作していることを確認する必要があります。

このアーキテクチャの両方のリージョンが停止している場合、アプリケーションは使用できなくなります。Google により停止が解決されたら、アプリケーションが期待どおりに動作することを確認する必要があります。

MIG の自動スケーリング

複数のリージョン MIG でアプリケーションを実行すると、分離されたゾーンやリージョンが停止しても、アプリケーションを使用できます。ステートレス MIG の自動スケーリング機能を使用すると、アプリケーションの可用性とパフォーマンスを予測可能なレベルで維持できます。

ステートレス MIG の自動スケーリングの動作を制御するには、CPU の平均使用率などの目標使用率の指標を指定します。ステートレス MIG にスケジュール ベースの自動スケーリングを構成することもできます。ステートフル MIG は自動スケーリングできません。詳細については、インスタンスのグループの自動スケーリングをご覧ください。

MIG サイズの上限

MIG のサイズを決める際は、MIG で作成できる VM の数のデフォルトと上限を考慮してください。詳細については、MIG の VM を追加または削除するをご覧ください。

VM の自動修復

アプリケーションをホストする VM が稼働し、使用可能な状態になっていても、アプリケーション自体に問題があり、アプリケーションでフリーズやクラッシュが発生したり、メモリ不足になることがあります。アプリケーションが期待どおりに応答しているかどうかを確認するには、MIG の自動修復ポリシーの一部としてアプリケーション ベースのヘルスチェックを構成します。特定の VM 上のアプリケーションが応答しない場合、MIG はその VM を自動修復します。自動修復の構成の詳細については、高可用性のための VM の修復についてをご覧ください。

VM の配置

このドキュメントで説明するアーキテクチャでは、アプリケーション階層とウェブ階層は、複数のゾーンに分散された Compute Engine VM で実行されます。このように分散することで、ゾーンの停止に対するアプリケーションの耐性が強化されます。

アーキテクチャの堅牢性を向上させるには、スプレッド プレースメント ポリシーを作成して MIG テンプレートに適用します。MIG は VM を作成する際、異なる物理サーバー（ホスト）の各ゾーンに VM を配置するため、VM は個々のホストの障害に対する耐性が強化されます。詳細については、スプレッド プレースメント ポリシーを作成して VM に適用するをご覧ください。

VM のキャパシティ プランニング

VM のプロビジョニングが必要になったときに、Compute Engine VM の容量を確実に使用できるように、予約を作成しておくことができます。予約により、選択したマシンタイプの指定された数の VM に対して、特定のゾーンでの容量が保証されます。予約は、プロジェクトに固有のものにすることも、複数のプロジェクトで共有することもできます。予約の詳細については、予約の種類を選択するをご覧ください。

ステートフル ストレージ

アプリケーション設計におけるベスト プラクティスは、ステートフルなローカル ディスクを必要としないようにすることです。ただし、要件が存在する場合は、VM の修復または再作成時にデータが保持されるように、永続ディスクをステートフルに構成できます。ただし、ブートディスクはステートレスのままにし、新しいバージョンとセキュリティ パッチで最新のイメージに更新できるようにすることをおすすめします。詳細については、MIG でのステートフル永続ディスクの構成をご覧ください。

データの耐久性

Backup and DR を使用すると、Compute Engine VM のバックアップを作成、保存、管理できます。Backup and DR は、アプリケーションで読み取り可能な元の形式でバックアップ データを保存します。必要に応じて、長期バックアップ ストレージのデータを直接使用することで、ワークロードを本番環境に復元し、データの準備や移動を回避できます。

Compute Engine には、Persistent Disk ボリュームに保存されているデータの耐久性を確保するために、次のオプションが用意されています。

• スナップショットは、Persistent Disk ボリュームの特定時点の状態をキャプチャするために使用できます。スナップショットは複数のリージョンに冗長的に保存されます。また、自動チェックサムによりデータの整合性が確保されます。スナップショットはデフォルトで増分方式となるため、使用するストレージ容量が少なく、費用を節約できます。スナップショットは、構成可能な Cloud Storage のロケーションに保存されます。スナップショットの使用と管理に関する推奨事項については、Compute Engine ディスク スナップショットのベスト プラクティスをご覧ください。
• ゾーンの停止が発生した場合に Persistent Disk のデータが引き続き使用できるようにするには、リージョン Persistent Disk または Hyperdisk Balanced High Availability を使用します。これらのディスクタイプのデータは、同じリージョン内の 2 つのゾーン間で同期的に複製されます。詳細については、ディスクの同期レプリケーションについてをご覧ください。

データベースの可用性

Compute Engine VM にデプロイされたデータベースにゾーン間のフェイルオーバーを実装するには、プライマリ データベースの障害を特定する仕組みとスタンバイ データベースにフェイルオーバーするプロセスが必要です。フェイルオーバー メカニズムの詳細は、使用するデータベースによって異なります。オブザーバー インスタンスを設定してプライマリ データベースの障害を検出し、フェイルオーバーをオーケストレートできます。スプリット ブレイン状態を回避し、不要なフェイルオーバーを防ぐには、フェイルオーバーのルールを適切に構成する必要があります。PostgreSQL データベースのフェイルオーバーの実装に使用できるアーキテクチャの例については、Compute Engine 上の PostgreSQL クラスタの高可用性アーキテクチャをご覧ください。

信頼性に関するその他の考慮事項

ご自身のワークロード用のクラウド アーキテクチャを構築する際には、次のドキュメントに記載されている信頼性関連のベスト プラクティスと推奨事項を確認してください。

• Google Cloud インフラストラクチャ信頼性ガイド
• スケーラブルで復元性の高いアプリのためのパターン
• 復元性に優れたシステムの設計
• Google Cloud Well-Architected Framework: 信頼性

費用の最適化

このセクションでは、このリファレンス アーキテクチャを使用して構築するマルチリージョン Google Cloud トポロジの設定と運用の費用を最適化するためのガイダンスを示します。

VM マシンタイプ

VM インスタンスのリソース使用率を最適化できるように、Compute Engine には推奨のマシンタイプが用意されています。この推奨事項を参照して、ワークロードのコンピューティング要件と一致するマシンタイプを選択します。リソース要件を予測できるワークロードの場合は、ニーズに合わせてマシンタイプをカスタマイズし、カスタム マシンタイプを使用することで費用を節約できます。

VM プロビジョニング モデル

アプリケーションがフォールト トレラントである場合、Spot VM を使用すると、アプリケーション階層とウェブ階層で VM の Compute Engine にかかる費用を削減できます。Spot VM の費用は、通常の VM よりも大幅に低くなります。ただし、Compute Engine は処理能力を調整するために、Spot VM をプリエンプティブに停止または削除する場合があります。

Spot VM は、プリエンプションを許容でき、高可用性の要件がないバッチジョブに適しています。Spot VM は、通常の VM と同じマシンタイプ、オプション、パフォーマンスを提供します。ただし、ゾーンのリソース容量が制限されている場合は、必要な容量が再び使用可能になるまで、MIG が指定のターゲット サイズに自動的にスケールアウトできない可能性があります（つまり、VM を作成できない可能性があります）。

VM リソースの使用率

ステートレス MIG の自動スケーリング機能により、アプリケーションはトラフィックの増加を適切に処理でき、リソースの必要性が低いときに費用を削減できます。ステートフル MIG は自動スケーリングできません。

サードパーティのライセンス

サードパーティのワークロードを Google Cloudに移行する場合は、お客様所有ライセンスの使用（BYOL）で費用を削減できる可能性があります。たとえば、Microsoft Windows Server VM をデプロイする場合、サードパーティ ライセンスの追加費用が発生するプレミアム イメージを使用する代わりに、カスタム Windows BYOL イメージを作成して使用できます。この場合、 Google Cloudで使用する VM インフラストラクチャに対してのみ課金されます。この戦略により、サードパーティ ライセンスに対するこれまでの投資の価値を継続的に現金化できます。BYOL 方式を採用する場合は、次の推奨事項がコスト削減に役立つ可能性があります。

• カスタム マシンタイプを使用して、メモリとは別に必要な数のコンピューティング CPU コアをプロビジョニングします。これにより、サードパーティのライセンス費用を必要な CPU コア数に制限できます。
• 同時マルチスレッディング（SMT）を無効にして、コアあたりの vCPU 数を 2 から 1 に減らします。

サードパーティ製データベース（Microsoft SQL Server など）を Compute Engine VM にデプロイする場合は、サードパーティ ソフトウェアのライセンス費用を考慮する必要があります。マネージド データベース サービス（Cloud SQL など）を使用する場合、データベース ライセンス費用はサービスの料金に含まれています。

費用に関するその他の考慮事項

ワークロードのアーキテクチャを構築する際には、Google Cloud Well-Architected Framework: Cost optimization に記載されている一般的なベスト プラクティスと推奨事項も検討してください。

業務の効率化

このセクションでは、このリファレンス アーキテクチャを使用して、効率的に運用できるマルチリージョン Google Cloudトポロジを設計および構築する際に考慮すべき要素について説明します。

VM 構成の更新

MIG 内の VM の構成（マシンタイプやブートディスク イメージなど）を更新するには、必要な構成を持つ新しいインスタンス テンプレートを作成し、そのテンプレートを MIG に適用します。MIG は、選択した更新方法（自動または選択）を使用して VM を更新します。可用性と業務の効率化の要件に基づいて、適切な方法を選択してください。これらの MIG の更新方法について詳しくは、MIG で新しい VM 構成を適用するをご覧ください。

VM イメージ

VM では、Google 提供の公開イメージを使用するのではなく、アプリケーションに必要な構成とソフトウェアを含むカスタム OS イメージを作成して使用することをおすすめします。カスタム イメージは、カスタム イメージ ファミリーにまとめることができます。イメージ ファミリーは、そのファミリー内の最新のイメージを指すため、特定のイメージ バージョンへの参照を手動で更新しなくても、インスタンス テンプレートやスクリプトでそのイメージを使用できます。カスタム イメージを定期的に更新して、OS ベンダーから提供されるセキュリティ アップデートとパッチを含める必要があります。

確定的なインスタンス テンプレート

MIG に使用するインスタンス テンプレートに、サードパーティ ソフトウェアをインストールする起動スクリプトが含まれている場合は、そのスクリプトでソフトウェア バージョンなどのソフトウェア インストール パラメータを明示的に指定します。そうしないと、MIG が VM を作成するときに、VM にインストールされるソフトウェアに一貫性がなくなる可能性があります。たとえば、インスタンス テンプレートに Apache HTTP Server 2.0（apache2 パッケージ）をインストールする起動スクリプトが含まれている場合は、このスクリプトで、インストールする apache2 バージョン（バージョン 2.4.53 など）を正確に指定してください。詳細については、確定的なインスタンス テンプレートをご覧ください。

運用上のその他の考慮事項

ワークロードのアーキテクチャを構築する際には、Google Cloud Well-Architected Framework: Operational excellence で説明されている運用効率に関する一般的なベスト プラクティスと推奨事項を検討してください。

パフォーマンスの最適化

このセクションでは、このリファレンス アーキテクチャを使用して、ワークロードのパフォーマンス要件を満たすリージョン トポロジをGoogle Cloud で設計、構築する際に検討すべき要素について説明します。

コンピューティング パフォーマンス

Compute Engine には、VM で実行するワークロード用に、事前定義済みのカスタマイズ可能なマシンタイプが幅広く用意されています。パフォーマンス要件に基づいて適切なマシンタイプを選択します。詳細については、マシン ファミリーのリソースと比較ガイドをご覧ください。

VM のマルチスレッディング

Compute Engine VM に割り当てる各仮想 CPU（vCPU）は、単一のハードウェア マルチスレッドとして実装されます。デフォルトでは、2 つの vCPU が 1 つの物理 CPU コアを共有します。高度に並列化された処理を伴うアプリケーションや浮動小数点演算を実行するアプリケーション（遺伝子配列分析や金融リスクのモデリングなど）では、各物理 CPU コアで実行されるスレッド数を減らすことでパフォーマンスを改善できます。詳細については、コアあたりのスレッド数を設定するをご覧ください。

VM のマルチスレッディングは、サードパーティ ソフトウェア（データベースなど）のライセンスに影響する場合があります。詳細については、サードパーティ ソフトウェアのライセンスに関するドキュメントをご覧ください。

Network Service Tiers

Network Service Tiers を使用すると、ワークロードのネットワーク費用とパフォーマンスを最適化できます。プレミアム ティアまたはスタンダード ティアを選択できます。プレミアム ティアは、Google のグローバル バックボーンを使用してトラフィックを配信し、パケットロスとレイテンシを最小限に抑えます。スタンダード ティアでは、 Google Cloud ワークロードが実行されているリージョンに最も近いエッジ ポイント オブ プレゼンス（PoP）で、ピアリング、インターネット サービス プロバイダ（ISP）、またはトランジット ネットワークを使用してトラフィックが配信されます。パフォーマンスを最適化するには、プレミアム ティアを使用することをおすすめします。コストを最適化するには、スタンダード ティアを使用することをおすすめします。

ネットワーク パフォーマンス

アプリケーション階層とウェブ階層内で VM 間のネットワーク レイテンシを低くする必要があるワークロードの場合は、コンパクト プレースメント ポリシーを作成して、これらの階層に使用される MIG テンプレートに適用できます。MIG は VM を作成すると、互いに近くにある物理サーバーに VM を配置します。コンパクト プレースメント ポリシーは VM 間のネットワーク パフォーマンスの向上に役立ちます。スプレッド プレースメント ポリシーは、前述のように VM の可用性の向上に役立ちます。ネットワーク パフォーマンスと可用性のバランスを最適にするために、コンパクト プレースメント ポリシーを作成するときに、VM を配置する距離を指定できます。詳細については、プレースメント ポリシーの概要をご覧ください。

Compute Engine には、下り（外向き）ネットワーク帯域幅の VM ごとの上限があります。この上限は、VM のマシンタイプと、トラフィックがソース VM と同じ VPC ネットワーク経由でルーティングされるかどうかによって異なります。特定のマシンタイプを使用する VM の場合、ネットワーク パフォーマンスを向上させるために、Tier_1 ネットワーキングを有効にして下り（外向き）の最大帯域幅を増やすことができます。

キャッシュ

アプリケーションが静的なウェブサイト アセットを提供し、アーキテクチャにグローバル外部アプリケーション ロードバランサが含まれている場合は、Cloud CDN を使用することで、定期的にアクセスされる静的コンテンツをユーザーの近くにあるキャッシュに保存できます。Cloud CDN は、ユーザー側のパフォーマンスの向上、バックエンドでのインフラストラクチャ リソース使用量の削減、ネットワーク配信費用の削減に役立ちます。詳細については、ロード バランシングのためのウェブ パフォーマンスの加速とウェブ保護の向上をご覧ください。

パフォーマンスに関するその他の考慮事項

ワークロードのアーキテクチャを構築する際には、Google Cloud Well-Architected Framework: Performance optimization に記載されている一般的なベスト プラクティスと推奨事項も検討してください。

次のステップ

• このリファレンス アーキテクチャで使用される Google Cloud プロダクトの詳細を確認する。
  • Cloud Load Balancing の概要
  • インスタンス グループ
  • Cloud DNS の概要
• Google Cloudへのワークロードの移行を開始する。
• クラウド ワークロードのアーキテクチャを構築するために選択できるデプロイ アーキタイプを調べて評価する。
• Google Cloudでワークロードに信頼性の高いインフラストラクチャを設計するためのアーキテクチャ オプションを確認する。
• Cloud アーキテクチャ センターで、リファレンス アーキテクチャ、設計ガイド、ベスト プラクティスを確認する。

寄稿者

著者:

• Kumar Dhanagopal | クロス プロダクト ソリューション デベロッパー
• Samantha He | テクニカル ライター

その他の寄稿者:

• Ben Good | ソリューション アーキテクト
• Carl Franklin | ディレクター、PSO エンタープライズ アーキテクチャ
• Daniel Lees | クラウド セキュリティ アーキテクト
• Gleb Otochkin | Cloud アドボケイト、データベース
• Mark Schlagenhauf | テクニカル ライター、ネットワーキング
• Pawel Wenda | グループ プロダクト マネージャー
• Sean Derrington | ストレージ担当グループ プロダクト マネージャー
• Sekou Page | アウトバウンド プロダクト マネージャー
• Shobhit Gupta | ソリューション アーキテクト
• Simon Bennett | グループ プロダクト マネージャー
• Steve McGhee | 信頼性アドボケイト
• Victor Moreno | プロダクト マネージャー、クラウド ネットワーキング