Compute Engine と Spanner を使用したグローバル デプロイ

Last reviewed 2024-05-12 UTC

このドキュメントでは、Google Cloud のグローバル トポロジで Compute Engine VM と Spanner を使用する多層アプリケーションのリファレンス アーキテクチャについて説明します。また、他の Google Cloud インフラストラクチャ サービスを使用するアーキテクチャの構築に役立つガイダンスも提供します。ここでは、クラウド アプリケーション用のグローバル アーキテクチャを構築する際に考慮すべき設計要素について説明します。このドキュメントは、クラウド アーキテクトを対象としています。

このアーキテクチャは、グローバル デプロイ アーキタイプに対応しています。世界中のユーザーにサービスを提供し、複数のリージョンの停止に対する高可用性と堅牢性を必要とするアプリケーションには、このアーキタイプをおすすめします。このアーキテクチャは、ネットワーク、アプリケーション、データベースの各レベルで柔軟なスケーリングをサポートしています。これにより、パフォーマンス、可用性、スケーラビリティを損なうことなく、使用量に応じて費用を調整できます。

アーキテクチャ

次の図は、複数の Google Cloud リージョンにグローバルに分散されたインフラストラクチャで実行されるアプリケーションのアーキテクチャを示しています。

Compute Engine と Spanner を使用したグローバル デプロイ アーキテクチャ。

このアーキテクチャでは、グローバル ロードバランサが、可用性、容量、トラフィックの送信元との近接性に基づいて適切なリージョンのウェブサーバーに受信リクエストを分散します。クロスリージョン内部ロード バランシング レイヤは、可用性と容量に基づいて、ウェブサーバーから適切なアプリケーション サーバーへのトラフィック分散を処理します。アプリケーション サーバーは、すべてのリージョンで利用できる同期的に複製されたデータベースに対して、データの書き込みと読み取りを行います。

このアーキテクチャでは、次の Google Cloud リソースを使用しています。

コンポーネント 目的
グローバル外部ロードバランサ

グローバル外部ロードバランサは、ユーザーのリクエストを受信してアプリケーションに分散します。グローバル外部ロードバランサは単一のエニーキャスト IP アドレスをアドバタイズしますが、このロードバランサは、Google Front End（GFE）に多数のプロキシが存在することを前提として実装されています。クライアント リクエストはクライアントに最も近い GFE に転送されます。

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

分散型サービス拒否（DDoS）攻撃やクロスサイト スクリプティング（XSS）などの脅威からアプリケーションを保護するために、Google Cloud Armor セキュリティ ポリシーを使用できます。
ウェブ階層のリージョン マネージド インスタンス グループ（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 には、アプリケーション階層の独立したインスタンスがホストされます。
Spanner マルチリージョン インスタンス

アプリケーションは、マルチリージョンの Spanner インスタンスに対してデータの書き込みと読み取りを行います。このアーキテクチャのマルチリージョン構成には、次のレプリカが含まれています。

  • 4 つの読み取り / 書き込みレプリカ。2 つのリージョンの各ゾーンに 1 つずつ存在します。
  • ウィットネス レプリカ。3 つ目のリージョンに存在します。
Virtual Private Cloud（VPC）ネットワークとサブネット

アーキテクチャ内のすべてのリソースは単一の VPC ネットワークを使用します。VPC ネットワークには次のサブネットがあります。

  • ウェブサーバー VM 用のサブネット。各リージョンに 1 つずつ存在します。
  • アプリケーション サーバー VM 用のサブネット。各リージョンに 1 つずつ存在します。
  • クロスリージョン内部ロードバランサ用のプロキシ専用サブネット。各リージョンに 1 つずつ存在します（このアーキテクチャ図には示されていません）。

単一の VPC ネットワークを使用する代わりに、各リージョンに個別の VPC ネットワークを作成し、Network Connectivity Center を使用してネットワークを接続することもできます。

使用するプロダクト

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

  • Compute Engine: Google のインフラストラクチャで VM を作成して実行できる、安全でカスタマイズ可能なコンピューティング サービス。
  • Cloud Load Balancing: 高パフォーマンスでスケーラブルなグローバル ロードバランサとリージョン ロードバランサのポートフォリオ。
  • Spanner: スケーラビリティに優れ、グローバルな整合性を備えたリレーショナル データベース サービス。

設計上の考慮事項

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

システム設計

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

リージョンの選択

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

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

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

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

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

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

ストレージ サービス

このドキュメントに示すアーキテクチャでは、VM にリージョン Persistent Disk ボリュームを使用しています。リージョン Persistent Disk ボリュームを使用すると、リージョン内の 2 つのゾーン間でデータの同期レプリケーションを行うことができます。Persistent Disk ボリュームのデータは、リージョン間で複製されません。

マルチリージョン デプロイ用の他のストレージ オプションには、Cloud Storage デュアルリージョン バケット、マルチリージョン バケットがあります。デュアルリージョン バケットまたはマルチリージョン バケットに保存されるオブジェクトは、少なくとも 2 つの地理的な場所に冗長的に保存されます。メタデータはリージョン間で同期的に書き込まれ、データは非同期で複製されます。デュアルリージョン バケットの場合は、ターボ レプリケーションを使用して、リージョン間で高速なレプリケーションを実現できます。詳細については、データの可用性と耐久性をご覧ください。

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

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

データベース サービス

このドキュメントのリファレンス アーキテクチャでは Spanner を使用します。Spanner は、グローバルに分散され、同期的に複製される、水平スケーリングが可能なフルマネージド データベースです。リージョン間の強力な整合性を必要とするミッション クリティカルなデプロイには、マルチリージョン Spanner 構成をおすすめします。Spanner は、フェイルオーバー、メンテナンス、サイズ変更で、ダウンタイムのないクロスリージョン同期レプリケーションをサポートします。

実際の要件に応じて選択可能な他のマネージド データベース サービスについては、Google Cloud データベースをご覧ください。マルチリージョン デプロイ用にデータベースを選択して構成する場合は、リージョン間のデータ整合性に関するアプリケーションの要件を考慮し、パフォーマンスとコストのトレードオフに注意してください。

外部ロード バランシング オプション

グローバル外部ロードバランサを使用するアーキテクチャは、デプロイの信頼性を高めるために役立つ特定の機能をサポートしています。このドキュメントのアーキテクチャも同様です。たとえば、グローバル外部アプリケーション ロードバランサを使用する場合は、Cloud CDN を使用してエッジ キャッシングを実装できます。

アプリケーションで Transport Layer Security（TLS）を特定のリージョンで終端する必要がある場合や、特定のリージョンからコンテンツを配信する必要がある場合は、Cloud DNS とリージョン ロードバランサを使用して、トラフィックを別のリージョンに転送できます。リージョン ロードバランサとグローバル ロードバランサの違いについては、次のドキュメントをご覧ください。

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

このセクションでは、このリファレンス アーキテクチャを使用して、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 リソースからのアウトバウンド接続を保護するには、Secure Web Proxy または Cloud NAT を使用します。

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

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

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

Compute Engine API が有効になっている Google Cloud プロジェクトでは、デフォルトのサービス アカウントが自動的に作成されます。2024 年 5 月 3 日より前に作成された Google Cloud 組織の場合、このデフォルトのサービス アカウントには編集者（roles/editor）の IAM ロールが付与されます（この動作が無効になっている場合を除きます）。

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

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

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

信頼性

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

MIG の自動スケーリング

複数のリージョン MIG でアプリケーションを実行すると、分離されたゾーンやリージョンが停止しても、アプリケーションを引き続き使用できます。ステートレス MIG の自動スケーリング機能を使用すると、アプリケーションの可用性とパフォーマンスを予測可能なレベルで維持できます。ステートレス MIG の自動スケーリングの動作を制御するには、目標使用率の指標（CPU の平均使用率など）を指定します。ステートレス MIG にスケジュール ベースの自動スケーリングを構成することもできます。ステートフル MIG は自動スケーリングできません。詳細については、インスタンスのグループの自動スケーリングをご覧ください。

VM の自動修復

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

VM の配置

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

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

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

Persistent Disk の状態

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

データの耐久性

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

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

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

Spanner のバックアップと復元機能を使用すると、オペレーターのエラーやアプリケーションの問題によるデータの破損を防ぐことができます。詳細については、Spanner のバックアップと復元の概要をご覧ください。

データベースの信頼性

マルチリージョン Spanner インスタンスに保存されたデータは、複数のリージョンに同期して複製されます。前述のアーキテクチャ図に示す Spanner 構成には、次のレプリカが含まれています。

  • 4 つの読み取り / 書き込みレプリカ。2 つのリージョンの各ゾーンに 1 つずつ存在します。
  • ウィットネス レプリカ。3 つ目のリージョンに存在します。

マルチリージョン Spanner インスタンスへの書き込みオペレーションは、少なくとも 3 つのレプリカ（2 つのリージョンにまたがる個々のゾーンにあるレプリカ）でオペレーションが commit された後に承認されます。ゾーンまたはリージョンで障害が発生した場合、Spanner は最新の書き込みオペレーションのデータを含むすべてのデータにアクセスし、読み取りリクエストと書き込みリクエストの処理を継続します。

Spanner は、コンピューティング リソースとストレージ リソースが分離された分散ストレージを使用します。HA またはスケーリングのためにコンピューティング容量を追加するときに、データを移動する必要はありません。新しいコンピューティング リソースは、必要なときに最も近い Colossus ノードからデータを取得します。これにより、フェイルオーバーとスケーリングが高速化され、リスクが軽減されます。

Spanner は、トランザクション処理システムの直列化可能性よりも厳密なプロパティである外部整合性を提供します。詳しくは次の記事をご覧ください。

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

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

費用の最適化

このセクションでは、このリファレンス アーキテクチャを使用して構築した 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 は自動スケーリングできません。

データベースの費用

Spanner を使用すると、データベースの費用を予測できます。指定したコンピューティング容量（ノード数または処理単位数）によってストレージ容量が決まります。読み取りと書き込みのスループットは、コンピューティング容量に比例してスケーリングされます。使用した分のみ料金が発生します。ワークロードのニーズに合わせて費用を調整する必要がある場合は、Spanner インスタンスのサイズを調整できます。

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

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

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

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

ご自身のワークロード用のアーキテクチャを構築する際には、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 など）を正確に指定してください。詳細については、確定的なインスタンス テンプレートをご覧ください。

Spanner への移行

MySQL、SQL Server、Oracle Database などの他のデータベースから Spanner にデータを移行できます。移行プロセスは、移行元のデータベース、データのサイズ、ダウンタイムの制約、アプリケーション コードの複雑さなどの要因によって異なります。Spanner への移行を効率的に計画し、実装できるように、Google Cloud の機能やさまざまなサードパーティ ツールが用意されています。詳細については、移行の概要をご覧ください。

データベース管理

Spanner では、レプリケーションやフェイルオーバーを構成したり、モニタリングする必要はありません。同期レプリケーションと自動フェイルオーバーが組み込まれています。データベースのメンテナンスとフェイルオーバーのダウンタイムは発生しません。運用の複雑さをさらに軽減するために、自動スケーリングを構成できます。自動スケーリングを有効にすると、インスタンス サイズを手動でモニタリングしてスケーリングする必要がなくなります。

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

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

パフォーマンスの最適化

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

VM の配置

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

VM マシンタイプ

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

要件 推奨されるマシン ファミリー
さまざまなワークロードに対して最も優れたコスト パフォーマンス 汎用マシン ファミリー
コアあたりのパフォーマンスが最高で、コンピューティング負荷の高いワークロードに最適化 コンピューティング最適化マシン ファミリー
メモリ対 vCPU 比率が高く、メモリ使用量の多いワークロード向け メモリ最適化マシンタイプ ファミリー
超並列ワークロード向けの GPU アクセラレータ最適化マシン ファミリー
コア使用率が低く、ストレージ密度が高い ストレージ最適化マシンタイプ ファミリー

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

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

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

Network Service Tiers

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

このドキュメントのアーキテクチャでは、外部 IP アドレスを持ち、複数のリージョンにバックエンドがあるグローバル外部ロードバランサを使用します。このアーキテクチャでは、プレミアム ティアを使用する必要があります。信頼性の高い Google のグローバル バックボーンを使用するプレミアム ティアにより、パケットロスとレイテンシを最小限に抑えることができます。

リージョン外部ロードバランサを使用し、Cloud DNS を使用してトラフィックをリージョンに転送する場合は、実際の要件に応じてプレミアム ティアまたはスタンダード ティアを選択できます。スタンダード ティアの料金は、プレミアム ティアよりも低く設定されています。スタンダード ティアは、パケットロスの影響を受けにくく、低レイテンシ要件のないトラフィックに適しています。

Spanner のパフォーマンス

Spanner インスタンスをプロビジョニングするときに、インスタンスのコンピューティング容量をノードまたは処理ユニットの数で指定します。Spanner インスタンスのリソース使用率をモニタリングし、予想される負荷とアプリケーションのパフォーマンス要件に基づいて容量をスケーリングします。Spanner インスタンスの容量は手動または自動でスケーリングできます。詳細については、自動スケーリングの概要をご覧ください。

マルチリージョン構成では、Spanner は複数のリージョンにデータを同期的に複製します。このレプリケーションにより、複数のロケーションからの低レイテンシの読み取りオペレーションが可能になります。クォーラム レプリカが複数のリージョンに分散しているため、書き込みオペレーションのレイテンシは高くなります。マルチリージョン構成での読み取り / 書き込みトランザクションのレイテンシを最小限に抑えるため、Spanner はリーダー認識ルーティングを使用します（これはデフォルトで有効になっています）。

Spanner インスタンスとデータベースのパフォーマンスを最適化するための推奨事項については、次のドキュメントをご覧ください。

キャッシュ

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

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

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

次のステップ

協力者

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

その他の関係者:

  • Ben Good | ソリューション アーキテクト
  • Daniel Lees | クラウド セキュリティ アーキテクト
  • Gleb Otochkin | Cloud アドボケイト、データベース
  • Justin Makeig | プロダクト マネージャー
  • Mark Schlagenhauf | テクニカル ライター、ネットワーキング
  • Sekou Page | アウトバウンド プロダクト マネージャー
  • Steve McGhee | 信頼性アドボケイト
  • Victor Moreno | プロダクト マネージャー、クラウド ネットワーキング