AWSへの移行方法と手順～オンプレからのクラウド移行を成功に導くために～ 【2】 計画と実行

AWSのクラウド環境への移行で必要な考え方、事前準備や移行時の注意点などをお伝えする「AWSへの移行方法と手順～オンプレからのクラウド移行を成功に導くために～ 」の連載です。前回の「【1】事前調査・移行ツール」では必要な5つの手順や移行ツールをご紹介しました。今回の「計画と実行」については、計画や実行に必要な手順などのおさえておきたいポイントやTIPSをご紹介します。

連載「AWSへの移行方法と手順～オンプレからのクラウド移行を成功に導くために～ 」

【1】事前調査・移行ツール
▶【2】 計画と実行
【3】 移行本番の切り替え
【4】AWSへの移行事例

AWSへの移行の方針を決める

事前調査を行い、課題の洗い出しを行ったあとは、各システムでAWSへの移行をどう行うかの方針・計画を決めていきます。AWSへ移行する場合には主にVPC(Virtual Private Network)環境のネットワーク構成と、OSより上の層について、移行対象のシステム・データをどのように配置するかを検討していきます。

OSやミドルウェアのバージョンの問題がない限りは、EC2をベースにミドルウェアを含めたアプリケーション・データを移行する方法が分かりやすいでしょう。
RDSやElastiCacheに代表されるマネージド型のサービスを使うと、データのバックアップ、エンジンのバージョンアップ、冗長化など、EC2ベースでシステムを構築した場合には個別に検討しないといけない機能が予め用意されている、という点から移行後の運用負荷軽減が期待できます。できればマネージド型サービスを活用する方向で検討してみると良いでしょう。

サーバーの移行方針の例

以下の項目は設計を進めていく中で注意しておくと良いケースをTIPSとしてまとめています。特にAWSへの事前申請が必要なケースは設計のタイミングで必要なリソースを洗い出し、上限の緩和申請をタスクに落とせると、その後の進行がスムーズです。また、移行作業で一時的に必要になる環境やリソースの手配は見落としがちなため、注意が必要です。

AWSへのデータ移行を考える

データの移行は移行計画をたてるうえで大切なポイントです。データベースのデータやWebのコンテンツ、各種ログなどオンプレミスの環境に分散配置されているこれらデータを、いつ、どのように移行するか、を検討します。
移行しないといけないデータを最新の状態で全てAWSに移行するというのがデータ移行のゴールになりますが、システムを切り替えるとき以外にも本番と同等のデータを移行しなれければいけないタイミングがおそらく出てくるでしょう。
例えば、初期構築完了後の動作テスト、あるいはシステム切り替え作業のリハーサルでは、動作確認や作業シナリオの確認のため、本番運用中の実データとほぼ近しいものが必要になるでしょう。

データの移行を考える際には、いつ、どんなデータを、どのように移行するかという切り口で整理してみると、移行計画や移行方式を検討しやすくなるでしょう。

移行対象のデータ量も考慮事項です。例えば大量のデータを転送する必要がある場合には

• AWS Direct Connectなどの専用線を敷設
• AWS Snowballのようなデータ転送サービスを利用

など、データの配送手段も検討事項になってきます。特に回線の手配は時間がかかるため、プロジェクトの進行管理上、早めの対応が必要です。データ量によっては転送時間も少なくはないため、ここにかかる時間も考慮が必要です。

社内関係者・外部連携先との調整は綿密に

AWSへ移行する対象のシステムやサービスに外部との連携がある場合、自社から外部のシステムを参照している場合と、自社に外部からデータを参照している場合の2つのパターンがありますが、どちらも切り替えるタイミングの調整が必要です。

例えば外部からのデータ連携処理があるため特定の時間帯は止められない、メンテナンスするときは最低1ヶ月前の告知が必要など、AWSへの移行に際して時間、作業時間や日付の制限がある場合にはあらかじめ把握し、計画したうえで移行を進める必要があります。

また自社環境から外部連携先にアクセスする場合に、先方がアクセス制限をかけているケースがあります。連携テストを行いたいときに、開発環境と新しい本番環境がつながるように許可をしてもらう必要があり、先方都合でリードタイムがかかることもしばしばです。タスクとして洗い出しを行い、遅延なく移行が進められるよう調整を行いましょう。連携テストの場合は、先方で一時的に試せる検証環境を用意している場合もあるため確認をしておくことをおすすめします。

その他、人間系の業務調整もこのタイミングで合わせて調整します。社内の別部署でもコンテンツ更新を行っている場合は更新計画の確認が必要です。あるいはDNSレコードの管理を外部に委託している場合には設定変更の依頼方法やリードタイムを踏まえたうえで計画に盛り込む必要があるかもしれません。

AWSへの移行は作業セットの抽出でまとめる

全てのシステムをAWSに移行する場合でも、一斉に移行を行うことは難しいため、いくつかのセットにわけて移行します。AWSへの移行の方法を考える際に、「一連の移行作業」を「ひとまとまりで行う必要がある」単位でセットにすると計画が立てやすくなります。
一般的にはサービスもしくは業務システムが1セット単位になりますが、運用や機能拡張のタイミングでサービス同士がつながっていることも多いため、システム連携や基盤の結合度合いなどの視点で分解していく作業も必要です。

AWSへの移行作業の管理を楽にする、マイルストーン設定のコツ

複数のシステムやサービスをAWSに移行する際には、移行するひとまとまりの作業セットにわけ、この作業セットごとに同じ基準でマイルストーンを決めると全体としての見通しが立てやすくなります。

移行はイレギュラーな事態が起きやすいため、「予定通り進んでいるか」よりも「作業がどこまで終わっているのか」を把握する必要があります。同じ粒度でマイルストーンを引いておくと、作業がどこまで完了しているかが可視化しやすいため、トラブルが起きた際に作業の順番の入れ替えが検討しやすくなるためおすすめです。

もう一つのポイントは移行前と移行後の判定をマイルストーンとして定義することです。
移行前の判定では、移行対象のシステムがAWS上で動作させたときに致命的な問題がないことを確認します。移行後の判定は移行したデータの内容も含め、システムの切り替えが完了したとみなしてよいかどうかを判定します。移行前・移行後の判定をマイルストーンに組み込むことで、完了条件がより明確になるでしょう。

移行対照表を活用してタスクの洗い出しとチェックリストをつくる

現状と移行完了時に何がどう変わるのかを把握するために、設計や移行作業を行う前に移行対照表を作成し、まとめておくと便利です。
例えばIPアドレスやOSやミドルウェアなどの移行対照表を統合や破棄の記載も含めて用意します。Web系のシステムであればDNSの切り替えを行うことが多いので、いまのレコードと新しい環境のレコードを整理しておくと、移行対照表自体が当日の作業内容となります。
移行対照表をつくることで、必要な作業の洗い出しとチェックリストの役割も果たしてくれるため、管理が楽になります。

IPアドレスの対照表の例

OS/ミドルウェアの対照表の例

想定外を防ぐ、リハーサルを使ったAWSへの移行作業の準備

移行手順が一旦確立したら、移行リハーサルを検討します。移行リハーサルの目的は、段取り上のヌケモレを発見する、データ移行などのオペレーションについて、見積もりの範囲内で収まるのか、など、計画しただけでは分からない、想定外の事象を洗い出すことです。
移行リハーサルを実施時に発生した問題に対策を打つことで、移行作業の本番当日の作業精度を向上させ、安心して当日を迎えることができるでしょう。

以上が、「AWSへの移行方法と手順～オンプレからのクラウド移行を成功に導くために～ 」の「計画と実行」です。次回は、移行に便利なAWSのサービスと実際に切り替える際のポイントをご紹介します。

連載「AWSへの移行方法と手順～オンプレからのクラウド移行を成功に導くために～ 」

【1】事前調査・移行ツール
▶【2】 計画と実行
【3】 移行本番の切り替え
【4】AWSへの移行事例

AWSへ移行を検討・実施される方にオススメ！

AWS移行に役立つ資料集
これからAWSへ移行を検討・実施される方は必読
・クラウド移行ガイド
・オンプレミスからクラウド移行の成功ポイント
・AWS導入事例集
など、AWS移行に役立つ資料や成功事例をご紹介します。

AWS移行に役立つ資料をダウンロード