COLUMN誰でもわかる！お役立ちコラム

AWS活用支援コラム

既存システムをAWSに載せ替えるには？

ITシステムを構築する上で、近年様々な会社でAWS(Amazon Web Services)の利用が増えています。AWSを利用すると、QCD（Quality、Cost、Delivery）を大幅に改善することができます。既存のITシステムをAWSに移行するためには、どのような計画をし、実行すればいいのでしょうか。具体的に記載していきます。

まずAWS移行のゴールを設定する

AWSへの移行プロジェクトを立ち上げる場合、ゴールを決めることが必要です。大きな目標と、各マイルストーンにおける小さなステップを定め、それぞれについて条件を設定し、達成度を測っていくことが必要です。

大きな目標としては、「ピークに合わせて調達しているサーバ投資を抑えてコストを削減したい」とか、「震災以降、課題に挙がっているが実現出来ていないディザスタリカバリを解決したい」といった、移行することで何を達成したいのか、ということを具体的に設定するといいでしょう。

小さなステップでは、どのITシステムを、いつまでに移行すればいいのか、といったプロジェクト自体のKPIと言えるようなものを設定しましょう。また、AWSの有識者を〇〇人に増やす、といった設定も行い、移行後の人的リソースや運用を見据えたKPIを定めることも重要です。

既存システムの棚卸しと対象の選定

次に、既存のITシステムに関する資産の状況を把握します。具体的には、実際に移行を行うシステムを明確にして、そのドキュメント、ハードウェア資産、ソフトウェア資産などを把握します。保有しているITシステムに関する資産の状況を把握することで、事前に定めたKPIの達成を行うためにはどうすればいいか、道筋を立てることができます。

また、サーバーやシステムにアクセスするための各種ログイン情報等の把握もこの時点で行うと、実際の移行作業に向けた実務的な準備にもつながります。
つぎに、最初の移行対象を選定していきます。

検証目的で、比較的ビジネスインパクトが小さく、利用者の少ないシステムから移行を進めてみるというアプローチと、非常にビジネスインパクトが大きいシステムから移行を始める、というアプローチがあります。前者は採用する企業も多く、注意点が把握しやすいという特徴があります。後者は採用する企業は少ないですが、移行に向けたノウハウやスキルを一気に獲得することができ、その後の移行作業の高速化を実現すると考えることが出来ます。

古いシステムでも安心して移行できるスタイルズのAWS導入・移行サービスはこちら→

システム実機の調査

既存システムの棚卸を行い、移行作業に着手する前には必ず実機での情報収集も必要です。設計書や構成図に反映されていないシステム変更もあり得るため、実機を調査してドキュメントの最新化を行っておくとトラブルを回避することができます。ITシステムを構成する部品はネットワーク機器、OS、ミドルウェア等様々ですが、どのような観点で調査を行えばいいか記載していきます。

ネットワーク機器

実際のネットワーク設定について把握しておきましょう。AWSに移行すると、ファイアウォールやロードバランサーについても仮想化されます。適切に設定を移行するためにconfigファイルベースの情報を正しく把握しておく必要があります。

OSやミドルウェア

OSやミドルウェアなどの、アプリケーションの動作に関わる要件は詳細に状態を把握しておく必要があります。特に、Windows2000などの古いOSについてはAWSにおいてサポートがないものも存在します。この場合は、システム移行ではなくリプレースも視野に入ってくるため、綿密な動作テストや十分な開発期間が必要になり、システム移行計画に大きな影響を及ぼします。

ソフトウェアライセンス

AWSに移行すると、ライセンス体系や対応製品自体が変わってしまうソフトウェアも存在します。そのため、各ソフトウェアベンダーに、移行の概要を説明しクラウド上でのライセンスの扱いや計算方法など必要な対応を仰ぐといいでしょう。また、AWS非対応の製品も中にはあるため、その場合は代替製品を調査していく必要があります。

データベース

Oracle EEやDB2等の、AWSのマネージドサービスで提供されていないデータベースエンジンやそのバージョンについては、別のRDSのエンジンを使う、EC2にインストールする、などの、AWSに移行後の対応方針を決めておく必要があります。また、同時にライセンス体系についても確認をしておくといいでしょう。

クラスタソフトウェア

共有ディスク構成などのクラスタ構成を組んでいる場合は、AWSに移行するとクラスタ構成を実現することが少々手間であったり、ソフトウェアの変更が必要になったりするので、洗い出しの必要があります。システムのユーザと可用性やSLAが厳格に設定されている場合は、AWSに移行後どのようにSLAを実現していけばよいか考えておく必要があります。

AWS移行による影響範囲の検討

AWSへ移行するシステムについて、周辺のシステムについても影響を調査しましょう。例えば、対象のシステムやサービスに外部との連携がある場合は連携方式を変更する必要がでてくるためです。また、運用手順や、運用を行うメンバーに対する影響調査も必要です。具体的にどのような検討を行えばいいのか、見ていきましょう。

移行後の運用への影響

AWSの運用と、オンプレミス環境上のITシステムの運用は手順が異なるため、移行期間中は運用メンバーへの負荷がどのくらい増えるのか、手順はどのくらい増えてしまうのか、といったことを検討し、スムーズに運用を行えるようにします。

既存アプリケーションへの影響

既存のアプリケーションについては、移行後に著しい処理遅延や、稼働しない、といったことがないようにしておく必要があります。アプリケーションに使われるモジュールやOSのライブラリについても正確な把握と検証が必要です。また、クラウドに移行することでレイテンシー（遅延）が増えてしまう場合もあるため、性能試験の目標値も確認しておきましょう。

他システムへの影響

他システムと連携しているシステムを移行する場合は、移行後に、他システムとの通信経路や連携方法を変更する場合があるので、洗い出しが必要です。また、移行中のタスクとして、他システムとの連携テストを行う場合も、他システムとのオーナーとの調整が必要になる場合が多いため、タスクとして事前に認識しておきましょう。

移行後のコストシミュレーション

移行後に思わぬコスト増にならないよう、事前に大まかな予算を決めておきましょう。AWSでは予算にアラートを紐づけることで、予算オーバーの検知が必要です。必要に応じてリザーブドインスタンスの購入等を行い、予算を下げる、といった選択肢も検討しておきましょう。

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

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

古いシステムでも安心して移行できるスタイルズのAWS導入・移行サービスはこちら→

想定外を防ぐ移行リハーサル

移行工程の後半には移行リハーサルを必ず行う必要があります。移行リハーサルの目的は、計画段階における想定外事象の洗い出しです。安心してシステム移行を実現させるため、移行リハーサルを実施時に発見した課題は移行本番までに確実につぶしておくようにしましょう。必要に応じて、移行リハーサルを複数回行えるようなスケジュールを組んでおくと良いでしょう。

移行本番の切り替え

システム切り替えの当日は、作業体制や連絡体制を事前に決めておきましょう。何時までにどのような工程が解消されていなければ戻しを行う、といった、作業工程のチェックリスト、移行中止の基準、移行中止を行う判断者と、判断者までのエスカレーション経路について事前に決めておきましょう。移行中止の基準があいまいだと、判断が行えず、サービスの停止やデータの破損といったトラブルが生じてしまい、被害が拡大することがあります。事前に連絡体制や基準をきちんと決めておけば、当日トラブルが発生しても被害を抑えることができます。

まとめ

システム移行について、一見難しそうではありますが、記載の順序に従えば大きなトラブルなく進めることができます。万が一不安であれば、実績豊富なベンダーと一緒に考えるのもいいでしょう。