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

Last reviewed 2024-01-31 UTC

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

アーキテクチャ

次の図では、リージョン内の 3 つの Google Cloud ゾーンにまたがってデプロイされた孤立スタックで、アクティブ / アクティブ モードで実行されるアプリケーションのアーキテクチャを示します。このアーキテクチャは、リージョン デプロイ アーキタイプに沿ったものになっており、Google Cloud トポロジがゾーンの停止に対して堅牢であることを保証します。

アプリケーションは、リージョン内の 3 つの Google Cloud ゾーンにまたがってデプロイされた孤立スタックでアクティブ / アクティブ モードで実行されます。

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

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

コンポーネント 目的
リージョン外部ロードバランサ

リージョン外部ロードバランサは、ユーザー リクエストを受け取り、ウェブ階層 VM に分散します。

トラフィックの種類やその他の要件に応じて、適切な種類のロードバランサを使用します。たとえば、バックエンドがウェブサーバーで構成されている場合（上記のアーキテクチャを参照）は、アプリケーション ロードバランサを使用して HTTP(S) トラフィックを転送します。TCP トラフィックをロードバランスするには、ネットワーク ロードバランサを使用します。詳細については、ロードバランサを選択するをご覧ください。
ウェブ階層のリージョン マネージド インスタンス グループ（MIG）

アプリケーションのウェブ階層は、リージョン MIG の一部である Compute Engine VM にデプロイされます。MIG は、リージョン外部ロードバランサのバックエンドです。

MIG には、3 つの異なるゾーンにある Compute Engine VM が含まれています。これらの各 VM は、アプリケーションのウェブ階層の独立したインスタンスをホストします。
リージョン内部ロードバランサ

リージョン内部ロードバランサは、ウェブ階層 VM からアプリケーション階層 VM にトラフィックを分散します。

要件に応じて、リージョン内部アプリケーション ロードバランサまたはネットワーク ロードバランサを使用できます。詳細については、ロードバランサを選択するをご覧ください。
アプリケーション階層のリージョン MIG

アプリケーション階層は、内部ロードバランサのバックエンドであるリージョン MIG の一部である Compute Engine VM にデプロイされます。

MIG には、3 つの異なるゾーンにある Compute Engine VM が含まれています。各 VM では、アプリケーション階層の独立したインスタンスがホストされます。
Compute Engine VM にデプロイされたサードパーティ製データベース

このドキュメントのアーキテクチャは、Compute Engine VM にデプロイされたサードパーティ製データベース（PostgreSQL など）を示しています。スタンバイ データベースは別のゾーンにデプロイできます。データベースのレプリケーションとフェイルオーバーの機能は、使用するデータベースによって変わります。

サードパーティ製データベースのインストールと管理には、更新の適用、モニタリング、可用性の確保など、追加の労力と運用コストがかかります。Cloud SQL や AlloyDB for PostgreSQL などのフルマネージド データベース サービスを使用すると、サードパーティ製データベースのインストールと管理にかかるオーバーヘッドを回避し、組み込みの高可用性（HA）機能を利用できます。マネージド データベースのオプションの詳細については、このガイドの後半のデータベース サービスをご覧ください。
Virtual Private Cloud ネットワークとサブネット

このアーキテクチャ内のすべての Google Cloud リソースは、単一の VPC ネットワークとサブネットを使用します。

要件に応じて、複数の VPC ネットワークや複数のサブネットを使用するアーキテクチャも構築できます。詳細については、「VPC 設計のためのベスト プラクティスとリファレンス アーキテクチャ」の複数の VPC ネットワークを作成するかどうかを決定するをご覧ください。
Cloud Storage デュアルリージョン バケット

アプリケーションとデータベースのバックアップは、デュアルリージョンの Cloud Storage バケットに保存されます。ゾーンまたはリージョンが停止しても、アプリケーションとデータは失われません。

また、バックアップと DR サービスを使用して、データベースのバックアップを作成、保存、管理することも可能です。

使用するプロダクト

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

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

ユースケース

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

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

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

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

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

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

アプリケーションのすべてのユーザーが同じ地域（1 つの国など）にいる場合は、リージョン デプロイ アーキテクチャによって、ユーザーから見たアプリケーションのパフォーマンスを改善できます。ユーザーに最も近い Google Cloud リージョンにアプリケーションをデプロイすることで、ユーザー リクエストのネットワーク レイテンシを最適化できます。

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

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

データ所在地に関する要件の遵守

シングルリージョン アーキテクチャを使用すると、データ所在地の要件を満たすうえで役に立つトポロジを構築できます。たとえば、ヨーロッパ内のある国が、すべてのユーザーデータを、物理的にヨーロッパ内に設置されたデータセンターに保存してアクセスすることを要求する可能性があります。この要件を満たすには、ヨーロッパの Google Cloud リージョンでアプリケーションを実行します。

設計上の考慮事項

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

システム設計

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

リージョンの選択

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

これらの要素や要件の中には、トレードオフを伴うものもあります。たとえば、費用対効果の最も高いリージョンが、温室効果ガス排出量が最も少ないリージョンとは限りません。詳細については、Google Cloud アーキテクチャ フレームワークの地理的ゾーンとリージョンを選択するをご覧ください。

コンピューティング サービス

このドキュメントのリファレンス アーキテクチャでは、アプリケーションのすべての階層に Compute Engine VM を使用しています。特に記載がない限り、このドキュメントの設計ガイダンスは Compute Engine に特化したものです。

アプリケーションの要件によっては、以下に示す他の Google Cloud コンピューティング サービスから選択できます。これらのサービスの設計ガイダンスは、このドキュメントでは扱いません。

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

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

ストレージ サービス

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

リージョン内のゾーン間で冗長な低コストのストレージが必要な場合は、Cloud Storage リージョン バケットを使用できます。

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

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

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

データベース サービス

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

フルマネージド データベース サービス（Cloud SQL、AlloyDB for PostgreSQL、Bigtable、Spanner、Firestore など）を使用すると、サードパーティ製データベースをインストールして管理する労力とコストを回避できます。こうした Google Cloud データベース サービスには、稼働時間のサービスレベル契約（SLA）が用意されており、スケーラビリティとオブザーバビリティのためのデフォルト機能を備えています。ワークロードに Oracle データベースが必要な場合は、Google Cloud が提供する Bare Metal Solution を使用できます。各 Google Cloud データベース サービスに適したユースケースの概要については、Google Cloud データベースをご覧ください。

セキュリティとコンプライアンス

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

外部の脅威からの保護

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

VM の外部アクセス

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

このリファレンス アーキテクチャの Compute Engine VM のように、内部 IP アドレスしか持たない Google Cloud リソースからのセキュアなアウトバウンド接続を有効にするには、Cloud NAT を使用します。

VM イメージのセキュリティ

VM が承認済みのイメージ（ポリシーまたはセキュリティ要件を満たすソフトウェアを含むイメージ）のみを使用するようにするには、特定の公開イメージ プロジェクトでのイメージの使用を制限する組織のポリシーを定義します。詳細については、信頼できるイメージのポリシーの設定をご覧ください。

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

Compute Engine API が有効になっている Google Cloud プロジェクトでは、デフォルトのサービス アカウントが自動的に作成されます。この動作を無効にしない限り、デフォルトのサービス アカウントには IAM の編集者ロール（roles/editor）が付与されます。デフォルトでは、デフォルトのサービス アカウントは、Google Cloud CLI または Google Cloud コンソールを使用して作成するすべての VM に関連付けられます。編集者ロールには幅広い権限が含まれているため、デフォルトのサービス アカウントを VM に関連付けると、セキュリティ リスクが発生します。このリスクを回避するには、アプリケーションごとに専用のサービス アカウントを作成して使用します。サービス アカウントがアクセスできるリソースを指定するには、詳細なポリシーを使用します。詳細については、「サービス アカウントの使用に関するベスト プラクティス」のサービス アカウントの権限を制限するをご覧ください。

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

アーキテクチャのリソース間のネットワーク トラフィックを制御するには、適切な Cloud Next Generation Firewall ルールを設定する必要があります。ファイアウォール ルールにより、プロトコル、IP アドレス、ポートなどのパラメータに基づいてトラフィックを制御できます。たとえば、ウェブサーバー VM からデータベース VM の特定のポートへの TCP トラフィックは許可し、他のすべてのトラフィックはブロックするファイアウォール ルールを構成できます。

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

ご自身のワークロード用のアーキテクチャを構築する際には、セキュリティ基盤ブループリントに記載されているプラットフォーム レベルのセキュリティのベスト プラクティスと推奨事項を考慮してください。

信頼性

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

インフラストラクチャの停止

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

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

このアーキテクチャのすべてのゾーンが停止した場合や、リージョンが停止した場合、アプリケーションは利用できません。Google によるサービス停止の解決を待ってから、アプリケーションが期待どおりに動作することを確認する必要があります。

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

リージョンの停止に対する耐性が必要なアプリケーションでは、マルチリージョン アーキテクチャの使用を検討してください。詳細については、Compute Engine でのマルチリージョン デプロイをご覧ください。

MIG の自動スケーリング

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

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

VM の自動修復

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

VM の配置

このドキュメントで説明するアーキテクチャでは、アプリケーション階層とウェブ階層は、複数のゾーンに分散された Compute Engine VM で実行されます。このように分散することで、ゾーンの停止に対するアプリケーションの耐性が強化されます。この堅牢性をさらに改善するには、スプレッド プレースメント ポリシーを作成して MIG テンプレートに適用します。MIG は VM を作成する際、異なる物理サーバー（ホスト）の各ゾーンに VM を配置するため、VM は個々のホストの障害に対する耐性が強化されます。詳細については、VM にスプレッド プレースメント ポリシーを適用するをご覧ください。

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

MIG の自動スケーリングに必要なときに Compute Engine VM の容量を使用できるようにするには、予約を作成します。予約により、選択したマシンタイプの指定された数の VM に対して、特定のゾーンでの容量が保証されます。予約は、プロジェクトに固有のものにすることも、複数のプロジェクトで共有することもできます。予約済みリソースがプロビジョニングまたは使用されていない場合でも、予約済みのリソースには料金が発生します。課金に関する考慮事項など、予約の詳細については、Compute Engine ゾーンリソースの予約をご覧ください。

永続ディスクの状態

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

データの耐久性

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

マネージド データベース サービス（Cloud SQL など）を使用する場合、バックアップは定義した保持ポリシーに基づいて自動的に作成されます。バックアップ戦略は、規制、ワークフロー、ビジネス要件を満たすために、追加の論理バックアップで補完できます。サードパーティ製データベースを使用していて、データベースのバックアップとトランザクション ログを保存する必要がある場合は、リージョン Cloud Storage バケットを使用できます。Cloud Storage のリージョン バケットは、ゾーン間で冗長化された低コストのバックアップ ストレージを提供します。

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

  • スナップショットは、Persistent Disk ボリュームの特定時点の状態をキャプチャするために使用できます。標準のスナップショットは複数のリージョンに冗長性をもたせて保存されます。また、自動チェックサムによりデータの完全性が確保されます。スナップショットはデフォルトで増分方式となるため、使用するストレージ容量が少なく、費用を節約できます。スナップショットは、構成可能な Cloud Storage のロケーションに保存されます。スナップショットの使用と管理に関する推奨事項については、Compute Engine ディスク スナップショットのベスト プラクティスをご覧ください。
  • リージョン Persistent Disk ボリュームを使用すると、永続ディスクの障害の影響を受けない高可用性アプリケーションを実行できます。リージョン Persistent Disk ボリュームを作成すると、Compute Engine は同じリージョン内の別のゾーンにディスクのレプリカを保持します。データは、両方のゾーンのディスクに同期して複製されます。2 つのゾーンのいずれかが停止しても、データは引き続き利用できます。

データベースの可用性

マネージド データベース サービス（HA 構成の Cloud SQL など）を使用している場合、プライマリ データベースに障害が発生すると、Cloud SQL は自動的にスタンバイ データベースにフェイルオーバーします。データベース エンドポイントの IP アドレスを変更する必要はありません。Compute Engine VM にデプロイされたセルフマネージドのサードパーティ製データベースを使用する場合は、内部ロードバランサや他のメカニズムを使用して、プライマリ データベースが使用できない場合にアプリケーションが別のデータベースに接続できるようにする必要があります。

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

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

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

費用の最適化

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

VM マシンタイプ

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

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

アプリケーションがフォールト トレラントである場合、Spot VM を使用すると、アプリケーション階層とウェブ階層で VM の Compute Engine にかかる費用を削減できます。Spot VM の費用は、通常の VM よりも大幅に低くなります。ただし、Compute Engine は処理能力を調整するため、Spot VM をプリエンプティブに停止または削除する場合があります。Spot VM は、プリエンプションを許容でき、HA 要件のないバッチジョブに適しています。Spot VM には、通常の VM と同じマシンタイプ、オプション、パフォーマンスが用意されています。ただし、ゾーンのリソース容量が制限されている場合、MIG は必要な容量が再び使用可能になるまで、指定されたターゲット サイズへ自動的にスケールアウト（VM を作成）できないことがあります。

リソースの活用

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

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

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

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

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

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

ご自身のワークロード用のアーキテクチャを構築する際には、Google Cloud Architecture Framework: 費用の最適化に記載されている一般的なベスト プラクティスと推奨事項も検討してください。

業務の効率化

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

VM 構成の更新

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

VM イメージ

MIG インスタンス テンプレートでは、Google 提供の公開イメージを使用するのではなく、アプリケーションに必要な構成とソフトウェアを含むカスタム イメージを作成して使用することをおすすめします。カスタム イメージは、カスタム イメージ ファミリーにまとめることができます。イメージ ファミリーは、そのファミリー内の最新のイメージを指すため、特定のイメージ バージョンへの参照を手動で更新しなくても、インスタンス テンプレートやスクリプトでそのイメージを使用できます。

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

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

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

ご自身のワークロード用のアーキテクチャを構築する際には、Google Cloud アーキテクチャ フレームワーク: オペレーショナル エクセレンスで説明されている運用効率に関する一般的なベスト プラクティスと推奨事項を検討してください。

パフォーマンスの最適化

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

VM の配置

VM 間のネットワーク レイテンシを低くする必要があるワークロードの場合は、コンパクト プレースメント ポリシーを作成して MIG テンプレートに適用できます。MIG は VM を作成すると、互いに近くにある物理サーバーに VM を配置します。詳しくは、コンパクト プレースメント ポリシーを使用してレイテンシを短縮するをご覧ください。

VM マシンタイプ

Compute Engine には、費用とパフォーマンスの要件に応じて選択できる、事前定義済みのカスタマイズ可能なマシンタイプが幅広く用意されています。マシンタイプは、マシンシリーズとマシン ファミリーにまとめられています。次の表に、さまざまなワークロード タイプに推奨されるマシン ファミリーとマシンシリーズの概要を示します。

要件 推奨されるマシン ファミリー マシンシリーズの例
さまざまなワークロードに対して最も優れたコスト パフォーマンス 汎用マシン ファミリー C3、C3D、E2、N2、N2D、Tau T2D、Tau T2A
コアあたりのパフォーマンスが最高で、コンピューティング負荷の高いワークロードに最適 コンピューティング最適化マシン ファミリー C2、C2D、H3
メモリ使用量の多いワークロード向けの高いメモリ対 vCPU 比率 メモリ最適化マシンタイプ ファミリー M3、M2、M1
超並列ワークロード向けの GPU アクセラレータ最適化マシン ファミリー A2、G2

詳細については、マシン ファミリーのリソースと比較ガイドをご覧ください。

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

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

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

Network Service Tiers

Network Service Tiers を使用すると、ワークロードのネットワーク コストとパフォーマンスを最適化できます。プレミアム ティアまたはスタンダード ティアを選択できます。

  • プレミアム ティアは、信頼性の高い Google のグローバル バックボーンを使用して、パケットロスとレイテンシを最小限に抑えることができます。トラフィックは、エンドユーザーに近いグローバル エッジ ポイント オブ プレゼンス（PoP）で Google ネットワークに出入りします。最適なパフォーマンスを得るには、プレミアム ティアをデフォルトの階層として使用することをおすすめします。
  • スタンダード ティアのトラフィックは、ワークロードが実行されている Google Cloud のロケーションに最も近いエッジ PoP で Google ネットワークに出入りします。スタンダード ティアの料金は、プレミアム ティアよりも低く設定されています。スタンダード ティアは、パケットロスの影響を受けにくく、低レイテンシの要件がないトラフィックに適しています。

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

ご自身のワークロード用のアーキテクチャを構築する場合は、Google Cloud アーキテクチャ フレームワーク: パフォーマンスの最適化に記載されている一般的なベスト プラクティスと推奨事項を検討してください。

次のステップ

協力者

著者: Kumar Dhanagopal | クロスプロダクト ソリューション デベロッパー

その他の関係者:

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