オンプレミスからAWSへのクラウド移行！ AWSマイグレーションことはじめ【前編】

本記事では、オンプレミスからクラウド移行について解説します。メインは移行フェーズとアプローチについての説明になりますが、移行フェースは大きく３つあり、評価フェーズ（Assess）、移行準備フェーズ（Mobilize）、移行フェースと近代化（Migrate＆Modernize）とそれぞれ紹介していきます。また、移行準備フェーズ（Mobilize）では、7つの移行戦略「7R」についても見ていきますが、実際のオンプレミスの構成図を題材として、構成図から見てどう変わっていくかを合わせて解説します。

オンプレミスにおける”所有する”デメリット

オンプレミスが抱える問題

「クラウド移行のメリット」を紹介するために、まずオンプレミスが抱える問題について軽く触れたいと思います。オンプレミスが抱える問題とは「ハードウェアの所有」そのものではないかと考えます。

ハードウェアの “所有”それは、サーバーやネットワーク機器本体、それらの機器を収容するラックや、設置するデータセンター、通信回線、電源設備の選定、見積、購買、納入、廃棄、契約など多岐にわたります。

オンプレミス環境の運用では、すべての運用と障害を自社で対応します。システム冗長化の構築・運用、ハードウェア機器などの保守契約管理、データセンターの入館手続き、夜間休日の障害対応など、運用・保守における辛さはインフラエンジニアであれば、経験されている方も多いのではないでしょうか。

俊敏に対応できない

例えば、「自社サービスがヒットしたのでサーバーを増強したい」 と、まさに今の需要に対応したいのに、インフラ環境が即座に用意できるのか？という問題があります。オンプレミスでは、サーバー購入の相見積や設置スペース確保の検討、サーバーを増やしたとして、3年後の見込みはどうか？保守契約も考えないといけないなど、“今すぐ”、“必要な時だけ”というニーズに対して柔軟に対応することが難しい場面もあるのではないでしょうか。

▼お役立ち資料
オンプレミスからクラウドへの移行を成功させるポイントとは？

クラウド（AWS）における”所有しない”メリット

俊敏に対応できる

“所有” しないインフラを提供するクラウドでは、仮想サーバーを時間単位の従量課金で利用するため、必要な時に、必要な分のサーバーリソースを、クリック一つで用意ができて、迅速なビジネス展開や、機会損失を防ぐことができます。 また、不要となれば削除して課金を停止できます。

運用・管理の負荷軽減

AWSではサーバー機器などの管理はAWS側でおこなうため、オンプレミスのようにサーバー機器の所有による運用管理の負荷などの問題からも解放されますので、これだけをとってもクラウド化のメリットは大きいと言えます。

クラウドの責任範囲

クラウドの責任範囲はユーザー側とAWS側それぞれで責任範囲を分担する「責任共有モデル」の方式となります。

AWSを運用するための物理的な基盤やネットワークなどの管理・運用はAWSの責任範囲となるため、ユーザーはその基盤の上で動作するサービスの利用だけに専念することが可能となります。一方、AWS上で稼働している仮想サーバーのセキュリティや脆弱性対策、ミドルウェアのバージョン管理、扱うデータなどの管理はユーザー側の責任範囲となります。

なお、ユーザーの責任範囲は利用するサービスによって異なります。上記図では、右のSaasとしての利用に近づくほど、ユーザー側の責任範囲は少なくなっていき、責任範囲を減らすことで、ユーザー側の管理・運用の負担が軽減されていきます。

次からはオンプレミス環境からクラウド環境へ移行していくためにはどのようにしていくかをご紹介していきます。

移行フェーズとアプローチ

移行フェーズには大きく3つのフェーズがあります。

Assess（アセス）
移行するにあたって現環境の洗い出し、分析・評価をする

Mobilize(モビライズ)
評価に基づいてどう移行していくか、移行計画の検討・準備をする

Migrate(マイグレート)
移行計画をもとに実際に移行していく

Modernize(モダナイズ)
移行後のクラウド環境を最適化していく

それぞれについて見ていきます。

評価 Assess（アセス）

移行を始めるにあたり最初の段階で、現環境の洗い出しをおこない、それをまとめて、現環境とクラウド移行した場合とを分析・評価するフェーズです。

移行対象を決めて、現状の機器一覧の作成、解決したい課題の分析、クラウド移行した場合のコスト試算をおこない、現状と比較して経済性はどうなのかを把握する必要があります。

もう少し細かく見ていきます。

1.信頼できる「機器一覧」を作る

最初に取り掛かりたいのが、現在の状況を把握するための「信頼できる ”機器一覧” の作成」です。サーバースペックや動作しているプロセス、ミドルウェアなど1台ずつ確認・調査して、正確で最新の情報にまとめます。

この洗い出しも台数が多いと大変ですが、これらの作業を支援するため、AWSより以下のようなツールも用意されています。

・AWS Application Discovery Service
サーバーの情報を収集し、一覧にまとめます。主にAssessの支援ツールです。

・Migration Evaluator
オンプレミス環境を評価しAWS移行後のコスト予測、移行計画の支援ツールです。

2.「解決したい課題」を分析する

そもそも移行の目的はなにか？クラウド移行で達成したいことを明確にします。

例えば、構成はこのままでインフラコストを削減したいのか？逆に、コストを掛けてでも安定性や強固なセキュリティが欲しいのか？もしくは、イベントに伴うサーバーへの大量アクセスに備えて、システム増強が必要なのか？また、データセンターが今月閉鎖するから、とにかくどこかに移行しなければならない、など、状況により目的はさまざまですが、クラウド移行の目的を明確にして、関係者と認識を合わせます。

3.クラウド移行を試算し、経済性を評価する

洗い出しが終わりましたら、クラウド化の試算をして、そのコストは移行前と比べどうかを比較します。ここではサーバーの費用に限らず、運用していく上での人員コストなどのリソースも考慮していきます。

4.クラウド移行を遂行するかの可否を判断する

ここまで来たら、クラウド移行を実行するか可否を判断をします。

評価・Assessが完了しましたら次のフェーズ、移行準備・Mobilize に移ります。

移行準備　Mobilize(モビライズ) ※移行戦略 “7R”

評価に基づいてどう移行していくか、移行計画の検討・準備をする段階です。

移行戦略 “7R”

移行戦略にはAWSが提唱する“7R”(セブンアール)があります。
表記の通り7つの戦略パターンがあり、それぞれ頭にRがつきます。

まず、「リホスト」、「リプラットフォーム」、「リファクタリング」これらが7つの戦略の中でも主なケースになりますので1つずつ見ていきます。

▼お役立ち資料
＜マンガでわかる＞AWS移行支援サービス

Rehost リホスト

既存の物理サーバーを ”そのまま” クラウド移行

移行の要件や動機として、「とにかく手早くクラウドに移行したい」、「アプリケーション改修が難しいので、そのまま動かせないものか？」または、「バージョンも構成も、今は変えたくない」という場合に有効な手段としてRehost（リホスト）の方法があります。実際にこのような要望は多く寄せられます。
ここで1つ目の戦略として「Rehost リホスト」をご紹介します。

特徴は“そのまま”クラウド移行することです。

上記はオンプレミス環境の左図から右図のAWSへリホストにより移行した場合の図になります。

ここでのポイントはAPサーバーはそのままAPサーバーへ、WEBサーバーもそのままWEBサーバーへとサーバーの役割・構成の変更はせずそのまま移行している点です。

では具体的にどうするかと言うと、AWSが用意しているAWS Application Migration Service 通称「AWS MGN」の支援ツールを使いますのでご紹介します。

AWS MGN（AWS Application Migration Service）を利用してリホストする

AWS MGNはオンプレミスのサーバーを無停止でAWS上にコピーする Rehost リホストのための中核となるサービスです。

移行対象のサーバーにAWS MGNのエージェントをインストールして利用します。AWS MGNの機能でAWS環境内にレプリケーションサーバーが自動で立ち上がり、エージェントと連携してデータを同期し、同期したデータを基にAmazon EC2を作成します。Amazon EC2が作成できたら、移行先へサービスの切り替えをおこない、移行完了となります。AWS MGNを利用するにあたり、いくつかの設定は必要ですが、比較的シンプルにリホストによる移行を可能にしています。

AWS MGNの特徴

・サーバーのデータ（HDD）をAWS上に丸ごとレプリケーション（同期）
・OSがAmazon EC2インスタンスとして”そのまま”動作するように調整される
・動作確認後、サービス切り替えを行えば移行が完了
オンプレミスからクラウド移行！AWS MGNによるリフト＆シフトでシンプルに始めよう

Rehost リホスト の メリット

・他と比べシンプルな移行のため、サーバー1台あたり数時間から、手早く移行が可能
・OSやミドルウェアのバージョンも変わらず中身もそのままのため、アプリケーションの改修コストが不要、もしくは低く押さえられる
・Amazon EC2を利用することで、ハードウェア所有が不要となり、スペック変更やスケーリングも容易となるクラウドのメリットをすぐに享受できる

Rehost リホスト の デメリット

・現状のサーバー内の問題点も引き継いでしまう
　レガシー環境でサポート切れのOS、既知の不具合、改善すべき問題点、構成上の弱点など、良くも悪くもそのまま移行される
・クラウドのメリットを十分には受けられない
　OSやミドルウェアの管理、DBのバックアップなどの運用は従来どおり必要
・AWS MGNの対応OS以外のリホストは難しい
　対応OSの例) CentOS 6.0以上、Windows Server 2003以上、Ubuntu 12.04以上など
　参考：AWS Application Migration Service の要件

リホストで移行した場合のクラウド責任範囲

クラウド責任共有モデルでは、リホストで利用するAmazon EC2はIaaSに分類されます。

物理基盤はAWSに任せられるようになるものの、他の戦略に比べると責任範囲（管理する）部分はまだ多い状況です。

データベースの管理がつらい、もっと楽に安定稼働させたい、また、OSのサポートが切れそうなのでバージョンアップしたいなど、ただ移し替えるだけでなく、もう少しクラウドを活用したい場合の方法について次のケースReplatform リプラットフォームを紹介します。

Replatform リプラットフォーム

大きな仕組みは変えず、より良い基盤に”乗せ替える”

先ほどのリホストでは、データベースサーバーもそのままAmazon EC2に移行し、使い勝手もそのままでしたが、もっとクラウドならではの恩恵や特色を生かしたいというケースで取る戦略は「リプラットフォーム」が該当します。

データベースの例では、MySQLというエンジンはそのまま、ただしクラウド化により新しい基盤上で同じエンジンを使うことで、根幹となるシステムは変わらず、基盤を変えるような戦略となります。

例
・最新OSで構築したAmazon EC2インスタンスに替える
・データベースをAWSマネージドサービスであるAmazon RDSに載せ替える

マネージドサービスとは…
例えばAmazon EC2では物理的な基盤、インフラ環境はAWSの責任範囲ですが、OSやソフトウェアの管理はユーザー側でおこないます。一方、Amazon RDSなどのマネージドサービスではOSやソフトウェアの管理・バージョンアップもAWSが対応する範囲となり、ユーザーの責任範囲は少なくなり、管理が容易となります。

▼お役立ち資料
オンプレミス環境からAWS環境への データベース移行を成功させるポイント

Replatform リプラットフォーム の メリット

・よりクラウドに適した環境を構築できる
・Amazon RDSやAmazon Aurora などクラウドメリットを生かした、耐久性や可用性の高いサービスが選択できる
・全てを作り直すよりは、低コストでクラウドに合わせた移行ができる

Replatform リプラットフォーム の デメリット

・マネージドサービスの特性によりOSやミドルウェアのバージョンアップが必要になる
例えば、Amazon RDSなどのマネージドサービスは、OS管理はAWSの責任範囲となるため、自動的にアップデートされます。自動アップデートまでは猶予期間があり、それまではユーザー任意のタイミングでアップデートを実施できますが、古い環境のまま利用し続けることはできません。Amazon EC2ではユーザーの責任範囲であるアプリケーションもAmazon RDSでは、自動アップデートに対応できるよう改修が必要となります。

・レガシーなシステムでは改修にコストが掛かる
主にバージョン差異に起因して、アプリケーションの一部改修が必要になり、リホストと比べると移行する難易度が高くなる。

システムがレガシーだと改修範囲が広く、一部改修では済まされず、全体的な改修が必要となる場合は、他の移行戦略を選択肢として選ぶ必要が出てきます。

リプラットフォームで移行した場合のクラウド責任範囲

オンプレミス環境のデータベースサーバーをAmazon RDSへ移行した場合、PaaSに分類され、よりユーザーの責任範囲が狭まります。

Refactor リファクタリング

”より”クラウド活用ができる設計に作り直す

冗長構成にして、障害でもサービスが落ちないようにしたい、サーバーの負荷に応じて自動でスケールさせてアクセス集中に耐えられるシステムをつくりたい。さらには、SSL証明書更新などの運用を自動化したいなど、サーバーの管理をしたくない、もっと運用負荷を減らしたいなどのケースで取る戦略は「リファクタリング」といいます。

AWSにはPaaS、SaaSタイプのサービスが数多くあり、実現したい内容や目的に応じてこれらを新しく柔軟に取り入れるなど、既存のシステムからインフラ構成の再設計を検討します。

例
・Auto Scalingで負荷に応じたサーバーのスケールアウト/インを実現
・AWSの各種サービスを活用しSSL自体を不要に (マネージドサービス/サーバーレス)

Refactor リファクタリング の メリット

・最適化をしていくにつれクラウドメリットをより多く受けられる
・さまざまなAWSのサービスから実現したい内容に応じて選ぶことができる
・状況に応じて段階的な移行が可能
・マネージドサービスの恩恵を受けられる
・冗長性や耐障害性に強いアーキテクチャを作りやすい

Refactor リファクタリング の デメリット

・アーキテクチャやアプリケーションの再設計/再開発が必要
・再設計/再開発のため、導入コストや時間が掛かる
・AWSや利用するサービスの知見や経験が必要になる
・理想形ではあるが、初めからこだわり過ぎると移行計画の進みが悪くなる

リファクタリング で移行した場合のクラウド責任範囲

リファクタリングではSaaSに分類されるサービスが多く、例えば、Amazon S3ではオブジェクト型のファイルストレージサービスであり、ユーザーはそのAmazon S3というサービスそのものを管理する必要はなく、そこに格納するデータや、アクセス許可などのセキュリティ管理のみに専念することができます。

その他の移行戦略

Relocate リロケート

リロケートは再配置という意味があり、現行システムには手を加えません。
VMware Cloud on AWS というサービスがありますが、VMwareゲストをそのまま移行できます。

Repurchase リパーチェス

オンプレミスサーバーで実行しているアプリケーションなどを、SaaSなどのパッケージ製品に代替えする方法です。

この場合、AWSのみが対象ではなく、例えば、サーバー内で管理している会計処理システムを、既製品のソフトに変更する。また、メール機能はGmailに変更したり、NASなどに集約しているデータを Amazon S3 に変更するなどの方法になります。

既存で動作しているアプリケーションの見直しをして、SaaS製品で代用可能な場合はそちらへ移行していく戦略です。

Retainリテイン

リテイン（retain）は持ち続ける、保持するという意味があります。
Assessで検討した結果、今回はクラウド移行せず現状維持が最適と判断した場合です。変動は何もありませんが、移行を検討したうえで現状維持が最適という方針を明確化することができた結果です。

Retire リタイア

Assessで検討した結果、オンプレミスでもクラウドでも不要なサーバーと判断した場合に、クラウド移行しないが、現環境でも不要と判断され廃止となることで、コストカットにつながります。

各戦略の利用頻度

下記図は、各戦略の利用頻度の割合です。

“そのまま” 移行できる「リホスト」が一番多く全体の40％を占めています。次いで「リプラットフォーム」が25%になります。リプラットフォームはリホストに比べ移行の難易度は高くなりますが、移行で課題となりやすい「データベース」の移行にフルマネージドサービスのAmazon RDSやAmazon AuroraなどのSaasを検討されるケースも多く、また、オンプレミス環境のOSなどが古く、バージョンアップして移行されるケースなどもリプラットフォームの割合が多い要因と思われます。
AWS導入・移行支援サービス

【前編】のまとめ

ここまで、オンプレミスのデメリット、AWSに移行するメリット、クラウドに移行した場合の責任範囲、また、3つの移行フェーズのうち2つの評価フェーズ（Assess）、移行準備フェーズ（Mobilize）について解説しました。次の【後編】からは、移行準備フェーズでご紹介した、7Rのうち３つリホスト、リプラットフォーム、リファクタリングについて構成図を題材として、構成図から見てどう変わっていくかと、移行フェーズと近代化 (Migrate & Modernize)について解説していきますので是非引き続きご覧ください。

連載「オンプレミスからクラウド移行！ AWSマイグレーションことはじめ」

▶【前編】
【後編】

おすすめのサービス

• AWS移行支援
• AWS運用・監視代行