しばやん雑記

Azure Serverless とメイドさんが大好きなフリーランスのプログラマーのブログ

Azure Cloud Services (Classic) のリタイア予定と PaaS のインフラが VMSS へ移行されている話

PDC 2008 で Azure が発表された時から存在していた純粋な PaaS と言える Cloud Services (Web Role / Worker Role) ですが、ついにリタイアの日程が 2024/8/31 に決まったようです。

今では Cloud Services を直接利用しているケースはかなり少ないと思いますが、Azure のコアサービスを支える屋台骨として内部ではかなり利用されています。リタイアに伴って依存していたサービスも同時にリタイアするようなので、詳しくは世界のブチザッキを確認してください。

厳密には ARM に対応した Cloud Services (extended support) が存在していますが、ダラダラ塩漬けにするよりも気合入れて App Service や Container 対応した方がメリットが多いはずです。

今回リタイアが発表されていないサービスでも、内部では Cloud Services にべったり依存しているものが存在します。大体は VMSS への移行が進んでいるので振り返っておきます。

Cloud Services から VMSS へ変わったもの

VMSS は単純な VM とは異なり、PaaS 寄りの機能を持っているので PaaS と IaaS の間ぐらいに存在しているサービスという認識です。直接使うのは面倒ですが、PaaS のインフラとしては良い感じです。

App Service (Web Apps / Azure Functions)

Cloud Services に依存しているサービスの代表格が App Service です。App Service も今となっては Azure の初期からあるサービスで、当時は VMSS なんて便利なものはなかったので Cloud Services ベースです。

とはいえ最近は Premium V3 の追加のタイミングでインフラ周りが大幅に更新されています。Premium V2 の時も Regional VNET Integration への対応でアップデートが行われましたが、Premium V3 は劇的な変更です。

既に何回か Cloud Services から VMSS に変更になったことを書いていますが、既存のリソースに対しては VMSS 対応が行われていないので、Cloud Services がリタイアする前には全てが VMSS ベースにアップグレードされるのでしょう。そうじゃないと困るので、この辺りはスケジュール公開待ちです。

VMSS ベースになることでシステムのドライブレターが変化するので、Cloud Services 前提で D:\ を触るようなコードを書いていると急に動かなくなる可能性もあります。ドライブレターを決め打ちにせずに、環境変数 SYSTEMDRIVE などを使うようにしましょう。詳しく知りたい方は以下のエントリを参照してください。

既に VMSS ベースの App Service は広く展開されてテストされているので、ドライブレターに依存したコードを書いていない限りは互換性に関して特に心配はないでしょう。

Cloud Services ベースから VMSS ベースへの切り替えが完全に自動的に行われるのか、それともタイミングをある程度制御できるのかは気になるところです。ぶっちゃけ個人的にはさっさとコスパに優れた Premium V3 に移行してしまうのをお勧めしています。

App Service Environment

意外にインパクトが大きいと思うのが App Service Environment v1 と v2 が同時にリタイアすることです。ASE v3 のリリースに時間がかかったこともあり、かなりのケースで ASE v2 を使っていると考えられますし、要件的にもアーキテクチャの大幅な変更が難しいケースで使っていることが多そうです。

アナウンスにも記載のある通り ASE v3 は VMSS ベースとなっています。従って構成はマルチテナントの App Service とほぼ同じになっていると考えて良さそうです。

ASE v3 はデプロイに 2 時間以上かかるのと、マルチテナントの App Service でネットワーク周りの機能が大幅に強化されたため試してはいません。完全に VNET 内に閉じる必要がある場合のみ検討する予定です。

自動マイグレーション機能が提供されていますが、ASE が必要なアプリケーションに対して気軽に実行できるものではないですし、そもそも日本リージョンに非対応なので新規に ASE v3 を作成して移行するのが安全でしょう。このタイミングで Availability Zones への対応や App Service への移行も検討して損はないです。

API Management

若干意外かもしれませんが API Management も Cloud Services に依存したサービスの一つです。

Consumption は App Service 上で動いているので、自動的に VMSS ベースに切り替わると思いますが、それ以外のプランでは作成した時期によって VMSS かどうかが決まります。

App Service は VMSS ベースに変更したい場合は新しく Premium V3 の App Service Plan を作成して、丸ごと作り直す必要がありますが API Management は設定を変更すると VMSS ベースの stv2 に移行できます。

若干移行の方法に癖があるので詳しくは公式ドキュメントに任せますが、ネットワーク周りの新機能を使おうとすると大体 VMSS になるようです。

手動で移行を行わなくても Cloud Services がリタイアする前に、自動で VMSS ベースにアップグレードが行われると思いますが、stv1 で作ってしまわないように ARM Template や Bicep で新規作成する際には API バージョンを注意しておきたいです。

おまけ : 最初から VMSS だったもの

当たり前ですが VMSS がリリースされた後に公開されたサービスは、大体が VMSS ベースになっているはずです。分かりやすいところでは AKS や Service Fabric は VMSS 上に構築されています。Cloud Services は Availability Zones に対応していないので、AZ 対応サービスは大体 VM か VMSS が使われています。

つまり AKS を基盤にしている Container Apps や Service Fabric を基盤にしているはずの Cosmos DB なども、同様に VMSS ベースで提供されていると考えられます。なので Azure のサービスは既に多くが VMSS ベースになっているっぽいです。

Azure の PaaS / Serverless を利用していると、インフラ側の進化に最小の労力で乗っかっていけます。今後も共同責任モデルに則って、良い感じに楽できる部分は全力で楽していきましょう。