クラウド移行を成功させるための 12 の重要なステップ

多くの企業がさまざまな理由からワークロードをクラウドに移行しています。パブリック クラウドは、ほとんどのオンプレミス データ センターよりも拡張性に優れており、豊富なリソース、サービス、自動化により、ユーザーのニーズに柔軟に対応できます。これらのサービスにより、企業は革新的な方法でワークロードを設計できるようになり、資本集約型のハードウェアおよびソフトウェア投資から定期的な運用費用への移行も可能になります。

[[436515]]

ただし、エンタープライズ ワークロードをオンプレミスのデータ センターからクラウドに移行するプロセスは単純ではなく、慎重な計画、十分な準備、明確なプロセスが必要です。以下は、クラウド移行を成功させるために必要な主な手順の概要です。

クラウド移行の重要な12のステップ

移行の動機と目標はさまざまですが、移行プロセスは一般的に、包括的なクラウド移行チェックリストの基礎となる 12 の個別のステップに分けられます。

（１）ビジネスケースを構築する

企業が特定のワークロードを移行する必要があるのはなぜでしょうか?ワークロードをクラウドに移行すると柔軟性が向上し、クラウドをストレージ ターゲットとして使用すると利便性が向上します。企業は、コスト削減、インフラストラクチャの負担軽減、スケーラビリティ、可用性、ユーザー満足度の向上などの推進要因を理解する必要があります。

（２）正しい移行方法を決定する

おそらく、クラウド移行において最も影響力のある決定は、クラウド コンピューティングの利点を最大限に活用できるようにアプリケーションを適応させるかどうかです。組織が採用できる移行アプローチは、クラウドとワークロードに関する専門知識に応じて主に 4 つあります。

• 再ホスティング。このアプローチは、リフト アンド シフトとも呼ばれ、既存のデータとアプリケーションを変更せずにクラウド ストレージとコンピューティング リソースに再展開します。これは多くの場合、最も迅速で簡単な移行アプローチです。すべてのタイプのアプリケーションに適しているわけではありませんが、クラウドの専門知識や基盤となるコード ベースへのアクセスが最小限である場合に適しています。
• リファクタリング。このアプローチでは、基盤となるコード ベースの小さな部分を変更してワークロードを最適化し、パブリック クラウドの信頼性やパフォーマンスを向上させます。たとえば、オンプレミスのデータベースではなく、クラウドで利用可能なデータベース サービスを使用するようにワークロードを変更する場合があります。
• 改訂。企業は、より多くのクラウドネイティブ サービスを使用するために、ワークロードのコードを大幅に変更することを選択する場合があります。これには、クラウド プロバイダーのリソース、サービス、インフラストラクチャを明確かつ詳細に理解する必要があります。ただし、ワークロードの全体的な特性と機能は (理想的には) 同じままです。
• 再建。これは通常、最も複雑で要求の厳しい移行方法です。クラウド コンピューティング プロバイダーの環境で効率的に実行できるように、ワークロードを根本から再作成します。たとえば、古くなったレガシー ワークロードは、マイクロサービスなどのクラウド ネイティブ アーキテクチャを使用して再設計および再構築できます。
• 交換する。企業は、ワークロードを展開、変更、または再作成する代わりに、多くの場合 SaaS サービスとしてサードパーティ ベンダーのアプリケーションを使用するようになりました。企業はそのアプリケーションのデータのみを移行します。簡単な例として、オンプレミスのデータセンターで実行されている同じツールを展開して使用するよりも、クラウド プロバイダーのワークロード監視ユーティリティを使用する方が簡単な場合があります。

移行の選択肢はすべてかゼロかではなく、ワークロードやユースケースに応じて異なるアプローチを取ることができます。つまり、コストからアーキテクチャ上の決定まで、企業が選択したアプローチによって決まります。

（３）コストとニーズを評価する

ワークロードの現在のコストとパフォーマンス特性を明確に把握できます。オンプレミス サーバーの取得、運用、保守コストを評価します。アプリケーション パフォーマンス監視ツールを使用して、1 秒あたりのトランザクション数や帯域幅使用量などのメトリックを収集し、ワークロードのオンプレミス パフォーマンスを慎重に評価します。 IT リーダーとビジネス リーダーは、これらのコストとパフォーマンスのメトリックを、ワークロードをクラウド インフラストラクチャに移行するときに発生するメトリックと客観的に比較する必要があります。クラウド コンピューティングのコストは定期的な予算項目となり、計画が必要であることを覚えておくことが重要です。

（4）クラウドコンピューティング環境を選択する

次に、長期的なビジネスニーズを最もよく反映するターゲット環境を検討します。通常、これらはプライベート クラウド、パブリック クラウド、ハイブリッド クラウドです。

• プライベート クラウドは、企業が既存のデータ センター インフラストラクチャ内で実装および運用する小規模なクラウド プラットフォームです。これには多大な財政的および技術的な取り組みが必要であり、他の環境に見られるサービスや拡張性が不足している可能性があります。ただし、ビジネスでクラウドの柔軟性が必要でありながら、データとワークロードを完全に制御する必要がある場合は、理想的な選択肢となります。
• パブリック クラウドは通常、大規模および小規模のサードパーティ プロバイダーによって提供されるユーティリティ サービスとしてのビジネス コンピューティングです。パブリック クラウドは通常、大規模で拡張性が高く、世界規模で展開され、豊富な個別サービスを提供します。パブリック クラウド ユーザーは通常、従量課金制でこれらのサービスを使用します。
• ハイブリッド クラウドは、プライベート クラウドとパブリック クラウドの利点を組み合わせ、企業に極めて高いレベルの制御、柔軟性、拡張性を提供します。ただし、ハイブリッド クラウドを実装するには、最大限の投資とコミットメントが必要です。同様に、すでに 1 つのクラウド コンピューティング プロバイダーに精通している企業の中には、2 つ以上のクラウド コンピューティング プロバイダー間でサービスを移行する企業もあり、これをマルチクラウドと呼びます。

（５）導入モデルの選択

クラウド プラットフォームからサービスにアクセスする方法はいくつかあります。各クラウド プラットフォームは、異なるレベルの利便性とユーザー制御を提供します。

• Infrastructure as a Service (IaaS) は、サーバー、ストレージ、ネットワーク、監視など、従来のデータ センター インフラストラクチャと非常によく似たクラウド コンピューティング リソースを提供します。クラウド コンピューティング アーキテクトは、これらの要素を組み合わせて、企業のワークロードをホストするための詳細なインフラストラクチャを構築します。 IaaS は、ほとんどのクラウド移行の典型的なモデルです。
• Platform as a Service (PaaS) は通常、より高度に統合された展開環境を提供します。ハードウェアベースのリソースを超えて、データベース、開発ツール、統合レイヤー、ランタイム、および従来のオンプレミス ツールの 1 つ以上を置き換えるその他の既製コンポーネントなどのソフトウェアも含まれます。
• SaaS (Software as a Service) は、既製のアプリケーションを提供するため、企業が独自のワークロードをクラウドに展開する必要性が軽減されます。 SaaS プロバイダーは、すべてのワークロードの開発と保守を担当します。一般的な SaaS 製品には、電子メールや生産性向上アプリケーションのほか、財務や人事のワークロードが含まれます。

（6）クラウドコンピューティングパートナーを選択する

3 大パブリッククラウドプロバイダーである AWS、Google Cloud、Microsoft Azure はすべて、IaaS および一部の PaaS 展開向けのグローバル サービスを提供しています。ただし、個々のサービスや API からコストや監視まで、クラウド運用の多くの側面は大きく異なる可能性があります。企業は通常、提供されるサービスの範囲と特定のワークロードに対する特定の機能に基づいてクラウド コンピューティング プロバイダーを選択します。たとえば、AWS はさまざまなパッケージ化されたコンピューティングインスタンスを提供しており、Google Cloud は機械学習と人工知能のサービスで知られています。

プライベート クラウドの一般的なプロバイダーには、VMware、Dell EMC、IBM、Nutanix、HPE、OpenStack オープン ソース プラットフォームなどがあります。考慮すべき重要な要素としては、テクノロジーの知識、既存のシステムとの統合の容易さ、信頼性などが挙げられます。

（７）設計建築

IaaS ユーザーは、クラウド コンピューティング アーキテクトに依存して、ワークロードに最適なクラウド コンピューティング アーキテクチャを設計します。設計では通常、仮想化されたコンピューティング、ストレージ、ネットワーク インスタンスと、さまざまなサービス (データベース、ログ記録/監視ツール、イベント駆動型コンピューティングなど) が組み合わされます。

再ホストが簡単な単一のコンピューティング インスタンスとストレージ インスタンスを管理するなど、アーキテクチャはシンプルでわかりやすいものになります。このアーキテクチャは、ミッションクリティカルな運用環境向けの分散された信頼性の高いワークロードや、クラウドでマイクロサービス ワークロードをホストするための多くの関連コンポーネントをサポートする複雑な環境にもなります。クラウド アーキテクトは、目的のアーキテクチャに関連するクラウド コストも考慮し、ワークロード所有者が適切な予算を採用できるようにします。

慎重な設計には、アーキテクチャを検証し、展開および本番環境の切り替え後にワークロードが適切に機能することを確認するための広範なテストも含まれます。したがって、実際の移行/変換が行われる前に、設計には複数の反復と改良を伴う検証プロジェクトが含まれる場合があります。

企業はクラウド移行の優先順位付けに特に注意する必要があります。ほとんどのエンタープライズ ワークロードには、データベースやアプリケーション監視ツールの可用性など、1 つ以上の依存関係が伴います。クラウド アーキテクトは、実際のワークロードの移行を実行する前に、展開の全体的な範囲を考慮し、必要な依存関係をインストールして検証する必要があります。

（８）移行手順の概要

インフラストラクチャと依存関係が整えば、IT リーダーとビジネス リーダーは、移行を最初から最後まで実行するために必要な手順を詳細に説明した現実的な移行計画を作成できます。移行計画は広範囲にわたる可能性があり、次のような多くのアクションが含まれます。

• ユーザー/顧客グループに通知します。
• オンプレミスのリソースを停止してバックアップします。
• ワークロードに必要なデータを転送および同期します。
• ワークロードとそのクラウド コンピューティング インフラストラクチャの移動またはインストール。
• 完了した移行のテストと検証。
• 問い合わせに対応し、トラブルシューティングを行うためのドキュメントを準備し、ヘルプデスク スタッフのスケジュールを設定します。
• 移行されたワークロードを一部 (またはすべて) のユーザーに公開します。
• ワークロード監視を実装および実施する。
• ロールバックやリカバリを含む緊急時対応計画を策定します。

（9）移行を実行する

最終的に、企業は移行計画を実装し、ワークロード、依存関係、および関連データを準備されたクラウド コンピューティング インフラストラクチャに移動します。このプロセスには、ドメインと IP 環境の構成や、ワークロード トラフィックをクラウド ワークロードに正常に (安全に) リダイレクトできるようにするためのセキュリティ環境のセットアップなど、ネットワークの変更も含まれます。

移行イベントがスムーズに進むようにするには、慎重な計画と原理実証プロジェクトを通じて、移行プロセスを事前にテストし、検証する必要があります。同時に、予期しない問題が発生した場合に備えて、現地の IT スタッフとクラウド プロバイダーのテクニカル サポートの最新の直接連絡先情報を保持しておきます。

（10）テストの負荷

移行が完了したら、ワークロードの機能とパフォーマンスを徹底的にテストする必要があります。企業はワークロード メトリックを収集して評価し、軽減すべき脆弱性を探します。移行スタッフによる基本的なテストから開始し、移行されたワークロードをより幅広いユーザー グループに公開して、すべてのユーザーが移行されたワークロードを正常に使用できるようにします。

（11）監視と調整

移行テストとカットオーバーの後は、監視、サポート/トラブルシューティング、チューニング、改善、その他の一般的なメンテナンスなど、デプロイされたワークロードと同様に継続的なメンテナンスを実行する必要があります。これらのタスクには以下が含まれます。

• ワークロードのパフォーマンスを監視して、使用傾向を予測し、ボトルネックを特定し、トラブルシューティングをサポートします。
• 適切なセキュリティとコンプライアンスを確保するために、展開構成を定期的に確認します。
• 毎月の請求書を確認し、作業量が予算内に収まるようにします。
• 移行されたワークロードのコストとパフォーマンスを評価し、ビジネスに期待されるメリットがもたらされることを確認します。

（12）クラウドコンピューティングのスキルとトレーニングを強化する

クラウドベンダーはクラウド インフラストラクチャへの移行を簡素化するために懸命に取り組んでいますが、クラウド環境は従来のオンプレミス データ センターとはまったく異なります。最も単純な再ホスティング プロジェクトでも、直接的な 1:1 スワップが行われることはほとんどありません。あらゆるクラウド移行プロジェクトでは、特定のクラウド プロバイダーのリソース、サービス、コスト構造、プロセスを明確に理解する必要があります。移行ウィザードでは基本的な専門知識と経験に取って代わることはできません。これは次の 2 つの方法で実現されます。

まず、IT 部門とワークロード所有者の間で慎重なコミュニケーションとコラボレーションを確立し、促進します。 IT リーダーとビジネス リーダーは、クラウド移行の目標と期待されるメリットについて合意する必要があります。技術者は、ワークロードに適したクラウド コンピューティング インフラストラクチャを作成するために、関係者の要件と期待を理解する必要があります。同様に、ビジネス リーダーは、移行に関して現実的な期待と制約を持つ技術スタッフを信頼する必要があります。

次に、技術者は特定のクラウド プロバイダーのサービスと API、つまりクラウド プロバイダーが提供できるサービスとそれらのサービスを効果的に使用する方法を理解する必要があります。 AWS ソリューションアーキテクト認定などのクラウドコンピューティングプロバイダーのトレーニングを活用してください。企業は、ライブ移行を行う前に、クラウド アーキテクチャを検証するための原理実証デプロイメントを構築するためのテストと実験に投資する場合があります。一部の企業では、クラウド コンピューティング アプリケーションの経験があるクラウド アーキテクトを雇用して従業員をトレーニングすることができます。