Azure Cloud Services（延長サポート）は2027年3月31日に廃止：WebロールとWorkerロールを移行する

MicrosoftはAzure Cloud Services（延長サポート）を2025年3月31日に非推奨とし、2027年3月31日に完全に廃止します。業務アプリケーションがWebロールとWorkerロールとして動いているなら、その日までにAzure上の別の場所で動いていなければなりません。廃止に関するFAQは、誰もが最初に尋ねる2つの質問にはっきり答えています。Microsoftは「延長の要請に応じることはできない」とし、「ワンクリックで移行できるツールはない」としています。

今日、2026年10月3日から数えて、残りは6か月です。

この記事の対象

典型的なケースはこうです。.NET Framework上のASP.NETアプリケーションで、前面にWebロールが1つ、その後ろでキューを処理するWorkerロールが1つか2つあり、8年から10年前に制作会社が作ったもの。制作会社はすでに手を引いていることが多く、アプリケーションはいまも受注処理や顧客ポータルを動かしていて、前回の移行以来、誰も.csdefファイルを開いていません。

影響を受けるかどうかを確認するには、Azureポータルを開き、種類が「Cloud services (extended support)」のリソースを一覧表示してください。Microsoftの廃止通知は、その画面に直接リンクしています。何もなければ、それで終わりです。

この記事は、2024年に廃止されたCloud Services（クラシック）についてのものではありません。ベンダーが製品をホストしているなら、移行はベンダーの仕事です。日付を書面で求めてください。以下はすべて、コードを保有しているチーム、あるいは書類上は保有していて、それを理解している人を探さなければならないチームのための内容です。

2024年の移行より難しい理由

多くの企業は、クラシックが廃止された2024年に延長サポートへ移行しました。その移行は、意図的に安く済むように作られていました。Microsoftの延長サポートの概要は、.csdef、.cscfg、.cspkgのファイルは「そのまま引き継がれ、形式に変更はない」とし、「ランタイムのコードに変更は必要ない」としています。インプレースでの移行さえありました。同じページは、進化を続けていないアプリケーションには延長サポートを勧めていました。「素早い移行の道筋を提供する」からです。

今回は、同等の移行先がありません。Microsoftの言葉では、Cloud Servicesは「アプリケーションをVMとしてデプロイするもの」であり、「書いたコードはVMのインスタンスと密に結合している」のです。コードは自分がロールの中で動いていることを知っています。ロールから設定を読み、ロールを通じてディスク領域を見つけ、ロールに証明書をインストールしてもらい、ロールが始まる前に管理者としてセットアップスクリプトを実行します。そのすべてを置き換えなければなりません。

公式のガイダンスを読む前に、もう1つ知っておくべきことがあります。Microsoftの廃止通知とFAQは、移行先としてService Fabricマネージドクラスターを1つだけ挙げています。概要のページは5つを挙げており、Microsoft自身の移行判断マトリクスは7つを比較しています。Service Fabricは既定の選択肢であって必須ではなく、多くのWebロールにとっては間違った選択肢です。

移行先と、それぞれが合う場合

WebロールとWorkerロールを同じ場所に移す必要はありません。ロールごとに移行先を選んでください。

App Service（Windows）。 ASP.NETアプリケーションにとって、Webロールに最も近いものです。Windowsのインスタンスにはサポート対象の.NET Frameworkのバージョンがインストールされているので、Web FormsとMVC 5は書き直さずに動きます。WorkerロールはWebJobsとして移すことができ、WebJobsは「Webアプリと同じインスタンスで」追加費用なしに動きます。限界はマシンそのものです。MicrosoftはCOMコンポーネント、レジストリへのアクセス、MSIインストーラーを必要とするアプリをManaged Instanceに誘導しているので、標準のプランでは、管理者権限のスタートアップタスクの行き場がありません。

App Service Managed Instance。 レガシーなWindowsのWebアプリのために作られたものです。Microsoftの概要によれば、「一部のリージョンでWindowsのWebアプリ向けに一般提供されている」もので、Pv4とPmv4のプランに限られ、.NET Framework 3.5と4.8がプリインストールされており、PowerShellのインストールスクリプトでCOMコンポーネントの登録、レジストリキーの書き込み、MSIインストーラーの実行、IISの設定ができます。管理者権限のスタートアップタスクがしていたことの大半はこれで賄えます。制約は、Webアプリのみ（WebJobsは不可）、コンテナー不可、Entra IDとマネージドIDのみ（ドメイン参加、NTLM、Kerberosは不可）で、執筆時点で一覧にある欧州のリージョンは北ヨーロッパだけです。

Container Apps。 最新の.NETに移した後のWorkerロールに向いています。キューに応じたスケーリング、スケジュール実行やイベントで起動するジョブ、ゼロまでのスケールインができます。ただしコンテナーの要件には「Linuxベース（linux/amd64）のコンテナーイメージが必要」とあります。.NET Frameworkのコードは、移植するまでそこでは動きません。

Azure Kubernetes Service。 WindowsノードプールでWindows Serverコンテナーを動かせるので、.NET Frameworkのロールをコンテナー化して移せます。判断マトリクスは、移行の複雑さと運用の負担をどちらも高いと評価しています。すでにKubernetesを運用しているなら合いますが、1つのレガシーアプリのために最初のクラスターを立てるものではありません。

仮想マシンスケールセット（VM Scale Sets）。 マトリクスはこれを「Cloud Servicesのモデルに近く、リフトアンドシフトがしやすい」と説明しています。VMが手元に戻ってきますが、ロールが代わりにやってくれていたパッチ適用、イメージのビルド、IISのセットアップも一緒に戻ってきます。

Service Fabricマネージドクラスター。 Microsoftが名指ししている移行先です。Workerロールはきれいに対応します。Webロールは対応しないことがよくあります。Service Fabricは「IISをサポートしていない」うえ、変換ガイドはASP.NET Web Formsを非サポートとし、ASP.NET Core MVCへの変換を道筋として挙げています。Service Fabricの移行ガイドはさらに、マネージドクラスターは「現在コンテナーをサポートしていない」としているので、IISに依存するアプリには従来型のクラスターが必要になり、運用するものが増えます。

判断表

コードで変わること

ソリューション全体でMicrosoft.WindowsAzure.ServiceRuntimeを検索してください。これをインポートしているファイルはすべて対象です。

RoleEntryPoint

Workerロールは、RoleEntryPointを継承してOnStart、Run、OnStopをオーバーライドするクラスです。Runが戻ると、インスタンスはリサイクルされます。Service Fabricは3つすべてを1つのRunAsyncにまとめており、これは「RunAsyncメソッドのCancellationTokenがシグナル状態になったとき」に止まるべきものです。App Serviceやコンテナーでは、同じロジックが、ループとキャンセルトークンを持つコンソールアプリケーションか、ホストされたバックグラウンドサービスになります。

見落とされがちなのはシャットダウンです。OnStopは、処理中のメッセージを終わらせる時間を与えてくれていました。新しいホストがキャンセルのシグナルを確実に渡すこと、そして処理の途中で放棄されたメッセージを二度処理しても安全であることを確認してください。

Webロールにも、たいていWebRole.csという形で同じものがあります。そのOnStartが何かをしているなら（IISの調整、キャッシュのウォームアップなど）、削除する前にそれが何かを突き止めてください。

RoleEnvironment

RoleEnvironment.GetConfigurationSettingValue("Key")は、.cscfgから設定を読みます。Cloud Servicesの外でこれを提供するものはありません。何かを移す前に、すべての呼び出しを1つの小さな設定用インターフェースで包み、新しいホストではそのインターフェースの参照先をアプリ設定、環境変数、Key Vaultに向けてください。プロジェクトの中で最も安い変更であり、それ以外の部分をノートパソコンでテストできるようにしてくれます。

ほかに探すべき使い方が3つあります。

• RoleEnvironment.Changed。再起動せずに設定の変更を反映していました。Service Fabricには同等のイベントがあります。それ以外では、設定の変更でプロセスが再起動すると考え、処理中の作業がどうなるかをテストしてください。
• RoleEnvironment.CurrentRoleInstance。スケジュールされた作業を担うインスタンスを1つ選ぶのに使われていました。トリガーされたWebJobは1つのインスタンスで動きますが、継続的なWebJobは制限しない限りすべてのインスタンスで動きます。どちらにするかを明示的に決めてください。
• RoleEnvironment.IsAvailable と IsEmulated による分岐。これらは「クラウド」の経路と「ローカル」の経路を分けており、どちらかがまもなくデッドコードになります。

.cscfgと.csdef

.cscfgは、環境ごとの設定、インスタンス数、証明書の拇印を保持しています。.csdefは、エンドポイント、VMのサイズ、ローカルストレージ、スタートアップタスク、証明書ストア、そして場合によっては1つのWebロールの中にある複数のIISサイトを保持しています。両方を1行ずつ確認し、各項目が移行後にどこに置かれるかを書き留めてください。アプリ設定、Key Vaultの参照、インフラのコード、あるいはどこにも置かない、のいずれかです。ロール同士が直接呼び合うための内部エンドポイントには、サービスのアドレスかキューという代わりが必要です。

証明書

延長サポートの時点で証明書はすでにKey Vaultに移されているので、2024年の作業のその部分は報われます。変わるのは、コードが証明書を見つける方法です。.csdefは証明書を名前付きのストアに、多くの場合LocalMachineにインストールします。WindowsのApp Serviceでは、WEBSITE_LOAD_CERTIFICATESの設定によって、証明書はCurrent User\Myで使えるようになります。LocalMachineのストアを開くコードは何も見つけられず、証明書が必要になった最初の呼び出しが失敗します。Linuxのコンテナーでは、代わりに起動時にKey Vaultから読み込んでください。

スタートアップタスク

Startup.cmdを開いてください。驚きが潜んでいるのはここで、たいていexecutionContext="elevated"で実行されています。PDF生成用のフォント、COMコンポーネント、IISのリライトモジュール、TLSのためのレジストリの変更などです。各行の行き先は3つです。もう不要か、Managed Instanceのインストールスクリプトに移すか、コンテナーやVMのイメージに焼き込むかです。

ローカルストレージ

.csdefのLocalStorageリソースは、RoleEnvironment.GetLocalResourceで読み取られ、各インスタンスに作業用のディスクを与えていました。本当に一時的なファイルには、プラットフォームの一時ディレクトリを使ってください。再起動後も残っていなければならないもの（誰かが永続的だと思い込んでいたファイルも含めて）は、Blob Storageに移します。

Web Forms

残りのすべてを左右するのがこの判断です。Web FormsはSystem.Webの上に作られており、ASP.NET Core版はないので、Web FormsのアプリケーションをService FabricやContainer Appsに移すことは、ユーザーインターフェースを書き直すことを意味します。App Service、Managed Instance、Windowsコンテナー、スケールセットなら、どれも変更なしで動かせます。そのまま移し、モダナイゼーションは独自の予算を持つ別のプロジェクトにしてください。UIの書き直しを、停止日に向けたクリティカルパスに載せるべきではありません。

その他

2つのクラウドサービス間のVIPスワップは、App Serviceではデプロイスロットに、Container Appsではリビジョンになります。診断（WAD）拡張機能で送っていたログには新しい送り先が必要で、通常はApplication Insightsです。標準のApp ServiceとContainer Appsにはリモートデスクトップがありません。Managed InstanceではAzure Bastion経由で使えますが、診断目的に限られます。

6か月計画

2027年3月31日から逆算し、途中に12月の休暇を挟みます。

10月：棚卸しと移行先の選択。 延長サポートのデプロイをすべて洗い出します。ロールごとに、.NET Frameworkのバージョン、Web FormsかMVCか、すべてのRoleEnvironmentの呼び出し、スタートアップタスク、ローカルストレージのリソース、証明書、エンドポイントを記録します。そのうえで、気の重い点を確認してください。手元のソースから、デプロイされているパッケージをビルドできるでしょうか。制作会社が作ったシステムでは答えが「いいえ」のこともあり、それを確かめるのが10月です。ロールごとに移行先を選びます。

11月：1つのロールをエンドツーエンドで。 設定用のラッパーを加え、移行先の環境をインフラのコードとして書き、1つのロール（たいていは最も単純なWorker）を、ログ、証明書、パイプラインを含めてテスト環境で動かします。

12月と1月：残りを移植する。 エントリーポイント、スタートアップタスク、ローカルストレージを置き換えます。本番に近いデータでステージング環境の負荷テストを行います。WebJobやコンテナーは、専用のロールVMのスループットに届かないかもしれません。

2月：並行稼働。 新しい環境を実際のトラフィックに対して動かします。古いロールとキューを共有するWorkerは、先に処理を冪等にするか、新しいWorkerを起動する前に古いWorkerを止めてください。

3月初め：切り替え。 余裕を持ってDNSを切り替えます。古いデプロイは止めたまま1、2週間そのまま残し、その後に削除します。切り替えを3月の最終週に予定しないでください。その時期に切り替えに失敗したら、2回目の機会はありません。

1月から始める場合は、モダナイゼーションを完全に諦めてください。コードの変更が最も少なくて済む移行先（App Service、Managed Instance、スケールセット）を選んで移し、リファクタリングはその後にします。

はっきりしていないこと

Microsoftは、このサービスが「完全に廃止」され、「サービスの中断を避ける」ために移行が必要だとしています。当社が読んだページには、2027年4月1日の時点でまだ動いているデプロイがどうなるかは書かれていません。それを確かめるつもりで計画しないでください。Managed Instanceのリージョンとプランも今後数か月で変わる可能性が高いので、この記事ではなく、判断する時点で確認してください。

ご相談先

当社は、他社が作ったアプリケーションを引き継ぎ、それがどう動いているかを解明し、移行します。棚卸し、ロールごとの移行先、RoleEnvironmentとスタートアップタスクの変更、そして切り替えです。.NET FrameworkとWeb Formsは、当社のレガシーシステムの保守の仕事で扱っています。自社のチームが移行を進めていて人手が足りないなら、スタッフ増強をご覧ください。

Cloud Servicesのデプロイを抱え、期限まで6か月なら、office@c9group.devまでご連絡ください。