AWS移行の基本（移行計画）
今月から配属先のチームが変わって、社内システムのAWS移行のチームに配属になりました。
元々AWSの移行をやっていたわけでもなく、IaaSとして構築したことがあるくらいのレベルなので、打ち合わせとかも全然よくわからんのです。。。
このままではいかん、ということでAWSの移行の基本的なところから勉強をし直しています。
とりあえずは今週1週間で得たことをつらつらと書いていくので、同じような立場にある人や、今後AWSへの移行を考えている人の参考になればと思います。
(書いていて気付いたのですが、noteよりもqiitaの方がまとめやすいので、詳しくはそっちでも書こうと思います。)
まず、移行で考えるべきステップは以下の3つ
・計画
・移行
・運用
まず計画のフェーズですが、以下の観点で進めていきます。
・AWS移行の目的
・移行対象の整理
・移行方式の整理
・やらないことを整理
この中でも特に重要なのが、移行の目的です。
移行すること、が目的ではなくビジネス観点でのメリットを享受することが目的です。
例えば、「TCOを何%削減する」「運用コストを何%削減する」「データセンターを統廃合する」などがそれにあたります。
この目的が明確でないと、ただ移行することに焦点が当たってしまい、結果的にランニングコストが高くなってしまう、というクラウドのメリットを享受できなくなってしまいます。
なので、しっかりと目的を決めてKPIを決めることが重要です。
次に、対象の整理です。
サーバー一覧、システム一覧のようなものが必要です。
また、関連システムの有無や移行コスト(難易度)についても精査して
今回の移行対象とするかどうかを選別していきます。
例えばOSやミドルのライセンス切れが近づいているものや
関連システムの少ないほとんど独立しているようなシステムは優先度が高いので移行対象として良いです。
反面、関連システムが多いもの(基幹システム)については難易度も高いので、今回のスコープに含めるのかどうかは協議が必要になってきます。
移行の対象が決まったら、次は方式の判定です。
AWSの移行には6つのRと呼ばれる移行方式があります。
・Rehost ・・・単純移行
・Replatform ・・・アーキテクチャはそのままで、マネージドサービスを活用(RDS、ELBなど)
・Refactor ・・・コンテナ、マイクロサービス、サーバレスなどアーキテクチャから再設計してクラウドネイティブに作り変える
・Repurchase ・・・SaaSに置き換える
・Retain ・・・クラウド移行せず、オンプレに残す
・Retire ・・・システムを廃止する
それぞれのシステムごとに上記の観点で移行方式を判定していきます。
移行の難易度として、以下のようになります。
難易度高 Refactor ＞ Replatform ＞ Rehost 難易度低
例えばオンプレでHWの保守切れが間近で、OSやアプリのバージョンアップをしている余裕がない時などはRehostを採用したり、
RDSにすることで運用コストを削減できそうであれば、Replatformを採用したり、
処理が夜間バッチなど定型的なものしか動かないのであれば、サーバーレスに作り変えるRefactorを採用したり、などなど観点は様々ありますが、移行方式を判定していきます。
最後に、やらないことを決めておくことです。
例えばクラウド移行するにあたって、アプリ側の改修も必要になってきます。
その際にOSのバージョンアップや機能の部分改修などもスコープに含めるかどうかなどを検討し始めてしまうと、スコープはどんどん膨れ上がってしまいます。
スコープをきっちり決めておくためにも、今回の移行としてはここはやらない、というところをはじめに決めておいた方がスムーズに進みます。
移行の考え方でよく言われるのが、リフトアンドシフトといって
まずはクラウドに持ってきてからそこからクラウド最適化を検討する、というやり方です。
一時的にコストはかかるというリスクはありますが、いきなりクラウド最適化を目指した移行よりはスケジュールを切りやすく、PJを進めやすいというメリットがあります。
とりあえずこんなところです。。。
ここまで書いたことはあくまで基本的な考え方なので、各システムの状況によって色々変わってくるので、都度ベンダーやステークホルダー含め調整が必要となってきます。
私は今自社の立場でいるので、様々な調整ごとだったり台帳の整理だったりと今までのベンダーとしての立場ではない動き方や考え方をしなければいけないので、結構苦戦しています。。。
３ヵ年での計画にはなっているので、ここでしっかりと結果と実績を残して、次につなげられるようにしていきたいと思います。
引き続きAWS関連のことはキャッチアップしてきます！