AWSへの移行方法と手順～オンプレからのクラウド移行を成功に導くために～【1】事前調査・移行ツール

クラウドファーストへのシフトが加速していく中、オンプレミスからクラウドへの移行を検討している企業も増加傾向にあります。では実際にオンプレミスからAWSのようなクラウド環境に移行する場合には、どうやって移行をすすめればいいのでしょうか？

AWSのクラウド環境への移行で必要な考え方、事前準備や移行時の注意点などを
「AWSへの移行方法と手順～オンプレからのクラウド移行を成功に導くために～」の連載でお伝えします。

連載「AWSへの移行方法と手順～オンプレからのクラウド移行を成功に導くために～」

▶【1】事前調査・移行ツール
【2】 計画と実行
【3】 移行本番の切り替え
【4】AWSへの移行事例

オンプレからAWSなどのクラウド環境へ移行する上で知っておくべき基礎知識

クラウドへ移行するかどうか検討する前に、まず最低限「クラウドとは何か」「オンプレミスとは何か」、そして両者の違いや特徴を知っておかなければなりません。すでに十分理解しているという方は読み飛ばしていただき、「クラウド移行時の課題」からお読みいただいて構いません。

1-1. クラウドとは

クラウド（パブリッククラウド）とは、自社でサーバーやOS、ソフトウェアなどを資産として保有せず、クラウドベンダーが用意したITリソースをネットワーク越しに利用し、利用量に応じて料金を支払う形態をいいます。代表的なクラウド環境としては、「AWS（Amazon Web Services）」やMicrosoft社の「Azure」、Googleの「Google Cloud Platform（GCP）」があります。

自社でサーバーを用意する必要がないため物理的なサーバーの管理負担がかからないことや、地震などの災害リスク分散システムをオンプレミスよりも容易に構築できるなどのメリットがあります。さらに詳しいメリットについては、次の章で改めて解説しています。

1-2. オンプレミス（オンプレ）とは

オンプレミス（on-premise）とは、企業が自社でサーバーやネットワーク、ソフトウェアなどを構築して、自社内やデータセンターで管理・運用する形態をいいます。クラウド・SaaSのサービスが広がるようになると、それらと区別するために従来型のスタイルに呼び名が必要になり、「オンプレミス」と呼ばれるようになりました。「オンプレ」と略されることもあります。

オンプレミスは自社で構築するため自由にカスタマイズできるという特徴があります。また、社内のネットワークを利用するため、回線の速度や質が安定しています。重要なデータの流出を防ぐという観点から、コンプライアンス上での理由でオンプレミス環境を必須としている企業もあります。

1-3. オンプレミスとクラウドの違いを比較

オンプレミスとクラウドの特徴を項目ごとに比較表にまとめました。

	オンプレミス	クラウド
導入しやすさ	構築に時間がかかる	アカウント登録後 すぐ利用可能
初期費用	初期費用が高額になりがち	初期費用はかからない
維持コストの特長	減価償却で費用負担は 下がっていく	従量課金で利用分だけの請求
障害時対応	自社で復旧対応が必須	クラウド提供者の対応箇所も あるため負担が減る
カスタマイズ	自由にカスタマイズできる	Iaas型なら比較的 自由度は高い
自社システムとの連携	システムと連携しやすい	ネット利用前提だと 連携できないケースもありえる
会計処理の簡単さ	固定資産税がかかり 減価償却処理が必要	経費として処理が可能 固定資産税はかからない

項目ごとに比較すると、オンプレミスでデメリットとなる部分（導入・維持コストが高い、障害時対応が必須）をクラウドだと解消できることが分かりますね。

クラウドとオンプレミス、それぞれのメリットを比較

クラウド移行時の課題

実際にクラウドへ移行するとなると不安のある方も多いのではないでしょうか。クラウド移行時のお悩みとしてよくあるのが

• そもそもなにから着手してよいかわからない
• クラウド移行のための技術的な知識やスキルが不足している
• 日々の運用で忙しく、移行にリソースを割くことが難しい

などです。
これらのクラウド移行の課題についての解決策の一つとして、本記事内では移行手順を明確にしたうえで、AWSへの移行で利用できるクラウド移行ツールやサービスを紹介しています。

AWS移行にベストプラクティス集「AWS Well-Architected Framework」の活用

AWSではユーザーの状況に応じてより最適にAWSを構築・設計・運用するための考え方やお手本となるプラクティス集「AWS Well-Architected Framework」が用意されています。AWS Well-Architected FrameworkはAWSの10年以上の経験から得られたもので、導入するAWSシステムがAWSのベストプラクティスにどれだけ準拠しているのかを評価するための質問集をまとめたものです。

Well-Architected Toolという形でブラウザ上で設問に回答することで、課題点が明らかになります。ITシステムやクラウド環境で将来起こりうる幅広いイベントに対して、事前に対策を検討することができます。
AWS Well-Architected

なお、オンプレミスからクラウドへ移行する際に、作業の流れの中で抜け漏れがないか確認できる移行チェックリストテンプレートをご参考資料としてご用意しています。

AWSの特長と移行するメリット

オンプレミスから移行先となるクラウドの中でも特にオススメのAWSについて特長とメリットを紹介します。

グローバルインフラストラクチャとセキュリティ

AWSは全世界に26ヶ所のリージョン、84ヶ所のアベイラビリティゾーン(地理的に分離された1つ以上のデータセンター)、300ヶ所以上のエッジロケーションがあります。(※2022年4月現在) 日本では東京と大阪の2箇所にリージョンがあり、国内でのDR対策が必要な企業は更に利用しやすくなりました。また海外のリージョンも手軽に利用できるため、自社でデータセンターを立ち上げるよりもコストと時間をかけずに海外展開が可能です。

AWSのリージョンは低レイテンシー、高いスループット、そして高度の冗長ネットワークで接続されている複数の物理的に独立・隔離されたアベイラビリティゾーンが用意されていますので、基盤全体で見たときには、高い可用性と耐障害性を実現しています。また、セキュリティ面でも、ISOやSOCを初めとした数多くの第三者監査によるセキュリティやコンプライアンスについての検証が実施されています。AWSを利用するということは、高い可用性と耐障害性、そしてセキュリティ対策が施された環境を莫大な初期投資をしないでも使えるということでもあります。

継続的な値下げ

オンプレミスからAWSのクラウド環境へ移行することでコストの概念も変わり、従量課金になることで費用部分が気になる方も多いかと思います。コストの部分でAWSを利用するメリットとしては、従量課金になることで従来の最大値を考慮したキャパシティプランニングではなく必要な分だけ利用して支払うことになるため費用が適正化されます。

またAWSは2006年にサービスを開始してから109回以上の値下げを実施した実績があります。（※2021年11月現在）AWSサービスの利用拡大に伴い、AWS自体に規模のメリットによるコスト優位性が生じることが一つの理由として挙げられますが、AWSはこの利益を値下げという形で顧客に還元します。サービスを利用する側としては利用を継続するだけで適正なランニングコストが維持されるともいえます。加えて今後も使っているリソースが値下げされることもあるでしょうから、長期的に見ればランニングコストが低減していく恩恵を受けられるかもしれません。

AWSサービスの拡張と機能改善

AWSは200を超えるサービスを提供しており、サービスは年々数を増やしています。仮想サーバーなどのコンピューティング領域にとどまらず、今ではIoTやデータ解析などの領域も含めたITインフラの幅広い分野でサービスを提供しています。例えば2020年に行った機能改善は2,757回にも及びます。また、そのうち90%以上は利用者からのフィードバックに基づく実装とのことです。サービスの豊富さと拡充されるスピードの速さは他社クラウドと比較しても全く引けを取りません。

ここまで、オンプレミス環境からの移行先としてAWSの優位な点をいくつか挙げさせていただきました。今回は3点ほど挙げる形を取りましたが、実際にオンプレミス環境の移行を検討する際には、AWSは移行先の第一候補としてぜひ含めていただきたいところです。

以下も合わせて参考にしていただきたい情報です。
AWSを導入する6つのメリット

AWSへの移行方法と手順【1】事前調査・移行ツール

「どのようにAWSヘの移行をすすめていけばわからない」という方に向けて、ここでは具体的な移行の準備手順を紹介します。
事前調査、計画と実施、当日の切り替えの3つの作業ステップを順次進めていきながら、移行時の作業を明確にしていく必要があります。

本連載では、準備、計画と実行、移行本番の切り替えと順番に紹介しますが、長くなりますのでご自分に必要な箇所だけお読みいただくことも可能です。またAWSへの移行についてより簡単に概要を把握したい方には「これから始める　クラウド移行ガイド」という冊子もありますのでそちらをご参照ください。

1.一番初めに決めること　ゴール設定

まず移行のプロジェクトを立ち上げるときに重要となるのが「ゴール設定」です。

• なぜ移行を行うのか
• 何をどこまで移行するのか
• いつまでに移行を行うのか

それぞれについて考え、移行の完了条件を設定することが大切です。

2.情報資産の棚卸し

事前調査ではステークホルダー、情報資産、月額費用の切り口でリストアップすると移行対象を把握しやすいでしょう。

ステークホルダー

システムに関わる人との密な連携が移行には必須です。社内の業務やシステムの担当者だけでなく、外部委託先やAPIなどで連携している外部サービスがある場合にはその担当者の連絡先もはじめに整理しておきましょう。移行に関係する各種業務調整や、移行作業でトラブルや障害が発生した場合の対処がスムーズです。

情報資産

実際に移行を行うシステムのドキュメント、ハードウェア資産、ソフトウェア資産などを把握します。見落としがちなのが、サーバーやシステムにアクセスするための各種ログイン情報や秘密鍵などです。移行作業に直接影響するため、アクセス手段の確保は重要です。

月額費用

外部でデータセンターやレンタルサーバーを借りている場合は、解約の時期を決める必要があります。解約条件を確認しましょう。一般的に移行が完了するまでは新旧両システムを並行で稼動させる事が多いため、移行期間中のコストも予算確保しておく必要があります。

3.AWSへの移行対象の選定

AWSへの移行対象を選定します。例えば対象がシステムの一部なのか、全部なのかといった範囲や、複数ある場合にはどれから移行するかという順序も検討します。移行の優先順位付けは「業務課題」、「影響度合い」、「担当事情」等の切り口で比較すると、判断しやすくなるでしょう。比較的ビジネスインパクトが小さく、利用者の少ないシステムからPoC(Proof of Concept（概念実証)）を兼ねて移行を進めてみるのは多くの場合良い選択です。小規模なシステムからの移行を早い段階で一通り行ってみることで、移行時の注意点が把握しやすい、早い段階からAWS上でシステムを運用する経験を蓄積できる、等のメリットが考えられます。

4.実機調査

設計書、設定シート、構成図、手順書などの各種ドキュメントが揃っていたとしても、実機調査をせずに移行計画を立てるのはトラブルの元です。管理ドキュメントの内容があっているのかの確認を含め、必ず実機調査を行いましょう。

過去、急ぎでCPUやメモリなどのリソースを追加したが、管理ドキュメントは更新されていなかった、というケースはよく聞く話です。実機のOSやミドルウェアのバージョンが管理ドキュメントより新しい、ということも考えられます。現環境の概要を把握するためにドキュメントを使いつつ、実機の状態を構成上の「正」として押さえるのが調査精度の面ではより安全でしょう。

逆に不要な設定が残ったままだった、ということもあるでしょう。実機調査と合わせてここで管理ドキュメントの更新と各種設定の棚卸しも行っておくと、その後の検討がやりやすくなるでしょう。

5.AWSへの移行に検討が必要なもの

バージョンが古いOS、ミドルウェア

移行対象とするシステム、特にアプリケーションの動作要件は早めに把握しておきたいものの一つです。AWS側で移行前と同じ環境を用意できない場合が考えられるからです。

例えばOSならRedHat4以前、Windows2000以前、あるいはミドルウェアのバージョンがあまりにも古いケースなどが挙げられます。この場合は、OSやミドルウェアは新しいバージョンの環境を用意することになるため、アプリケーションの動作テストが重要なタスクになるでしょう。場合によってはアプリケーション側の改修が必要なケースも考えられます。

アプリケーションにIPアドレスやIDがハードコーディングされている

アプリケーションそのものにIPアドレスやハードウェアなどのIDがハードコーディングされているような場合、AWSに移行を行うタイミングでやはりアプリケーション改修と動作テストが必要になるでしょう。

クラスタや負荷分散設定

オンプレミス環境でクラスタ構成を組んでいる場合、構成によっては実現方式を見直すことになるかもしれません。同様にロードバランサーを利用していて、アプリケーション要件で特殊な負荷分散設定を行っているケースなども注意が必要です。

AWS移行で利用するマイグレーションサービスなどの移行ツール

ツールやサービスについて理解し、計画に組み込む必要があります。AWSにはさまざまなマイグレーションサービスがあり、データベースの移行用サービスやツールも用意されているので紹介します。

AWSのマイグレーションサービス 1：仮想マシンへの移行

VM Import/Export

VM Import/Exportを使うとオンプレミスの仮想マシンイメージをAWSのEC2に移行することができます。移行に際して大きな変更を加える必要が無い点は魅力的ですが、利用できる仮想化ソフトウェアやOSは限定されていることに注意が必要です。移行元のオンプレミスで稼働しているシステムと要件が合致しているか確認する必要があります。
VM Import/Export

AWS Server Migration Service

AWS Server Migration Serviceを利用するとVMware vSphere または Microsoft Hyper-V/SCVMM上で動いている仮想マシンをAWSに移行することができます。オンプレミスの仮想化環境にAWS Server Migration Service Connectorを導入して、AWS Server Migration Service Connector経由でAWS環境に仮想マシンのデータを転送します。

こちらもVM Import/Export同様、移行要件が合致しているかどうかはしっかりと確認する必要があるでしょう。自社で対応が難しい場合には同移行ツールを使ったソリューションを提供しているAWSのパートナーに依頼して進めることを考えてみても良いかもしれません。

AWS Server Migration Service（SMS）でAWSへの仮想マシンの移行を手軽に行うには

CloudEndure Migration

2019年6月にCloudEndure社をAWSが買収したことにより、AWSで無料で利用ができるようになったサービスです。OSごとにエージェントを導入すれば、物理・仮想マシン、どちらの移行もできます。

移行先のサーバーにそのままデータを移行でき、切り替えを行うだけで移行が完了するため、最短のダウンタイムで移行できることが特長です。またデータ転送ではAWS Direct Connectを利用することができ、移行時のネットワーク帯域の制御も行えます。

仮想マシンの移行サービスは複数あるため、どのサービスを利用するかは自社のニーズに合わせて検討が必要です。
AWSへの移行を効率化するAWS SMSとCloudEndureを徹底比較

AWSのマイグレーションサービス ２：ネットワーク経由のデータ転送

AWS Direct Connect

移行作業時は、データの転送を考えるとセキュリティが担保されたネットワークが必要です。AWSではインターネット経由の通信はもちろん、インターネットVPN、専用線(AWS Direct Connect)を利用することが可能です。

インターネット経由でのデータ転送にセキュリティ面などから制約がある場合、リードタイムとコストを理由として、インターネットVPN経由でのデータ転送が採用されることが比較的多いですが、回線のセキュリティと通信品質を重視する場合はAWS Direct Connectを利用することになるでしょう。
AWS Direct Connect

AWS Snowball

移行作業では、大容量のデータをAWSに転送させないといけないケースもあるでしょう。例えば、ネットワーク越しに数十TBのデータを移行する必要があったとしたら、データ転送だけで相当の時間がかかります。AWS Snowballはそんなときに利用を考えたいサービスです。AWS Snowballは大容量の物理デバイスを利用した、データの配送サービスです。

AWSからデータを移行するためのSnowballデバイスが送られてくるので、このSnowballデバイスにオンプレミス環境のデータを転送したのち、AWSにSnowballデバイスを配送します。AWS側でのデータインポートが完了すると、Snowballデバイスに保存したデータは、オブジェクトストレージであるS3に格納されます。Snowballデバイスには10GBaseT ネットワーク接続が同梱されているため、大量のデータもすばやく転送することができます。また、Snowballデバイスは耐障害性やセキュリティ面も考慮されており、データ配送上のリスクも考慮された設計になっています。
AWS Snowball

AWSのマイグレーションサービス ３：データベースの移行

AWS Database Migration Service

データベースのデータを移行する場合に活用したいのがAWS Database Migration Serviceです。これはデータベース間のインポート・エクスポート、同期を実現するものです。これは異なるDBエンジン間のデータ移行にも対応しています。例えばMicrosoft SQL Server から MySQLのような移行にも活用可能です。多彩なソース、ターゲットエンドポイント指定が可能なため、活用の仕方次第では柔軟な移行計画が立てられそうです。

異なるDBエンジン間のデータ移行はAWS Schema Conversion Tool(AWS　SCT)を合わせて使っていくことになるでしょう。ただ、全てが完全に移行できるとは限りませんので、基本的には事前に検証の上で作業計画を立てる必要があるでしょう。
AWS Database Migration Service

AWSパートナーが提供する移行支援サービスの活用

工数、ノウハウなどの理由からAWSへの移行作業を自社で行うことが難しい場合には、AWSの公式パートナーが提供している移行支援サービスを利用するのも一つの手です。 しかし、日本のAWSパートナーは数多くあり、得意な領域もそれぞれ異なります。AWSへの移行を得意とするパートナーの見分け方として、AWSの「移行コンピテンシー」認定を取得しているかが一つの判断材料となります。

「移行コンピテンシー」はパートナーがAWSの活用において、移行の分野で専門性の高い技術力を持ち、定められた水準を満たすレベル以上で優れたソリューションを提供していることをAWSが認定するものです。

当社、NHNテコラスもAWSの公式パートナーであり「移行コンピテンシー」をはじめ数多くのパートナープログラムを取得しています。また、全世界のAWSパートナーのなかでもわずか1%しか認定されていないAWS最高ランクのプレミアパートナーでもあります。

AWSへの移行をサポートするAWS移行支援サービス、また、AWS Well-Architected Frameworkの活用においても、企業の状況に応じたAWSの構築・運用のご提案をしておりますので、お気軽にご相談下さい。

AWSへの移行方法と手順【1】事前調査・移行ツール（まとめ）

ここまで、クラウド（AWS）の特徴、クラウド移行前の事前調査の方法、AWS移行に活用できるサービスや移行ツールについてご紹介してきました。

オンプレミス環境からAWSへの移行を考えたとき、全てをAWSに移行してしまう、というのが理想ではあります。しかし、環境によっては、運用レベルから、移行作業に必要な停止時間を確保できない、などの理由で、AWSに全てを移行するのが難しいケースもあります。この場合はオンプレミス環境に一部を残し、AWSとのハイブリッド環境を志向するのが解決策になるかもしれません。

AWSへの移行は運用や管理の負担が大きいものから行い、手間を減らすことから始めることがおすすめです。運用の時間を最小化し、新しい技術の検証や開発への注力など本来の事業に貢献できる部分に時間をあてることができるようになるでしょう。

以上が、オンプレミスからAWSのクラウド環境への移行を考えるための事前準備に必要なこととなります。

次回は「計画と実行」について紹介します。

連載「AWSへの移行方法と手順～オンプレからのクラウド移行を成功に導くために～」

▶【1】事前調査・移行ツール
【2】 計画と実行
【3】 移行本番の切り替え
【4】AWSへの移行事例

おすすめのサービス

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