ハイブリッド クラウドとマルチクラウド
Embedded Files
IDG の 2020 年の調査によると、すでに 83% の企業がオンプレミスとクラウドを併用するハイブリッド クラウドを、54% の企業（エンタープライズに限れば 66%）が複数のクラウドを利用しているという結果がでています。ハイブリッド クラウドについては、ワークロードの要件に応じてオンプレミスとクラウドを使い分けることが多かった中、近年、災害復旧対応や可用性向上を理由にした移行も見られます。マルチクラウドについては、採用理由として 「各プロバイダが提供するサービスの中から最適なサービスを選択できる」が 49% と、最も高くなっています。今後日本においてもこの方針はより重要になり、普及していくものと考えられます。
Google Cloud は「お客様が選択できること」を重視したサービス展開をしてきましたが、ハイブリッド / マルチクラウドの文脈においても、つまりオンプレミスや他社クラウドでも Google のソリューションがご選択いただけるよう、様々なソリューションを展開しています。
この節ではハイブリッド クラウドやマルチクラウドを、より効果的に実現するための手法をご案内します。特性が異なるアプリケーションとデータベースに対し、それぞれパターンごとに考慮点やベスト プラクティスをみていきましょう。
Cloud Run + Cloud Firestore
Cloud Run + Cloud Firestore
解決する課題・使い所
企業におけるパブリック クラウドの活用は一般的になっていますが、機密データを扱うためパブリック クラウドに移行できないワークロード や、既存システムとの低遅延通信や既存 IT 資産の有効活用の観点からオンプレミス上での稼働が望ましいワークロードも存在します。多くの企業では、パブリック クラウド上のワークロードと上記のようなオンプレミス上のワークロードを適材適所で組み合わせて活用する必要があります。
本ドキュメントでは、以下の図のようにパブリック クラウドとオンプレミスを組み合わせたアーキテクチャをハイブリッド クラウド アーキテクチャと定義します。
ハイブリッド クラウドは以下のようなケースで活用することができます。
顧客情報や機密情報など社内ルール的にクラウドに置けないデータを扱っている
既存システムと低遅延で接続する必要がある
エッジロ ケーション上にアプリケーションをデプロイする必要がある
ライセンスがパブリック クラウドに対応していない
既存オンプレミスリソースを活用したい
同一のワークロードをオンプレミスとパブリック クラウド上にデプロイすることによる高可用性の実現
本番環境はオンプレミス上で稼働し、DR 環境をパブリック クラウド上で稼働させる等、環境毎にデプロイ先を分ける
ハイブリッド クラウド アーキテクチャのパターン
ハイブリッド クラウド アーキテクチャのパターンは、大きく以下 2 種類に分類することができます。
分散デプロイパターン
各ワークロードの特性に応じて、パブリック クラウドとオンプレミスそれぞれデプロイ先を分けるパターンです。以下のようなケースで活用することができます。
顧客情報や機密情報など社内ルール的にクラウドに置けないデータを扱っている
既存システムと低遅延で接続する必要がある
エッジ ロケーション上に稼働する
ライセンスがパブリック クラウドに対応していない
冗長デプロイパターン
同じワークロードをパブリック クラウドとオンプレミス両方にデプロイし、可用性を高めるパターンです。以下のようなケースで活用することができます。
同一のワークロードをオンプレミスとパブリック クラウド上にデプロイすることによる高可用性の実現
本番環境はオンプレミス上で稼働し、DR 環境をパブリック クラウド上で稼働させる等、環境毎にデプロイ先を分ける
ハイブリッド クラウド アーキテクチャ
ハイブリッド クラウドアーキテクチャを構成する上で重要となる技術観点として、以下項目が考えられます。本項では各技術観点の検討ポイントについて確認をしていきます。
アプリケーション実行環境
データベース
インバウンド トラフィックの負荷分散
ハイブリッド クラウド間接続
構成管理
コンテナレジストリ
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 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 機能を有効化したり、事前に想定されるトラフィック量に応じたサイジングを行うなど、利用者側で可用性やスケーラビリティに関する設計が必要となります。
また、冗長デプロイパターンにおいて、インバウンド トラフィックをハイブリッド クラウド間で負荷分散する場合、以下のような選択肢があります。
DNS による負荷分散
DNS ラウンドロビンや Health Check 機能を持った DNS サービスを利用して負荷分散します。DNS の TTL に依存するためフェイルオーバーにかかる時間が他の方式に比べ長くなります。CDN による負荷分散
サードパーティー の CDN サービスを利用して負荷分散します。フェイルオーバーにかかる時間は DNS に比べ短くなります。ロードバランサによる負荷分散
Google Cloud の External HTTP(S) Load Balancing + Internet NEG による構成で負荷分散を実現します。フェイルオーバーにかかる時間は DNS に比べ短くなります。
ハイブリッド クラウド間接続
ハイブリッド クラウド上のアプリケーション間でデータ連携をする場合や、オンプレミスから Google Cloud のサービスに対して API アクセスをする場合、ハイブリッド クラウド間の接続方式について検討します。接続方式として複数のオプションがあるため、ネットワーク接続プロダクトの選択を参考にし、通信帯域や暗号化等の要件に応じて選択します。 インターネット経由での接続
インターネット経由でパブリック IP アドレスを利用した通信をする方式です。
専用線経由での接続
Dedicated Interconnect や Partner Interconnect を利用し、専用線経由でプライベート 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 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 やその他サードパーティ製品を導入しオンプレミス上でメトリクス / ログを保管します。
利点
ハイブリッド クラウド アーキテクチャを採用することにより、パブリック クラウドとオンプレミス各環境の利点を享受でき、ワークロードの特性に合わせた柔軟な構成が可能となります。
アプリケーション実行環境としてコンテナ / Kubernetes を利用することにより、パブリック クラウドとオンプレミス間の差異を吸収し、ワークロード のポータビリティの向上やアプリケーションのデプロイ / インフラ構成のコード化を実現することが可能です。
Anthos を利用して複数環境を統合的に管理することで、ハイブリッド環境における運用コストの高騰を防ぐことができます。
注意事項
ワークロードのポータビリティについて、GKE の BackendConfig のような環境固有の機能を利用している場合はワークロード の単純な移行ができないため、ハイブリッド環境間での Kubernetes マニフェストの互換性有無については事前の確認が必要となります。
HTTP(S) Load Balancing + Internet NEG によるハイブリッド環境の負荷分散では、現在 2020 年 10 月 ヘルスチェック機能がサポートされていません。
GKE On-Prem アプリケーションメトリクス / ログの Cloud Monitoring / Cloud Logging への集約機能は 2020 年 10 月現在 プレビュー ステータスとなっています。
このパターンで作成された事例
参照文献
マルチクラウド パターン（GCP + AWS）
マルチクラウド パターン（GCP + AWS）
解決する課題・使い所
551 名の IT 決裁権者に対して実施された IDG 社の Cloud Computing Survey によると、2020 年時点でクラウドを利用している組織は 81% に及び、うち 55% が複数のパブリック クラウドを使用しています。規模別では、中堅・中小規模（SMB）の企業の 47％、より複雑な環境への管理能力や、より多くの予算が求められるエンタープライズ企業の 66% が複数のパブリック クラウドを利用していると回答しています。 その理由としては、以下の 5 つが挙げられます。
最も優れた IT 基盤とサービスの選択 (49%)
コスト削減 / 最適化 (41%)
災害復旧 / 事業継続の改善 (40%)
よりよい IT 基盤やサービスの柔軟性を追求 (39%)
ベンダー ロックインの回避 (37%)
これらの理由が重要なのは、クラウドは単なるハードウェアの時間貸しではなく、その上に利用者の課題を解決すべくソフトウェアが実装されていることが背景にあるためです。ソフトウェアである以上、「各社クラウドの設計思想や実装が異なる」「各社の強みのある機能エリアが異なる」ことから、 “選択” したり “ロックインを回避” したりする必要があり、その解消のためにマルチクラウドが採用されています。
本ドキュメントでは、以下のように 2 つ以上のプロバイダのパブリック クラウドを組み合わせた構成をマルチクラウド アーキテクチャと定義します。
マルチクラウドは、以下のようなケースで活用することができます。
各クラウド プロバイダ固有の、または強みの機能を利用したい
既存のクラウド環境にあるリソースを活用したい
既存のクラウド環境と低遅延で接続する必要がある 大規模なデータ分析のコストを最適化したい
同一のワークロードを複数のクラウド上にデプロイすることで可用性を高めたい
ミッション クリティカルなシステムの単一障害点回避、リスクの最小化
マルチクラウド アーキテクチャのパターン
マルチクラウド アーキテクチャのパターンは、（1）分散デプロイパターン、および（2）冗長デプロイパターンの 2 種類に分類することができます。
（1）分散デプロイパターン
各ワークロードの特性に応じて、複数のパブリック クラウドを組み合わせ、より適したコンピューティング環境にアプリケーションをデプロイする柔軟性が得られます。このパターンは、以下のようなケースで活用することができます。
各クラウド プロバイダ固有の、または強みの機能を利用したい
既存のクラウド環境にあるリソースを活用したい
既存のクラウド環境と低遅延で接続する必要がある
もう 1 つ、トランザクション システムとデータ分析システムを、分散デプロイするパターンがあります。Google Cloud では、データ取得から、処理、分析、最終的な可視化まで、データのライフサイクル全体を通じてデータを管理する豊富なサービスを提供しています。このパターンを利用することで、サーバーレス型のマネージド サービスを活用し、大規模なスケールが必要なデータ分析を、より最適化されたコストで実施することが可能です。
（2）冗長デプロイパターン
同じワークロードを複数のコンピューティング環境にわたりデプロイすることで、処理能力や復元力が高まることが期待できます。具体的には、以下のようなケースです。
同一のワークロードを複数のクラウド上にデプロイすることで可用性を高めたい
ミッション クリティカルなシステムの単一障害点回避、リスクの最小化
マルチクラウド アーキテクチャ
マルチクラウド アーキテクチャを構成する上で重要となる技術的な観点として、以下 6 項目が考えられます。本項では、それぞれの検討ポイントについて確認します。
アプリケーション実行環境
データベース
クラウド間接続
構成管理
コンテナ レジストリ
CI / CD パイプライン
1）アプリケーション実行環境
マルチクラウド環境では、ワークロードのポータビリティや運用の統一性が重要です。アプリケーションの実行環境としてコンテナを選択することで、ワークロードのポータビリティを確保し、コンテナのオーケストレータとして Kubernetes を利用することで、自動的、かつ統一的な方法で、アプリケーションのデプロイやインフラの構成管理が可能です。またその際、Google Kubernetes Engine（GKE）や Anthos clusters on AWS といったマネージド Kubernetes プラットフォーム、またはすでに構築された Kubernetes クラスタを統合して管理することのできる Anthos Attached Clusters を利用することで運用負荷を低減することができます。
Google Kubernetes Engine（GKE）
アマゾン ウェブ サービス（AWS）上にデプロイ可能な Kubernetes のマネージド サービスです。Amazon Elastic Block Store（Amazon EBS）や Application Load Balancer（ALB）、SecurityGroup などを活用しながら Amazon Elastic Compute Cloud (Amazon EC2）上で動作し、Anthos Config management などをとおして、マルチクラウド環境上でも運用に一貫性をもたせることができます。利用時には Anthos ライセンスが必要となります。Anthos clusters on AWS
アマゾン ウェブ サービス（AWS）上にデプロイ可能な Kubernetes のマネージド サービスです。Amazon Elastic Block Store（Amazon EBS）や Application Load Balancer（ALB）、SecurityGroup などを活用しながら Amazon Elastic Compute Cloud (Amazon EC2）上で動作し、Anthos Config management などをとおして、マルチクラウド環境上でも運用に一貫性をもたせることができます。利用時には Anthos ライセンスが必要となります。Anthos Attached Clusters
Amazon Elastic Kubernetes Service（Amazon EKS）、Azure Kubernetes Service（AKS）、Red Hat OpenShift Kubernetes Engine、Rancher Kubernetes Engine（RKE）といった製品で構築された Kubernetes クラスタを Anthos の管理下とすることで、Anthos Config management などにより運用に一貫性をもたせることができます。利用するには Anthos ライセンスが必要となります。
分散デプロイ パターンの場合、各ワークロードの持つ特性に応じてデプロイ先のアプリケーション実行環境を分散します。一例として、すでに 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 アクセスをする場合、ハイブリッド クラウド間の接続方式について検討します。接続方式として複数のオプションがあるため、ネットワーク接続プロダクトの選択を参考にし、通信帯域や暗号化などの要件に応じて選択します。
インターネット経由での接続
インターネット経由でパブリック IP アドレスを利用した通信をする方式です。専用線経由での接続
Dedicated Interconnect や Partner Interconnect を利用し、専用線経由でプライベート IP アドレスを利用した通信をする方式です。
VPN 経由での接続
Cloud VPN を使って IPsec VPN を張り、インターネット経由でプライベート IP アドレスを利用した通信をする方式です。
また、他社クラウド環境上から Google Cloud API に対して、グローバル IP アドレスではなく、プライベート IP アドレスを利用した接続をする場合は、限定公開の Google アクセス もあわせて有効化します。
4）構成管理
複数環境をまたがった管理でも、運用負荷がかからないように統合的に構成管理ができるツール/サービスを利用します。Anthos で提供している下記の機能を活用し、クラスタの構成情報や Kubernetes リソース設定などを統合的に管理することで、運用コストの低減を実現します。
Fleet / Connect
マルチクラウド環境上の Kubernetes クラスタの構成情報を統一された UI 上で管理でき、各環境に安全にデプロイできます。Namespace や Quota、RBAC など、Kubernetes リソースの設定をハイブリッド環境の各クラスタ間で GitOps 的に同期 / 管理することができます。
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」をご参照ください。
利点
マルチクラウド アーキテクチャを採用することにより、各パブリック クラウド プロバイダが強みとする機能や利点を享受でき、ワークロードの特性にあわせた柔軟な構成が可能になります。
アプリケーション実行環境としてコンテナ / Kubernetes を利用することにより、各パブリック クラウド プロバイダ間の差異を吸収し、ワークロード のポータビリティの向上やアプリケーションのデプロイ / インフラ構成のコード化を実現できます。
Anthos を利用して、複数環境を統合的に管理することで、運用コストの高騰を防ぐことができます。
このパターンで作成された事例
参考ドキュメント
Cloud SQL とオンプレミス環境のデータベース同期
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
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 はピアリングによって経路交換
次にオンプレミス環境を 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 のみです。その他のデータベースについては、順次対応予定です。
Cloud SQL for MySQL の外部サーバーとのレプリケーション構築手順が新しくなりました。今後構築される場合は、「外部サーバーから Cloud SQL への移行（v1.1） | Cloud SQL for MySQL」を、2020 年 9 月 21 日 より前に構築済みの環境について「Replicating from an external master (v1) | Cloud SQL for MySQL」を御覧ください。
サンプル設定
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 における外部とのレプリケーション構築
ドキュメント「外部サーバーから Cloud SQL への移行（v1.1）」に従い、構築してください。
プライベート IP を利用した、外部プライマリ構成時のルーティングの仕組み
Page updated
Report abuse