このドキュメントでは、ワークロードをクラウドに移行するための一般的で実績のあるアプローチと考慮事項を紹介します。このドキュメントは、ハイブリッドまたはマルチクラウド アーキテクチャ採用の戦略を設計するための想定される、かつ推奨されるさまざまなステップを説明しているハイブリッドとマルチクラウドのアーキテクチャ戦略を設計するのガイダンスを拡張するものです。
クラウド ファースト
パブリック クラウドの使用を開始するときは、クラウド ファーストのアプローチを取るのが一般的です。このアプローチでは、新しいワークロードをパブリック クラウドにデプロイしますが、既存のワークロードの場所はそのままになります。このケースでは、プライベート コンピューティング環境への従来どおりのデプロイを検討するのは、技術的または組織的な理由でパブリック クラウドへのデプロイが不可能である場合のみとなります。
クラウド ファースト戦略にはメリットとデメリットがあります。メリットは、将来にも目を向けていることです。新しいワークロードをモダナイズされた方法でデプロイできると同時に、既存のワークロードを移行する煩わしさを避ける（または最小限に抑える）ことができます。
クラウド ファースト アプローチには一定のメリットがありますが、採用した結果として既存のワークロードの改善や使用の機会を逃してしまう可能性があります。新しいワークロードは 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 を利用するとどのようにベスト プラクティスを活用し、リスクを低減し、コストをコントロールし、クラウドでの成功への道筋をシンプルにできるかをご紹介しています。