オンプレミスに構築したシステムをAzureに移行する際には、最適な手順と考慮すべきポイントがあります。今回の記事ではその手順とポイントをまとめています。最適なコストと方法で失敗なくAzureへの移行を実現したい方は、是非お読みください。
移行の基本プロセス
Azureへの移行は、大きく3段階のプロセスで実施します。
第1段階の評価プロセスでは、まず対称となる仮想マシンを選定し、Azureに移行が可能かどうかを調べます。移行可能であれば、オンプレミスでの利用状況から必要なスペックのホストを選定し、予算に見合うかを判断します。
第2段階の移行プロセスでは、実装の設計から実際の移行作業までを行います。
第3段階のリリースプロセスでは、監視やセキュリティなどクラウド上の運用機能を付加し、本番運用を実施します。また運用をコンプライアンスに則って、滞りなく実施するためのガバナンスを整えます。
移行プロジェクトの全体ステップ
前項の移行プロセスを実際の移行プロジェクトに適用する際には、大きく6つのステップで実施します。
ステップ1：現状把握
アセスメントツールを利用して、移行対称の仮想マシンを検出し、それらのリソース使用状況を可視化します。
ステップ2：移行先選定
システムの実現性とコストの観点から、クラウドでの実装方法を選定します。
ステップ3：設計
クラウドでの実装方法を設計します。仮想マシンやネットワークだけでなく、認証や運用管理、セキュリティなどを含めた全体像を検討します。
ステップ4：検証
先行して一部の仮想マシンをAzureにテスト移行し、OSやアプリケーションの動作を確認します。また移行作業の手順が最適かを検証し、不具合があれば改善します。
ステップ5：移行
すべての移行対象をAzureへ移行します。
ステップ6：運用
Azure環境で本番運用します。ガバナンス適用を忘れてはなりません。
どんなプロジェクトでもそうですが、移行プロジェクトにおいても事前準備が最も大切です。その中でも目的を明確化することが重要です。
例えば、現状のアプリケーションを変更したくないが、機器のリプレースのタイミングなので数年間だけ運用を継続したい場合と、今後10年間進化させ続ける予定の戦略的システムを構築する場合とでは予算感も違いますし、実装方式も大きく変わってきます。移行体制もまったく違うでしょう。
目的を明確にし、それに見合った予算で、最適の方式を設計しないと、クラウドに移行しても期待したような費用対効果や価値が得られません。
ステップ1：現状把握で収集すべき情報
現状把握ステップでは、現在運用しているシステムの情報を集めます。収集すべき情報の例を表にまとめました。
Azure移行で収集すべき情報の例
| カテゴリ | 項目 |
|---|---|
| 既存サーバー環境 | ハイパーバイザーの種類、バージョン |
| 仮想マシン台数 | |
| CPU、メモリ、ディスクサイズ要件 | |
| 他のサーバーとのネットワーク依存関係 | |
| 可用性、冗長性 | |
| メンテナンスウィンドウ | |
| 通信、ネットワーク状況 | 必要なネットワーク帯域 |
| IP アドレス（変更可能かどうかも含む） | |
| セキュリティ | ファイアウォール |
| アンチウイルス | |
| サーバー OS | OS 種類、バージョン、パッチレベル |
| データベース | 種類、エディション、バージョン、パッチレベル |
| アプリケーション | サポートベンダ |
| その他・運用での注意点など | OS アップグレード可否、Azure エージェント追加可否 |
例えば、現在使用しているソフトウェアのバージョンによっても、移行ツールや考慮すべきポイントが変わってきます。
仮想サーバーのスペックの確認はもちろん、アプリケーションやミドルウェアのライセンスをAzureに持ち込めるかも重要な確認事項です。
ステップ2：移行先選定ではクラウドの形式を決める
移行先選定ステップでは、クラウドをどのような形で使っていくかを決めます。
セキュリティや柔軟性を最大にしたければ、プライベートクラウドを選択することになりますが、その分運用負荷が高くなります。
運用管理もクラウドベンダーに任せることで運用負荷を下げたいのであればパブリッククラウドを選択することになりますが、他社との共有環境になることとシステム利用に一部制限がかかることを受け入れる必要があります。
プライベートクラウドやオンプレミスの長所とパブリッククラウドの長所とを適材適所で組み合わせたいのであればハイブリッドクラウドです。しかし統一した管理基盤を準備するなど難易度が高い部分があることも覚悟しなければなりません。
このようにどの方式も一長一短ありますが、そもそもの目的に最も適う方式を選ぶことが大切です。
移行方法の選択はコストとモダナイズのトレードオフ
移行方法にはリホスト、リファクタリング、リアーキテクト、リビルドの4種類があります。
移行方法の選択肢
| リホスト | リファクタ | リアーキテクト | リビルド | |
|---|---|---|---|---|
| 特徴 | そのまま展開 | 最低限の変更 | 大幅な改修 | 一から再構築 |
| 目的 | 最短期間での移行 CAPEX の削減 |
短期間での更新 システム効率化 |
最新機能の導入 スケールとアジリティ |
イノベーション加速 DevOps 実現 |
| テクノロジ | IaaS | PaaS コンテナ |
PaaS サーバレス マイクロサービス |
PaaS サーバレス マイクロサービス |
| サービス | Azure VM | App Services Azure Kubernetes Service Azure SQL DB |
Azure Functions Cosmos DB |
Cognitive Service IoT Hub Machine Learning |
図の左に行くほど移行コストが小さくなり、右に行くほどクラウドネイティブといわれるモダンな、つまり将来にわたって使い続けられる可能性が高いシステムとなります。なお
リホストは、リフト＆シフト（L&S）ともいいます。
すべてをモダナイズする必要はありません。例えばサーバーのサポート期限が迫っているため迅速に移行したいシステムや、利用者が少ないなどの理由で資産価値の低いシステムはリホストが適切な選択肢です。またOSレベルのレイヤーを細かくカスタマイズしているためPaaSでは対応できないアプリケーションはリホストするしかありません。
またサイト間接続でハイブリッドな運用をしたい場合にも、IaaSレベルで実装するリホストが選択肢となります。Azureでは共用サーバーと専用ホストの2種類のサービスを提供しています。
ステップ3：設計での重要ポイント
設計ステップで考慮すべきポイントは多岐にわたりますが、ここでは最も重要であるネットワーク、認証、リソースオーガナイゼーション（リソース一元管理）について説明します。
本稿で紹介していない項目も、設計構築支援の一環として弊社でサポートできますので、ご相談いただければと存じます。
ネットワーク設計のポイント
外部公開するWebサービスに関しては負荷分散設計が重要になります。AzureではL4とL7のロードバランサーが用意されていますので、それらを適切に組み合わせたり、ロードバランサーにWAF（Web Application Firewall）の機能を付加したりして実装することになります。
グローバルなWebサービスであれば、CDN（Contents Delivery Network）の仕組みが不可欠です。AzureではCDNとWAFを兼ね備えたAzure Frontdoorというプロダクトを提供しています。
オンプレミスとAWSを接続する場合には、コストとセキュリティ要件の兼ね合いで、インターネットVPNか閉域網かどちらかを選択する必要があります。AzureではインターネットVPNとしてIPSec、閉域網としてExpressRouteを提供しています。
認証設計のポイント
意図せぬミスで重大なファイルが削除されてしまった。機密情報を一般社員や外部の人間に見られてしまった――このようなことを防ぐためにはユーザーの階層やグループなどによって適切なアクセス権限を設定できなければなりません。
Azureでは、サブスクリプションやリソースグループ等に対して、IDによって細かくアクセス権限を制御できるようになっています。
リソースオーガナイゼーション設計のポイント
ユーザーやリソースに適切なタグを付与することで運用管理の負荷が小さくなります。
例えば課金管理であれば、顧客、利用部門、費用負担部門などにAzureで発生したコストを細分化して表示できるようにする必要があります。このような場合は、課金管理のための適切なロールを割り当てて、「オーナー」「利用部門」「環境」「システム」「費用負担部門」などのタグ付けをします。また必要に応じて、ネットワークやサーバーなどのリソースにもタグ付けをします。
こうすることで経理的に見てスムーズに処理が流れていくようになります。またタグを見れば連絡先がわかるなどの利点もあります。
＼ もっと詳しく知りたい方はこちら ／
オンプレからAzureへの移行方法Azureへの移行ツールAzure Migrate
Azureでは移行のための機能を統合したリューションとして、Azure Migrateを提供しています。
Azure Migrateでは仮想マシンやデータベースなど様々な環境に対応をしており、事前のアセスメントから実際の移行の進捗確認までAzureポータルで集中管理することができます。
Azure Migrateによる仮想マシンの移行
たとえば仮想マシンを移行する際、Azure Migrateを使えば次のようなことが実現できます。
- 移行元となるオンプレミスや仮想基盤・他のパブリッククラウドに、どのような仮想マシンが存在するかリスト化する。
- そのリストのなかから移行対象となる仮想マシンを指定し、どのようなネットワーク通信がされているか、ネットワークの依存関係を可視化し、実際に動いているシステムの形を明らかにする。
- そのうえで移行先のマシンでは必要となるスペックや、ランニングコストを見積もる
- 既存環境に影響を与えないテスト移行を行い、トラブルが生じないか確認をしたあと本番移行に繋げる
Azure移行をする際は、是非Azure Migrateをうまく使うことをご検討ください。
Azure Migrateの移行シナリオ
Azure Migrateが対応するワークロード、移行元環境、移行先を表にまとめました。
| ワークロード | 移行元環境 | Azure 移行先 |
|---|---|---|
|
|
|
WindowsはもちろんLinuxサーバー・データベース・各種データ・Webアプリケーション・仮想デスクトップなど、Azure Migrateは幅広いワークロードに対応をしています。
移行元の環境としては、VMwareのハイパーバイザーを利用した環境、物理サーバからAzure以外のパブリッククラウドまで対応をしており、また移行先の環境については、IaaSの仮想マシンやPaaSで提供されているデータベースなどを利用することができます。最近リリースされたAzure VMware Solutionに対する移行にも対応をしています。
以降の際に使うツールはMicrosoftが提供する標準のもの以外に、3rdパーティが提供するより高機能・専門的なツールもAzure Migrateで利用することが可能です。
| Microsoft提供ツール | サードパーティー提供ツール |
|---|---|
|
|
Azure Migrateを知りたい方は是非こちらのブログもご覧ください。
Azureへの移行お助けツール！ Azure Migrateとは!? >
最後に
オンプレミスの環境をAzureに移行すると、クラウドの様々なメリットを受けることができます。
しかし、
- ただ単にクラウドに移行するだけでいいのかという不安がある
- 理想の基盤デザインに沿った構築ができるかどうかわからない
- 移行をどのように進めていけばよいのかわからない
そうお困りの方もいらっしゃるのではないでしょうか。
弊社では、そのような方に向けて、今後の運用も視野に入れたサーバのAzure移行支援を行っております。
豊富な知見を持った弊社エンジニアが移行前の計画から移行そのものまでをご支援しますので、安心して運用を開始していただけます。
まずはぜひお気軽にご相談ください。
お問い合わせはこちら※Microsoft社主催の「Azure Everywhere」対象キャンペーンとなります。
移行云々の前に、「クラウドに移行できるサーバがわからない」「Azure基盤のデザインから相談したい」「どこから手を付けたらいいか分からない」というお客様、無償のアセスメントキャンペーンもございます。ぜひご確認くださいませ。
無償アセスメントサービスは コチラ。
引き続き、お役立ていただける情報を発信していきますので、どうぞよろしくお願いいたします。
この記事を書いた人
-
こんにちは！日商エレクトロニクスでは、Microsoft Azure活用に関する有益な情報を皆様にお届けしていきます。Azure移行、データ活用、セキュリティなどに関するお困りごとや、Microsoft Azureに関する疑問点などお気軽にご相談ください。
ブログにしてほしいネタなどのリクエストもお待ちしております。
この投稿者の最新の記事
- 2024年3月27日ブログデータレイクとは？ ～DWHとの違い、メリット、活用例などをわかりやすく解説～
- 2024年3月6日ブログデータカタログとは？～機能、導入のメリット、導入方法まで解説～
- 2024年2月19日ブログMicrosoft Azure とは？基本概要、5大メリット、主要サービスを解説
- 2024年2月6日ブログ今さら聞けない「DWH」とは？ ～データベースやデータマートとの比較も含めて解説！～