Microsoft Azureのはじめ方（移行編）

小野友顕 - Microsoft MVP（Microsoft Azure カテゴリー）

はじめに

こんにちは、NRIの小野です。

オンプレミスからクラウドへの移行は多くのお客様で進んできており、私たちが受ける相談内容も単純な移行だけでなく、クラウドのメリットをより享受したい、より早く・より新しい機能を使うにはどうしたらよいかという内容に変化してきています。
一方で、これからクラウドを利用し始めるお客様もたくさんいます。
そのような方にとっては、クラウド移行にはどんな手段があるの？そもそも移行と一言で言われているけど何をする必要があるの？と心配になることが多くあると思います。

そこで今回は、Microsoft Azure（以下Azure）を例に「クラウドへの移行手段、移行に際して利用するサービス」をご説明したいと思います。

合理化の５R ～クラウドへの移行～

Microsoft社の「クラウド導入フレームワーク（Cloud Adoption Framework、以下CAF）」によると、”R”で始まる5つの単語で表されるクラウド移行の基本的な考え方（合理化の5 R）があります。

概念的な説明なのでわかりづらいのですが、私なりの解釈は以下の通りです。

クラウド移行の基本的な考え方（合理化の5R）

他のクラウドベンダーのフレームワークでは、同じ言葉でも含まれる範囲が違う場合もあります。そのため、言葉にとらわれすぎず、意味を意識して既存のデジタル資産を整理してクラウドへの移行方法を考えることが重要です。

また、CAFの5Rには明記されていませんが、以下の2つのRも大事な選択肢になります。「移行にメリットがない」あるいは「代替手段に置き換えることでシステム運用コストを大きく下げることができる」といった場合に取る選択肢です。

合理化の5Rには入っていないが考えるべき2つのR

Reduce、Reuse、Recycle…ゴミを減らす標語みたいですね。

さて、これらの"5R"について、R毎の移行の進め方や、利用するAzureのサービスは、CAFの中では明確に語られていません。そこで私なりの解釈を踏まえて、代表例や考慮ポイントを紹介します。

「5R」の押さえておくべきポイント

Rehost

「オンプレミスのサーバーをそのままAzureに移行し、Azure VMとして稼働させる」といった方法で移行を行います。「リフト＆シフト」とも呼ばれます。

オンプレミス側で、機器やデータセンター自体のEOSLを迎える場合や、「構成変更は難しいが、クラウドに移行済の別のアプリケーションと近い場所で稼働させる必要がある」といった場合に採用されます。

また、Azureでは「AzureにWindows Server 2012やSQL Server 2012を移行させるとサポート期限が延長となる特典」※もあり、このメリットをいかすために移行を検討されるお客様もいます。

SQL Server 2012 と Windows Server 2012 のサポート終了のオプション | Microsoft Base

クラウド利用を始めようと考える際に、まずこの「Rehost」から始めるお客様も多くおり、NRIでも下記のような事例があります。

野村信託銀行のオンプレミス上の半数以上のシステムを、Azure Site Recoveryを活用し、短期間で移行 | お知らせ | 野村総合研究所(NRI)

上記記事で紹介されている「Azure Site Recovery」のクラウド移行機能は、2023年現在、「Azure Migrate」という名前に変わっていますが、引き続き主流の方式となっています。

オンプレミスのアーキテクチャをそのままに移行させるため、移行コスト、アプリケーションの稼働確認テストも最小限に抑えることができます。一方で、性能面、特にストレージに関しては注意が必要です。一般的にクラウドのストレージはレイテンシが遅い傾向にありますので、性能テストなどを行いシステムの要件を満たすか十分に確認を行う必要があります。

Refactor

Rehostの次のステップとして、一部の機能をPaaS（マネージドサービス）に移行します。一部のアプリケーションコードを修正する必要がありますが、最小限の労力でクラウド活用のメリットを受けやすくすることができます。他のフレームワークでは「Replatform（リプラットフォーム）」と呼ばれることもあります。

Azureでは、SQL Serverのマネージドサービスである「Azure SQL Database」や、.NETのアプリケーションを実行することができる「Azure App Service」などを利用してPaaS化を進めます。移行における互換性の評価から、移行自体まで実行することが可能な「Azure App Service Migration Assistant」「Data Migration Assistant」といったツールが用意されています。

従来、「障害が起きた時の根本対策でしかパッチは当てていない」という運用が一般的におこなわれており、特にデータベースなどのミドルウェアはバージョンやパッチレベルを塩漬けにすることが多くありました。しかしPaaSを利用する場合、クラウドサービスの提供者により強制的にパッチが適用され機能強化なども行われます。
また、性能問題が出た場合の対策もRehostの場合よりも難しくなります。PaaSのサービス群はシングルスレッドではなく処理の並列化を行わないと性能を引き出しきれないことが多く、特に「夜間バッチ」のような処理と相性が良くない印象があります。強制パッチ適用や性能問題に対応するため、結果として、アプリケーションのレイヤに手を入れる必要が出て来てしまい、後述するRearchitectに近い修正が必要になることもあります。
以上のように、Refactorを行うかどうかは、移行時だけではなくその後の運用も含めて利用を検討する必要があります。

Rearchitect

システム構成に少し手を加えることで、クラウドのメリットを受けられるように再設計を行います。
例えばwebシステムを移行する場合、可用性ゾーンを跨るようにwebサーバーを配置し、Azure Load Balancerで負荷分散を行いながらシステムの可用性を向上させ、Azure 仮想マシンスケールセットを用いて負荷状況に応じて自動でスケーリングされるようにします。クラウドの機能を使ってDisaster Recovery（DR）機能を導入する、ということもあります。Azureの仮想マシンでは「Azure Site Recovery」のリージョン間同期機能をつかって、DR構成を簡単に追加することができます。

クラウドの各種機能を使えるようになる一方で、クラウドならではの検討事項が増えてきます。

例えば、多くの方が気にされるのはセキュリティや統制面です。
各サービス・機能間の通信がパブリックなネットワークを通っているのか、あるいは閉域で接続できているのか？各種データはどこに置かれていて、暗号化はされているのか？そのサービスには、どこから誰が接続できて、どんな操作（更新や読み取り）ができるのか？
また、コスト（クラウド利用料）も気になるところです。クラウドに適した設計をすることで、インフラコストを抑制することができます。逆に言えば、クラウド最適ではない単なるRehostをした場合、オンプレミスに比べてかえってトータルコストが上がってしまう場合も散見されます。
システムの移行・アプリケーションの改修にかかるコストと、削減できるクラウドの利用料や運用負荷を天秤にかけ、トータルで考えてどこまで変更を加えるか？とバランスを見ながら検討することが重要です。

Rebuild

Rearchitectより一歩進んで、アプリケーションを改修し、クラウドネイティブな形で再構築を行う、という考え方です。クラウドネイティブという単語は、CNCF(Cloud Native Computing Foundation)という団体により「CNCF Cloud Native Definition v1.0」というドキュメントで定義されています。

クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築および実行するための能力を組織にもたらします。このアプローチの代表例に、コンテナ、サービスメッシュ、マイクロサービス、イミュータブルインフラストラクチャ、および宣言型APIがあります。
これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。これらを堅牢な自動化と組み合わせることで、エンジニアはインパクトのある変更を最小限の労力で頻繁かつ予測どおりに行うことができます。
Cloud Native Computing Foundationは、オープンソースでベンダー中立プロジェクトのエコシステムを育成・維持して、このパラダイムの採用を促進したいと考えてます。私たちは最先端のパターンを民主化し、これらのイノベーションを誰もが利用できるようにします。

ただしCAFの中では、「マネージドサービスやPaaSをフル活用しましょう」というくらいのもう少し広い意味合いで使われているようです。

例えばサーバーで稼働させていたコンピューティング処理を、Azure FunctionsなどのFaaSや、Azure Logic Appsのようなサーバーレスアーキテクチャに移行させたり、アプリケーションをコンテナ化しAzure Kubernetes Service (AKS)を利用したり、Azure DevOps Servicesを用いてインフラのCI/CDを実現したりします。

アプリケーションの改修自体にもコストがかかるため、「オンプレミスからアプリケーションを単純に移行させたい」という場合にはRebuildのアプローチは過剰な検討かもしれません。実際には既存アプリケーションの移行で「Rebuild」までやることは少なく、クラウドネイティブを目指すのは新規アプリケーションの構築行う際にスモールスタートで…という方針の場合が多いのではないのでしょうか。
また、新しい知識が求められる側面が強く、システム構築・運用に関して技術者の教育というのも重要な観点になってきます。特にこれらのサービス領域は高頻度で機能追加・バージョンアップが進められていくため、学習・情報キャッチアップを行っていく継続的な体制が求められます。

Replace

「Repurchase（買い替え）」などとも呼ばれるアプローチで、既存のアプリケーションから、SaaSの利用に切り替えていきます。

例えば、オンプレミスでMicrosoft Exchange Server やSharePoint Serverを運用されていた企業は多いと思いますが、それらを「Microsoft 365」などのサービス利用に置き換える方式を指します。

Rebuildと同様に、これらのSaaSは、サービスが継続的にアップデートされ、使い方や機能が絶えず変化していきます。システムを作って終わり・データを移行して終わりにはなりません。従来のシステム運用とは違う意味での継続的な体制が必要になっていきます。また、システム障害が発生した場合などはサービス側で対応されることになるため、自社でできることが限られてきます。業務継続のための計画も、自社でコントロールできる範囲内でどうするか？といった観点で考える必要があり、従来の運用と異なってきます。