このドキュメントでは、ハイブリッド クラウドとマルチクラウドの戦略を計画する際に、事前定義されたビジネス上の考慮事項を適用する方法について説明します。推進要因、考慮事項、戦略、アプローチのガイダンスを拡張したものです。この記事では、企業がこのような戦略を計画する際に考慮すべきビジネス上の考慮事項を定義し、分析しています。
ビジョンと目標を明確にし、合意する
結論を示すと、ハイブリッド クラウドまたはマルチクラウド戦略の主な目的は、特定のビジネス目標に沿って、特定されたビジネス要件と各ビジネス ユースケースに関連する技術目標を達成することです。この目標を達成するには、次の点を考慮した、適切に構成された計画を作成します。
- 各コンピューティング環境で実行するワークロード。
- 複数のワークロードに適用するアプリケーション アーキテクチャ パターン。
- 使用するテクノロジーとネットワーキング アーキテクチャ パターン。
すべてのワークロードと要件を考慮した計画を定義することは、特に複雑な 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 つ目のクラウド プロバイダのデプロイについて有している経験。
- 既存の法律上または規制上の制限に従う必要性。
移行の技術的な困難さを評価するには、次の要素を確認してください。
- アプリケーションのサイズ、複雑さ、経過期間。
- さまざまなコンピューティング環境にわたる他のアプリケーションやサービスとの依存関係の数。
- サードパーティ ライセンスによって課されている制限。
- オペレーティング システム、データベースやその他の環境構成の特定バージョンに対する依存。
初期ワークロードを評価したら、ワークロードの優先順位付けと、移行ウェーブとアプローチの定義を開始できます。次に、該当するアーキテクチャ パターンとサポートしているネットワーキング パターンを特定できます。評価は時間の経過とともに変化する可能性があるため、このステップを複数回繰り返すことが必要になる場合があります。したがって、最初にクラウドへのデプロイを行った後にワークロードを再評価することも必要です。