クラウド間の移行に必要な 7 つの重要なステップ

企業のビジネスがクラウド プラットフォーム間で移行する場合、少なくとも短期的には、製品やテクノロジーよりも計画とプロセスが重要になります。

ほとんどの組織のクラウド コンピューティング戦略は、オンプレミスとパブリック クラウドの展開の単純な選択を超えています。代わりに、企業は、アプリケーションをクラウド間で移動したり、異なるクラウドに存在するシステムとサービスの組み合わせとして移動したりできるマルチクラウド アプローチをますます求めるようになっています。

[[267900]]

これは多くの組織がまだ完全に達成していない野心的な目標です。代わりに、多くの企業はこれまで、クラウド プラットフォーム間の移行を可能にするプロセスとテクノロジーの簡素化に主に重点を置いてきました。

ビジネスをあるクラウド プラットフォームから別のクラウド プラットフォームに移行する前に、あらゆる状況に当てはまる一般的なプロジェクト管理と計画の考慮事項を理解することが重要です。戦略を構築し、移行を実行するのに役立つ 7 つの重要なステップを以下に示します。

1. 目標を決める

クラウド プラットフォームを使用する動機は組織によって異なります。より堅牢な分散型災害復旧 (DR) およびビジネス継続性環境の構築を目指す企業もあれば、ソフトウェア開発およびテスト インフラストラクチャを求める企業もあります。特定のシナリオとクラウド コンピューティングの目標によって、移行の対象、方法、時期が左右されます。

2. 環境を評価する

アプリケーションとデータ資産を評価することは不可欠です。評価では通常、自動化されたソフトウェアを使用して、アプリケーションとデータ、および関連するシステム構成とライセンスを検出し、インベントリを作成します。また、アプリケーションとデータ ソース間の接続と依存関係を検出する必要もあります。その結果、クラウド移行を実装するための戦術的な計画が作成されます。

3. データとアプリケーションを特定して準備する

データとメタデータの取得と準備は、移行前のプロセスの重要な部分になります。そのタスクには、ネットワーク アドレス指定、CPU 仕様、メモリ、ストレージなどのインフラストラクチャ構成の詳細をキャプチャすることが含まれます。データの準備では、ユーザーはボリュームと仮想マシンまたはコンテナ イメージのスナップショットを作成し、データベース作業を複製する準備をする必要があります。

4. 移行を実行する

企業は、直接接続や VPN 経由のネットワーク転送、リムーバブル ハード ディスク経由の一括転送など、さまざまな方法でクラウド コンピューティング環境にデータをコピーできます。その他のオプションには、VMware などの特定のインフラストラクチャの災害復旧環境を自動的に作成するように設計されたパッケージ ソフトウェアやサービスが含まれます。

5. ターゲットクラウドインフラストラクチャを構成する

これは大変な仕事です。企業は、移行されたアプリケーションとデータをホストするために必要なクラウド コンピューティング インフラストラクチャとサービスを作成します。これには、仮想マシン、ストレージ ボリューム、ネットワーク、データベース、ロード バランサー、アクセス管理などの設定が含まれます。

6. 新しい環境をテストして最適化する

組織がワークロードを本番環境に移行する前に、新しいクラウド コンピューティング環境をさまざまな負荷とストレスの条件下で徹底的にテストし、許容できるパフォーマンスを提供できるように最適化する必要があります。テストには、冗長システムやリソース（存在する場合）の有効性を判断するためのさまざまな障害条件も含める必要があります。

7. ワークロードを新しい環境に切り替える

最後のステップは、ワークロードを新しいプラットフォームに切り替えて移行することです。他の移行イベントと同様に、ダウンタイムが発生する可能性があるため、この移行は営業時間外や需要の少ない時間帯に行うのが最適です。レプリケーション プロセス以降に追加されたデータを取得するには、データベースを再構築する必要があることがよくあります。

移行計画

今日では、クラウド コンピューティング ユーザーの数だけクラウド移行シナリオが存在します。ただし、最も一般的なクラウド間移行方法は次のとおりです。

• 再ホスト/置換: リフト アンド シフトとも呼ばれるこのアプローチでは、通常、オンプレミスからクラウド プラットフォームにアプリケーションを移行します。クラウド プラットフォームの再プラットフォーム化モデルでは、企業はデータベースやコンテナ クラスター管理システムなどのクラウドベースのサービスを置き換えますが、これには再ホスティングよりも若干多くの変更が必要になります。
• 買戻し: ビジネスを別のクラウド プラットフォームに移行する場合、企業は商品を買い戻したり、直接購入したりできます。同等の SaaS 製品の代わりに、コモディティ サービス (電子メールや ERP システムなど) を提供する自己管理システムを導入します。
• リファクタリングと再構築: これは、マネージド コンテナ サービスに移行する前にアプリケーションをコンテナにパッケージ化するという単純なものから、クラウド ネイティブ サービス、コンテナ、サーバーレス関数を中心にアプリケーションを再設計するという包括的なものまでさまざまです。
• 維持または廃止: 目標設定と評価のフェーズでは、特定の IT システムが機能的に時代遅れであるか、十分に活用されていないか、移行できないことが認識されます。

クラウドに依存しないハイブリッドインフラストラクチャスタック

場合によっては、再設計アプローチにより、企業はインフラストラクチャの戦略的見直しを実施することになります。多くの場合、企業は、ほとんどまたはまったく変更を必要とせず、複数のクラウド プラットフォームに展開できるソフトウェア スタックを望んでいます。いくつかの大手 IT ベンダーは、ハイブリッドまたはマルチクラウド エンタープライズ環境向けの基盤となる製品とサービスを通じて、このますます一般的になりつつある目標に取り組んでいます。最も重要なものは次のとおりです。

• マイクロソフト Azure スタック
• Google Cloud の Anthos
• AWS アウトポスト
• AWS 上の VMware クラウド
• Cloud Foundry や Red Hat OpenShift などのコンテナベースのマルチクラウド PaaS

マルチクラウドの課題と制限

アプリケーションをオンプレミスから単一のクラウド プロバイダーに移行すると、価値の高いサービスの世界が開かれますが、クラウド間の移行 (ロックインの懸念のためか、高可用性の要望のためかに関係なく) には、より注意が必要です。クラウド間の移行には、最も基本的なインフラストラクチャ サービスに対応してクラウド固有の機能を犠牲にするか、または別の形式のロックイン、つまり VMware や Cloud Foundry などのマルチクラウド スタックを採用する必要があります。