第2回では、AWS移行のメリットや移行の基礎知識について、解説しました。今回は、AWS移行プロジェクトを進めるポイントをお伝えします。

AWS移行プロジェクト計画書の作成


事前調査の結果、移行目的、移行対象、予算などが明確になりました。また、これらの調査の中で、課題も出てきたはずです。調査結果を踏まえ、次に行うのは「AWS移行プロジェクト計画書の作成」です。
計画書の作成にあたり、考慮すべき点を以下に紹介します。

(1)移行方針の明確化
オンプレミスからAWSへの移行にあたり、最も重要なのが「移行方針を明確にする」ことです。なぜなら、AWSには175を超えるサービスがあり、どのサービスを利用してシステムを構築するかで、システム移行の方針が変わるからです。
OSやデータベースなどに特に制約がないのであれば、「Amazon EC2」(仮想サーバーサービス)と「Amazon RDS」(データベースサービス)を利用して移行するのがやりやすいでしょう。この場合、主な検討項目となるのは、VPC(Virtual Private Network)環境のネットワーク構成、データベースをはじめとしたミドルウェア、アプリケーションやデータの移行方法となります。

また、各種マネージドサービスを利用することで、データバックアップや冗長化など、AWSへの移行後の運用負荷軽減が期待できます。

(2)データ移行方法の検討
データ移行は、AWSへの移行計画を立てる上で重要なポイントの一つです。なぜなら、システム移行前のデータとの整合性が保たれていないと、AWSへのシステム稼働後、業務に大きな影響を及ぼすからです。とはいえ、現行システムはAWSへの移行中も常に稼働しており、データが更新されています。このため、「いつ」、「どのようなデータ」を、「どのように」移行するかが検討のポイントになります。例えば、「商品マスターなどは追加や更新頻度が少ないために事前に移行する」、「顧客マスターや各種トランザクションデータは追加や更新頻度が多いため、稼働直前に移行する」などです。
場合によっては、移行元となるオンプレミスのサービスを停止できる休日に出勤し、データ移行を行う必要があります。また、データ量によっても移行時間が変わります。スムーズなデータ移行を行うためにも、タイムスケジュールの準備やトラブル発生時の対応方針など、予め綿密なデータ移行計画を立てておきましょう。

(3)ステークホルダーの明確化
AWSへの移行において、ステークホルダー(経営者、システム関係者、業務関係者など)と調整しながら進めることが必要です。また、ベンダーやパートナーなどの外部委託先もステークホルダーに含まれます。
AWS移行プロジェクトを開始するにあたり、「どの人にプロジェクトに参加をしてもらうか?」、あるいは「どの人を窓口として関係部門との調整を行なってもらうか?」など、ステークホルダーを明確にしておきましょう。

(4)移行ツールの検討
オンプレミスからAWSへの移行を人手で行うには、多くの時間と労力を要します。また、特にデータ移行の場合、限られた時間の中で大量のデータを移行するには物理的に不可能なことがあり得ます。このため、移行ツールを利用することで、移行時間の短縮と効率化を検討しましょう。
AWSが提供している移行サービスの一部をご紹介いたします。

AWS Server Migration Service: 移行元の対象はVMware、Hyper-V、Azure上の仮想マシンとなり、これらの仮想マシンをAmazon マシンイメージ(AMI)としてAWSへ移行することができます 。
AWS Snowファミリー: AWS Snowcone、AWS Snowball と AWS Snowmobile で構成される Snow ファミリーは、AWS へエクサバイト規模のデータを物理的に転送 ができます。
AWS Database Migration Service: データベースを短期間で安全に AWS に移行できます。 異なるデータベースプラットフォーム間の移行もサポート されています。

AWS移行プロジェクト計画の実行


AWS移行プロジェクト計画書を作成したら、計画に基づいてAWS移行プロジェクトを実行します。この時、必要になるのが「進捗管理」です。ここでは、進捗管理のポイントについて解説します。

(1)マイルストーンの設定
プロジェクトにおけるマイルストーンとは、「プロジェクトがどこまで進んでいるかを確認するポイント」を表す言葉です。マイルストーンを設定して、進捗の測定基準を設定することで、AWSへの移行が予定通りに進んでいるのか、それとも遅れているのかを確認することができます。また、マイルストーンを設定することで、もし作業遅れが生じた場合、リカバリープランを検討しやすくなるメリットもあります。

(2)作業タスクの洗い出し
計画実行時に必要なのが「作業タスクの洗い出し」です。作業タスクとは、「いつ、何を、誰が行うのか?」を明確にした作業単位です。作業タスクを週単位で設定し、作業管理表としてまとめておくことで、作業状況を把握しやすくなります。

(3)移行リハーサル
ここまで来ると、AWSへの移行プロジェクトも最終段階です。とはいえ、いきなり本番移行を行うのは、大きなリスクを伴います。また、手順の不備など、トラブルが発生した時に混乱を招きかねません。このため、本番移行を行う前に、移行リハーサルを実施することをおすすめします。

移行リハーサルは、本番と同様の手順で移行を実施し、移行計画だけでは分からない問題点や手順の抜け漏れを発見する目的で行います。もし移行リハーサルで問題が発生した場合、移行当日までに解決策を検討します。このように、移行リハーサルで発生した問題に対して対策を打つことで、当日の移行作業を安心して迎えることができます。

(4)本番移行とリリース
移行リハーサルで発生した問題点を解決し、移行手順書を修正したら、いよいよ本番移行です。本番移行を行うにあたり、以下の点を予め決めておく必要があります。
移行作業は夜間や休日になることがあります。このため、誰がいつ出勤し、移行作業を実施するのかを予め決めておきます。
また、移行当日は出勤しないステークホルダーに連絡を取る可能性があります。このため、連絡体制を決め、確認事項が発生した時に連絡を取れるようにします。移行リハーサルで予測されるトラブルを洗い出したとしても、それでも本番移行中に不測の事態が発生することがあります。そのような事態に備え、トラブルの種類に応じて、誰が判断を下し、誰が対応するのかを決めておく必要があります。

(5)リリース判断
本番移行が無事に終えることができたら、リリース判断を行いましょう。そして、問題ないと判断されたなら、いよいよAWSでのシステム稼働です。