クラウド移行の流れは待ったなし!?現場から見るAWS移行の勘所
こんにちは、きうちです。
さて、今回はお仕事の話ですが、ここ最近弊社へのお問い合わせでは、AWSへのシステム移行のご相談が増えています。
移行について
移行の規模は様々で、数台規模から始まり数百台なんて規模もあります。
対象システムも同じく様々ですが、最近の傾向としては、お客様における主要な業務システムが移行の対象として挙がってくることが多い気がしています。
少し前ですと、外部公開向けのWEBシステムであったり、業務システムでも規模が小さい一部のシステムなど、試しにAWSを利用してみたいといったような傾向があった気がします。
移行の目的は?
弊社では、お問い合わせに対して、営業とプリセールスがお話を伺いに行きます。
一言でシステム移行のご相談と言っても内容はいろいろあって、「パブリッククラウドの選定で、候補としてAWSが挙がっている」だとか、「AWSへの移行は決まっているのだけれど、初めての利用であまり知見がなく不安」だとか、当たり前ですがお客様ごとに十人十色です。
このときに気にしなければならないのは、移行の目的です。
移行はあくまで手段なので、なぜ移行しようと思ったのか、移行しなければならなくなったのか、その辺りが重要です。
なぜ重要かといえば、それが目標やゴール設定、さらには移行方式にも関わってくるからです。
AWSでは以下のような5段階の移行プロセスを設定しています。
このプロセスの中では、目的の確認は1段階目に行います。
そして、目標やゴールの設定など、移行に関する計画を立てます。
ちなみに、弊社もお客様と会話する際は、まず目的の確認や目標の認識合わせなどを行いますが、最近は以下のような目的が多いです。
- 既存のデータセンターが閉鎖(サービス終了)してしまうので、それまでにどこか別の場所に移さなければならない
- いま使っているOSのバージョンがサポート切れを迎えるので、このタイミングで移設も検討したい
前者については移行させることが必須ですが、後者については、別に移行が必須なわけではないため、何か秘められた要望がありそうなので、少しヒアリングで聞き出す必要があります。
ただ、あまりに理想を引き出しすぎてしまうと収拾がつかなくなってしまうので、うまく整理して進めることが大事です。
たまにあるのですが、せっかくの移行なのであれもやりたいこれもやりたいと要望を積み上げると、適切ではない移行戦略を選択してしまうこともあります。
移行戦略
移行の目的や目標、ゴールがある程度明確化されてきたら、次に移行戦略を検討します。
AWSでは、Gartnerの「5つのR」を踏まえた「6つのR」を定義しています。
移行と言った場合、一般的なイメージとしては「Rehost」と「Replatform」が該当するかと思われます。
「Rehost」はサーバーをそのまままるっと移行してしまう手法で、「Replatform」は移行の際に少し手を加える(OSのバージョンアップを行ったり、一部のミドルウェアをマネージドサービスに置き換えたりする)手法になります。
もちろん、クラウド製品やSaaSに置き換える「Repurchase」やアプリケーションごと刷新してしまう「Refactor」も、検討の際には選択肢として考える必要はあります。
ただ、弊社がお話を伺う範囲では、「Rehost」と「Replatform」が多いと感じています。
先に挙げた目的の例に当てはめても、データセンターのサービス終了のケースであれば、期限が決まっているので、「Rehost」でまずはAWSに移行してしまう。そして、AWS最適化はそのあとのフェーズで計画的に行えばいいと考えます。
また、OSのサポート切れのケースであれば、「Replatform」で移行するのがよいと考えます。もし対象サーバー上にデータベースが同居していたら、Amazon RDSに置き換える選択もよいかと思います。
クラスメソッドのご支援
以上のように、訪問時にヒアリングしながら、移行の道筋を立てていきます。
弊社では、以下のようなマイグレーションサービスを提供していますが、別に最初からすべてのご相談がこれに当てはまる必要はありません。
AWS環境移行(マイグレーション) | クラスメソッドのユースケース
もちろん、「移行先をどこにしようかというところから悩んでいる」、「移行の要件がまだしっかり固まっていない」、といったような状況でも、お気軽にご相談いただければ進め方のご支援もいたします。
ちなみに、半年以上検討を重ねながらご提案を行っていったお客様もいらっしゃいます。
とにかく、システム移行に悩んだら、一度お声がけください。