今年はシアトルから変わってシカゴで開催されている Ignite ですが、例によってキーノート開始してすぐに各種サービスのアップデートが発表されましたね。今年も例によって AI 周りの発表が多いのですが、しっかり App Service / Azure Functions / Container Apps 周りも重要なアップデートがあったので、自分の興味がある部分に特化して確認しました。
個人的には Flex Consumption の GA と Durable Task Scheduler の Limited Early Access が一番熱い発表で、この 2 つに関しては別途エントリを個別に書こうかと思っています。
Ignite 2024 で発表されたものだけではなく、その直前に公開されたものも含めていますが .NET 9 や Node.js v22 など言語サポートのアップデートは省いています。
App Service
前回同様に Ignite 2024 で発表された App Service のアップデートまとめブログが公開されているので、これを読んでおけば Ignite 前に発表された内容も一気に把握できます。
.NET 9 や Node.js v22 サポートの追加は Ignite 前に行われていたものです。Java 周りもアップデートがまとめられていますが、これも Ignite 前に発表があったものですね。
App Service on Linux の Sidecar が GA
Windows の App Service で言うところの Site Extensions に相当する Sidecar container 機能が App Service on Linux で GA になりました。APM やキャッシュに使うシナリオが多く紹介されています。
最近だと Phi-3 をホストした Sidecar をデプロイして、App Service から使うチュートリアルが結構話題になっていた気がします。今回 Sidecar が GA したため、Docker Compose ベースのマルチコンテナーは恐らく廃止になると思います。
E2E 暗号化と最小 TLS Cipher Suite が GA
デフォルトで App Service の Frontend から Web Worker までの通信は HTTPS で暗号化されていないのですが、その部分を含めて HTTPS で暗号化する E2E 暗号化オプションが Windows と Linux で GA しました。設定には Standard 以上の SKU が必要になります。
同時に最小 TLS Cipher Suite の構成についても Windows と Linux で GA しています。Frontend での対応なので Web Worker 側の OS には依存しない仕組みで、Kestrel ベースに書き直されたことで実現されています。こちらについては Basic 以上の SKU で利用可能になっています。
マルチテナントの App Service でも安全性の高い GCM を使う Cipher Suite を強制出来ます。
Unique Default Hostname が GA
Subdomain Takeover 対策となる Unique Default Hostname が App Service に関しては GA しました。このタイミングで Azure Functions でも Public Preview になりましたが、Azure Portal ではまだ指定できません。
Bicep や Terraform から使う方法については以下のエントリで書いていますので参考にしてください。
Unique Default Hostname を利用すると App Service 名が Global スコープから Region スコープに変わるため、別リージョンであれば同名の App Service が作れることに注意してください。
Availability Zones サポートの改善が 2025 年に
今回は予告だけになりますが 2025 年の初頭に App Service の Availability Zones サポートが大幅に改善され、App Service を作成した後からも AZ を有効に出来るようになります。そして SLA 99.99% の要件が 3 インスタンスから 2 インスタンスになるため、これまでよりも低いコストで可用性の要件を満たしやすくなります。
そして現在 2 インスタンス以上で運用している環境は、プラットフォーム側のアップデートによって Availability Zones が有効化出来るように変更されるようです。
これまで作成した後から Availability Zones の有効化が行えなかったので、最初から 3 インスタンス以上で構成する必要がありコスト面でのインパクトが大きかったですが、今後はサービスの成長に伴って AZ を有効化出来るようになります。
Azure Functions
毎回 Azure Functions は対応言語のアップデートが中心で、あまり大きなアップデートは発表されないのですが、今年は Flex Consumption と Durable Task Scheduler というかなり大きなアップデートがありました。
対応言語などについてはまとめブログを読んでおけば問題ありません。.NET 9 や .NET 8 の In-Process サポートが紹介されていますが、特に後者は Ignite 感はありません。
Flex Consumption が GA
今回のアップデートの目玉が Build 2024 で Public Preview になっていた Flex Consumption の GA です。新規に開発された Legion バックエンドにより非常に高速なスケーリングを実現しています。これまでの Consumption Plan の弱点であった VNET Integration にも対応しているため、今後は Linux で Azure Functions を動かす場合には Flex Consumption 一択になる予感です。
GA の時点では Availability Zones をサポートしていませんが、Flex Consumption の仕組みから考えると後から有効化出来るようなものになる気配です。2025 年初頭にサポートが予定されています。
既に Azure Portal では Flex Consumption が一番選びやすい位置に表示されているので、Azure 的にも Flex Consumption を強く推しているのが分かります。
GA で Flex Consumption はスケーリング上限がこれまで Stamp レベルに制限されていたのが、Region レベルに拡大されたようです。それによりバースト時のスケーリングでリソースが更に確保しやすくなっているようです。以下のブログでは Flex Consumption の技術的側面が一部解説されているため非常に面白いです。
Flex Consumption の詳細は公式ドキュメントもアップデートされているので、こちらも利用前には参照しておくと良いです。まだ制限がいくつか残っているため App Service Plan 感覚で使うとはまりそうです。
ただし現時点では Japan East / Japan West の両方で Flex Consumption が利用できず、直近の拡大予定リージョンにも含まれていないため時間がかかりそうです。非常に残念ですが Japan East / Japan West のキャパシティが足りていないのが原因と聞いています。
Durable Task Scheduler が Limited Early Access
もう一つの大きな Azure Functions アップデートは Durable Task Scheduler です。これまで Durable Functions を利用する際には Azure Storage / MSSQL / Netherite という 3 つのバックエンドから選択する必要があり、そのバックエンドにはパフォーマンス上の制限や個別にリソースを準備して設定する必要があり運用面で手間がかかる部分がありました。
そして Observability の観点では現状の Azure Portal で確認出来る Orchestrator ログは貧弱で、詳細を確認するには Durable Functions Monitor などを追加でデプロイする必要がありましたが、今回 Limited Early Access になった Durable Task Scheduler を使うと全て解決します。
Durable Task Scheduler は完全に Azure マネージドとなっているため、運用に関しては任せっぱなしでほぼ必要ありません。パフォーマンスに関してはこれまで最速の Netherite よりも良いため機能面ではメリットしかありません。ちなみに .NET 8 In-Process はサポート外のようです。
気になるのは価格がどのように設定されるかですが、恐らく Event Hubs のように Throughput Unit に近い概念が導入されて、その数によって課金されるのではないかと見ています。個人的には Azure Storage か Durable Task Scheduler の 2 択になると考えています。
Container Apps
最近あまり目立っていない Container Apps ですが、Serverless GPUs 始め大きなアップデートがありました。基本的には AI 文脈での新機能が多いですが、アプリケーション開発でも役立つ機能が追加されています。
これまでは AKS でしかサポートされていない機能が Container Apps にも実装されている感じなので、個人的には AKS を無理して使う機会はもう無いなという気持ちです。
Serverless GPUs が Public Preview
待望と言える Serverless GPUs が Public Preview となりました。これまでも Workload Profile を使うと GPU インスタンスをプロビジョニング出来ていましたが、今回の機能は Serverless と付いているだけあって、完全な従量課金で GPU インスタンスを利用できるようです。
利用するには最初に GPU クオーターの申請が必要になるため、正直なところそこが最初で最大のハードルになっています。Container Instances の GPU サポートよりも圧倒的に使い勝手が良いはずなので、Azure 上で GPU が必要な場合はこの方法が主流になっていくと思います。
Dynamic Sessions (Python / Custom container) が GA
信頼できないコードを実行するサンドボックス環境として利用可能な Container Apps の Dynamic Sessions が Python と Custom container を利用するケースで GA となりました。Code Interpreter と組み合わせて利用するのがメインのシナリオですが、ユーザーが入力したコードを安全に実行する場としても使えます。
Python と Custom container は GA しましたが、Node.js の Code Interpreter サポートが Public Preview で新たに追加されています。JavaScript の安全なサンドボックス実行環境も利用シナリオが多そうです。
Private Endpoint が Public Preview
正直なところこれまで使えなかったんだという感じですが、Container Apps の Private Endpoint 対応が Public Preview となりました。Workload Profile 環境が必須になるので注意が必要ですね。
元々 Internal な Container Apps は作成できてたじゃないかという話ですが、Private Endpoint が使えるようになると Front Door Premium から Container Apps へのセキュアな接続が実現できるメリットがあります。
主なユースケースとしては Front Door Premium からのセキュアな接続のようです。Internal な Container Apps との使い分けを上手くやっていく必要があります。
Planned Maintenance が Public Preview
コンピューティング系の PaaS では珍しめですが、Azure 側でのメンテナンスが行われる期間をある程度指定できる Planned Maintenance が Public Preview になっています。App Service などでは事前通知だけですが Container Apps は都合の良いメンテナンス期間を指定できます。
メンテナンス期間を指定してもクリティカルなアップデートについては随時行われるため、この機能に頼りっぱなしになるのではなくアプリケーションの実装やアーキテクチャでアップデート時の影響を最小限に出来るように作る必要があります。
HTTP Path-based Routing が Early Access
Container Apps に付いてくる HTTP Ingress で Path-based Routing を行う機能が Early Access になりました。Container App Environment 単位でルーティングを定義して、特定の Container App にトラフィックを流すことが簡単に出来るようになります。
まだ Azure Portal や Azure CLI でのサポートはありませんが ARM Template や Bicep では managedEnvironments/httpRouteConfigs というリソース作成すれば利用可能です。
これまで Container Apps で HTTP の Path-based Routing を実現するには Front Door や Application Gateway を前方において、バックエンドの Container App へリクエストを振り分けるといった実装が必要でしたが、今回のアップデートで将来的には Container Apps だけで実現出来るようになります。
