ハイブリッド クラウドとマルチクラウド  

IDG の 2020 年の調査によると、すでに 83% の企業がオンプレミスとクラウドを併用するハイブリッド クラウドを、54% の企業（エンタープライズに限れば 66%）が複数のクラウドを利用しているという結果がでています。ハイブリッド クラウドについては、ワークロードの要件に応じてオンプレミスとクラウドを使い分けることが多かった中、近年、災害復旧対応や可用性向上を理由にした移行も見られます。マルチクラウドについては、採用理由として 「各プロバイダが提供するサービスの中から最適なサービスを選択できる」が 49% と、最も高くなっています。今後日本においてもこの方針はより重要になり、普及していくものと考えられます。


Google Cloud は「お客様が選択できること」を重視したサービス展開をしてきましたが、ハイブリッド / マルチクラウドの文脈においても、つまりオンプレミスや他社クラウドでも Google のソリューションがご選択いただけるよう、様々なソリューションを展開しています。


この節ではハイブリッド クラウドやマルチクラウドを、より効果的に実現するための手法をご案内します。特性が異なるアプリケーションとデータベースに対し、それぞれパターンごとに考慮点やベスト プラクティスをみていきましょう。

Cloud Run + Cloud Firestore

解決する課題・使い所

企業におけるパブリック クラウドの活用は一般的になっていますが、機密データを扱うためパブリック クラウドに移行できないワークロード や、既存システムとの低遅延通信や既存 IT 資産の有効活用の観点からオンプレミス上での稼働が望ましいワークロードも存在します。多くの企業では、パブリック クラウド上のワークロードと上記のようなオンプレミス上のワークロードを適材適所で組み合わせて活用する必要があります。


本ドキュメントでは、以下の図のようにパブリック クラウドとオンプレミスを組み合わせたアーキテクチャをハイブリッド クラウド アーキテクチャと定義します。

ハイブリッド クラウドは以下のようなケースで活用することができます。


ハイブリッド クラウド アーキテクチャのパターン 

ハイブリッド クラウド アーキテクチャのパターンは、大きく以下 2 種類に分類することができます。

分散デプロイパターン

各ワークロードの特性に応じて、パブリック クラウドとオンプレミスそれぞれデプロイ先を分けるパターンです。以下のようなケースで活用することができます。

冗長デプロイパターン

同じワークロードをパブリック クラウドとオンプレミス両方にデプロイし、可用性を高めるパターンです。以下のようなケースで活用することができます。

ハイブリッド クラウド アーキテクチャ

ハイブリッド クラウドアーキテクチャを構成する上で重要となる技術観点として、以下項目が考えられます。本項では各技術観点の検討ポイントについて確認をしていきます。


アプリケーション実行環境

ハイブリッド クラウド環境では、ワークロードのポータビリティや運用の統一性が特に重要となります。アプリケーションの実行環境としてコンテナを選択することでワークロードのポータビリティを確保し、コンテナのオーケストレータとして Kubernetes を利用することによりアプリケーションのデプロイやインフラの構成管理を自動的かつ統一的な方法で行うことを可能にします。またその際、Google Kubernetes Engine（GKE）や GKE On-Prem などのマネージド Kubernetes プラットフォームを利用することで運用負荷を下げることができます。

分散デプロイパターンの場合、各ワークロードの持つ特性に応じてデプロイ先のアプリケーション実行環境を分けます。一例として、機密情報を扱うワークロードや既存システムと低遅延接続が必要なワークロードといったオンプレミス上での稼働が望ましいものをオンプレミス上の GKE On-Prem にデプロイし、そのような制約の無いワークロード を Google Cloud 上の GKE にデプロイするといった考え方があります。

冗長デプロイパターンの場合、同一アプリケーションをオンプレミスとパブリック クラウド両方にデプロイを行います。一部、GKE の BackendConfig のような環境固有の機能も存在するため、ハイブリッド環境間での Kubernetes マニフェストの互換性有無について事前に確認されることをおすすめします。 

また、ミッション クリティカルなシステム等、高い可用性が求められるワークロードをデプロイする場合は GKE / GKE On-Prem 単体の可用性も高める必要があります。GKE / GKE On-Prem における高可用性クラスタ設計のベスト プラクティスについては、以下ドキュメントで解説をしていますのでそちらをご確認ください


データベース

分散デプロイパターンの場合、各ワークロードの特性に応じて利用するデータベースを使い分けます。一例として、パブリック クラウド上に置けないデータを扱うワークロードの場合は、オンプレミス上の独立したデータベースサーバを利用し、GKE 上のワークロードなどデータのロケーションに大きな制約の無いワークロード は Cloud Spanner や Cloud SQL といった Google Cloud のデータベースサービスを活用することで、運用負荷を軽減しつつスケーラブルなワークロードを構築するといったことが考えられます。Google Cloud の各データベースサービスの特徴については Google Cloud データベース をご参照ください。

冗長デプロイパターンの場合、オンプレミスとパブリック クラウド間で同一のデータを保持するように構成するケースがあります。オンプレミスとパブリック クラウド間でデータベースを同期する際のアーキテクチャについては「Cloud SQL とオンプレミス環境のデータベース同期」で解説していますのでそちらをご参照ください。


インバウンド トラフィックの負荷分散

インバウンド トラフィックの負荷分散は、 GKE / GKE On-Prem 各クラスタで Ingress もしくは Loadbalancer タイプの Service を利用して構成します。GKE では Ingress や Loadbalancer タイプの Service として Cloud Load Balancing を利用します。GKE On-Premでは Ingress として Envoy Proxy を利用し、Loadbalancer タイプの Service として Bundled LB もしくは F5 BIG-IP 等サードパーティ製ロードバランサを利用することができます。

Cloud Load Balancing は Google が提供するマネージドサービスであり、利用者側でロードバランサ単体の可用性やスケーラビリティに関して検討をする必要はありませんが、Bundled LB のようなオンプレミス上で稼働するロードバランサについては HA 機能を有効化したり、事前に想定されるトラフィック量に応じたサイジングを行うなど、利用者側で可用性やスケーラビリティに関する設計が必要となります。

また、冗長デプロイパターンにおいて、インバウンド トラフィックをハイブリッド クラウド間で負荷分散する場合、以下のような選択肢があります。


ハイブリッド クラウド間接続

ハイブリッド クラウド上のアプリケーション間でデータ連携をする場合や、オンプレミスから Google Cloud のサービスに対して API アクセスをする場合、ハイブリッド クラウド間の接続方式について検討します。接続方式として複数のオプションがあるため、ネットワーク接続プロダクトの選択を参考にし、通信帯域や暗号化等の要件に応じて選択します。 インターネット経由での接続

また、オンプレミス環境から Google Cloud API に対して、グローバル IP アドレスではなくプライベート IP アドレスを利用した接続をする場合は 限定公開の Google アクセス も合わせて有効化します。


構成管理

複数環境を跨った管理でも運用負荷が上がらないように統合的に構成管理ができるツール/サービスを利用します。Anthos で提供している下記機能を活用し GKE / GKE On-Prem クラスタの構成情報や Kubernetes リソース設定等を統合的に管理することで、運用コストの低減を実現します。


コンテナレジストリ

GKE / GKE On-Prem ではコンテナレジストリとして Google Container Registry (GCR) を利用することができます。コンテナイメージをパブリック クラウド上で保管できないケース等では、GKE On-Prem でプライベートレジストリを利用するよう構成します。


CI / CD パイプライン

Cloud Source Repositories (CSR) や Cloud Build、Container Registry (Artifact Registry) といった Google Cloud のサービスやサードパーティ製品を利用することにより、自動化された CI / CD パイプラインをハイブリッド クラウド環境で実装することができます。CI / CD のアーキテクチャパターンについては「Google Cloud での CI / CD」で解説していますのでそちらをご参照ください。


モニタリング / ロギング

ハイブリッド環境に配置した GKE クラスタのシステムメトリクス / ログや GKE 上で稼働しているアプリケーション メトリクス / ログを Google Cloud の Cloud Monitoring / Cloud Logging に集約し一元管理することで複数環境下での管理オーバーヘッドを低減させることができます。

データローカリティの観点からアプリケーションのメトリクス / ログをパブリック クラウド上で保管することができない場合は、オンプレミス上に Prometheus + Grafana やその他サードパーティ製品を導入しオンプレミス上でメトリクス / ログを保管します。


利点


注意事項


このパターンで作成された事例


参照文献

マルチクラウド パターン（GCP + AWS）

解決する課題・使い所

551 名の IT 決裁権者に対して実施された IDG 社の Cloud Computing Survey によると、2020 年時点でクラウドを利用している組織は 81% に及び、うち 55% が複数のパブリック クラウドを使用しています。規模別では、中堅・中小規模（SMB）の企業の 47％、より複雑な環境への管理能力や、より多くの予算が求められるエンタープライズ企業の 66% が複数のパブリック クラウドを利用していると回答しています。 その理由としては、以下の 5 つが挙げられます。

これらの理由が重要なのは、クラウドは単なるハードウェアの時間貸しではなく、その上に利用者の課題を解決すべくソフトウェアが実装されていることが背景にあるためです。ソフトウェアである以上、「各社クラウドの設計思想や実装が異なる」「各社の強みのある機能エリアが異なる」ことから、 “選択” したり “ロックインを回避” したりする必要があり、その解消のためにマルチクラウドが採用されています。

本ドキュメントでは、以下のように 2 つ以上のプロバイダのパブリック クラウドを組み合わせた構成をマルチクラウド アーキテクチャと定義します。

マルチクラウドは、以下のようなケースで活用することができます。


マルチクラウド アーキテクチャのパターン

マルチクラウド アーキテクチャのパターンは、（1）分散デプロイパターン、および（2）冗長デプロイパターンの 2 種類に分類することができます。

（1）分散デプロイパターン

各ワークロードの特性に応じて、複数のパブリック クラウドを組み合わせ、より適したコンピューティング環境にアプリケーションをデプロイする柔軟性が得られます。このパターンは、以下のようなケースで活用することができます。

もう 1 つ、トランザクション システムとデータ分析システムを、分散デプロイするパターンがあります。Google Cloud では、データ取得から、処理、分析、最終的な可視化まで、データのライフサイクル全体を通じてデータを管理する豊富なサービスを提供しています。このパターンを利用することで、サーバーレス型のマネージド サービスを活用し、大規模なスケールが必要なデータ分析を、より最適化されたコストで実施することが可能です。

（2）冗長デプロイパターン

同じワークロードを複数のコンピューティング環境にわたりデプロイすることで、処理能力や復元力が高まることが期待できます。具体的には、以下のようなケースです。

マルチクラウド アーキテクチャ

マルチクラウド アーキテクチャを構成する上で重要となる技術的な観点として、以下 6 項目が考えられます。本項では、それぞれの検討ポイントについて確認します。


1）アプリケーション実行環境

マルチクラウド環境では、ワークロードのポータビリティや運用の統一性が重要です。アプリケーションの実行環境としてコンテナを選択することで、ワークロードのポータビリティを確保し、コンテナのオーケストレータとして Kubernetes を利用することで、自動的、かつ統一的な方法で、アプリケーションのデプロイやインフラの構成管理が可能です。またその際、Google Kubernetes Engine（GKE）や Anthos clusters on AWS といったマネージド Kubernetes プラットフォーム、またはすでに構築された Kubernetes クラスタを統合して管理することのできる Anthos Attached Clusters を利用することで運用負荷を低減することができます。

分散デプロイ パターンの場合、各ワークロードの持つ特性に応じてデプロイ先のアプリケーション実行環境を分散します。一例として、すでに AWS 上で稼働するサービスがあり、そのシステムと低遅延接続が必要なワークロードについては Anthos clusters on AWS 上にデプロイし、制約の無いワークロード は Google Cloud 上の GKE にデプロイするといった方法があります。

冗長デプロイ パターンの場合、同一アプリケーションを複数のパブリック クラウド上にデプロイします。一部、GKE の BackendConfig のような環境固有の機能も存在するため、ハイブリッド環境間での Kubernetes マニフェストの互換性の有無については、事前に確認することが必要です。


2）データベース

分散デプロイ パターンの場合、各ワークロードの特性に応じて利用するデータベースを使い分けます。一例として、セキュリティやレイテンシの問題から、各クラウド上の Kubernetes クラスタは、同じクラウド上のマネージド サービスを利用しつつ、GKE 上のワークロードやデータのロケーションに大きな制約の無いワークロード は Cloud Spanner や Cloud SQL といった Google Cloud のデータベース サービスを活用することで、運用負荷を軽減しつつスケーラブルなワークロードを構築することができます。Google Cloud の各データベース サービスの特徴については Google Cloud データベース をご参照ください。


3）クラウド間接続

ハイブリッド クラウド上のアプリケーション間でデータ連携をする場合や、他社クラウド上から Google Cloud のサービスに対して API アクセスをする場合、ハイブリッド クラウド間の接続方式について検討します。接続方式として複数のオプションがあるため、ネットワーク接続プロダクトの選択を参考にし、通信帯域や暗号化などの要件に応じて選択します。

また、他社クラウド環境上から Google Cloud API に対して、グローバル IP アドレスではなく、プライベート IP アドレスを利用した接続をする場合は、限定公開の Google アクセス もあわせて有効化します。


4）構成管理

複数環境をまたがった管理でも、運用負荷がかからないように統合的に構成管理ができるツール/サービスを利用します。Anthos で提供している下記の機能を活用し、クラスタの構成情報や Kubernetes リソース設定などを統合的に管理することで、運用コストの低減を実現します。


5）コンテナレジストリ

GKE / Anthos clusters on AWS では、コンテナ レジストリとして Google Container Registry (GCR) を利用できます。Anthos clusters on AWS でコンテナイメージをパブリック クラウド上に保管できない場合、限定公開イメージ レジストリの使用 をご参照ください。


6）CI / CD パイプライン

Cloud Source Repositories (CSR) や Cloud Build、Container Registry (Artifact Registry) といった Google Cloud のサービスやサードパーティ製品を利用することにより、自動化された CI / CD パイプラインをハイブリッド クラウド環境に実装することができます。CI / CD のアーキテクチャ パターンについては、「Google Cloud での CI / CD」をご参照ください。


利点


このパターンで作成された事例


参考ドキュメント

Cloud SQL とオンプレミス環境のデータベース同期

解決する課題・使い所

データベースには様々な種類がありますが、ここでは Google Cloud のマネージド データベースである Cloud SQL に焦点を絞って紹介します。データベースのデータ連携一般論については「RDBMS データ マイグレーション パータン」もあわせて御覧ください。

Cloud SQL とは、OSS の RDBMS である MySQL や PostgreSQL、商用 RDBMS である SQL Server を、Google Cloud 上で簡単に利用できる、フルマネージドなリレーショナル データベース サービスです。 Cloud SQL を使う際、オンプレミス環境にあるデータベースとデータを同期したい場合があると思います。ここでいう同期とは、2 つのデータベースの状態を可能な限り同じ内容にし続けることです。データベース同期を使って解決できる課題として、以下のようなものがあるでしょう。


「最小のダウンタイムで、オンプレミス環境からクラウド環境へデータを移行したい」

オンプレミス環境からクラウド環境へデータを移行する場合、データのコピーが発生します。コピーはデータ量に比例して時間がかかるため、移行日になってからコピーを開始するとデータ量に応じたダウンタイムが発生してしまいます。移行日前からデータベースを同期させ続けることで、ダウンタイムを最小に保ちつつ、オンプレミス環境からクラウド環境への移行を実現できます。


「オンプレミス環境とクラウドの両方を活用するハイブリッド構成をしたい」

クラウド環境への移行の際、どうしてもオンプレに残さざるを得ないシステムなども出てくることがあります。この際オンプレミス環境とクラウド環境双方にあるアプリケーションで、同じデータベースを参照することがあるかもしれません。このような場合、データベースを同期しつづけることで、オンプレミス環境のアプリケーションはオンプレミス環境のデータベースを、クラウド環境のアプリケーションはクラウド環境のデータベースを参照できるため、ローカリティの観点でも貢献できます。

なおここで紹介する同期方式は、オンプレミス環境のデータベースと Cloud SQL だけではなく、他のクラウドベンダー環境にあるデータベースと Cloud SQL との同期にも応用ができます。


アーキテクチャ

データベースのデータを同期、つまりレプリケーションさせるには様々な方法が考えられますが、一般に各 RDBMS 製品は、それぞれデータベースのレプリケーション機能を持っていることがほとんどです。

そしてデータの転送には、レプリケーションを組む 2 つのデータベース同士が、ネットワーク経由で通信できる必要があります。クラウド環境とオンプレミス環境で通信をする場合、インターネット経由でパブリック IP を使った通信と、VPN 経由でプライベート IP を使った通信が考えられます。

昨今では、インターネットを通さず、プライベート IP のみによる通信が求められる機会が増えてきました。そのため、今回はプライベート IP による通信を前提とします。パブリック IP を使った構成の場合、今回紹介するアーキテクチャのうち、VPN 周りの手順が省略できます。その代わり、インターネットにさらされる、オンプレミス環境及び Cloud SQL のパブリック IP の保護が必要になります。

アーキテクチャを考える際、以下の 2 つを実現する必要があります。

図に示すと以下のような構成となります。

プライベート IP を利用した、オンプレミス環境と Cloud SQL のデータベース同期 

プライベート IP を利用した、外部プライマリ構成の構成画面例


プライベート IP によるオンプレミス環境と Cloud SQL の通信

Cloud SQL のインスタンスは、ユーザーの VPC ではなく、専用の VPC 上に構築されます。そのため、ユーザーの VPC 上にあるアプリケーションから Cloud SQL にプライベート IP で接続するときは、VPC ネットワーク ピアリングにより互いの経路を交換することによって、ネットワーク到達が可能になっています。Cloud SQL のインスタンス作成時にプライベート IP を割り当てる際、プライベート サービス アクセス（Private Service Access）にて設定されているレンジからプライベート IP が払い出されます。

ユーザー VPC と Cloud SQL の VPC はピアリングによって経路交換

次にオンプレミス環境を Cloud VPN または Cloud Interconnect により接続された状態を考えます。

オンプレミス環境にあるゲートウェイ ルーターと Cloud Router では、互いの環境が通信ができるよう BGP による経路交換の設定を行っているはずです。これにより、オンプレミス環境の経路情報はユーザーの VPC へ、ユーザーの VPC の経路情報はオンプレミス環境へと経路広告されます。

しかしこの状態だけでは、Cloud SQL の VPC と疎通できません。さらに、オンプレミス環境から受け取った経路を Cloud SQL の VPC へ渡すため、Cloud SQL の VPC ネットワーク ピアリングの設定より「カスタムルートのエクスポート」にチェックをいれます。また Cloud SQL への経路をオンプレミス環境へ伝えるため、VPN に利用している Cloud Router の設定より、追加で経路広告するカスタム範囲として、Cloud SQL が利用しているネットワークの範囲（プライベート サービス アクセスで設定されている範囲）を入力します。


利点

レプリカをプライマリにプロモート（昇格）させる事が可能

注意事項


サンプル設定

Cloud SQL for MySQL と、オンプレミス環境の MySQL を接続する設定の流れを以下に示します。

インポート済みのルート画面

プライベート IP を利用した、外部プライマリ構成時のルーティングの仕組み