このアーキテクチャ ガイドでは、Google Cloud を使用したハイブリッド クラウド環境とマルチクラウド環境の計画と設計に関する実践的なガイダンスを提供します。このドキュメントは、一連の 3 つのドキュメントの 1 つ目です。ビジネスとテクノロジーの観点から、これらのアーキテクチャに関連する機会と考慮事項を検討します。また、実績のある多くのハイブリッド クラウドとマルチクラウドのアーキテクチャ パターンを分析し、説明します。
ハイブリッド クラウドとマルチクラウドのアーキテクチャ パターンのドキュメント セットは、次の部分で構成されています。
- ハイブリッド クラウドとマルチクラウドのアーキテクチャを構築する: Google Cloud でハイブリッド クラウドとマルチクラウドの設定を設計するための戦略の計画について説明します（この記事）。
- ハイブリッド クラウドとマルチクラウドのアーキテクチャ パターン: ハイブリッド クラウドとマルチクラウド戦略の一部として採用する一般的なアーキテクチャ パターンについて説明します。
- ハイブリッド クラウドとマルチクラウドの安全なネットワーキング アーキテクチャ パターン: ネットワーキングの観点から、ハイブリッド クラウドとマルチクラウドのネットワーキング アーキテクチャ パターンについて説明します。
これらのアーキテクチャに関する記事はそれぞれ個別に読むことができますが、最大限のメリットを得るには、アーキテクチャに関する決定を行う前に順番に読むことをおすすめします。
市場の需要が急速に変化する中、企業の IT 部門には、動的スケーリング、最適化されたユーザー エクスペリエンスのためのパフォーマンスの向上、セキュリティなど、さまざまな要件と期待が寄せられています。多くのエンタープライズ レベルの企業は、従来のインフラストラクチャとプロセスのみを使用しながらこうした要望や期待に応えることは困難だと感じています。IT 部門はコスト効率の改善も求められているため、データセンターや機器への追加の資本投資を正当化することは困難です。
パブリック クラウド コンピューティング機能を利用するハイブリッド クラウド戦略は、実用的なソリューションです。パブリック クラウドを使用すると、先行資本投資に伴う費用が発生することなくコンピューティング プラットフォームの容量と機能を拡張できます。
Google Cloud などのパブリック クラウドベースのソリューションを 1 つ以上既存のインフラストラクチャに追加すると、既存の投資を維持するだけでなく、1 つのクラウド ベンダーに拘束されることがなくなります。さらに、ハイブリッド戦略を採用することで、アプリケーションとプロセスをリソースの許容範囲で段階的にモダナイズできます。
アーキテクチャの決定とハイブリッド クラウドまたはマルチクラウドの戦略に関する計画を支援するために、考慮すべきいくつかの課題と設計上の考慮事項があります。このアーキテクチャ ガイドは複数のパートで構成されており、さまざまなアーキテクチャの潜在的なメリットと課題の両方に重点を置いて説明します。
ハイブリッド クラウドとマルチクラウドの概要
ワークロード、インフラストラクチャ、プロセスは企業ごとに異なるため、各ハイブリッド クラウド戦略は企業の特定のニーズに合わせる必要があります。そのため、ハイブリッド クラウドとマルチクラウドという言葉は、状況によって違う使われ方をします。
この Google Cloud アーキテクチャ ガイドのコンテキストでは、ハイブリッド クラウドという用語は、ワークロードが複数のコンピューティング環境にわたってデプロイされるアーキテクチャを指します。1 つの環境はパブリック クラウドに基づき、少なくとも 1 つはプライベート コンピューティング環境（オンプレミス データセンターやコロケーション施設など）です。
マルチクラウドという用語は、2 つ以上のパブリック CSP を組み合わせたアーキテクチャを指します。次の図に示すように、このアーキテクチャにはプライベート コンピューティング環境が含まれる場合があります（プライベート クラウド コンポーネントの使用が含まれる場合があります）。この構成をハイブリッド クラウド アーキテクチャとマルチクラウド アーキテクチャと呼びます。
作成・変更者
著者: Marwan Al Shawi | パートナー カスタマー エンジニア
その他の寄稿者:
- Saud Albazei | アプリケーション モダナイゼーション担当カスタマー エンジニア
- Anna Berenberg | エンジニアリング フェロー
- Marco Ferrari | クラウド ソリューション アーキテクト
- Victor Moreno | プロダクト マネージャー、クラウド ネットワーキング
- Johannes Passing | クラウド ソリューション アーキテクト
- Mark Schlagenhauf | テクニカル ライター、ネットワーキング
- Daniel Strebel | アプリケーション モダナイゼーション担当 EMEA ソリューション リード
- Ammett Williams | デベロッパー リレーションズ エンジニア
推進要因、考慮事項、戦略、アプローチ
このドキュメントでは、ビジネスの目標、推進要因、要件の定義とその説明を示すとともに、これらの要素がハイブリッドとマルチクラウドのアーキテクチャを構築するときの設計上の意思決定にどのように影響するかを説明します。
目標
組織は、ハイブリッドまたはマルチクラウド アーキテクチャを特定のビジネス目標達成のための恒久的なソリューションとして採用することもあれば、特定の要件（たとえばクラウドへの移行）の達成を容易にするための一時的な状態として採用することもあります。
ビジネス要件を定義するために、およびビジネス目標を達成する方法について具体的な見通しを立てるために、ビジネスに関する次の質問への答えを考えることをおすすめします。これらの質問の焦点は、お客様のビジネスに何が必要かであり、それを技術的にどう実現するかではありません。
- どのビジネスゴールが動機となって、ハイブリッドまたはマルチクラウド アーキテクチャの採用という決定に至っているのですか？
- ハイブリッドまたはマルチクラウド アーキテクチャの採用によって達成されるのは、ビジネス面と技術面のどのような目標ですか？
- これらの目標に影響を与えるビジネス推進要因は何ですか？
- 具体的なビジネス要件はどのようなものですか？
ハイブリッドやマルチクラウドのアーキテクチャに関して、エンタープライズ企業が持つビジネスゴールの例としては、オンライン販売の事業運営または市場を単一地域から拡張してその市場セグメントでのグローバル リーダーになるというものが考えられます。ビジネス目標の例としては、世界中の（または特定の地域の）ユーザーからの発注の受け付けを 6 か月以内に開始するというものが考えられます。
前述のビジネス要件と目標をサポートするための、技術面での主な目標の例としては、パブリック クラウドのグローバルな能力とサービスを使用して会社の IT インフラストラクチャとアプリケーション アーキテクチャをオンプレミスのみのモデルからハイブリッド アーキテクチャに拡張するというものが考えられます。この目標は具体的かつ測定可能であることが必要であり、これで拡張のスコープがターゲットの地域およびタイムラインとして明確に定義されます。
一般に、ハイブリッドまたはマルチクラウド アーキテクチャはそれ自体がゴールとなることはまれであり、特定のビジネス要件を満たすために設定された技術面の目標を達成するための手段となります。したがって、ハイブリッドまたはマルチクラウド アーキテクチャを適切に選択するには、最初にこれらの要件を明確にする必要があります。
重要なのは、IT プロジェクトのビジネス面の目標と技術面の目標を区別することです。ビジネス面の目標は、組織のゴールと使命に焦点を当てたものとなるようにしてください。技術面の目標では、組織のビジネス面の要件と目標の達成を可能にする技術基盤の構築に焦点を当ててください。
ビジネス推進要因は、ビジネス面の目標とゴールの達成に影響を与えます。したがって、ビジネス推進要因が明確に特定されていれば、ビジネス面の目標またはゴールを市場のニーズやトレンドに合わせて形成するのが容易になります。
次のフローチャートは、ビジネス面の推進要因、ゴール、目標、要件と、技術面の目標と要件が、相互にどのように関連しているかを示しています。
ビジネス面と技術面の推進要因
ビジネス面の推進要因が技術面の目標にどのように影響するかを考慮してください。ハイブリッド アーキテクチャを選ぶときに影響を与える、一般的なビジネス推進要因の例を次に示します。
- データ主権に関する法律および規制への留意。
- 資本的支出（CAPEX）または IT 全般の支出を、クラウド財務管理とコスト最適化の規律（たとえば FinOps）を利用して縮小する。
- CAPEX 縮小につながるシナリオがクラウド導入の推進要因となることがあります。たとえば障害復旧ソリューションをハイブリッドまたはマルチクラウドのアーキテクチャで構築することです。
- ユーザー エクスペリエンスの向上。
- 変化する市場の需要に対応するための柔軟性とアジリティの向上。
- コストとリソース消費に関する透明性の向上。
ハイブリッドまたはマルチクラウド アーキテクチャ採用へのビジネス面の推進要因を、リストにまとめて検討してください。個別に検討することは避けてください。最終的な決定は、ビジネスの優先事項のバランスに基づいて行ってください。
クラウドのメリットを認識した組織は、完全移行を決定する可能性がありますが、それには制約がないことが条件となります。制約の一例がコストであり、他にもコンプライアンスの要件としてきわめて機密性の高いデータをオンプレミスでホストすることが義務付けられている場合は、完全移行は難しくなります。
単一クラウド プロバイダ採用には多数のメリットがあり、たとえば複雑さの軽減や、サービス間の統合の組み込み、コスト最適化オプション（たとえば確約使用割引）が考えられますが、マルチクラウド アーキテクチャがビジネスにとって有益となるシナリオもあります。次に示すのは、マルチクラウド アーキテクチャ採用へのビジネス推進要因として一般的なものと、それぞれに付随する考慮事項です。
- データ主権に関する法律および規制への留意: 最も一般的なシナリオは、組織がビジネスを新たな地域または国に拡張するときにデータ ホスティングに関する新たな規制の遵守が必要であるというものです。
- すでに使用しているクラウド サービス プロバイダ（CSP）にはその国でのローカル クラウド リージョンがないという場合は、その国にローカル クラウド リージョンを持つ別の CSP を使用するのが、コンプライアンスの目的を果たすための一般的な解決策です。
- コスト縮小: コスト縮小は多くの場合、特定の技術またはアーキテクチャ採用へのビジネス推進要因として最も一般的です。ただし、マルチクラウド アーキテクチャを採用するかどうかを決定するときは、サービスのコストと想定される価格割引以外についても考えることが重要です。複数のクラウドにまたがるソリューションの構築と運用に要するコストと、既存のシステムに起因するアーキテクチャ面の制約（ある場合）を考慮に入れてください。
時には、マルチクラウド戦略に付随する潜在的な課題がメリットを上回ることもあります。マルチクラウド戦略を採用した結果、追加コストが後で発生することもあります。
マルチクラウド戦略の策定に付随する一般的な課題としては、次のものがあります。
- 管理の複雑さの増大。
- 一貫したセキュリティの維持。
- ソフトウェア環境の統合。
- クロスクラウドでの一貫したパフォーマンスと信頼性の達成。
- マルチクラウドのスキルを持つ技術チームを作るには高額のコストがかかる可能性があり、第三者企業によって管理されるものでない場合は、チームの拡張が必要になる可能性があります。
- 各 CSP のプロダクトの価格と管理ツールの管理。
- コストの可視化とダッシュボードをまとめて提供するソリューションがなければ、複数の環境にまたがるコスト管理を効率的に行うことは困難です。これに該当する場合は、可能であれば Looker のクラウドコスト管理ソリューションを使用することをおすすめします。詳細については、クラウド料金請求コスト管理を効果的に最適化するための戦略をご覧ください。
- 各 CSP 提供の独自機能の使用: マルチクラウド アーキテクチャを採用する組織は、自らの強みを活かした商品やサービスを向上させる新しいテクノロジーを追加するときに、単一クラウド プロバイダが提供する選択肢しか選べないという制限はなくなります。
- 予期しないリスクや複雑さを回避するには、どのような課題が考えられるかを実現可能性と有効性の評価を通じて明らかにしてください。これには前述の一般的な問題も含まれます。
- ベンダー ロックインの回避: エンタープライズ企業は、単一のクラウド プロバイダのみへの依存を避けることが必要になる場合もあります。マルチクラウド アプローチを採用すると、ビジネスのニーズに応じて最適なソリューションを選択できます。ただし、この決定が現実的かどうかは、次のようなさまざまな要因に左右されます。
- 技術的な依存関係
- アプリケーション間の相互運用性に関する考慮事項
- アプリケーションのリビルドまたはリファクタリングのコスト
- 技術的なスキルセット
- 一貫したセキュリティと管理性
- ビジネス クリティカルなアプリケーションの信頼性と可用性のレベル向上: シナリオによっては、マルチクラウド アーキテクチャを採用するとサービス停止時のレジリエンスを実現できます。たとえば、ある CSP の 1 つのリージョンがサービスを停止した場合に、トラフィックの宛先を同じリージョン内の別の CSP にすることができます。このシナリオは、必要な機能またはサービスを両方のクラウド プロバイダがそのリージョンでサポートしていることを前提としています。
特定の国または地域にデータ所在地に関する規制があり、センシティブ データ（たとえば個人を特定できる情報）をその場所の中に保存することが義務付けられている場合は、マルチクラウド アプローチを採用すると、規制を遵守するソリューションが実現します。サービス停止時のレジリエンスを実現するために 2 つの CSP を 1 つのリージョン内で使用することによって、規制による制限の遵守と同時に、可用性の要件にも対処することができます。
レジリエンスに関しては、マルチクラウド アーキテクチャを採用する前に次のことを明らかにしてください。
- データの移動: マルチクラウド環境内でデータが移動する頻度はどの程度ですか？
- データの移動が理由で高額のデータ転送料金が請求される可能性はありますか？
- セキュリティと管理性: セキュリティまたは管理性が複雑になる可能性はありますか？
- 機能の同等性: どちらの CSP も、選択されたリージョン内で必要な機能とサービスを提供していますか？
- 技術的なスキルセット: 技術チームはマルチクラウド アーキテクチャの管理に必要なスキルを持っていますか？
レジリエンス向上を目的とするマルチクラウド アーキテクチャ使用の実現可能性を評価するときは、これらの要素すべてを考慮してください。
マルチクラウド アーキテクチャの実現可能性を評価するときは、長期的なメリットを考慮することが重要です。たとえば、障害復旧または信頼性向上を目的としてアプリケーションを複数のクラウドにデプロイすると、短期的にはコストが増加する可能性がありますが、サービスの停止や障害を防ぐことができます。このような障害が実際に発生すれば、長期に及ぶ財務的損失や評判の低下につながる可能性があります。したがって、マルチクラウド採用の短期的なコストと長期的に期待できる価値を比較することが重要です。また、長期的に期待できる価値は、組織の規模、テクノロジーのスケール、テクノロジー ソリューションのクリティカル性、業種によって異なります。
ハイブリッドまたはマルチクラウド環境作りの成功に向けた計画を立てている組織は、Cloud Center of Excellence（COE）の構築を検討する必要があります。COE チームがパイプ役となって、組織内の各チームがビジネスに貢献する方法をクラウドへの移行時に変革することができます。COE は、組織がクラウドの導入に要する時間を短縮し、標準化を推進し、組織のビジネス戦略とクラウド投資の整合性をより強固に維持するための方法の一つです。
一時的な状態を作ることがハイブリッドまたはマルチクラウド アーキテクチャの目標である場合の、一般的なビジネス推進要因には次のものがあります。
- 短期プロジェクトの CAPEX または IT 全般支出の削減の必要性。
- 特定のビジネス ユースケースをサポートするインフラストラクチャを短時間でプロビジョニングする能力。次に例を示します。
- このアーキテクチャは、期間限定のプロジェクトに使用されるものです。あるプロジェクトで大規模な分散インフラストラクチャが一定の期間だけ必要となり、しかもオンプレミスにあるデータを使用したいという場合に、このようなプロジェクトをサポートするのに使用できます。
- 大企業が複数年にわたるデジタル トランスフォーメーション プロジェクトを必要としており、インフラストラクチャとアプリケーションのモダナイゼーションをビジネスの優先事項に整合させるために、ハイブリッド アーキテクチャを確立してしばらくの間使用する必要がある。
- 企業合併後に一時的なハイブリッド、マルチクラウド、または混合型のアーキテクチャを作成する必要がある。これで、新組織が新しいクラウド アーキテクチャの最終的な状態に向けた戦略を定義できます。合併する 2 社がそれぞれ別のクラウド プロバイダを使用している、あるいは一方がオンプレミスのプライベート データセンターを使用し他方がクラウドを使用しているということはよくあります。どちらの場合でも、M&A の最初のステップは IT システムの統合であることがほとんどです。
技術面の推進要因
前のセクションでは、ビジネス面の推進要因について説明しました。アーキテクチャに関する重要な意思決定の承認を得るには、ほぼすべての場合に、これらの推進要因の支持が必要になります。しかし、技術面の推進要因（その基になるのは技術的な利得のことも、制約のこともあります）も、ビジネス面の推進要因に影響を与えることがあります。場合によっては、技術面の推進要因をビジネス面の推進要因に言い換えて、それがどのようにビジネスにプラスまたはマイナスの影響を与えるかを説明することが必要になります。
次に示すのは、ハイブリッドまたはマルチクラウド アーキテクチャの採用への技術面の一般的な推進要因のうち、ごく一部のリストです。
- 高度な分析サービスや AI などの技術的能力を発展させたいが、既存の環境では実装が困難である。
- サービスの品質とパフォーマンスの向上。
- 製品化までの時間とサイクル時間の短縮を目的とする、アプリケーションのロールアウトの自動化とスピードアップ。
- 開発スピードを上げるための、ハイレベルの API とサービスの活用。
- コンピューティングとストレージのリソース プロビジョニングのスピードアップ。
- サーバーレス サービスを使用して、弾力性のある（エラスティックな）サービスと機能を短期間で大規模に構築する。
- グローバル インフラストラクチャの能力を使用して、特定の技術要件を満たすグローバルまたはマルチリージョンのアーキテクチャを構築する。
一時的なハイブリッドと一時的なマルチクラウドの両アーキテクチャに共通する技術面の推進要因として最も一般的なものは、オンプレミスからクラウドへの、または追加のクラウドへの移行を容易にすることです。一般的に、クラウド移行のほとんどは自然に、ハイブリッド クラウド セットアップに至ります。エンタープライズ企業の多くは、アプリケーションとデータの移行を体系的に、自社の優先順位に基づいて行う必要があります。同様に、短期的なセットアップの目的は、概念実証を行うために、クラウドで利用可能な高度なテクノロジーを特定の期間だけ使用するというものが考えられます。
技術的設計の決定
特定された技術面の目標とその推進要因は、ビジネス ドリブンでアーキテクチャを決定するための、およびこのガイドで説明するアーキテクチャ パターンの 1 つを選ぶための鍵となります。たとえば、特定のビジネスゴールをサポートするために企業が設定するビジネス目標の例として、3～6 か月間の研究開発業務を構築するというものがあります。この目標をサポートする主たるビジネス要件は、研究と設計に必要なテクノロジー環境を、可能な限り CAPEX を抑えて構築することです。
このケースの技術面の目標は、一時的なハイブリッド クラウド セットアップを用意することです。この技術面の目標の推進要因は、クラウドの利点であるオンデマンド価格モデルを利用して前述のビジネス要件を満たすことです。もう一つの推進要因には特定のテクノロジー要件が影響を与えており、この要件ではコンピューティング容量が高く短時間でのセットアップが可能なクラウドベースのソリューションが求められています。
Google Cloud をハイブリッドとマルチクラウドのアーキテクチャに使用する
オープンソースのソリューションを使用すると、ハイブリッドとマルチクラウドのアプローチを取り入れるのが簡単になるとともに、ベンダー ロックインを最小限に抑えることができます。ただし、次の点での複雑さが考えられるため、アーキテクチャを計画するときにこれらを考慮する必要があります。
- 相互運用性
- 管理性
- コスト
- セキュリティ
オープンソースをサポートするとともにそれに貢献しているクラウド プラットフォームを基盤として選ぶと、ハイブリッドとマルチクラウドのアーキテクチャの導入への過程を単純にできる可能性があります。オープン クラウドというアプローチを取ると、選択肢を最大限に増やすとともに、複雑さを取り除くことができます。加えて、柔軟性を特徴としている Google Cloud では、アプリケーションの移行、構築、最適化をハイブリッドとマルチクラウドの環境を横断して行うと同時にベンダー ロックインを最小限に抑え、各分野の最高水準のソリューションを使用でき、規制要件を満たすことができます。
Google はオープンソース エコシステムへの貢献が最大の参加者でもあり、オープンソース コミュニティと協力して、よく知られているオープンソース テクノロジーを開発していますが、その一つが Kubernetes です。Kubernetes をマネージド サービスとしてロールアウトすると、ハイブリッドとマルチクラウドの管理性とセキュリティにまつわる複雑さを軽減できます。
ハイブリッド クラウドとマルチクラウドの戦略を計画する
このドキュメントでは、ハイブリッド クラウドとマルチクラウドの戦略を計画する際に、事前定義されたビジネス上の考慮事項を適用する方法について説明します。推進要因、考慮事項、戦略、アプローチのガイダンスを拡張したものです。この記事では、企業がこのような戦略を計画する際に考慮すべきビジネス上の考慮事項を定義し、分析しています。
ビジョンと目標を明確にし、合意する
結論を示すと、ハイブリッド クラウドまたはマルチクラウド戦略の主な目的は、特定のビジネス目標に沿って、特定されたビジネス要件と各ビジネス ユースケースに関連する技術目標を達成することです。この目標を達成するには、次の点を考慮した、適切に構成された計画を作成します。
- 各コンピューティング環境で実行するワークロード。
- 複数のワークロードに適用するアプリケーション アーキテクチャ パターン。
- 使用するテクノロジーとネットワーキング アーキテクチャ パターン。
すべてのワークロードと要件を考慮した計画を定義することは、特に複雑な IT 環境では困難な作業です。さらに、計画の作成には時間を要するため、利害関係者同士のビジョンが競合してしまう可能性もあります。
このような状況を回避するには、まず、少なくとも次の質問に答えられるビジョン ステートメントを策定します。
- 特定のビジネス目標を達成するための対象となるビジネス ユースケースは何ですか？
- 現在のアプローチとコンピューティング環境が、ビジネス目標を達成するために不十分であるのはなぜですか？
- パブリック クラウドを使用して最適化するための主な技術的側面は何ですか？
- 新しいアプローチでビジネス目標を最適化、達成する理由と方法はどのようなものですか？
- ハイブリッド クラウドまたはマルチクラウドの設定を使用する期間はどれくらいですか？
ビジネスと技術の主要な目標と推進要因について合意し、関係者の承認を得ることで、計画プロセスの次の手順に進むための基盤を築くことができます。提案されたソリューションを組織の包括的なアーキテクチャのビジョンと効果的に調整するには、チームとこのイニシアチブを主導し、後援するステークホルダーに対して調整を行います。
その他の考慮事項を特定して明確にする
ハイブリッド クラウドまたはマルチクラウドのアーキテクチャを計画する際は、プロジェクトのアーキテクチャと運用に関する制約を特定し、合意することが重要です。
オペレーションの側面について、アーキテクチャを計画する際に考慮すべき制約を生じる可能性のある要件を以下の一覧に示します。この一覧は、すべてを網羅したものではありません。
- 複数のクラウドを個別に管理および構成する場合と、さまざまなクラウド環境を管理して保護するための包括的なモデルを構築する場合。
- 環境全体で認証、認可、監査、ポリシーの一貫性を確保する。
- 環境全体で一貫したツールとプロセスを使用して、セキュリティ、費用、最適化の機会を包括的に把握する。
- 一貫したコンプライアンスとセキュリティ標準を使用して、統合されたガバナンスを適用する。
アーキテクチャの計画の視点では、大きな制約には次のようなものがあり、多くは既存のシステムに起因します。
- アプリケーション間の依存関係
- システム間通信のパフォーマンスとレイテンシの要件
- パブリック クラウドでは使用できない可能性があるハードウェアやオペレーティング システムへの依存
- ライセンス上の制限
- マルチクラウド アーキテクチャの選択したリージョンにおける必要な機能の可用性に対する依存
ワークロードのポータビリティ、データの移動、セキュリティの側面に関するその他の考慮事項については、その他の考慮事項をご覧ください。
ハイブリッド クラウドとマルチクラウドのアーキテクチャ戦略を設計する
ビジネス要件と関連するビジネス目標と技術目標の詳細を明確にした後（理想的にはビジョン ステートメントを明確にして合意した後）、ハイブリッド クラウドまたはマルチクラウドのアーキテクチャを作成するための戦略を策定できます。
次のフローチャートは、このような戦略を構築するための論理的な手順をまとめたものです。
ハイブリッド クラウドまたはマルチクラウドのアーキテクチャの技術的な目標とニーズを決定できるように、上に示したフローチャートの手順は、ビジネスに関する要件と目標から開始されています。戦略の実装方法は、各ビジネス ユースケースの目標、推進要因、技術移行パスによって異なります。
移行プロセスは始まったばかりです。次の図は、Google Cloud に移行するで説明されているこの移行のフェーズを示しています。
このセクションでは、上の図の「評価」、「計画」、「デプロイ」、「最適化」の各フェーズについて説明します。この情報は、ハイブリッド クラウドまたはマルチクラウドへの移行のコンテキストで提示しています。移行は、Google Cloud への移行ガイドの移行パスのセクションで説明されているガイダンスとベスト プラクティスに沿って行う必要があります。これらのフェーズは、すべてのワークロードに一度に適用されるのではなく、ワークロードごとに個別に適用される場合があります。任意の時点で、複数のワークロードが異なるフェーズにある可能性があります。
評価フェーズ
評価フェーズでは、初期ワークロードの評価を行います。このフェーズでは、ビジョンと戦略の計画書に記載されている目標を考慮します。まず、パブリック クラウドにデプロイまたは移行することによってメリットを得られる可能性のあるワークロードの候補リストを特定して、移行計画を決定します。
まず、ビジネス クリティカルではなく、移行が過剰に困難ではない（他の環境に存在するワークロードに対する依存が最小限または依存していない）が、その後に行うデプロイや移行のためのブループリントの役目を果たせる標準的なワークロードを選択します。
選択するワークロードまたはアプリケーションは、ターゲットとするビジネス ユースケースまたは機能の一部で、完了後にビジネスに測定可能な効果をもたらすものであることが理想です。
移行に伴う潜在的なリスクを評価して軽減するには、移行リスクの評価を行います。移行候補のワークロードを評価して、マルチクラウド環境への移行に適しているかどうかを判断することが重要です。この評価では、次のようなアプリケーションとインフラストラクチャのさまざまな側面を評価します。
- 選択したクラウド プロバイダとのアプリケーションの互換性要件
- 料金モデル
- 選択したクラウド プロバイダが提供するセキュリティ機能
- アプリケーションの相互運用性要件
評価を実行すると、複数のクラウド環境にわたるデータのプライバシー要件、コンプライアンス要件、整合性要件、ソリューションを特定することもできます。特定したリスクは、移行または運用対象として選択したワークロードに影響する可能性があります。
既存のワークロードを評価するために、Google Cloud Migration Center などのいくつかの種類のツールがあります。詳細については、Google Cloud への移行: 評価ツールを選択するをご覧ください。
ワークロードのモダナイゼーションの観点から、適合性評価ツールは VM ワークロードを評価し、コンテナへのモダナイゼーションまたは Compute Engine への移行にワークロードが適しているかどうかを判断するのに活用できます。
計画フェーズ
計画フェーズでは、特定されたアプリケーションと必要なクラウド ワークロードから始めて、次のタスクを実行します。
- アプリケーションの移行ウェーブとパスを定義する優先順位付けされた移行戦略を策定します。
- 該当する概略的なハイブリッド クラウドまたはマルチクラウドのアプリケーション アーキテクチャ パターンを特定します。
- 選択したアプリケーション アーキテクチャ パターンをサポートするネットワーキング アーキテクチャ パターンを選択します。
理想的には、クラウド ネットワーキング パターンとランディング ゾーンの設計を組み合わせる必要があります。ランディング ゾーンの設計は、ハイブリッド クラウドとマルチクラウドのアーキテクチャ全体の重要な基盤要素として機能します。設計では、これらのパターンとのシームレスなインテグレーションが必要です。ランディング ゾーンを単独で設計しないでください。これらのネットワーキング パターンは、ランディング ゾーン設計のサブセットと考えてください。
ランディング ゾーンは、それぞれ異なるネットワーキング アーキテクチャ パターンを持つ異なるアプリケーションで構成できます。また、このフェーズでは、Google Cloud の組織、プロジェクト、リソース階層の設計を決定して、ハイブリッド クラウドまたはマルチクラウドのインテグレーションとデプロイに対してクラウド環境のランディング ゾーンを準備することが重要です。
このフェーズの一環として、次の点を考慮する必要があります。
- 移行とモダナイゼーションのアプローチを定義します。移行方法の詳細については、このガイドで後述します。また、Google Cloud に移行するの移行の種類のセクションで詳しく説明しています。
- 評価フェーズと検出フェーズの調査結果を使用します。移行する予定のワークロード候補に合わせて調整します。次に、アプリケーションの移行ウェーブプランを作成します。この計画には、評価フェーズで決定した推定リソースサイズの要件を設定する必要があります。
- 目的のハイブリッド クラウドまたはマルチクラウドのアーキテクチャの分散アプリケーション間とアプリケーション コンポーネント間の通信モデルを定義します。
- 選択したアーキテクチャ パターンに適したデプロイ アーキタイプ（ゾーン、リージョン、マルチリージョン、グローバルなど）でワークロードをデプロイします。選択したアーキタイプは、ビジネスと技術のニーズに合わせてアプリケーション固有のデプロイ アーキテクチャを構築するための基盤となります。
- 移行の測定可能な成功基準を決定し、移行の各フェーズまたは Wave について明確なマイルストーンを設定します。短期的な設定としてハイブリッド アーキテクチャを導入することが技術的な目標であっても、基準を選択することが不可欠です。
- アプリケーションがハイブリッド設定で動作する場合、特に複数の環境にコンポーネントが分散している可能性があるアプリケーションでは、アプリケーション SLA と KPI を定義します。
詳細については、適切な移行を計画し、関連するリスクを最小限に抑えることができるよう移行計画についてをご覧ください。
デプロイ フェーズ
デプロイ フェーズでは、移行戦略の実行を開始する準備が整います。考えられる要件数を考慮すると、反復的なアプローチを使用するのが適切です。
計画フェーズで開発した移行ウェーブとアプリケーション ウェーブに基づいて、ワークロードの優先順位を付けます。ハイブリッド クラウドとマルチクラウドのアーキテクチャでは、Google Cloud と他のコンピューティング環境間に必要な接続を確立してデプロイを開始します。ハイブリッド クラウドまたはマルチクラウドのアーキテクチャに必要な通信モデルを容易にするために、選択した設計とネットワーク接続の種類に基づいて、該当するネットワーキング パターンとともにデプロイします。ランディング ゾーンの設計全体の決定については、このアプローチを採用することをおすすめします。
また、定義されたアプリケーションの成功基準に基づいて、アプリケーションまたはサービスをテストして検証する必要があります。理想的には、本番環境に移行する前に、機能テストと負荷テスト（非機能）の両方の要件がこれらの基準に含まれる必要があります。
最適化フェーズ
最適化フェーズでは、デプロイをテストします。テストが完了し、アプリケーションまたはサービスが機能とパフォーマンスのキャパシティに対して期待される水準を満たしたら、本番環境に移行できます。Cloud Monitoring などのクラウド モニタリングと可視化のツールを使用すると、アプリケーションとインフラストラクチャのパフォーマンス、可用性、健全性に関する分析情報を取得し、必要に応じて最適化できます。
詳細については、Google Cloud への移行: 環境の最適化をご覧ください。 ハイブリッド クラウドまたはマルチクラウドのアーキテクチャ用にこのようなツールを設計する方法について詳しくは、ハイブリッド クラウドとマルチクラウドのモニタリングとロギングのパターンをご覧ください。
候補となるワークロードを評価する
さまざまなワークロードのコンピューティング環境の選択は、ハイブリッド クラウドとマルチクラウド戦略の成功に大きく影響します。ワークロードの配置に関する決定は、特定のビジネス目標に合わせて行う必要があります。したがって、これらの決定は、測定可能なビジネス効果を実現するターゲット ビジネス ユースケースに基づいて行う必要があります。ただし、最もビジネス クリティカルなワークロードやアプリケーションから始めることが、必ずしも必要または推奨されるわけではありません。詳細については、Google Cloud への移行ガイドの最初に移行するアプリの選択をご覧ください。
ビジネスと技術の推進要因セクションで説明したように、ハイブリッド クラウドとマルチクラウドのアーキテクチャには、さまざまなタイプの推進要因と考慮事項があります。
ハイブリッド クラウドまたはマルチクラウドのアーキテクチャのコンテキストで移行ユースケースを評価し、測定可能なビジネス効果を得る機会を探す際に、次の要因の概要リストを活用できます。
- クラウド サービスを使用して特定のビジネスに関する機能や能力を実現することにより、市場での差別化やイノベーションの可能性を高める（既存のオンプレミス データを使用して ML モデルをトレーニングする AI 機能など）。
- アプリケーションの総所有コスト節減の可能性。
- 可用性、復元力、セキュリティ、パフォーマンスの改善の可能性。例: クラウドへの障害復旧（DR）サイトの追加。
- 開発とリリースに関するプロセスの迅速化の可能性（クラウドでの開発環境とテスト環境の構築など）
移行のリスクを評価するには、次の要素を確認してください。
- 移行が原因で発生する停止による考えられる影響。
- チームがパブリック クラウドのデプロイ、または新しいクラウド プロバイダまたは 2 つ目のクラウド プロバイダのデプロイについて有している経験。
- 既存の法律上または規制上の制限に従う必要性。
移行の技術的な困難さを評価するには、次の要素を確認してください。
- アプリケーションのサイズ、複雑さ、経過期間。
- さまざまなコンピューティング環境にわたる他のアプリケーションやサービスとの依存関係の数。
- サードパーティ ライセンスによって課されている制限。
- オペレーティング システム、データベースやその他の環境構成の特定バージョンに対する依存。
初期ワークロードを評価したら、ワークロードの優先順位付けと、移行ウェーブとアプローチの定義を開始できます。次に、該当するアーキテクチャ パターンとサポートしているネットワーキング パターンを特定できます。評価は時間の経過とともに変化する可能性があるため、このステップを複数回繰り返すことが必要になる場合があります。したがって、最初にクラウドへのデプロイを行った後にワークロードを再評価することも必要です。
ハイブリッド クラウド アーキテクチャまたはマルチクラウド アーキテクチャを導入するためのアーキテクチャ アプローチ
このドキュメントでは、ワークロードをクラウドに移行するための一般的で実績のあるアプローチと考慮事項を紹介します。このドキュメントは、ハイブリッドまたはマルチクラウド アーキテクチャ採用の戦略を設計するための想定される、かつ推奨されるさまざまなステップを説明しているハイブリッドとマルチクラウドのアーキテクチャ戦略を設計するのガイダンスを拡張するものです。
クラウド ファースト
パブリック クラウドの使用を開始するときは、クラウド ファーストのアプローチを取るのが一般的です。このアプローチでは、新しいワークロードをパブリック クラウドにデプロイしますが、既存のワークロードの場所はそのままになります。このケースでは、プライベート コンピューティング環境への従来どおりのデプロイを検討するのは、技術的または組織的な理由でパブリック クラウドへのデプロイが不可能である場合のみとなります。
クラウド ファースト戦略にはメリットとデメリットがあります。メリットは、将来にも目を向けていることです。新しいワークロードをモダナイズされた方法でデプロイできると同時に、既存のワークロードを移行する煩わしさを避ける（または最小限に抑える）ことができます。
クラウド ファースト アプローチには一定のメリットがありますが、採用した結果として既存のワークロードの改善や使用の機会を逃してしまう可能性があります。新しいワークロードは IT 環境全体のごく一部にすぎず、IT の支出とパフォーマンスへの影響は限定的ということもあります。既存のワークロードの移行に時間とリソースを割り当てるほうが、新しいワークロードをクラウド環境に対応させようとすることに比べて、大幅なメリットまたはコスト節約が得られることもあります。
また、クラウド ファーストのアプローチに厳格に従おうとすると、IT 環境全体の複雑さが増すリスクもあります。このアプローチでは冗長性が生じ、環境間で過度の通信が行われることが原因のパフォーマンス低下も考えられます。また、このアプローチで作られたコンピューティング環境が、個々のワークロードには適していないものになる可能性があります。また、業界規制とデータ プライバシー関連法の遵守が理由で、機密データを保持する特定のアプリケーションの移行が制限される場合があります。
上記のリスクを考慮すると、クラウド ファースト アプローチは一部のワークロードに限定して使用するのが適切と考えられます。クラウド ファースト アプローチを使用すると、クラウドへのデプロイまたは移行から得られるメリットが最大であるワークロードに集中できます。このアプローチでは、既存のワークロードのモダナイゼーションも考慮されます。
クラウド ファーストのハイブリッド アーキテクチャを採用する一般的な例の一つは、重要なデータを保持するレガシーのアプリケーションとサービスを新しいデータまたはアプリケーションと統合する必要があるときです。この統合を完成させるには、API インターフェースを使用してレガシーのサービスをモダナイズする、ハイブリッド アーキテクチャを使用します。これでレガシーのサービスを新しいクラウド サービスとアプリケーションで使用できるようになります。Apigee などのクラウド API 管理プラットフォームを使用すると、このようなユースケースを実装するときにアプリケーションの変更を最小限に抑えるとともに、レガシー サービスにセキュリティ、分析、スケーラビリティを追加できます。
移行とモダナイゼーション
ハイブリッド マルチクラウドと IT モダナイゼーションはそれぞれ独立した概念ですが、これらの結び付きが好循環を作り出しています。パブリック クラウドを使用すると、IT ワークロードのモダナイゼーションが容易かつシンプルになります。IT ワークロードをモダナイズすると、クラウドからさらに多くの効果を引き出すことができます。
ワークロードのモダナイズの主なゴールは次のとおりです。
- 要件の変化に適応できるようにアジリティを高める。
- インフラストラクチャと運用のコストを縮小する。
- リスクを最小限に抑えるために信頼性とレジリエンスを高める。
ただし、移行プロセスですべてのアプリケーションを同時にモダナイズすることは現実的であるとは限りません。Google Cloud への移行で説明しているように、以下の移行の種類の 1 つを、または必要に応じて複数の種類の組み合わせを実装することができます。
- リホスト（リフト＆シフト）
- リプラットフォーム（リフト＆最適化）
- リファクタリング（移行と改良）
- リアーキテクト（モダナイズの継続）
- リビルド（削除して交換、リップ＆リプレースとも呼ばれます）
- リパーチェス
ハイブリッドとマルチクラウドのアーキテクチャに関する戦略的な意思決定を行うときは、戦略の実現可能性をコストと時間の観点から考えることが重要です。段階的な移行アプローチの検討をおすすめします。具体的には、最初にリフト＆シフトまたはリプラットフォームを行い、次のステップとしてリファクタリングまたはリアーキテクトを行います。一般的に、リフト＆シフトは、インフラストラクチャの観点からアプリケーションを最適化するために役立ちます。アプリケーションがクラウドで実行されるようになると、クラウド サービスの使用と統合が簡単になるため、クラウドファーストのアーキテクチャと機能を使用してさらに最適化できます。また、これらのアプリケーションは引き続き、他の環境との通信をハイブリッド ネットワーク接続を介して行うことができます。
たとえば、大規模なモノリシック VM ベースのアプリケーションをリファクタリングまたはリアーキテクトして、クラウドベースのマイクロサービス アーキテクチャに基づく複数の独立したマイクロサービスに作り替えます。この例のマイクロサービス アーキテクチャでは、Google Cloud のマネージド コンテナ サービス（Google Kubernetes Engine（GKE）や Cloud Run など）が使用されます。ただし、アプリケーションのアーキテクチャまたはインフラストラクチャが移行先のクラウド環境で現状どおりにはサポートされない場合は、このような制約を克服するために、可能であれば移行戦略のリプラットフォーム、リファクタリング、またはリアーキテクトを最初に検討することをおすすめします。
これらの移行アプローチを使用するときは、アプリケーションのモダナイズを検討してください（これが適切であり可能である場合）。モダナイゼーションを行うには、サイト信頼性エンジニアリング（SRE）または DevOps の原則の採用と実装が必要になることがあります。そのため、アプリケーションのモダナイゼーションをハイブリッド方式でプライベート環境まで拡張することも必要になる可能性があります。SRE の原則を実装するにあたってはエンジニアリングがその中心となりますが、これは技術的に克服すべき課題というよりは、変革プロセスの一つです。そのため、業務の進め方や企業文化を変えなければならなくなることがほとんどです。組織が SRE を実装するときの最初のステップは上層部の支持を得ることですが、その詳細についてはSRE を成功させるには、まず計画を立てることが大事をご覧ください。
さまざまな移行アプローチを組み合わせる
ここで説明する移行アプローチには、それぞれ長所と短所があります。ハイブリッドとマルチクラウドの戦略に従うことによる主な利点の一つは、単一のアプローチに決める必要がないことです。次の図に示すように、どのアプローチが最適かをワークロードまたはアプリケーション スタックごとに決定できます。
この概念図は、移行とモダナイゼーションのさまざまなパスまたはアプローチをさまざまなワークロードに同時に適用できることを示しています。どれを適用するかは、各ワークロードまたはアプリケーションの固有のビジネス、技術要件、目標に基づいて決まります。
加えて、同じアプリケーション スタックのコンポーネントが同じ移行アプローチまたは戦略に従う必要はありません。例:
- アプリケーションのバックエンド オンプレミス データベースはリプラットフォームして、セルフホスト MySQL から Google Cloud の Cloud SQL を使用するマネージド データベースに移行します。
- アプリケーション フロントエンドの仮想マシンはリファクタリングして、GKE Autopilot を使用してコンテナ上で実行します。この方法では、Google がクラスタ構成（ノード、スケーリング、セキュリティ、その他の事前構成された設定）を管理します。
- オンプレミスのハードウェアによるロード バランシング ソリューションとウェブ アプリケーション ファイアウォール（WAF）機能はリプレースして、Cloud Load Balancing と Google Cloud Armor に置き換えます。
次の条件が一つでも当てはまるワークロードでは、リホスト（リフト＆シフト）を選択してください。
- 環境に対する依存関係が比較的少ない。
- リファクタリングする価値はないと見なされているか、移行前のリファクタリングが現実的に可能ではない。
- サードパーティ ソフトウェアに基づいている。
次の種類のワークロードでは、リファクタリング（移行と改良）を検討してください。
- 解決しなければならない依存関係がある。
- 依存しているオペレーティング システム、ハードウェア、またはデータベース システムが、クラウドには対応していない。
- コンピューティングまたはストレージのリソースが効率的に使用されていない。
- デプロイを自動化するには、ある程度の労力が必要である。
次の種類のワークロードでは、リビルド（削除して交換）によってニーズを満たせるかどうかを検討してください。
- 現在の要件を満たせなくなっている。
- ビジネス要件を損なうことなく、同様の機能を提供する他のアプリケーションと統合できる。
- サードパーティのテクノロジーに基づいているが、そのテクノロジーがすでにサポート終了となっている。
- 支払いが必要なサードパーティ ライセンス料の金額が経済的ではなくなった。
高速移行プログラムのページでは、Google Cloud を利用するとどのようにベスト プラクティスを活用し、リスクを低減し、コストをコントロールし、クラウドでの成功への道筋をシンプルにできるかをご紹介しています。
その他の考慮事項
このドキュメントでは、ハイブリッド クラウドとマルチクラウドのアーキテクチャ全体を形成するうえで重要な役割を果たすコア設計上の考慮事項について説明します。これらの考慮事項を特定のワークロードだけでなく、すべてのワークロードを含むソリューション アーキテクチャ全体で包括的に分析して評価します。
リファクタリング
リファクタリングによる移行では、新しい環境で機能するようにワークロードを変更するだけでなく、クラウド機能を利用できるようにワークロードを変更します。これにより、ワークロードのパフォーマンス、機能、費用、ユーザー エクスペリエンスを改善します。リファクタリング: 移行と改善で説明したように、一部のリファクタリング シナリオでは、ワークロードをクラウドに移行する前に変更を行うことができます。このリファクタリング方法には、特に長期的なターゲット アーキテクチャとしてハイブリッド アーキテクチャを構築する場合に、次のような利点があります。
- デプロイ プロセスを改善できます。
- 継続的インテグレーション / 継続的デプロイ（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 か所で収集、分析、検出、調査することで、セキュリティ情報とイベント管理を実現します。
Google Cloud を使用したハイブリッド アーキテクチャとマルチクラウド アーキテクチャを構築する: 次のステップ
- Google Cloud への移行を開始する方法について学ぶ。
- ハイブリッド クラウドとマルチクラウドの一般的なアーキテクチャ パターン、それらのパターンに最適なシナリオと適用方法について学ぶ。
- ハイブリッド クラウドとマルチクラウド アーキテクチャのネットワーキング パターンと、それらを設計する方法の詳細を確認する。
- Google Cloud でさまざまなデプロイ アーキタイプを調査、分析、比較する。
- Google Cloud のランディング ゾーンの設計について学習する。
- Google Cloud アーキテクチャ フレームワークの詳細を確認する。
- VM を Compute Engine に移行する場合のベスト プラクティスに関する説明を読む。