オンプレミスに構築したシステムをAzureに移行する際には、最適な手順と考慮すべきポイントがあります。今回の記事ではその手順とポイントをまとめています。最適なコストと方法で失敗なくAzureへの移行を実現したい方は、是非お読みください。

移行の基本プロセス

Azureへの移行は、大きく3段階のプロセスで実施します。

Azure移行の基本プロセス
Azure移行の基本プロセス

第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

Azure移行コスト

図の左に行くほど移行コストが小さくなり、右に行くほどクラウドネイティブといわれるモダンな、つまり将来にわたって使い続けられる可能性が高いシステムとなります。なお
リホストは、リフト&シフト(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 Migrate

Azureでは移行のための機能を統合したリューションとして、Azure Migrateを提供しています。
Azure Migrateでは仮想マシンやデータベースなど様々な環境に対応をしており、事前のアセスメントから実際の移行の進捗確認までAzureポータルで集中管理することができます。

Azure Migrateによる仮想マシンの移行

たとえば仮想マシンを移行する際、Azure Migrateを使えば次のようなことが実現できます。

  • 移行元となるオンプレミスや仮想基盤・他のパブリッククラウドに、どのような仮想マシンが存在するかリスト化する。
  • そのリストのなかから移行対象となる仮想マシンを指定し、どのようなネットワーク通信がされているか、ネットワークの依存関係を可視化し、実際に動いているシステムの形を明らかにする。
  • そのうえで移行先のマシンでは必要となるスペックや、ランニングコストを見積もる
  • 既存環境に影響を与えないテスト移行を行い、トラブルが生じないか確認をしたあと本番移行に繋げる

Azure移行をする際は、是非Azure Migrateをうまく使うことをご検討ください。

Azure Migrateの移行シナリオ

Azure Migrateが対応するワークロード、移行元環境、移行先を表にまとめました。

ワークロード 移行元環境 Azure 移行先
  • Windows サーバー
  • Linux サーバー
  • データベース
  • 各種データ
  • 仮想デスクトップ
  • ウェブアプリケーション
  • VMware
  • Hyper-V
  • 物理サーバー
  • Amazon Web Services
  • Google Cloud
  • 他パブリッククラウド
  • Azure VM
  • Azure SQL データベース
  • Azure App Service
  • Azure VMware Solution

WindowsはもちろんLinuxサーバー・データベース・各種データ・Webアプリケーション・仮想デスクトップなど、Azure Migrateは幅広いワークロードに対応をしています。
移行元の環境としては、VMwareのハイパーバイザーを利用した環境、物理サーバからAzure以外のパブリッククラウドまで対応をしており、また移行先の環境については、IaaSの仮想マシンやPaaSで提供されているデータベースなどを利用することができます。最近リリースされたAzure VMware Solutionに対する移行にも対応をしています。

以降の際に使うツールはMicrosoftが提供する標準のもの以外に、3rdパーティが提供するより高機能・専門的なツールもAzure Migrateで利用することが可能です。

Microsoft提供ツール サードパーティー提供ツール
  • Azure Migrate: Server Assessment
  • Azure Migrate: Server Migration
  • Azure Migrate: Database Assessment
  • Azure Migrate: Database Migration
  • Azure Migrate: Web App Assessment
  • Azure Migrate: Web App Migration
  • Databox
  • Movere
  • RackWare
  • Cavonite
  • Corent
  • Cloudamize
  • Device42
  • Lakeside
  • RiverMeadow
  • Trubonomic
  • Flexera
  • UnifyCloud
  • Zerto

Azure Migrateを知りたい方は是非こちらのブログもご覧ください。

Azureへの移行お助けツール! Azure Migrateとは!? >

最後に

オンプレミスの環境をAzureに移行すると、クラウドの様々なメリットを受けることができます。
今回の記事でご紹介したクラウド移行の6つのステップ、「現状把握」「移行先選定」「設計」「検証」「移行」「運用」それぞれを、日商エレクトロニクスではご支援することができます。
もしクラウドの活用をお考えであれば、簡単な内容でも構いませんのでお気軽にお問い合わせいただけますようお願いします。
お問合せはこちら

この記事を書いた人

NE + Azure 編集部
NE + Azure 編集部
日商エレクトロニクス特設サイト「日商エレ+Azure」サイトマスターです。