移行の考え方｜基礎を学ぶ

このレッスンを終えると、オンプレミスからクラウドへ移す戦略の類型を挙げ、要件の文からどれを選ぶべきかを判断できるようになります。

自分でサーバーを1台建てるなら

自分で建てたサーバーが社内に10台あるとします。これをクラウドへ移すとき、10台すべてに同じことをするわけではありません。実際には次のような判断が混ざります。

とにかく同じ構成のまま動けばよいサーバーがある
データベースだけはマネージドサービスに任せたいサーバーがある
使っているソフトを、業者が売っている月額サービスに乗り換えたほうが早いものがある
作りが古すぎて、いっそ書き直したほうが安いものがある
誰も使っていないので、この機会に消せるものがある
契約や規制の都合で、当面は動かせないものがある

この判断の型に名前を付けたものが、移行戦略です。AWS では代表的な7つを頭文字の R で並べて 7R と呼びます。

7つの移行戦略

戦略	何をするか	選ぶ場面
Rehost (リホスト)	構成を変えずにそのまま移す。リフト・アンド・シフトとも呼ぶ	期限が近く、まず移すことを優先したい
Replatform (リプラットフォーム)	作りは変えず一部だけマネージドに置き換える	データベースだけ運用から手を離したい
Repurchase (リパーチェス)	別の製品、多くは SaaS に買い替える	自前の業務ソフトをやめて市販品にしたい
Refactor (リファクタ、再設計)	アプリを作り直してクラウド向けにする	今の作りでは要件を満たせず、投資に見合う
Retire (リタイア)	使われていないので廃止する	棚卸しで利用者がいないと分かった
Retain (リテイン)	当面そのまま残す	規制や契約の都合で今は動かせない
Relocate (リロケート)	基盤ごと移す。仮想環境を別基盤へ移す形	仮想化基盤をまとめて移したい

7つのうち Retire と Retain は「移さない」判断だという点が見落とされがちです。移行計画の最初にやるのは棚卸しで、消せるものを消し、動かせないものを外してから、残りに戦略を割り当てます。

移行の進め方

移行はふつう3段階で語られます。評価 (現状の棚卸しと費用の試算)、準備 (足りない体制と技術の整備)、移行と最新化 (実際に移して作り直す) です。この考え方の枠組みとして AWS クラウド導入フレームワーク (AWS CAF) があり、ビジネス・人材・ガバナンス・プラットフォーム・セキュリティ・オペレーションという観点で準備状況を点検します。技術だけでなく、人と組織の準備も対象に入っている点が特徴です。

移行を助けるサービスも押さえておきます。手元のサーバーをそのまま移すなら AWS Application Migration Service、データベースを移すなら AWS Database Migration Service (DMS) です。回線では現実的でない大量のデータを運ぶには、物理的な装置でデータを持ち込む AWS Snowball 系のサービスがあります。

試験ではこう出る

「期限が迫っており、変更を最小限にしてまず移したい」→ Rehost
「アプリはそのままだが、データベースの運用から手を離したい」→ Replatform
「自社で保守している業務ソフトをやめ、市販の SaaS に乗り換える」→ Repurchase
「監視したところ、そのサーバーには誰もアクセスしていなかった」→ Retire
「契約上、来年までは現行環境を維持しなければならない」→ Retain
「回線では何か月もかかる量のデータを移したい」→ Snowball 系で物理的に運ぶ
「移行に向けて組織や人材の準備状況を点検したい」→ AWS CAF

引っ掛かりやすいのは Rehost と Replatform の境目です。「一切変更しない」なら Rehost、「一部だけマネージドに差し替える」なら Replatform と読み分けてください。

まとめ

移行戦略の代表は 7R です。うち Retire と Retain は移さない判断です
変更なしで移すのが Rehost、一部だけマネージド化するのが Replatform です
SaaS への乗り換えは Repurchase、作り直しは Refactor です
進め方は評価・準備・移行と最新化の3段階で、AWS CAF が観点を与えます
大量データの持ち込みには Snowball 系、データベースの移行には DMS を使います