データセンター移行の一般的なプロセス
2023年11月1日- By Hiromasa Chigusa
はじめに
皆さん、こんにちは。
昨今のDXの流れやコストに関する懸念から、今あるオンプレミスのデータセンターを、クラウド環境に代表される別の場所に移す必要性を感じている（また実際に迫られている）企業も多いと思います。
今回は、「データセンター移行って具体的に何をするの？」「どうやって進めるの？」という疑問にお答えするべく、ごくごく一般的にですが、そのプロセスについて基本的なところをご紹介したいと思います。
（※）企業の置かれている状況や業態、規模等によって、プロジェクトの形態は千差万別です。ここではあくまで一般論としての記載であること、ご理解ください。
移行プロセスの概要
データセンター移行のプロセス全体を概観すると、大きく4つに分かれます。
（「4つ」が妥当かどうかの感覚値に個人差があることは承知の上で、一旦そのように考えます）
1. 1つ目は、「今ある状況がどうなのか？」を詳しく知るための「現況評価」
2. 次に、評価の結果をもって「今後どうするか」を考える「戦略立案と計画」
3. 続いて、計画に基づいて実際にサーバー群を移行し動作確認する「移行と検証」
4. 最後に、移行後の環境をモニタリングして問題点を改善する「監視と最適化」
少し詳しく見ていきましょう。
1. 現況評価
現況評価のフェーズでは、現⾏稼働環境の詳細な状況評価を⾏います。
インフラやアプリケーションなどの具体的な資産状況に加え、表には現れにくい⾮機能⾯での要求事項も確認します。
ここでスムーズに現行のIT資産が全部出て来れば良いのですが、なかなかそうもいかないこともあります。
大体のインベントリは存在しているものの、一部欠けていたり、目的不明のサーバーがあったり、担当者がいなくなってよくわからなくなっているということも。
IT資産の正確な洗い出しのためには、ハードやソフト、また業務観点も取り入れた多角的な分析が必要になったりします。
2. 戦略立案と計画
ここでは、AWSの「7つのR」（参考情報[1]）等で表される移行方針や、移行先プラットフォームの選定をします。また移行するアプリケーションの順番や手順の決定、関連するステークホルダーの役割分担定義等を行いながら、綿密な計画を作成します。
戦略立案の部分では、移行方針の決定やプラットフォームの選定を行います。最初から「移行先はAWS」などと半ば決定しているようなケースもありますが、ビジネスゴールに沿った形で、クラウド環境だけでなく、別のオンプレミス環境に移行する、あるいは規模を縮小して留まる、というパターンも考えられます。いずれにしても、企業が重視するポイントを活かせる移行先選定が重要でしょう。
また、「何を以て成功とするか」という判断基準は、ステークホルダーによって異なる可能性もあります。成功の基準はここで明確にしておきたいものです。
計画策定の部分では、現状の構成と戦略を踏まえ、具体的な移行プランを確定させていきます。例えば、何かあったときに影響の少ない内部用アプリケーションをパイロットとして移行して様子を見てみる、開発環境などから移行する、など様々なパターンが考えられます。また、アプリケーションの相互依存関係にも注意して、慎重に移行の順番を決めていきます。リハーサルを設けて、移行時のシミュレーションを行い、本番に備える計画を立てることもあります。
3. 移行と検証
計画を立て、体制構築ができたら、いよいよサーバーを移行します。
本番ワークロードの前に、検証環境や開発環境を先行移行することがあります。ただ、その場合も本番移行まであまり時間を空けるわけにもいきません（検証環境と本番環境とでインフラの構成が違うと問題になることがあるため）。慎重に進める必要がありますが、同時にスピード感も重要です。
本番ワークロードの移行では、基本的に検証環境やリハーサルでのプロセスを踏襲します。本番環境ならではの特殊事情（冗長構成がある、長い停止時間は認められない、等）を考慮しつつ、粛々と、事前計画通りに、迅速に行うことが求められます。
移行作業後は、移行先での動作確認をします。移行データの整合性やアプリケーションの打鍵確認等を行い、問題なしと判断されれば、移行作業は終了です。
4. 監視と最適化
無事移行が終わったからと言って気は抜けません。
事前に定められた特別監視期間の間、移行先環境を注視することがあります。使用するメトリクスは一般的なものからアプリケーション固有のものまで様々ですが、「何を監視し」「問題があったときにどう動くのか」まで事前に計画しておくことが望ましいでしょう。
監視中のアラートやトラブルが想定よりも多い場合は、メトリクスの妥当性や、必要に応じて構成の見直し等も行います。
ワークロードの負荷状況やかかっているコスト等も見ながら、場合によってはリソースの追加や解放も実施していきます。
監視・最適化に終わりはありません。IT構成の「どうあるべきか」は時間と共に変化していきますので、その時々に応じて最適な構成・ソリューションを採っていくのが理想です。
おわりに
今回ご紹介したのは、あくまで極々一般的に想定されるプロセスです。冒頭でも強調しましたが、実際の移行プロジェクトは、企業の状況や業態にも依存し、進行プロセスは千差万別です。加えてデータセンターの移⾏は多くの場合、⾮常に複雑かつ⼤規模なものとなることから、開始時から完了時まで関係者間の緊密な連携や協⼒が不可⽋です。
関係者間で移行プロジェクトの特徴を理解し、最適なプロセスを実行していきましょう。
参考情報
[1]AWSウェブマガジン “builders.flash” 2020年11月掲載 マイグレーションを実現するために – 第2回：移行戦略と移行パスとは？
Rackspaceについて
Rackspace Technologyの日本国内サービスは、アイレット株式会社Global Solutions事業部より提供させていただきます。
Amazon AWSとMicrosoft Azureの導入検討のコンサルティング（勉強会）から構築、運用・保守までワンストップのクラウド支援サービスです。
お客様のご要望に柔軟に対応いたしますので、まずはお気軽にご相談ください。