[AWS入門] オンプレミス環境からのAWS移行～クラウドマイグレーションに必要な準備とは～

クラウドマイグレーションを実施する背景

マイグレーションを実施する背景はいろいろありますが、大きな実施目的はビジネス価値を享受することです。

たとえば、データセンター統廃合によるコスト削減、インフラコード化^（※1）や自動化による運用負荷軽減、サーバー納期短縮や開発生産性向上によるビジネスの俊敏性などがあります。

※1 インフラコード化：OS・ミドルウェアといったITインフラ構築・運用をコード化すること。

最近では企業のカーボンニュートラルへの取り組みが重要視されているため、クラウド移行によるCO2削減効果にも注目が集まっています。

全てのシステムもしくは大部分のマイグレーションが完了した時に、享受できるビジネス価値がどの程度かを把握してから、マイグレーション実施計画を立てます。

本記事では、マイグレーション実施にあたり事前準備をどのように進めるかについてご紹介します。

クラウドマイグレーションの全体像

マイグレーションの全体像は下図のような流れになります。

1：アセスメントフェーズ移行対象把握料金試算 TCO分析現行サーバ調査 2：調査、計画フェーズ移行方式判断提案書作成現行サーバ調査 3：PoCフェーズ移行PoC 準委任で実施 4：設計構築フェーズ AWS環境設計 AWS環境構築運用設計 5：移行フェーズ移行計画本番移行 6：運用フェーズシステム運用 — マイグレーションの全体像

1：アセスメントフェーズ
2：調査、計画フェーズ

マイグレーションを成功させるためには、準備段階がとくに重要です。

アセスメントフェーズと調査計画フェーズで、移行対象や移行順序・移行後のサーバーコストなどをイメージできている方は多いと感じています。

しかし意外と忘れがちで重要なのが、移行先となるAWS基盤のセキュリティ策定や利用ガイドライン、運用体制・標準化検討をしておくことです。
「AWS移行を実施したが、運用がうまくいかず、社内のクラウド普及が進まなかった」といったことが、起こる可能性があるからです。

AWS基盤のセキュリティ策定や利用ガイドライン、運用体制・標準化検討は、実際に試してみないと決められない部分もあります。
PoCフェーズを並行して進め、各システムをどのようなマイグレーション手法で移行するのがベストなのか、検討しましょう。

移行対象の調査について

日頃の管理が追い付かず、移行対象の調査に課題を抱えている方も多いと思います。

たとえば、サーバー台帳などで各サーバーのスペック・OS種類・稼働するアプリ等を管理しており、
使用状況や負荷状況も把握できているとしたら不足部分だけ調査すればよいですが、実際には管理できていない場合が多くあります。

そのような場合は、AWS Application Discovery Service を利用することで簡単に移行計画のための確実なデータ検出ができます。

AWS Application Discovery Serviceとは、対象とするWindowsサーバーやLinuxサーバーから、エージェント型（物理/仮想サーバー）またはエージェントレス型（VMware基盤）でサーバーの仕様情報、パフォーマンスデータ、実行中のプロセス情報やネットワーク接続に関する詳細情報を収集するAWSのサービスです。また、収集したデータを基にAmazonEC2 インスタンスタイプの推奨などを行えます。

エージェント型とは

サーバーにAWS Application Discovery Agent（サーバー内の情報を収集）をインストールして、システム設定、システムパフォーマンス、実行中のプロセス、およびシステム間のネットワーク接続の詳細をキャプチャすることです。

エージェントレス型（VMware基盤）とは

AWS Discovery Connectorを使用します。
AWS Discovery Connectorとは、VMware 仮想マシン（VM）に関する情報のみを収集できるVMware アプライアンスです。

Open Virtualization Archive（OVA）ファイルを使用して、VMware vCenter Server環境にVMとしてDiscovery Connectorをインストールします。
Discovery Connectorは、オペレーティングシステムの種類を問わず、VMware メタデータに基づいてサーバー情報を収集するため、オンプレミスインフラストラクチャの初回評価の所要時間を最小限に抑えられます。

クラウドマイグレーションの手法（7つのR）

既存システムの整理/棚卸しができたら、どのようなアーキテクチャを採用するのか、ということを個々のシステムごとに検討しましょう。
これを移行パスと呼び、英語の頭文字を取って7つのRでまとめることができます。

以下で具体的にご紹介します。

移行パス	各移行パスの概要
廃止（Retire）	不要と判断されたアプリケーション/データベースを単純に廃止または削除すること。
保持（Retain）	クラウドへ移行する正当なビジネス上の理由がないため、移行せず元の環境で稼働させ続けること。
リロケート（Relocate）	オンプレミスのVMware 環境をVMware Cloud on AWSに移行すること。
リホスト（Rehost）	既存のアプリケーション/データベースに何も変更を加えることなく、そのままクラウドへ移行させること。
再購入（Repurchase）	既存の製品から、別の製品に切り替えること。特に、既存のライセンスモデルの製品から、SaaS モデルの製品に切り替えることを指す。
リプラットフォーム（Replatform）	クラウドへ移行する際に、クラウドの機能を活用するため、部分的に最適化を行うこと。
リファクタリング（Refactor）	アプリケーション/データベースを移行するにあたり、クラウドネイティブな機能を最大限に活用し、俊敏性・パフォーマンス・拡張性を高めるため、コードの修正やデータベースの変換を行うこと。一般的に、OSやデータベースの変更を伴う。

まとめ

マイグレーションを実施する前の準備段階では、何のために、何を、何に、いつまでに、どのように移行するのかを決定します。

移行対象の一覧や使用状況等の調査結果が集まったら、利害関係者を集めて優先順位を決めていきましょう。

今回の記事を読んで、AWS移行に興味を持った方、マイグレーション移行検討中で課題をお持ちの方は、是非当社までお問い合わせください。

作者プロフィール

名前	高谷
担当のAWS業務	アライアンス関係
AWSの持っている資格	Solution Architect Professional
好きなAWSのサービス	System Manager
趣味	スキューバダイビング
ひとこと	ビーチリゾートでテレワークしたいです。