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

このソリューションでは、Google Cloud Platform(GCP)の複数リージョンにわたってデータを分散する際に使用できる 3 つのアーキテクチャの例を説明します。

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

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

GCP の利点

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

次のステップ

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

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...