オンプレミスからAWSのクラウド環境への移行を考える
  • よくわかるクラウド
  • AWS
  • 移行
  • オンプレミス

AWSへの移行を徹底解説!オンプレミスからクラウド環境への移行手順【2】 計画と実行 (前編)

AWSのクラウド環境への移行で必要な考え方、事前準備や移行時の注意点などをお伝えする「AWSへの移行を徹底解説!オンプレミスからクラウド環境への移行手順」の連載です。前回の「事前準備」では必要な5つの手順をご紹介しました。今回の「計画と実行」について前編・後編にわかれて、必要な手順などのおさえておきたいポイントやTIPSをご紹介します。

連載「AWSへの移行を徹底解説!オンプレミスからクラウド環境への移行手順」

【1】 事前調査編
【2】 計画と実行 (前編)
【2】 計画と実行 (後編)
【3】 移行本番の切り替え
【4】 移行先としてのAWSと移行で活用したいサービス

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

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

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

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

項目 注意点 理由
プライベートIP プライベートIPアドレス帯は既存の環境と別にしておく 専用線やVPNの通信が必要になることを考慮して予め別にしておくと楽
固定IP(EIP) 外部との連携に固定IPアドレスを必要とするかを事前に洗い出す 外部連携の関係で固定IPが必要な場合があるため(アクセス制御)
メール送信 メールの送信が必要な場合は方式設計が必要 特にSESを使わない場合は、AWSに対して上限緩和申請が必要
インスタンスタイプ 可能ならEC2/RDS/ElastiCacheのインスタンスタイプはサイズを揃える リザーブド購入を検討するなら、インスタンスタイプをそろえると管理しやすい
上限の緩和 AWSの各サービスには上限設定がされており、上限を緩和する申請が必要な場合がある 設計時にできるだけ必要なリソースの数をピックアップし、上限緩和申請もタスクに含める
テクニカルサポート AWSから十分なサポートを受けるためにはサポート契約が必要 プロダクション用途なら、ビジネスサポート以上の契約を結ぶことを推奨

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

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

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

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

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

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

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

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

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

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

その他、人間系の業務調整もこのタイミングで合わせて調整します。社内の別部署でもコンテンツ更新を行っている場合は更新計画の確認が必要です。あるいはDNSレコードの管理を外部に委託している場合には設定変更の依頼方法やリードタイムを踏まえたうえで計画に盛り込む必要があるかもしれません。
 
 
以上が、「AWSへの移行を徹底解説!オンプレミスからクラウド環境への移行手順」の「計画と実行」について前編となります。後編では、マイルストーンの管理方法やリハーサルの実施に関する内容をご紹介します。

連載「AWSへの移行を徹底解説!オンプレミスからクラウド環境への移行手順」

【1】 事前調査編
【2】 計画と実行 (前編)
【2】 計画と実行 (後編)
【3】 移行本番の切り替え
【4】 移行先としてのAWSと移行で活用したいサービス

AWSへの移行事例や稟議に役立つ資料を提供

オンプレミスからクラウドへの移行を成功させるポイントやミズノ株式会社様の導入事例など、AWSへの移行を促進するお役立ち資料を提供します。ぜひご活用ください。

おすすめの記事

おすすめのカテゴリ