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

GKE + GKE On-Prem

解決する課題・使い所

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

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

1

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

  • 顧客情報や機密情報など社内ルール的にクラウドに置けないデータを扱っている
  • 既存システムと低遅延で接続する必要がある
  • エッジロ ケーション上にアプリケーションをデプロイする必要がある
  • ライセンスがパブリック クラウドに対応していない
  • 既存オンプレミスリソースを活用したい
  • 同一のワークロードをオンプレミスとパブリック クラウド上にデプロイすることによる高可用性の実現
  • 本番環境はオンプレミス上で稼働し、DR 環境をパブリック クラウド上で稼働させる等、環境毎にデプロイ先を分ける 

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

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

分散デプロイパターン

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

  • 顧客情報や機密情報など社内ルール的にクラウドに置けないデータを扱っている
  • 既存システムと低遅延で接続する必要がある
  • エッジ ロケーション上に稼働する
  • ライセンスがパブリック クラウドに対応していない 
2

冗長デプロイパターン

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

  • 同一のワークロードをオンプレミスとパブリック クラウド上にデプロイすることによる高可用性の実現
  • 本番環境はオンプレミス上で稼働し、DR 環境をパブリック クラウド上で稼働させる等、環境毎にデプロイ先を分ける 
3

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

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

  • アプリケーション実行環境
  • データベース
  • インバウンド トラフィックの負荷分散
  • ハイブリッド クラウド間接続
  • 構成管理
  • コンテナレジストリ
  • CI / CD パイプライン
  • モニタリング / ロギング 

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

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

  • Google Kubernetes Engine(GKE)
    • Google が提供する Kubernetes のマネージドサービスです。Google Cloud 上で動作し、自動スケールや自動修復、自動アップグレード、自動プロビジョニングといった機能を持っており、比較的容易に Kubernetes を導入、運用することができます。Google Cloud のサービスとネイティブに連携することも可能です。
  • GKE On-Prem
    • オンプレミス環境上でデプロイ可能な Kubernetes のマネージドサービスです。VMware vSphere 上で動作し、GKE と同様に Cloud Monitoring や Cloud Logging といった Google Cloud の各サービスとネイティブに連携することが可能です。利用するには Anthos ライセンスが必要となります。

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

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

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

データベース

分散デプロイパターンの場合、各ワークロードの特性に応じて利用するデータベースを使い分けます。一例として、パブリック クラウド上に置けないデータを扱うワークロードの場合は、オンプレミス上の独立したデータベースサーバを利用し、GKE 上のワークロードなどデータのロケーションに大きな制約の無いワークロード は Cloud SpannerCloud 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 機能を有効化したり、事前に想定されるトラフィック量に応じたサイジングを行うなど、利用者側で可用性やスケーラビリティに関する設計が必要となります。

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

  • DNS による負荷分散
    • DNS ラウンドロビンや Health Check 機能を持った DNS サービスを利用して負荷分散します。DNS の TTL に依存するためフェイルオーバーにかかる時間が他の方式に比べ長くなります。
  • CDN による負荷分散
    • サードパーティー の CDN サービスを利用して負荷分散します。フェイルオーバーにかかる時間は DNS に比べ短くなります。
  • ロードバランサによる負荷分散

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

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

  • インターネット経由でパブリック IP アドレスを利用した通信をする方式です。
  • 専用線経由での接続
  • VPN 経由での接続
    • Cloud VPN を使って IPsec VPN を張り、インターネット経由でプライベート IP アドレスを利用した通信をする方式です。

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

構成管理

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

  • GKE Hub / Connect
    • ハイブリッド環境の GKE クラスタの構成情報を統一された UI 上で管理することができます。
  • Anthos Config Management
      • Namespace や Quota、RBAC など Kubernetes リソースの設定をハイブリッド環境の各クラスタ間で GitOps 的に同期 / 管理することができます。 

コンテナレジストリ

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

CI / CD パイプライン

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

モニタリング / ロギング

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

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

利点

  • ハイブリッド クラウド アーキテクチャを採用することにより、パブリック クラウドとオンプレミス各環境の利点を享受でき、ワークロードの特性に合わせた柔軟な構成が可能となります。
  • アプリケーション実行環境としてコンテナ / Kubernetes を利用することにより、パブリック クラウドとオンプレミス間の差異を吸収し、ワークロード のポータビリティの向上やアプリケーションのデプロイ / インフラ構成のコード化を実現することが可能です。
  • Anthos を利用して複数環境を統合的に管理することで、ハイブリッド環境における運用コストの高騰を防ぐことができます。 

注意事項

  • ワークロードのポータビリティについて、GKE の BackendConfig のような環境固有の機能を利用している場合はワークロード の単純な移行ができないため、ハイブリッド環境間での Kubernetes マニフェストの互換性有無については事前の確認が必要となります。
  • HTTP(S) Load Balancing + Internet NEG によるハイブリッド環境の負荷分散では、現在 2020 年 10 月 ヘルスチェック機能がサポートされていません。
  • GKE On-Prem アプリケーションメトリクス / ログの Cloud Monitoring / Cloud Logging への集約機能は 2020 年 10 月現在 プレビュー ステータスとなっています。 

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 つを実現する必要があります。 

  • Cloud VPN や Cloud Interconnect を用いて、オンプレミス環境とクラウド環境にある Cloud SQL を、プライベート IP で疎通できるようにする
  • サポートされる任意のデータベース レプリケーション方式を用いて、オンプレミス環境にあるデータベースと、Cloud SQL でレプリケーションを構成する。Cloud SQL が外部とのレプリケーションを直接サポートしている Cloud SQL for MySQL では、Cloud SQL の外部プライマリ方式を使うことができます。 

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

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

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

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

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

  • Cloud SQL
    • Cloud SQL は、サポートしている RDBMS のネイティブのレプリケーション機能を使って、リードレプリカを作成することができます。通常は Cloud SQL 環境に、DB のプライマリ インスタンス を設置し、同じく Cloud SQL 環境にリードレプリカ インスタンスを設置します。このレプリケーションを、外部に設置することも可能で、外部リードレプリカ、または外部プライマリ(外部マスター / External Master )構成などと呼ばれます。
  • Cloud SQL の外部プライマリ
    • 現在、外部にあるデータベースと、レプリケーションのネイティブ対応は、Cloud SQL for MySQL のみ対応しており、PostgreSQL については今後対応予定です。
  • Cloud VPN
    • Cloud VPN または Cloud Interconnect を用いて、オンプレミス環境とユーザーの VPC 間を接続します。VPN の構築方法などはデータベースの同期のテーマからは外れますので、ここでの説明は割愛します。すでに VPN の構築が完了しているものとします。 

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

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

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

 ユーザー 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 が利用しているネットワークの範囲(プライベート サービス アクセスで設定されている範囲)を入力します。

利点 

  • プライベート IP による通信を行っているため、オンプレミス環境 Cloud SQL 環境ともにパブリック IP をインターネットに露出する必要がありません。そのため、運用管理やセキュリティの観点からもメリットを享受できます。
  • 一度 Cloud SQL までのプライベート IP によるネットワーク環境が設置されれば、今回紹介した方法以外にも、その他の RDBMS の機能や、サードパーティ製品によるデータベース連携アプリケーションを利用した、データベース同期を行うことも可能です。
  • Cloud SQL が直接サポートするネイティブのレプリケーション方式であるため、Goolge Cloud のコンソールから、レプリカをプライマリにプロモート(昇格)させるなど、運用性の観点でメリットが得られます。 
レプリカをプライマリにプロモート(昇格)させる事が可能

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

注意事項

サンプル設定

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

  • VPN の構築
    • Cloud VPN または Cloud Interconnect などを利用し、オンプレミス環境とユーザーの VPC が通信できるようにします。
    • BGP による経路交換が行われるように設定してください。
    • この時点ではまだ Cloud SQL の VPC までの到達性はありません。
  • Cloud SQL 環境とオンプレミス環境が疎通できるよう経路交換の設定をする
    • VPC ネットワーク
      • 「VPC ネットワーク ピアリング」より、Cloud SQL for MySQL が利用する「ピアリング」を選択し、「編集」より、「カスタムルートのエクスポート」にチェックを入れて保存します。
      • 同じく Cloud SQL for MySQL のピアリングより、「インポート済みのルート」を確認し、「送信先 IP 範囲」をメモとして控えておきます。 
インポート済みのルート画面

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

  • Cloud VPN ( Cloud Router)
    • 「ハイブリッド接続」の「クラウドルーター」より、今回の VPN における経路交換を行ってるルーターを選択します。「編集」より「カスタム範囲」にて「Cloud SQL for MySQL が使っているネットワーク範囲」を入力します。ここで入力するネットワーク範囲は、先程ピアリングの画面で控えた、「送信先 IP 範囲」です。問題なければ、適切に経路集約設定して構いません。
  • Cloud SQL for MySQL における外部とのレプリケーション構築
プライベート IP を利用した、外部プライマリ構成時のルーティングの仕組み

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