パーティション分割されたマルチクラウド アーキテクチャ パターンは、異なるクラウド サービス プロバイダによって運用される複数のパブリック クラウド環境を組み合わたものです。このアーキテクチャでは、このシリーズの最初のパートで説明したマルチクラウドの推進要因と考慮事項を考慮して、最適なコンピューティング環境にアプリケーションを柔軟にデプロイできます。
次の図は、パーティション分割されたマルチクラウド アーキテクチャ パターンを示しています。
このアーキテクチャ パターンは、次の異なる 2 つの方法で構築できます。最初のアプローチは、アプリケーション コンポーネントをさまざまなパブリック クラウド環境にデプロイすることに基づいています。このアプローチは、コンポジット アーキテクチャとも呼ばれ、階層型ハイブリッド アーキテクチャ パターンと同じアプローチです。ただし、パブリック クラウドでオンプレミス環境を使用する代わりに、少なくとも 2 つのクラウド環境を使用します。複合アーキテクチャでは、単一のワークロードまたはアプリケーションが複数のクラウドのコンポーネントを使用します。2 つ目のアプローチでは、異なるパブリック クラウド環境に異なるアプリケーションをデプロイします。次のリストは、2 番目のアプローチにおけるビジネスの推進要因の一部を示したものであり、すべてを網羅したものではありません。
- 2 つの企業間の合併や買収のシナリオで、異なるクラウド環境でホストされているアプリケーションを完全に統合するため。
- 組織内の柔軟性を促進し、多様なクラウドのニーズに対応するため。このアプローチを採用すると、組織部門が特定のニーズと設定に最適なクラウド プロバイダを選択できます。
- マルチリージョンまたはグローバル クラウドのデプロイで運用するため。特定のリージョンまたは国のデータ所在地に関する規制を遵守する必要がある企業は、プライマリ クラウド プロバイダが対象のリージョンにクラウド リージョンを保持していない場合は、ロケーションで利用可能なクラウド プロバイダから選択する必要があります。
パーティション分割されたマルチクラウド アーキテクチャ パターンでは、必要に応じて、あるパブリック クラウド環境から別のパブリック クラウド環境にワークロードをシフトする機能を維持できます。その場合は、ワークロードのポータビリティが重要な要件になります。ワークロードを複数のコンピューティング環境にデプロイしつつ、環境間でワークロードを移動する機能を維持する必要がある場合は、環境間の差異を抽象化する必要があります。GKE Enterprise を使用すると、一貫したガバナンス、運用、セキュリティ ポスチャーでマルチクラウドの複雑さを解決するソリューションを設計して構築できます。詳細については、GKE Multi-Cloud をご覧ください。
前述のように、Google Cloud と別のクラウド プロバイダを組み合わせ、それらのクラウド環境間でワークロードをパーティション分割することに合理的な理由が存在する場合があります。マルチクラウド ソリューションを使用すると、マルチクラウド環境全体で移行、構築、アプリケーションのポータビリティの最適化を柔軟に行うことができます。また、ロックインを最小限に抑え、規制要件を満たすことができます。たとえば、Google Cloud と Oracle Cloud Infrastructure（OCI）を接続して、プライベート Cloud Interconnect を使用し各プラットフォームの機能を活用するマルチクラウド ソリューションを構築することで、OCI で実行されているコンポーネントと Google Cloud で実行されているリソースを組み合わせることができます。詳細については、Google Cloud と Oracle Cloud Infrastructure - マルチクラウドを最大限に活用するをご覧ください。さらに、Cross-Cloud Interconnect を使用すると、Google Cloud と他のサポートされているクラウド サービス プロバイダ間で高帯域幅の専用接続を確立できます。これにより、クラウド間のトラフィック量の増加に対応するマルチクラウド ソリューションを設計して構築できます。
利点
マルチクラウド アーキテクチャを使用すると、推進要因、考慮事項、戦略、アプローチで説明しているようにビジネスと技術の両面でメリットが得られますが、各メリットの実現可能性を詳細に評価することが不可欠です。評価では、直接的または間接的な課題や潜在的な障害、それらを効果的に回避できることについて慎重に検討する必要があります。また、アプリケーションやサービスの長期的な成長により、初期のメリットを上回る複雑さが生じる可能性があることも考慮してください。
パーティション分割されたマルチクラウド アーキテクチャ パターンの主なメリットは次のとおりです。
単一のクラウド プロバイダの確約利用を最小限に抑える必要があるシナリオでは、複数のクラウド プロバイダにアプリケーションを分散できます。その結果、クラウド プロバイダ間でプランを（ある程度）変更できるため、ベンダー ロックインを比較的軽減できます。Open Cloud は、GKE Enterprise などの Google Cloud の機能をさまざまな物理的な場所に提供します。Google Cloud の機能をオンプレミス、複数のパブリック クラウド、エッジに拡張することで、柔軟性とアジリティを実現し、変革を推進します。
規制上の理由から、Google Cloud のクラウド リージョンが存在しない国のユーザーベースとデータの特定のセグメントにサービスを提供できます。
パーティション分割されたマルチクラウド アーキテクチャ パターンによって、プライマリ クラウド プロバイダがクラウド リージョンまたはポイント オブ プレゼンスを保持しないロケーションで、レイテンシを短縮し、ユーザー エクスペリエンスの全体的な品質を改善できます。このパターンは、分散 CDN で Cross-Cloud Interconnect や CDN Interconnect などの大容量で低レイテンシのマルチクラウド接続を使用する場合に特に有効です。
複数のクラウド プロバイダにアプリケーションをデプロイし、他のクラウド プロバイダが提供する最適なサービスの中から選択できるようにします。
パーティシン分割されたマルチクラウド アーキテクチャ パターンは、2 つの企業のアプリケーションとサービスが異なるパブリック クラウド環境でホストされる合併と買収のシナリオを容易にし、加速させることができます。
ベスト プラクティス
- まず、ミッション クリティカルでないワークロードをデプロイします。セカンダリ クラウドでのこの最初のデプロイは、将来のデプロイや移行のパターンとして使用できます。ただし、特定のワークロードを特定のクラウド リージョンに配置することが法律または規制で義務付けられている場合、およびプライマリ クラウド プロバイダが必要な国または地域にリージョンを保持していない場合、このアプローチは適用できない可能性があります。
- 特に通信が同期的に処理されている場合、さまざまなパブリック クラウド環境で動作しているシステム間の依存関係を最小限に抑えます。こうした依存関係は、パフォーマンスの低下、全体的な可用性の低下、アウトバウンド データ転送の追加料金が発生する原因となる可能性があります。
- 環境の違いを抽象化するには、アプリケーションでサポートされており、実行可能な場合は、コンテナと Kubernetes の使用を検討してください。
- CI / CD パイプライン、および、デプロイとモニタリングに使用するツールについては、クラウド環境間で一貫性を保つようにします。
- 使用しているアプリケーションに最も効率的で効果的な通信ソリューションを提供する最適なネットワーク アーキテクチャ パターンを選択します。
- 通信は詳細に制御する必要があります。安全な API を使用して、アプリケーション コンポーネントを公開します。
- 特定のビジネス要件と技術要件に基づいて、メッシュ化されたアーキテクチャ パターンまたはゲート型ネットワーキング パターンのいずれかを使用することを検討してください。
- 可用性とパフォーマンスの期待値を満たすには、エンドツーエンドの高可用性（HA）、低レイテンシ、適切なスループット レベルを実現するように設計します。
機密情報を保護するため、転送中のすべての通信を暗号化することをおすすめします。
- 接続レイヤで暗号化が必要な場合は、選択したハイブリッド接続ソリューションに基づいてさまざまなオプションを使用できます。これらのオプションには、VPN トンネル、Cloud Interconnect を介した HA VPN、Cross-Cloud Interconnect の MACsec などがあります。
マルチクラウドのパーティション分割されたアーキテクチャ パターンの一部として複数の CDN を使用しており、Google Cloud から大量のデータファイルを他の CDN に送信している場合は、Google Cloud とサポートされているプロバイダ間の CDN Interconnect リンクを使用して、このトラフィックと可能な場合はコストを最適化することを検討してください。
システムが環境境界を越えて安全に認証できるように、環境間でID 管理ソリューションを拡張します。
Google Cloud と別のクラウド プラットフォーム間でリクエストを効果的に分散するには、Cloud Load Balancing を使用します。詳細については、オンプレミスの場所または別のクラウドにトラフィックを転送するをご覧ください。
- Google Cloud から他の環境へのアウトバウンド データ転送量が多い場合は、Cross-Cloud Interconnect の使用を検討してください。
さまざまなバックエンド間でプロトコル、API、認証メカニズムの不整合を解消するには、必要に応じて、統合ファサードとして API ゲートウェイまたはプロキシをデプロイすることをおすすめします。このゲートウェイまたはプロキシは、一元化された制御ポイントとして機能し、次の対策を行います。
- 追加のセキュリティ対策を実装します。
- クライアント アプリやその他のサービスをバックエンド コードの変更から保護します。
- すべてのクロス環境アプリとその分離されたコンポーネント間の通信の監査証跡を容易にします。
- レガシー サービスと最新のサービス間の中間通信レイヤとして機能します。
- Apigee と Apigee ハイブリッドを使用すると、オンプレミス環境、エッジ、他のクラウド、Google Cloud 環境にわたってエンタープライズ クラスのハイブリッド ゲートウェイをホストして管理できます。
次のケースの一部では、API ゲートウェイを使用した Cloud Load Balancing によって、複数のリージョン間で API トラフィックを管理、保護、分散するための堅牢で安全なソリューションを実現できます。
- 異なるリージョンでの Apigee API ランタイムに対するマルチリージョン フェイルオーバーのデプロイ。
Cloud CDN によるパフォーマンスの向上。
Google Cloud Armor を介した WAF と DDoS 保護の実施。
可能であれば、クラウド環境全体のロギングとモニタリングに一貫したツールを使用します。オープンソースのモニタリング システムの使用を検討してください。詳細については、ハイブリッド クラウドとマルチクラウドのモニタリングおよびロギング パターンをご覧ください。
単一のアプリケーションのコンポーネントを複数のクラウド環境にデプロイする分散方式でアプリケーション コンポーネントをデプロイする場合は、階層型ハイブリッド アーキテクチャ パターンのベスト プラクティスをご覧ください。