今年も Microsoft Build 2025 に現地参加していますが、例によってキーノートでは全く触れられていない PaaS / Serverless 系のアップデートは多いので、自分の興味のある機能を中心に簡単にまとめます。
最近は AI 関連の機能に押されがちなのですが、App Service や Azure Functions は AI アプリケーションのワークロードを支える重要な部分なので、順当にアップデートが行われています。特に App Service は少し前に VMSS への移行が完了しているので、いろいろ手を入れやすくなってそうな気配です。
最近の App Service や Azure Functions は小手先の機能追加ではなく、足回りとなる PaaS 基盤の大規模なアップデートが行われているのでかなり気合が入っていることがわかります。
App Service
Azure の PaaS 基盤として割と枯れてきた App Service ですが、今回の Build 2025 の前後で魅力的なアップデートが発表されています。新しい Tier だけではなく、ネットワーク周りも Hybrid Connection Manager の新バージョンや IPv6 への対応が着々と進んでいます。
それ以外にもキーノートでも話が合った SRE Agent への対応も注目ですね。新しい言語バージョンへの対応も淡々と行われていますし、今年の夏には .NET 10 の Early Access が提供される予定のようです。
Premium V4 が Public Preview
Ignite 2020 で Premium V3 が発表されてから早 5 年、そして Build 2023 でメモリ最適化インスタンスと P0V3 が追加されていますが、今年の Build 2025 では新しい Premium V4 が Public Preview となりました。最新世代の VM インスタンスが使われていて、全てが AMD ベースとなっています。
現在は Public Preview 中かつ、段階的にロールアウトが行われているようなので利用可能なリージョンは限られますが、Azure CLI で以下のコマンドを叩くと一覧で確認可能です。
az appservice list-locations --sku P0V4 -o table
基本的には Premium V4 はこれまでの Premium V3 の VM アップグレード版となるので、機能面での差は特になく Windows と Linux の両方で利用可能になります。例によって現時点では新しく作成した場合のみ利用可能で、既存の App Service Plan を Premium V4 に切り替えることはほぼ出来ません。
但し Premium V4 はこれまでの App Service Plan とは異なり、Outbound IP アドレスが固定化されなくなり Azure Functions の Consumption Plan と同じように動的に変わるようになりました。ドキュメントにも以下のように記載されていて、Outbound IP アドレスの固定が必要な場合は NAT Gateway が必要です。
The Premium V4 tier lacks stable outbound IP addresses. This behavior is intentional. Although Premium V4 apps can make outbound calls, the platform doesn't provide stable outbound IPs for this tier. This differs from previous App Service tiers. The portal shows "Dynamic" for outbound IP addresses for Premium V4 apps. ARM and CLI calls return empty strings for outboundIpAddresses and possibleOutboundIpAddresses. If Premium V4 apps need stable outbound IPs, use Azure NAT Gateway for predictable outbound IPs.
Azure Portal 上も Dynamic という表示になりますので、外部サービスのファイアーウォール設定が必要な場合は NAT Gateway の追加コストが発生しますが、最近は Outbound IP アドレスがあまりにも多くなってきていたので、NAT Gateway を使った方が安心ではあります。
ちなみに Azure 内で完結する場合は Outbound IP アドレスを使うのではなく、Service Endpoint や Private Endpoint を使ってアクセス元を制限するようにしてください。
2 Availability Zones サポートが GA
少し前に App Service でも 3 つの Availability Zones にデプロイすることで 99.99% の SLA が得られるようになりましたが、今回の Build 2025 のアップデートで 2 つの Availability Zones だけでも 99.99% の SLA になりました。これまでと違いコストが 2 倍で済むので非常に使いやすくなっています。
そして大きな変更点としては既存の App Service Plan の Zone Redundancy を後からオンオフ出来るようになりました。最初はスモールスタートで 1 インスタンスかつ 1 ゾーンで運用を開始して、サービスが大きくなるにつれて可用性を高めたいというケースは多いはずなので、今回のアップデートは待望の機能です。
以下のドキュメントで変更方法が公開されていますが、自分が試した範囲ではまだ利用出来ませんでした。Azure Portal でもまだ変更できないので、機能自体がデプロイ中の予感です。
ちなみに Zone Redundancy のオンオフが出来るかどうかは App Service Plan によるので、非対応の Scale unit に当たってしまっている場合は再デプロイが必要になります。対応した App Service Plan かどうかは Azure CLI などを使って maximumNumberOfZones プロパティの値を確認する必要があります。
.NET Aspire サポートが Public Preview
Azure Functions に続いて App Service でも .NET Aspire サポートが Public Preview になっています。.NET Aspire サポートによって App Service にデプロイするアプリケーションでも依存関係の解決などが簡単に行えるようになります。
仕組みが Azure Functions と App Service は同じなので使い勝手はほぼ同じのようです。App Service 側のアップデートというよりも .NET Aspire 側のアップデートになります。
Azure Functions
Azure Functions についても App Service と同じ基盤で動くオプションがあるので、Premium V4 などの恩恵をそのまま受けることが出来るようになっていますが、Build 2025 で発表されたものとして重要なのは Flex Consumption Plan 関連のアップデートになります。
Flex Consumption は GA となっていますが、まだサポートされていない機能や Public Preview の機能が多いので今後のアップデートにも期待です。それ以外には各言語のアップデートなどが順当に行われています。
Flex Consumption を利用可能なリージョンが拡大
これまで Flex Consumption は GA していても限られたリージョンでのみで利用可能でしたが、Build の少し前に大幅にリージョンが拡大されて東日本でも利用可能になりました。
いろいろなチャネルからフィードバックを上げていましたが、ようやく東日本でも使えるようになったのは嬉しいですね。西日本ではまだ利用可能になっていませんが、少し前に西日本は AZ がサポートされたこともありますし、キャパシティ面での問題が解消されつつあるので近いうちに来ると考えています。
Flex Consumption で 512MB インスタンスが Public Preview
これまでの Flex Consumption は 2048MB と 4096MB のインスタンスサイズが用意されていましたが、Flex Consumption のスケーリングはリージョン単位でインスタンス合計サイズの上限が決まっているため、小さいアプリケーションの場合スケーリングの効率が下がっていましたが、512MB を使うとこれまで以上のスケーリングが実現出来ます。
特に Azure Functions の場合は小さいアプリケーションをデプロイするケースが多いと思うので、512MB インスタンスを使う機会が増えるのではないかと思います。
Flex Consumption で Availability Zones サポートが Public Preview
Azure Functions で従量課金のオプションで Zone Redundancy を有効化することは出来ませんでしたが、Flex Consumption が今回一部のリージョンで Zone Redundancy を有効に出来るようになりました。しかも後から変更することも出来るので柔軟に設定可能です。
まだ東日本では AZ を有効化することは出来ませんが、Flex Consumption の AZ は Cosmos DB などのサービスとは異なり、有効化してもコストが変わることが無いので非常に使いやすいものになっています。
SQL Trigger の Consumption Plan サポートが GA
Azure Functions の SQL Trigger 自体は既に GA していましたが、Consumption Plan はサポートされていませんでした。スケールコントローラが対応していないと Consumption Plan への対応とは言えない事情がありますが、v3.1.284 以上でサポートされました。
SQL Database へのアクセスはプライベートネットワークに閉じている場合は Consumption Plan では上手く動作しない気配があります。Flex Consumption サポートとは言っていないのが気になりますが、将来的には正式対応されると考えています。
Python での HTTP Streaming サポートが GA
Ignite 2024 で Python を使った場合の HTTP Streaming サポートが Public Preview になっていましたが、Build 2025 では GA となり安心して使えるようになりました。
LLM 利用時にはレスポンスのストリーミングが必須なので、今回のリリースはかなり重要だと思います。
OpenTelemetry サポートが Public Preview
これまで Application Insights へのテレメトリ送信はこれまで独自のプロトコルでしたが、OpenTelemetry への対応が Public Preview で追加されています。今回は珍しく全ての言語で最初からサポートされているので広く試すことが出来ます。
OpenTelemetry を使うことで Application Insights 以外にも、OTel に準拠したサービスに送信することが出来るようになっています。OTel を使うことでカスタマイズ性は高まっていますが、現在は非対応の機能も多く存在しているので注意が必要です。
Container Apps
ここ最近の Container Apps は足回りのアップデートはあまり多くなく、Azure の PaaS / Serverless の中では AI 関連の機能が多く実装されている印象があります。特に GPU を必要とするシナリオでは Container Apps が Serverless で GPU が使えるのは大きなメリットです。
AI 関連以外ではネットワーク周りのアップデートが目立ちます。足回りのコンピューティングについては大きなアップデートはないので、割と安定してきている気がします。
Dedicated GPU サポートが GA
Container Apps の Serverless GPU は既に GA していましたが、今回の Build では Dedicated GPU が GA となりました。常に GPU を使い続ける必要があるようなワークロードに最適なオプションとなります。
利用される GPU VM は NC A100 v4 ベースとなるので、NC シリーズでの最新世代となります。SKU は以下のドキュメントにもあるように複数用意されているので、VM をデプロイして管理するよりも簡単に GPU インスタンスを扱えるのはメリットです。
Dedicated GPU は Workload Profile な Container App Environment である必要があるので注意が必要です。オンデマンドで使う用途ではこれまで通り Serverless GPU を使っていただくのがベストですが、パフォーマンスを重視する場合は Dedicated GPU を使うことになります。
Dynamic Session の Serverless GPU サポートが Early Access
正直なところ Container Apps 感が無い機能である Dynamic Session ですが、Serverless GPU 付きで動かす機能が Early Access となっています。
これを使うことで LLM が生成した Python コードが GPU を使う場合でも、完全に分離された環境内で安心して利用できるようになっています。
Native Azure Functions サポートが GA
Azure Functions のホスティングオプションとして Container Apps が選べますが、これまでは Azure Functions を作成しても裏側の Container Apps リソースが作成されるので、1 つの Azure Functions を作成すると 2 つのリソースが存在する形になっていました。
今回の Native Azure Functions サポートで裏側の Container Apps リソースが作成されず、Azure Functions リソースだけになるため設定や管理が行いやすくなっています。
もちろん Container Apps の機能は全てサポートされているので、安心して Native Azure Functions へ移行することが出来ます。リソースの作成時に kind プロパティで functionapp を指定するだけなので、移行自体も簡単に行えます。
既に Azure Functions を Container Apps でホスティングしている方は、今回の Native Azure Functions サポートへ移行するのがお勧めです。
Private Endpoint サポートが GA
Contianer Apps は標準の機能で Public IP を持たない Private 専用の環境を作成することが可能ですが、Front Door のようなグローバルリソースでは Private Endpoint を使わない限り Private 接続が行えませんでした。今回 Private Endpoint 対応が GA したので安心して利用できるようになりました。
Public Preview 中は対応していませんでしたが、GA のタイミングで TCP も利用できるようになっています。Private Endpoint はテナント間でも利用できるので、複雑なシナリオでも VNET Peering を使わずに実現できるケースも多いかと思います。
Premium Ingress が Public Preview
デフォルトで用意されている Container Apps の Ingress はコストが発生しない代わりに、割り当てられているコンピューティングリソースに上限があり、最大のスケーリングも 10 までとなっています。ほとんどのケースでは十分だと思いますが、それ以上のスケーリングが必要なケースのために Premium Ingress が Public Preview となりました。
Premium Ingress はデフォルトの Ingress とは異なり、特定の Workload Profile に紐づくためインスタンスサイズやスケーリングも柔軟に設定可能です。Premium Ingress ではタイムアウト設定など細かく制御が可能なので、そのあたりの調整を行いたい場合にも利用できます。
但し Premium Ingress は Workload Profile にデプロイする必要があるので、デフォルトの Ingress とは異なり追加のコストが発生します。この点だけは注意が必要ですね。
Rule-based Routing が Public Preview
これも Ingress に関係しますが、これまでホスト名単位でそれぞれの Container Apps にルーティングされるのが基本でしたが、Front Door などのように HTTP のカスタムドメインやパスベースで細かくルーティングを定義出来るようになりました。
カスタムドメインを使う場合には少し手間が発生しそうですが、簡単なルールであれば Front Door や Application Gateway を追加する必要が無く、Container Apps だけで完結出来るため柔軟に対応できますしコストも最適化出来そうです。
