このドキュメントでは、ハイブリッド クラウドとマルチクラウドのアーキテクチャ全体を形成するうえで重要な役割を果たすコア設計上の考慮事項について説明します。これらの考慮事項を特定のワークロードだけでなく、すべてのワークロードを含むソリューション アーキテクチャ全体で包括的に分析して評価します。
リファクタリング
リファクタリングによる移行では、新しい環境で機能するようにワークロードを変更するだけでなく、クラウド機能を利用できるようにワークロードを変更します。これにより、ワークロードのパフォーマンス、機能、費用、ユーザー エクスペリエンスを改善します。リファクタリング: 移行と改善で説明したように、一部のリファクタリング シナリオでは、ワークロードをクラウドに移行する前に変更を行うことができます。このリファクタリング方法には、特に長期的なターゲット アーキテクチャとしてハイブリッド アーキテクチャを構築する場合に、次のような利点があります。
- デプロイ プロセスを改善できます。
- 継続的インテグレーション / 継続的デプロイ（CI / CD）のインフラストラクチャとツールに投資することで、リリースの間隔を短縮し、フィードバック サイクルを短縮できます。
- リファクタリングを基盤として、アプリケーションのポータビリティを備えたハイブリッド アーキテクチャを構築して管理できます。
このアプローチを適切に実施するには、通常、オンプレミス インフラストラクチャとツールに対してなんらかの投資を行う必要があります。たとえば、ローカルの Container Registry を設定し、Kubernetes クラスタをプロビジョニングしてアプリケーションをコンテナ化します。ハイブリッド環境でのこのアプローチには Google Kubernetes Engine（GKE）Enterprise エディションが役立ちます。GKE Enterprise の詳細については、次のセクションをご覧ください。詳細については、GKE Enterprise ハイブリッド環境のリファレンス アーキテクチャもご覧ください。
ワークロードのポータビリティ
ハイブリッド アーキテクチャとマルチクラウド アーキテクチャでは、データをホストするコンピューティング環境間でワークロードをシフトできる場合があります。環境間でワークロードをシームレスに移動できるようにするには、次の要素を考慮してください。
- アプリケーションとその運用モデルを大幅に変更することなく、アプリケーションをコンピューティング環境間で移行できます。
- アプリケーションのデプロイと管理がコンピューティング環境間で一貫している。
- 可視性、構成、セキュリティがコンピューティング環境全体で一貫している。
- ワークロードをポータブルにすることと、ワークロードをクラウド ファーストにすることとが競合していない。
インフラストラクチャの自動化
インフラストラクチャの自動化は、ハイブリッド クラウド アーキテクチャとマルチクラウド アーキテクチャのポータビリティに不可欠です。インフラストラクチャの作成を自動化する一般的なアプローチの一つは、Infrastructure as Code（IaC）の使用です。IaC では、ユーザー インターフェースで VM、セキュリティ グループ、ロードバランサなどのリソースを手動で構成するのではなく、ファイルでインフラストラクチャを管理します。Terraform は、ファイルでインフラストラクチャ リソースを定義するための一般的な IaC ツールです。Terraform を使用すると、異種混合環境でこれらのリソースの作成を自動化することもできます。
Google Cloud リソースのプロビジョニングと管理を自動化できる Terraform のコア機能の詳細については、Google Cloud 用の Terraform ブループリントとモジュールをご覧ください。
Ansible、Puppet、Chef などの構成管理ツールを使用すると、デプロイと構成の共通プロセスを確立できます。また、Packer などのイメージ作成ツールを使用して、さまざまなプラットフォーム用の VM イメージを作成することもできます。単一の共有構成ファイルを使用すると、Packer と Cloud Build を使用して、Compute Engine で使用する VM イメージを作成できます。また、Prometheus や Grafana などのソリューションを使用すると、複数の環境間で一貫したモニタリングを実施できます。
これらのツールにより、次の論理図に示すように共通のツールチェーンを組み立てることができます。この共通ツールチェーンは、コンピューティング環境間の違いを抽象化します。また、プロビジョニング、デプロイ、管理、モニタリングを一元化できます。
一般的なツールチェーンでもポータビリティを実現できますが、短所もあります。
- VM を共通基盤として使用すると、真にクラウド ファーストのアプリケーションを実装するのが難しくなる可能性があります。また、VM のみを使用すると、クラウド マネージド サービスを使用できなくなる可能性があります。管理オーバーヘッドを削減する機会を逃す可能性があります。
- 共通のツールチェーンの構築と維持には、オーバーヘッドと運用コストが発生します。
- ツールチェーンが拡大すると、企業の特定のニーズに合わせて独自の複雑さが生じる可能性があります。複雑さが増すことで、トレーニング費用の増加につながる可能性があります。
ツールと自動化を開発するかどうかを判断する前に、クラウド プロバイダが提供するマネージド サービスを調べてください。プロバイダが同じユースケースをサポートするマネージド サービスを提供している場合は、複雑さを抽象化できます。これにより、基盤となるインフラストラクチャではなく、ワークロードとアプリケーション アーキテクチャに集中できます。
たとえば、Kubernetes リソースモデルを使用して、宣言型構成アプローチで Kubernetes クラスタの作成を自動化できます。Deployment Manager Convert を使用すると、Deployment Manager の構成とテンプレートを、Google Cloud がサポートする他の宣言型構成形式（Terraform や Kubernetes リソースモデルなど）に変換し、公開時に移植できるようになります。
プロジェクトの作成と、そのプロジェクト内のリソースの作成を自動化することも検討してください。この自動化により、プロジェクトのプロビジョニングに Infrastructure as Code アプローチを採用できます。
コンテナと Kubernetes
クラウド管理機能を使用することで、カスタム ツールチェーンの構築と維持の複雑さを軽減し、ワークロードの自動化とポータビリティを実現できます。ただし、VM を共通基盤としてのみ使用すると、真にクラウド ファーストのアプリケーションを実装することが難しくなります。解決策の一つとして、コンテナと Kubernetes を活用する方法があります。
コンテナを利用すると、ソフトウェアを異なる環境に移行しても、その動作の信頼性を維持できます。コンテナは、基盤となるホスト インフラストラクチャからアプリケーションを分離するため、ハイブリッドやマルチクラウドなどのコンピューティング環境全体にわたるデプロイが容易になります。
コンテナ化されたアプリケーションのオーケストレーション、デプロイ、スケーリング、管理は Kubernetes によって行われます。これはオープンソースで、Cloud Native Computing Foundation によって管理されています。Kubernetes により、クラウド ファースト アプリケーションの基盤となるサービスが提供されます。Kubernetes は多くのコンピューティング環境にインストールして実行できるため、Kubernetes を使用してコンピューティング環境間に共通したランタイム レイヤを確立することもできます。
- Kubernetes では、クラウド コンピューティング環境とプライベート コンピューティング環境で同じサービスと API が提供されます。さらに、抽象化のレベルが VM の使用時より大幅に高まるため、必要な下準備が減り、デベロッパーの生産性が向上します。
- カスタム ツールチェーンとは異なり、Kubernetes は開発とアプリケーション管理の両方に広く採用されているため、既存の専門知識や技術、ドキュメント、第三者サポートを活用できます。
- Kubernetes は、次の条件を満たすすべてのコンテナ実装をサポートしています。
- Kubernetes の Container Runtime Interface（CRI）をサポートする
- 業界で採用されている
- 特定のベンダーに縛られない
ワークロードが Google Cloud で実行されている場合は、Google Kubernetes Engine（GKE）などのマネージド Kubernetes プラットフォームを使用して、Kubernetes のインストールと運用の手間を省くことができます。これにより、運用担当者はインフラストラクチャの構築と保守からアプリケーションの構築と保守に重点を移すことができます。
Autopilot を使用することもできます。Autopilot は、ノード、スケーリング、セキュリティ、その他の事前構成された設定などのクラスタ構成を管理する GKE の運用モードです。GKE Autopilot を使用する場合は、スケーリング要件とそのスケーリングの上限を考慮してください。
技術的には、多くのコンピューティング環境に Kubernetes をインストールして実行し、共通のランタイム レイヤを確立できます。ただし、実際には、このようなアーキテクチャの構築と運用は複雑になる可能性があります。コンテナレベルのセキュリティ制御（サービス メッシュ）が必要な場合、アーキテクチャはさらに複雑になります。
GKE Enterprise を使用すると、マルチクラスタ デプロイの管理を簡素化し、最新のアプリケーションをどこでも大規模に実行できます。GKE を構成する強力なマネージド オープンソース コンポーネントにより、ワークロードのセキュリティを確保し、コンプライアンス ポリシーを適用して、詳細なネットワークのオブザーバビリティとトラブルシューティングを提供できます。
次の図に示すように、GKE Enterprise を使用すると、マルチクラスタ アプリケーションをフリートとして運用できます。
GKE Enterprise は、ハイブリッド アーキテクチャとマルチクラウド アーキテクチャをサポートする次の設計オプションをサポートしています。
アプリケーションを GKE Enterprise ハイブリッド環境に移行するための、クラウドのようなエクスペリエンスを提供するオンプレミス ソリューションまたは統合ソリューションを設計して構築します。詳細については、GKE Enterprise ハイブリッド環境のリファレンス アーキテクチャをご覧ください。
GKE Multi-Cloud を使用して、一貫したガバナンス、運用、セキュリティ ポスチャーでマルチクラウドの複雑さを解決するソリューションを設計して構築します。詳細については、GKE Multi-Cloud のドキュメントをご覧ください。
また、GKE Enterprise では、一貫したセキュリティ、構成、サービス管理により、類似環境を論理的にグループ化できます。たとえば、GKE Enterprise はゼロトラスト分散アーキテクチャを強化します。ゼロトラスト分散アーキテクチャでは、オンプレミスまたは別のクラウド環境にデプロイされたサービスは、エンドツーエンドの mTLS で保護されたサービス間通信を介して環境間で通信できます。
ワークロードのポータビリティに関する考慮事項
Kubernetes と GKE Enterprise には、コンピューティング環境の複雑で細かい内容やコンピューティング環境間の相違点を覆い隠せるワークロード抽象化レイヤが用意されています。次のリストに、これらの抽象化の一部を示します。
- アプリケーションはほとんど変更を行わずに別の環境に移植できますが、アプリケーションが両方の環境で同じパフォーマンスを示すとは限りません。
- 基盤となるコンピューティング、インフラストラクチャのセキュリティ機能、またはネットワーキング インフラストラクチャの相違と、依存関係のあるサービスとの近接性によって、パフォーマンスが大幅に変わる可能性があります。
- コンピューティング環境間でワークロードを移動すると、データの移行も必要になることがあります。
- 環境によって、データ ストレージと管理のサービスや施設が異なる場合があります。
- Kubernetes または GKE Enterprise でプロビジョニングされたロードバランサの動作とパフォーマンスは、環境によって異なる場合があります。
データの移動
コンピューティング環境間で大規模なデータの移動、共有、アクセスは複雑になる可能性があります。このため、エンタープライズ レベルの企業では、ハイブリッドまたはマルチクラウド アーキテクチャの構築を躊躇することがあります。すでにデータのほとんどをオンプレミスまたは 1 つのクラウドに保存している場合、この傾向はさらに強まる可能性があります。
ただし、Google Cloud が提供するさまざまなデータ移行オプションにより、データの移動、統合、変換を行う包括的なソリューション セットを利用できます。これらのオプションを使用すると、企業は特定のユースケースに合わせて、さまざまな環境間でデータを保存、共有、アクセスできます。この機能により、ビジネスとテクノロジーの意思決定者がハイブリッド アーキテクチャとマルチクラウド アーキテクチャを簡単に採用できるようになります。
データの移動は、ハイブリッド クラウドとマルチクラウドの戦略とアーキテクチャの計画において重要な考慮事項です。チームは、さまざまなビジネス ユースケースと、それらを支えるデータを特定する必要があります。また、ストレージの種類、容量、アクセス方法、移動オプションについても検討する必要があります。
規制の厳しい業界向けのデータ分類がある場合、その分類は、特定のデータクラスの保存場所とリージョン間のデータ移動の制限を特定する際に役立ちます。詳細については、Sensitive Data Protection をご覧ください。Sensitive Data Protection は、データアセットの検出、分類、保護を支援するフルマネージド サービスです。
データ転送の計画から、計画の実装におけるベスト プラクティスの実施までのプロセスの詳細については、Google Cloud への移行: 大規模なデータセットの転送をご覧ください。
セキュリティ
組織がハイブリッド アーキテクチャとマルチクラウド アーキテクチャを採用すると、システムとデータの分散方法によっては、攻撃対象領域が増加する可能性があります。攻撃対象領域の増加は、絶えず進化する脅威の状況と相まって、不正アクセス、データ損失、その他のセキュリティ インシデントのリスクを高める可能性があります。ハイブリッドまたはマルチクラウド戦略を計画して実装する際は、セキュリティを慎重に検討してください。
詳細については、Google Cloud での攻撃領域対象の管理をご覧ください。
ハイブリッド アーキテクチャを設計する場合、オンプレミスのセキュリティ アプローチをクラウドに拡張することは、技術的に実現または実行可能であるとは限りません。ただし、ハードウェア アプライアンスのネットワーク セキュリティ機能の多くはクラウド ファーストの機能であり、分散型で動作します。Google Cloud のクラウド ファーストのネットワーク セキュリティ機能の詳細については、クラウド ネットワーク セキュリティをご覧ください。
ハイブリッド アーキテクチャとマルチクラウド アーキテクチャでは、整合性やオブザーバビリティなど、追加のセキュリティ上の課題が生じる可能性があります。どのパブリック クラウド プロバイダにも、さまざまなモデル、ベスト プラクティス、インフラストラクチャとアプリケーションのセキュリティ機能、コンプライアンス義務、セキュリティ サービスの名前など、独自のセキュリティ アプローチがあります。このような不整合は、セキュリティ リスクを高める可能性があります。また、クラウド プロバイダによって責任共有モデルが異なる場合があります。このため、マルチクラウド アーキテクチャにおける責任の明確な境界を特定して理解することが重要です。
オブザーバビリティは、さまざまな環境から分析情報と指標を取得するうえで重要です。マルチクラウド アーキテクチャでは通常、各クラウドにセキュリティ ポスチャーと構成ミスをモニタリングするツールが用意されています。ただし、これらのツールを使用すると、可視化がサイロ化され、環境全体にわたる高度な脅威インテリジェンスの構築が難しくなります。セキュリティ チームは、クラウドのセキュリティを維持するためにツールとダッシュボードを切り替えなければなりません。ハイブリッド環境とマルチクラウド環境の包括的なエンドツーエンドのセキュリティ インサイトがないと、脆弱性の優先度の判断とリスクの軽減が困難になります。
すべての環境の完全な可視性とポスチャーを取得するには、脆弱性の優先度を判断し、特定した脆弱性を回避する必要があります。一元化された可視性モデルをおすすめします。一元化された可視性モデルを使用すると、異なるプラットフォームの異なるツールやダッシュボードを手動で相関付ける必要がなくなります。詳細については、ハイブリッド クラウドとマルチクラウドのモニタリングおよびロギング パターンをご覧ください。
セキュリティ リスクを軽減し、Google Cloud にワークロードをデプロイする計画の一環として、セキュリティとコンプライアンスの目標を達成するためのクラウド ソリューションを計画、設計する際には、Google Cloud のセキュリティ ベスト プラクティス センターとエンタープライズ基盤のブループリントをご覧ください。
コンプライアンスの目標は、業界固有の規制と、地域や国によって異なる規制要件の両方の影響を受けるため、異なる場合があります。詳細については、Google Cloud のコンプライアンス リソース センターをご覧ください。安全なハイブリッド クラウドとマルチクラウド アーキテクチャを設計するために推奨される主なアプローチは次のとおりです。
統合され、調整されたクラウド セキュリティ戦略とアーキテクチャを策定する。ハイブリッド クラウドとマルチクラウドのセキュリティ戦略は、組織の特定のニーズと目標に合わせて調整する必要があります。
環境ごとに異なる機能、構成、サービスを使用できるため、セキュリティ管理を実装する前に、対象のアーキテクチャと環境を理解することが重要です。
ハイブリッド環境とマルチクラウド環境全体で統合されたセキュリティ アーキテクチャを検討してください。
クラウドの設計とデプロイ、特にセキュリティ設計と機能を標準化する。これにより、効率が向上し、統合されたガバナンスとツール管理が可能になります。
複数のセキュリティ コントロールを使用する。
通常、単一のセキュリティ コントロールですべてのセキュリティ保護要件を適切に処理することはできません。したがって、組織は多層防御アプローチでセキュリティ コントロールを組み合わせて使用する必要があります。
セキュリティ ポスチャーをモニタリングして継続的に改善する。組織は、さまざまな環境でセキュリティ上の脅威と脆弱性をモニタリングする必要があります。また、セキュリティ ポスチャーを継続的に改善する必要があります。
クラウド セキュリティ ポスチャー管理（CSPM）を使用して、セキュリティの構成ミスやサイバーセキュリティの脅威を特定して修正することを検討する。CSPM は、ハイブリッド環境とマルチクラウド環境全体の脆弱性評価も提供します。
Security Command Center は、Google Cloud に組み込まれたセキュリティおよびリスク管理ソリューションで、構成ミスや脆弱性などの特定に役立ちます。Security Health Analytics は、マネージド脆弱性評価スキャンツールです。これは、Google Cloud 環境のセキュリティ リスクと脆弱性を特定し、それらを修正するための推奨事項を提供する Security Command Center の機能です。
Mandiant Attack Surface Management for Google Cloud を使用すると、マルチクラウド環境またはハイブリッド クラウド環境のアセットをより詳細に把握できます。複数のクラウド プロバイダ、DNS、拡大された外部攻撃対象からアセットを自動的に検出し、企業がエコシステムをより深く理解できるようにします。この情報を使用して、最もリスクの高い脆弱性とリスクに優先順位を付けます。
- クラウド セキュリティ情報およびイベント管理（SIEM）ソリューション: ハイブリッド環境とマルチクラウド環境からセキュリティ ログを収集して分析し、脅威を検出して対応できます。Google Cloud の Google Security Operations SIEM は、すべてのセキュリティ データを 1 か所で収集、分析、検出、調査することで、セキュリティ情報とイベント管理を実現します。