クラウド移行とは ― リフト&シフトと移行戦略

クラウド移行とは、自社のサーバで動いているシステムを、クラウドの上で動くように移すことです。機器の買い替えの時期や、データセンターを引き払う予定をきっかけに、移行を考えることがよくあります。移し方は1つではなく、システムをどこまで作り変えるかで選びます。

何も変えずに移せば、早く終わります。作りを大きく変えれば時間はかかりますが、クラウドの機能を多く生かせます。移さずにやめる、今は移さずに残す、という判断も移行の計画に含めます。移行の前と後の費用は、使い終えるまでの総額であるTCOで比べます。

リフト&シフトとは、アプリに手を加えずに、動かす場所だけをクラウドへ移すやり方です。移行の資料ではリホストと呼び、リフトアンドシフトとも書きます。

アプリを変えないため、作業が少なく、短い期間で移せます。多くのサーバを一度に移すときや、データセンターを早く空けたいときに選ばれます。クラウドの操作に慣れる最初の一歩として使う、という考え方もあります。

一方で、クラウドの利点は一部しか得られません。Microsoftの資料は、性能や作りに問題があるシステムをリホストしないよう勧めています。リホストでは問題が直らず、そのままクラウドへ持ち込まれるからです。

移すやり方を、作り変える度合いの小さい順に並べると、リホスト・リプラットフォーム・リファクタリングになります。これに、別の製品へ乗り換える再購入が加わります。次の図は、同じ3段の箱のうち、どこが替わるかを示しています。

リプラットフォーム

アプリのコードはほぼそのままにして、動かす基盤の一部を替えて移すやり方です。仮想マシンで動かしていたデータベースを、クラウドの管理型のデータベースへ移すのが典型的な例です。バックアップや更新の作業を事業者に任せられ、運用の手間が減ります。

リファクタリング

アプリの設計から見直し、クラウドの機能を前提に作り変えて移すやり方です。1つにまとまったアプリを機能ごとに分ければ、混む部分だけを増やせます。機能ごとに分ける作りをマイクロサービスと呼び、アプリを入れ物ごと運ぶ方式をコンテナと呼びます。

得られる効果は大きい反面、時間と費用が最もかかります。AWSの資料も、移行戦略の中で最も複雑で費用がかかるやり方としています。

再購入、リタイア、リテイン

再購入は、自社のアプリをやめて、同じ働きをするSaaSなどの製品に乗り換えるやり方です。アプリの保守を自社で抱えなくて済みますが、データの移し替えと利用者の教育が要ります。

リタイアは、使われていないシステムを移さずに止めることです。リテインは、規制や特殊な機器などの事情で、今は移さずに残すことです。どちらもクラウドへは移しませんが、移す対象を決める段階で必ず検討します。

移行のやり方の分け方と呼び方は、資料によって違います。AWSの資料は7つに分け、7Rと呼びます。Microsoftの資料は8つに分けます。

大きな違いは、作り変える部分の分け方です。AWSの「Refactor or re-architect」は、クラウドの機能を生かすように設計を変えるやり方です。Microsoftは、作り変えをコードを直すRefactor、設計を変えるRearchitect、新しく作り直すRebuildの3つに分けます。AWSの1つとMicrosoftの3つは、範囲がぴったりとは重なりません。

逆に、AWSのRelocateに当たる独立した名前は、Microsoftの分け方にありません。Relocateは、いまの基盤ごと、クラウド上の同じ種類の基盤へ移すやり方です。どちらの分け方が正しいということはなく、作り変える度合いで並べると、おおよその対応がとれます。

AWSの資料はリプラットフォームを「lift and reshape」、再購入を「drop and shop」とも呼んでいます。

やり方は、システムごとに選びます。同じ会社の中でも、あるシステムはリホストし、別のシステムはリタイアする、という組み合わせになります。選ぶときは、急ぐ度合い、かけられる費用と人手、移したあとに得たい効果を比べます。

多くのシステムを一度に移すときは、手間の少ないやり方を中心にします。AWSの資料は、大規模な移行ではリホスト・リプラットフォーム・リロケート・リタイアがよく使われるとしています。作り変えは、移行が終わってから行うよう勧めています。

Microsoftの資料によると、移行と同時に作り変えるのは、必要な技能と時間がある場合です。足りなければ、作り変えは移行のあとに回します。ただし、性能や作りに問題があるシステムは、移行と同時に作り変えるよう勧めています。

クラウドへ移さずに、自社の機器を事業者の施設に預ける置き方もあります。この置き方はホスティングとハウジングの記事で比べています。

データベースを移すときは、移し先が同じ製品か、別の製品かで作業が変わります。同じ製品どうしなら、表の定義をそのまま使えるため、データを写すことが作業の中心です。英語の資料では、同じ製品どうしの移行をhomogeneous migration、別の製品への移行をheterogeneous migrationと呼びます。

別の製品へ移すときは、表の定義やSQLの書き方が違うことがあります。そのため、データを写す前に、表の定義などを移し先の製品に合わせて変換します。アプリの中のSQLも、直す必要が出ることがあります。

アプリを止める時間を短くするには、データを写す作業を2段階に分けます。まず、アプリを動かしたまま全件を写します。次に、その間に入った変更を追いかけて、移し先に反映し続けます。差がなくなったら、アプリを短時間止めて残りの変更を反映し、アプリの接続先を移し先に切り替えます。

AWSには、データを写すAWS DMSと、表の定義を変換するAWS SCTがあります。AWSの資料は、SQL ServerをAmazon RDS for SQL Serverへ移す例を、リプラットフォームの例に挙げています。RDSの仕組みはAmazon RDSの記事で説明しています。

移行の最後には、利用者がつなぐ先を、古い環境から新しい環境へ切り替えます。切り替えの前には、新旧の環境を並べて動かし、新しい環境で結果が正しいかを確かめます。確かめ終えてから古い環境を止めます。古い環境のデータは、安全を確保したうえで残しておきます。

移したあとに自社で管理する範囲は、移し先のサービスの形で決まります。IaaSの仮想マシンへリホストした場合、OSの更新は自社の仕事として残ります。PaaSへ移せばOSは事業者が管理し、SaaSへ乗り換えればアプリも事業者が管理します。

どこまでを事業者が受け持つかは、IaaS・PaaS・SaaSの違いの記事で比べています。AWSでの分担は、責任共有モデルの記事が参考になります。やり方を選ぶときは、移したあとに誰が何を管理するかまで決めておきます。

移し先の事業者の独自機能に頼るほど、その事業者から別の場所へ移しにくくなります。この状態の原因と減らし方は、マルチクラウドとベンダーロックインの記事にまとめました。

• AWS Prescriptive Guidance「About the migration strategies」（7R の各戦略と、大規模な移行での選び方）
• Microsoft Learn「Select your cloud migration strategies」（Cloud Adoption Framework の8つの移行戦略）
• AWS Database Migration Service User Guide「How AWS DMS works」（全件の複写、変更の反映、切り替えの流れ）
• NIST Special Publication 800-145「The NIST Definition of Cloud Computing」（IaaS・PaaS・SaaS で利用者が管理する範囲）