この記事は更新から24ヶ月以上経過しているため、最新の情報を別途確認することを推奨いたします。

前回の記事ではCloud Adoption Framework(以下CAF)のライフサイクルの”準備”について以下の内容を記載しました。

1.Azureセットアップガイドの確認
2.ランディングゾーンの選択
3.ランディングゾーンの展開
4.ランディングゾーン変更の検証

次に実施する”導入”では、オンプレミスの資産をクラウドに移す”移行”とクラウド上で新規に開発を行う”イノベーション”の２つのフェーズがありますが、今回の記事では”移行”について記載します。

これまでの戦略・計画・準備の内容を踏まえて、CAFにおける移行の原則について概要を記載します。具体的な移行の作業手順ではありませんので、ご了承ください。
詳細についてはこちらの公式ドキュメントをご確認ください。

移行とは

CAFにおける移行プロセスではワークロードをクラウドに移行します。ワークロードを構成する各資産は合理化の5Rで説明されている移行方式のうち一つが使用されます。移行を成功させるにはここで決定した移行方式は戦略にて定義した同期と一致している必要があります。さらにビジネス成果と整合していると最も成功した移行と言えます。

ワークロードを移行するために必要な作業

移行作業は各ワークロードにつき ①ワークロードの評価 ②ワークロードのデプロイ ③ワークロードのリリース の３つに分類されます。1つのワークロードを移行するためにこの3つの作業を実施して、次のワークロードの移行を行うといったように反復して移行作業を実施していきます。

次の図は公式ドキュメントの移行作業のイメージ図です。

CAFでは上記のプロセスに則り移行を行うための簡略化されたガイドとしてAzure移行ガイドが提供されています。以下にこのガイドを参考にワークロードの評価、デプロイ、リリースについてもう少し詳しく解説をします。
なおAzure移行ガイドは複雑ではない最小限に限られた範囲の作業に焦点があてられたものとなります。条件についてはこちらをご確認の上、条件に該当しない場合にはベストプラクティスを参照するように案内されています。

ワークロードの評価

移行を行う前にワークロードを評価して前提条件を満たしているか確認する必要があります。ワークロードを構成するすべての資産がクラウドと互換性があるわけではなく、またクラウドに移行することで必ずしもメリットを得られるわけでないためです。Azure移行ガイドではこういった評価を行うツールとしてAzure Migrateが紹介されています。Azure Migrateを利用することでオンプレミスのインフラストラクチャ、アプリケーション、データが評価され次のような情報が得られます。

• オンプレミス資産の移行の適合性の評価
• パフォーマンスベースのサイジング
• オンプレミスの試算をAzureで実行する場合のコスト
  
  

ワークロードのデプロイ

評価の結果を元に環境を移行していきます。Azure移行ガイドではWindows サーバー・SQL Server・Linux及びオープンソースデータベース等のサーバー用途に沿った移行方法や、ASP.NET・PHP Webアプリ・Javaアプリ等のアプリケーションの移行方法が紹介されています。
移行を行うには環境によって適切なツールを選定する必要があります。まずはAzure移行ガイドで紹介されているネイティブツールで移行可能かを確認することを推奨します。移行ツールの選定にはこちらの移行つーつ決定ガイドも参照してください。

ワークロードのリリース

Azureへのデプロイが完了したら、テスト、最適化を実施し、ワークロードを実際にリリースします。リリースでは、次の３点を常に確認します。

1. サービスの最適化
   たとえば、”再ホスト” 移行を実行した後、サービスが Azure 上で実行されている場合は、ソリューション構成や消費されるサービスを再検討し、可能であれば何らかの “リファクタリング” を実行してソリューションの機能を最新化して向上することができます。
   
   
2. コスト分析
   継続的なコスト分析とレビューを実行することが重要です。 この作業は、コストとワークロードのバランスを取るために必要な場合に、リソースのサイズを変更する機会になります。
   
   
3. 資産の適切なサイジング
   各サービスの使用状況のメトリックを確認し、サービスの適切なサイジングを行います。また、必要に応じてメトリックの分析を行い、サービスのパフォーマンスを管理します。
   
   

段階的な移行

移行は各ワークロードにつき3つの作業を行う反復作業であることを先ほど記載しました。

図では1つのイテレーション(内側の枠)にワークロードの評価・デプロイ・リリースのすべてが収まっていますが、実際にはワークロードの規模や複雑さに応じて通常2週間のイテレーションの中で移行できるワークロードの数は異なります。ワークロードが小規模であれば2~3のワークロードを移行が完了しますが、ワークロードが複雑な場合には1つのワークロードの移行完了に2週間のイテレーションが複数回必要になる場合があります。

最初に移行するワークロードは複雑ではないものを選択することがCAFでは推奨されています。移行プロセスが洗練し改善されていくにつれてより多くのワークロードを含む移行にします。

移行作業を取り囲んでいる移行ウェーブはワークロードの最小コレクションとなります。クラウド導入チームが移行作業に取り組む間にクラウドガバナンスチームはその次に行われる移行ウェーブを計画することに注力します。
※クラウド導入チーム、ガバナンスチームについては計画の記事内の組織配置を参照してください。

おわりに

この記事ではオンプレミスからクラウドへの移行に必要な3つの作業と、クラウド移行後にIT資産を最新化し続ける移行ウェーブの反復について概要を説明致しました。