クラウド導入フレームワークにおけるクラウド移行

エンタープライズ規模のクラウド導入計画には、新しいビジネス ロジックの開発に大きな投資を行う価値のないワークロードが含まれてます。 そのようなワークロードは、リフト アンド シフト、リフト アンド オプティマイズ、モダナイズなど、さまざまな方法でクラウドに移すことができます。 そのいずれも仮想マシンの移行とみなされます。

リフト アンド シフト アプローチの概要については、次のビデオをご覧ください。

次の演習は、そのようなワークロードを評価、移行、最適化、セキュリティ保護、管理するための反復プロセスの構築に役立ちます。

クラウド導入ライフサイクルのこのフェーズを準備するために、次の手順が推奨されます。

	最初のワークロードを移行する:「Azure 移行ガイド」を使用して、Azure のネイティブ ツールと移行アプローチについて理解を深めてください。
	移行シナリオ: その他の移行ツールとアプローチを使用して、その他の移行シナリオに対処します。
	ベスト プラクティス:一貫したベスト プラクティスの適用によって、移行の一般的なニーズに対処します。
	プロセス改善:移行はプロセス負荷の高い行為です。 移行作業の増加に応じて、これらのプロセス改善を使用して、移行のさまざまな側面を評価し、成熟させてください。

移行手法と上記の手順は、次の前提に基づいています。

• 移行のスプリントが移行の段階またはリリースの中で適合する手法。 計画、準備完了、導入の各手法を使用して、移行の段階またはリリースを定義します。 各移行スプリント内で、ワークロードのバッチがクラウドに移行されます。
• ワークロードを移行する前に、短期的なクラウド導入計画のニーズを満たすために、少なくとも 1 つのランディング ゾーンが識別、構成、デプロイされています。
• 移行は、通常、"リフト アンド シフト" または "再ホスト" と いう用語に関連しています。 この手法と上記の手順は、純粋な再ホスト アプローチを使用してデータセンターを移行しない (移行するワークロードはわずかである) という信念を基に構築されています。 多くのワークロードを再ホストできますが、お客様は多くの場合、各ワークロード内の特定の資産を最新化することを選択します。 この反復プロセスでは、速度と最新化のバランスが共通の論点となります。

移行作業

ワークロードを移行するために必要なアクションは、一般に各ワークロードにつき、ワークロードの評価、ワークロードのデプロイ、ワークロードのリリースの 3 つの作業 (フェーズ) に分類されます。 クラウド導入フレームワークのこのセクションでは、ワークロードを運用環境に移行するために必要な各フェーズからのリターンを最大化する方法について説明します。

2 週間の標準のイテレーションの中で、経験豊富な移行チームは、複雑さが低いまたは中程度の 2 つから 5 つのワークロードについて、このプロセスを完了できます。 SAP などのより複雑なワークロードでは、1 つのワークロードの移行作業の 3 つのフェーズすべてを完了するのに、2 週間のイテレーションが複数回必要になる場合があります。 経験と複雑さは両方とも、タイムラインと移行速度に大きな影響を与えます。

次の箇条書きは、このプロセス (上図) の各フェーズの概要を示しています。

• ワークロードの評価: コスト、最新化、デプロイ ツールを評価するためのワークロードを評価します。 このプロセスは、前提条件の検証または批評に焦点を当てています。 これらの前提条件は、検出と評価の際に、合理化のオプションについて詳しく調べることで確立します。 また、このプロセスは、移行後のワークロードで技術的な成功を確実に収められるよう、ユーザー パターンと依存関係をより詳しく調査する場合にも使用されます。

  包括的な評価の完了に関する簡単な概要については、このビデオをご覧ください。

  
  

• ワークロードのデプロイ: ワークロードを評価した後、既存のワークロード機能がクラウドで複製または強化されます。 この複製には、クラウドへの "リフト アンド シフト" や "再ホスト" が伴う場合があります。 しかし、より一般的には、このフェーズの間に、これらのワークロードをサポートする資産の多くがクラウドの利点を活用できるように最新化されます。

• ワークロードのリリース: 機能がクラウドに複製されると、継続的な運用のためにワークロードをテスト、最適化、文書化、リリースできます。 このプロセスでは、移行されたワークロードを確認し、それらを引き継ぐことが重要です。 この作業は、継続的なワークロードのサポートのために、ガバナンス、運用管理、およびセキュリティのチームにとって重要です。

注意

移行作業の初期のイテレーションでは、スコープを 1 つのワークロードに制限するのが一般的です。 このアプローチにより、スキルのリテンション期間が最大化されるので、チームはより多くの時間をかけて実験して学ぶことができます。

注意

移行ファクトリを構築する際、チームによっては上記のフェーズを複数のチームやスプリントにわたって分散することを選択する場合があります。 このアプローチにより、再現性を高め、移行作業を高速化できます。

移行ウェーブと反復的な変更管理

移行のイテレーションでは、資産とワークロードを移行することによって技術的価値を提供します。 移行ウェーブとは、測定可能なビジネス価値を提供する、ワークロードの最小のコレクションです。 各イテレーションは、完了した技術的な作業を大まかにまとめたレポートにつながる必要があります。 ただし、ビジネスの変更や戦略の計画は、一般に若干高いレベルで行われます。 クラウド導入チームが移行作業に取り組む間、クラウド戦略チームはその次に行われる 1 つか 2 つの移行ウェーブを計画することに注力します。 また、クラウド戦略チームは、ビジネス価値を実現するためのタイムラインをより把握できるように、学習メトリックとして技術的な進行状況を追跡します。 移行ウェーブはビジネスの結果、担当者、およびタイムラインを追跡するための反復的な変更管理アプローチです。

前のセクションでは、このプロセスが、クラウド導入フレームワークの計画手法、準備手法、一部の戦略手法の図で示されています。 これらの手法は、移行ウエーブの計画と管理に関するガイダンスを提供します。 これらのウェーブを管理することで、技術チームによって行われる移行作業が定義されます。

次の手順

上記の概要手順と手法に関する詳細なガイダンスは、各移行スプリント内のプロセスを改善するのに役立ちます。 Azure 移行ガイドには、最初の移行ウェーブで必要になる最も一般的なツールと方法を概説した記事が含まれています。

Azure 移行ガイド