オンプレミスからクラウド利用の流れが加速する昨今、すでにオンプレミスやホスティングの環境で稼働しているワークロードをいかに扱うかは大きな問題です。
既存のワークロードをクラウドへ移行（マイグレーション）することにより、下記のような点を解決できることが一般的に知られています。
- データセンター保守期限からの脱却
- インフラ保守運用の効率化
- コストメリット（※アーキテクチャによるところが大きい）
- セキュリティとコンプライアンス
- PaaS/サーバレスが視野に入り、さらなる効率化が狙える
ですが、クラウドへの移行には一時的な作業費用がかかります。また、内部のリソースを調達する必要があるなど、簡単な意思決定ではありません。
この記事では、総合的なPros/Consを判断しつつクラウドへのワークロード移行を進めるための大まかな4つのステップについて説明します。
また、クラウドへワークロードを移行する一般的なメリットと最近の戦略トレンドについては別の記事にまとめていますのでそちらをご覧ください。
クラウド移行に向けた4ステップ
ここからは、オンプレミスまたはホスティング環境からクラウドへの移行をゼロから始めるための道のりを4つの段階に分けて説明していきます。
ビジネスゴールの設定・企画
まずは、現行のシステムの課題や将来的に何を達成したいか、そのために費やして良いリソースと全社の課題から見た優先順位を話し合いましょう。
このとき、いきなりクラウドありきで話を進めてはいけません。課題が現行システムの改善で解決できるならそれは十分な選択肢となりますし、逆にクラウドへ移行しても課題が解決しないのであれば意味はありません。
最初の段階であるからこそ、クラウドは手段であって目的ではないと意識しておくべきでしょう。
現行システムの課題出しは中々に大変な作業です。話が発散しがちですし、役割によって懸念点も異なってくるため取りまとめにもエネルギーを使います。
しかし、頻出する課題としてはいくつかの類型があります。これらをご参考に課題を洗い出してみましょう。
これらはどれもクラウド化する前によくある課題です。言い換えれば、こうした課題を抱える企業であればクラウド化は検討するに値する
そのためにはまずクラウドの特性を知るところがスタートです。こちらの記事に基本的なところをまとめていますので、どうぞご覧ください。
移行のアセスメント
具体的に移行を検討するとなったら、次は必要な情報を収集してのアセスメント（評価）フェーズに入ります。
このフェーズは、更に細かないくつかのステップに分けることができます。
- 現行システムのサーバ情報の集約
- クラウド移行のロジックにあてはめ、各サーバの移行リスク、難易度を見積もる。あるいは破棄、塩漬けなどのアクションを割り振る
- 移行すると決めたものに関して具体的な方法を立て、移行後のコストとスケジュールを立てる
- 全体計画に基づき、実験を通じて解決したい問題をリストアップする
このフェーズでは情報の収集、整理、分析、POCのプランニングと、やるべきことが山積しています。
全体のパフォーマンスを左右する重要なフェーズですので、別の記事にて更に詳細に説明しています。あわせてこちらもご覧ください。
実証実験（POC）
アセスメントが終わり、ある程度のスケジュールと費用などの目処がたったら、本番移行をする前に実証実験（Proof of Concept、POC）をすることをオススメします。
これにはいくつかの理由があります。
- いきなり本番環境に手を入れると、ヒューマンエラーの際に取り返しがつかない
- 移行作業をしつつクラウドそのものに慣れる、あるいは詳しい人からそうでない人へのナレッジトランスファーが行える
- DBなど移行作業そのものに時間がかかるインスタンスに関しては、基本的にリードタイムを設ける必要がある
- 一時的にクラウドとオンプレミスの両系を稼働させる事により、バックアップにも転用できる
一方で、最後の理由の裏返しではありますが、POCの期間中は従来のオンプレミス環境に加えてクラウドの利用が発生するため、一時的な費用の増大は計算しておく必要があります。
一部の商用DBMSなどではコア数課金（動いているサーバCPUのコア数に応じて料金が発生する）などになっているため、特に注意が必要です。
そのため、いたずらにPOCの期間を伸ばすのではなく、アセスメントの段階で検証すべき項目とスケジュールをきちんと追い込んでおきましょう。
だらだらとPOCを続けた挙げ句、別システムのトラブルなどで人手が取られ、結局クラウド化プロジェクト自体が頓挫するケースも過去何度も目撃しています。
POCは通過点に過ぎませんので、予め終了条件を設けておくことはくれぐれも留意しましょう。
移行の実行と改善計画
アセスメントとPOCを通じて作業量とリスクは見積もりができているとは思いますが、本番作業時は思わぬトラブルがつきものです。
オンプレミスでの更新でも同じことですが、下記のような点については当日までに決定しておきましょう
- OK/NG判断の基準
- NGだった際の切り戻し手順
- 連絡方法と要因の確保
- エスカレーションフロー
また、各クラウドベンダやMSP（マネージドサービスプロバイダ、クラウドの再販や運用をするパートナー）のサポートサービスでは、有事の際の対応時間を短めに設定しているところもあります。
本番作業の予定日には、予め外部にも通達しておくべきでしょう。
そして、無事にクラウド上でシステムが稼働してもそれで終わりではありません。
オンプレミスからクラウドに移行した直後では、大抵IaaSが前提になっていると思いますが、これからはこのIaaSをクラウドネイティブな構成へ改善していくことで、更なる効率化を狙うことができます。
一度クラウド上に構築したシステムの改善については多くのドキュメントやサービスが存在しますので、ベンダと相談しながらよりクラウドの利点を活かした構成を検討してみてください。
具体的にはPaaSやサーバレスがキーワードになるでしょう。また、一方でクラウドならではの冗長化やセキュリティの保全も大切な要素になります。
まとめ
この記事では、オンプレミスやホスティングサーバからクラウドへ移行するための手順を4つのフェーズで説明しました。
最近ではクラウドのメリットも多くの人が知ることとなったため、フェーズ1などはすんなりと通ることが多い印象です。
一方で、ある程度クラウドの知識や経験のある人を起用しないとフェーズ2,3で停滞しがちです。また、中には現行サーバの情報を集める時点で苦労するような企業もかつては目にしてきました。
最初に述べたように、クラウド化はあくまで手段の一つです。効率化や改革の前にはまず腰を据えた調査と実験の段階があることを覚悟しておきましょう。
今回は以上です。お読みいただきありがとうございました。
コメント