グローバルなデータ分散に適したアーキテクチャの選択

このソリューションでは、Google Cloud リージョン間でデータを分散するために使用できる 3 つのアーキテクチャについて説明します。

多くの企業は、地理的に分散したロケーションからのデータを処理し、クライアントのリクエストにほぼリアルタイムで応答します。たとえば、デジタル広告のデマンドサイド プラットフォーム(DSP)では、地理的な位置や現在のネットワーク ロードに関係なく、データベースから 20 ミリ秒以内に応答を得ることを顧客が期待することがあります。ネットワーク アーキテクチャが中央の単一データベースに基づいている場合、物理的な距離に基づくレイテンシの影響を受けやすく、また使用率のスパイクの影響を大きく受けるため、このようなグローバル DSP ソリューションを実装することは不可能です。

このようなニーズに対応するには、データ ストレージに分散アーキテクチャを使用できます。すべてのアーキテクチャがあらゆるビジネスニーズに対応できるわけではなく、アーキテクチャによってその長所と短所は異なります。したがってこのソリューションでは、全体的なビジネス戦略の実施を支援し、ネットワーク実装アプローチを促進するためのさまざまな Google Cloud の選択肢を提示します。

Google Cloud の利点

Google Cloud は、世界中で堅牢かつ安定したネットワーク帯域幅を提供します。Google Cloud には、この他にも多くの利点があります。

非常に柔軟性の高い Google Cloud を使用すると、アプリケーションがプライベート IP アドレスを使ってリージョン間で安全に通信できるグローバル仮想ネットワークを構築できます。たとえば、us-central1asia-east1 などの 2 つのリージョン間で Compute Engine の仮想マシン(VM)インスタンスを設定できます。このような VM インスタンスでプライベート IP アドレスを使用して相互に直接通信できるようにするには、Virtual Private Cloud ネットワークを作成します。このようにして、組織はインスタンス間の安全な通信を維持できます。

Google Cloud のエニーキャスト IP により、1 つのグローバル IP アドレスがマネージド サービス(負荷分散など)に割り当てられます。エニーキャスト IP を使用すると、各リージョンでロードバランサを構成する代わりに、1 つのグローバルなロードバランサを作成できます。グローバル ロードバランサは、最も近いリージョンで実行されているアプリケーションにクライアント リクエストをルーティングし、需要の変化に対応するために自動的にスケールします。

データ分散アーキテクチャの 3 つの例

このセクションでは、3 種類のデプロイ アーキテクチャについて概説し、各アーキテクチャが適している状況を説明します。アーキテクチャとそのユースケースは次のとおりです。

  • Google Cloud とオンプレミス サービスで構成されるハイブリッド デプロイ。いくつかのオンプレミス サービスを維持し、かつ Google Cloud の機能も利用する場合を考えます。Google Cloud は現在のネットワークにリンクされ、現行の社内プロセスに組み込まれます。オンプレミス データの一部またはすべてが Google Cloud にコピーされるか、Google Cloud に組み込まれます。

  • Google Cloud とその他のクラウド サービス プロバイダ プラットフォームで構成されるハイブリッド デプロイ。現行のクラウド サービス プロバイダ オペレーションを維持しながら、いくつかの Google Cloud 機能を導入し、2 つのシステムが相互に通信するように構成できます。

  • 複数のリージョンを使用する Google Cloud。グローバル規模で、近同期データ転送をサポートする必要が生じることがあります。複数リージョンで Google Cloud を構成することで、世界規模で非常に高速かつほぼ同時のデータ転送が実現します。

ハイブリッド デプロイ: Google Cloud とオンプレミス サービス

オンプレミス サービスと Google Cloud の組み合わせが適しているユースケースは、データをオンプレミスで保存して Google Cloud にも伝播するアプリケーションを扱う場合です。

たとえば小売業界では、新製品についてのマスターデータがレガシー在庫管理システム用のオンプレミス データベースに挿入することがあります。またこの企業は、オンライン ウェブストアに使用する Google Cloud データベースにもそのデータを伝播する必要があります。ハイブリッド方式では、既存のオンプレミス システムに影響を与えずに Google Cloud を使用する新しいシステムを構築できます。このアーキテクチャでは、Google Cloud は本質的にオンプレミス ネットワーク構造と並列的に機能します。

Google Cloud とオンプレミスのハイブリッド デプロイを実装するかどうかを決定する際は、次の点を考慮する必要があります。

  • オンプレミスと Google Cloud の両方にデータを置く場合、どちらのデータをマスターデータとして扱うか、マスターデータをどこに格納するかを決定する必要があります。たとえば、Google Cloud データをマスターデータとして定義するとします。この場合 Google Cloud は、1 つまたは複数のオンプレミス環境を接続して環境間でのデータ交換を行う、データハブとして動作します。Google Cloud 環境で追加または更新されたデータは、オンプレミス システムに転送されます。あるいは、オンプレミス システムにマスターデータを保持し、定期的に Google Cloud を更新することもできます。
  • このハイブリッド環境用のアプリケーションを開発する場合、マネージド サービスは Google Cloud のリソースに対してのみ使用可能であることにご注意ください。オンプレミスと Google Cloud 環境の両方で動作するアプリケーションは、自動バックアップ、冗長性、スケーラビリティなどのマネージド サービスに依存できない可能性があります。
  • データの移動性を維持し、一貫性のある管理運用を実現するには、オンプレミスと Google Cloud デプロイの両方で、クロスプラットフォーム データストア(MySQL など)を仮想マシンでホストするのが容易な方法だと考えられます。

ハイブリッド アーキテクチャの例

次の図に、Google Cloud およびオンプレミス システムを使用したハイブリッド アーキテクチャの例を示します。

ハイブリッド システムのアーキテクチャ

このアーキテクチャの例の内容は次のとおりです。

  • オンプレミス ファイル サーバーと Cloud Storage の間でデータが交換されます。たとえば、ローカル ファイルを Google Cloud にバックアップできます。また、入力としてファイルをバッチ処理することも、Google Cloud からオンプレミス ネットワークにファイルをダウンロードすることも可能です。
  • ローカル データセンターのカスタム アプリケーションは、REST API を使用して App Engine 上のアプリケーションにアクセスし、データの取得や送信を行います。通常、REST リクエストは同期的で、結果が返されるまでクライアントをブロックします。このアーキテクチャで、App Engine は必要に応じて容量を拡大する自動スケーリングを提供します。これにより、同期呼び出しのレイテンシを低く抑えられます。
  • カスタム アプリケーションは、Pub/Sub にメッセージを直接送信します。メッセージは、後で処理できるように複製されたキューに保存されます。メッセージが Pub/Sub に到達すると、Pub/Sub はすぐにステータスを返し、クライアントはブロックされません。メッセージは、Cloud FunctionsDataflowCompute Engine で実行されるアプリケーションなどの方法を使用して、取得と処理が非同期で行われます。オンプレミス環境のクライアント アプリケーションもメッセージを取得できます。
  • オンプレミス データベースに格納されたデータは(多くの場合は CSV ファイル)エクスポートされ、Google Cloud にアップロードされて、Cloud SQL により管理されるデータベースに一括して読み込まれます。
  • Firebase データベースは、オンプレミス システムと Google Cloud の間のデータの同期に使用されます。アプリケーションはデータベースのキーに登録し、値が更新されるたびにリアルタイムで通知され、更新された値を受け取ります。Firebase と情報をやり取りするアプリケーションは、オンプレミスと Google Cloud のいずれか、または両方に配置できます。

ハイブリッド デプロイ: Google Cloud と他のクラウド プロバイダ

データを効率的に分散したり、複数のフェールセーフ メカニズムを利用したり、特定の Google Cloud 機能を利用したりするために、Google Cloud と他のクラウド プロバイダを組み合わせることができます。このアーキテクチャが適しているのは、他のクラウド プロバイダで稼働している本番環境サービスがあるが、Google Cloud の機能も利用したい場合です。たとえば、アプリケーション データ、ログ、モニタリング指標の分析に BigQuery を使用できます。

このアーキテクチャは、前述のオンプレミスと Google Cloud のハイブリッド アーキテクチャに似ています。Google Cloud と他のクラウド プロバイダのハイブリッド デプロイを実装する際は、次の点を考慮する必要があります。

  • jcloudslibcloud などのオープンソースのマルチクラウド クライアント ライブラリを使用すると、Google Cloud と他のクラウド サービス間で API を統合できます。
  • Google Cloud には、Storage Transfer ServiceCloud MonitoringCloud Logging など、Amazon Web Services(AWS)からデータを転送する機能があります。ログを BigQuery にエクスポートすると、詳しく分析できます。
  • Pub/Sub はグローバル サービスであり、アプリケーションは Pub/Sub キューがどのリージョンに存在するかを認識する必要がありません。メッセージを発行したり、グローバルに利用可能なトピックを購読したりできます。Google Cloudでは、クライアント アプリは IP アドレスとポートの組み合わせを 1 つだけ認識する必要があります。他のクラウド プロバイダでは、キューがリージョン固有である可能性があります。その場合、複数のリージョンにわたってアプリをデプロイするときに、クライアント アプリはすべてのリージョンのエンドポイントを認識する必要があります。エンドポイントの追跡は、特に新しいリージョンのサービスを追加する場合などには複雑になることがあります。

別のクラウド プロバイダと組み合わせた Google Cloud のアーキテクチャ例

次の図に、GCP と他のクラウド プロバイダで構成されるハイブリッド アーキテクチャを示します。

Google Cloud と別のクラウド プロバイダを使用したシステムのアーキテクチャ

このアーキテクチャの例の内容は次のとおりです。

  • Pub/Sub と他のパブリック クラウドとの間でメッセージが交換されます。Pub/Sub はグローバル エンドポイントを提供し、クラウド間のメッセージハブとして機能できます。これは、メッセージ キューが実際にどのリージョンに存在するかをアプリケーションが認識する必要がないためです。
  • 他のパブリック クラウドの仮想マシンには Cloud Monitoring エージェント インスタンスがインストールされ、CPU 使用率、メモリ使用量、プロセス情報などの指標が収集されます。Cloud Monitoring は、ハイブリッド クラウド環境全体のリソース使用状況をモニタリングします。
  • 他のクラウド環境の仮想マシンで実行されるカスタム アプリケーションは、REST API を使用して、App Engine 上でホストされているアプリケーションを呼び出し、データの送信や取得を行います。
  • Storage Transfer Service は、オンデマンドで、または定期的に Amazon S3 からファイルを直接転送します。転送されたファイルは、Compute Engine で処理して Cloud SQL に読み込めます。

ハイブリッド デプロイ: 複数リージョンでの Google Cloud

複数リージョンでの Google Cloud をベースにしたアーキテクチャは、アプリケーションがグローバル規模でユーザーにサービスを提供し、リージョン間でレイテンシを最小限に抑えてデータを同期する必要がある場合に適しています。この例としては、プレーヤーの間でほぼリアルタイムに同期され、世界規模で機能する必要があるインターネット対応ビデオゲームなどです。

このアーキテクチャでは、管理タスクを削減してシステム設計を容易にするために、Google Cloud マネージド サービスを利用します。Google Cloud により、インフラストラクチャ設計に時間を割くことなく、アプリケーションに集中できます。複数リージョンと Google Cloud のハイブリッド デプロイを実装する際は、次の点を考慮する必要があります。

  • メッセージ パブリッシャーとサブスクライバーはどのリージョンでも実行できるため、マルチリージョン データ処理サービスを簡単にデプロイできます。Pub/Sub では、アプリケーションの実行場所を指定することなく、異なるリージョンで動作するアプリケーション間でメッセージを交換できます。このアーキテクチャでは、Pub/Sub メッセージは完全に Google CloudP 内にとどまり、インターネット経由で送信されないため、レイテンシが小さくなります。
  • Compute Engine インスタンス上のアプリケーションは、Google Cloud VPC ネットワーク内のプライベート IP アドレスを使用して、リージョン間で直接通信できます。
  • REST API を使用すると、カスタム アプリケーションを疎結合させることができます。このアーキテクチャは Google Cloud 環境内に完全に組み込まれているため、アプリケーション管理に App Engine を使用することで管理タスクを最小限に抑えられます。
  • リージョン間でデータを分散した後は、DataflowDataproc を使用して、ETL や分析ワークロードを処理できます。

マルチリージョン Google Cloud アーキテクチャの例

次の図に、複数リージョンで構成される Google Cloud デプロイのアーキテクチャを示します。

複数の Google Cloud リージョンを使用したシステムのアーキテクチャ

このアーキテクチャの例の内容は次のとおりです。

  • ハイブリッド クラウド アーキテクチャの場合と同様に、Cloud Monitoring がすべてのコンピューティング リソースをモニタリングし、リソース使用状況の統合グローバル ビューを表示します。収集されたログと指標は、詳しい分析のために BigQuery にエクスポートされます。
  • ハイブリッド クラウド アーキテクチャの場合と同様に、Pub/Sub がメッセージハブとして使用されます。Pub/Sub では、サービスを疎結合でき、サービスが実際のアプリケーション実行場所に依存しないようにできます。
  • App Engine または Compute Engine で実行されるカスタム アプリケーションは、REST API を使用して他のカスタム アプリケーションとメッセージを直接交換します。これは、ハイブリッド アーキテクチャと比較して結合が密接なアーキテクチャであるため、レイテンシの予測可能性が向上します。
  • Cloud Storage バケットの同期には Storage Transfer Service が使用されます。また、gsutil ツールを使用すると、異なるリージョンにあるバケット間でオンデマンド転送もできます。

次のステップ

Google Cloud でのデータ管理については、次のリンクをご覧ください。