先週開催された Microsoft Build 2024 は去年同様メイントピックは Generative AI でしたが、Azure Serverless 周りのアップデートが去年以上に発表されました。現地参加ではみたいセッションが被りすぎていてキャッチアップが遅れてしまうことが多いので、帰国してからアップデートまとめは書くようにしています。
自分は基本的に Azure の中でも PaaS / Serverless にしか興味がないので、今回も App Service / Azure Functions を中心に気になったアップデートをまとめておきます。
今年は珍しく Azure Functions の個別セッションがあり、アップデート自体もかなり多かったのが印象的です。詳細は後述しますが App Service についても Windows Server 2022 へのアップデートに伴って TLS 1.3 がサポートされるなど、まだまだ動きはありそうです。
App Service
Build では App Service のセッションもありましたが、AppCAT と呼ばれているアセスメントツールや Copilot for Azure 連携といった機能が中心が、App Service のプラットフォームに関する内容はほぼありませんでしたが、内部的な改善を伴うアップデートは日々行われています。
確認出来る範囲では、App Service のインフラは全て VMSS ベースにアップデートされて、OS も Windows Server 2022 にもアップデートが行われたため
Zone Redundant 有効化時の SLA が 99.99% に
これまでは App Service のデプロイ時に Zone Redundant を有効化して、3 インスタンスをデプロイしても SLA は 99.95% のままで変わらなかったのですが、ついに 5/1 から 99.99% に SLA が更新されました。
SLA は 99.95% のままでしたが、実際の可用性という観点では確実に向上していましたが、この度 SLA が 99.99% となったのでエンタープライズ向けで AZ 構成を選択しやすくなったのではないかと思います。
TLS 1.3 サポートが GA
前述した通り App Service のフロントエンドが Windows Server 2022 ベースに一通り更新されたことで、TLS 1.3 がデフォルトで有効化されています。最近のブラウザは TLS 1.3 に対応しているので、既に使われている可能性が高いです。
ちなみに TLS 1.2 の時と同様に最低の TLS バージョンは指定できますが、TLS 1.3 を無効化することは出来ません。現状は最低 TLS バージョンを 1.2 にしておくのがベターです。
TLS Cipher Suite の優先順がアップデート
App Service のフロントエンドが YARP + Kestrel で書き直されてからサポートした TLS Cipher Suite の設定ですが、初回リリース時は何故か GCM より CBC が使われる TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
の優先度が高くなっていて、安全な設定とは言い難いものになっていましたが、今回のアップデートで CBC よりも GCM が優先されるようになりました。
この TLS Cipher Suite の設定自体は現在も Public Preview のままなので本番での利用は注意が必要です。なかなか GA にならない機能ですが、今年中の GA を期待しています。
Windows での gRPC / E2E 暗号化が Public Preview
去年の時点で Linux の App Service ではサポートされていましたが、今回のタイミングで Windows の App Service でも gRPC と E2E 暗号化がサポートされるようになりました。
Linux では gRPC を使う場合に HTTP20_ONLY_PORT
という特別なポートを参照する必要がありましたが、Windows 向けのドキュメントでは HTTP 2.0 Proxy と E2E 暗号化を同時に有効化することで、特別なポートを参照しなくても使えるようになっている可能性があります。
今後 E2E 暗号化を含めて、この辺りは追加で検証をしてみたいところです。
Azure Functions
最初の方に書いた通り、今年は Azure Functions のアップデートが非常に多く、今後のアーキテクチャ設計を左右する Flex Consumption が Public Preview になったことで注目度が高いです。Build では Azure Functions だけのセッションがあるぐらいでしたので、かなり力が入っています。
それ以外にも Generative AI が関係する機能が追加されていますが、個人的には Python 関連への投資がされているという感覚があります。
Flex Consumption が Public Preview
待望の Flex Consumption Plan がついに Public Preview となりました。去年の Ignite で Private Preview が開始されたので、その時から試していましたが Public Preview のタイミングでリージョンも増えました。
あまりここで詳細を書くつもりはありませんが、Flex Consumption のインフラは Container Apps でも使われているものと同じで、現時点で最大 1000 インスタンスまでの非常に高速なスケーリングと、VNET Integration がサポートされているのが大きな特徴です。
Flex Consumption については Project Legion と呼ばれる、新しいインフラについても公開されているので、別でしっかり検証してまとめる予定です。
これで Linux の Consumption と Functions Premium を利用するユースケースの大半は、Flex Consumption に移行することになるはずです。カスタムコンテナーには対応していないので、その点では Functions Premium が残ることになると思いますが、Consumption を使うことはほぼなくなるでしょう。*1
Container Apps ホスティングが GA
同じインフラを使っているので実質 Flex Consumption と同じなのでは、という気持ちがある Azure Functions の Container Apps ホスティングが GA しました。Container Apps には Dapr や Container Apps Jobs といった Azure Functions に近い機能がありますが、Azure Functions の開発体験と機能を維持したまま、Container Apps と同じ環境にデプロイ出来るのは大きなメリットです。
Container Apps でのホスティングの場合は常に Docker Image を作成する必要があるので、通常の Run From Package に慣れているとその部分だけ少し面倒ではありますが、Container Apps を使うということはそういうものです。
Node.js での HTTP Streaming サポートが GA
最近は OpenAI の応答向けでも需要が高まっている HTTP Streaming サポートが GA しました。Azure Functions がアーキテクチャ的に全てのトリガーを gRPC 経由で扱っていたのを、HttpTrigger
だけ HTTP のまま直接 Worker で処理させる仕組みなので、アップロードとダウンロードの両方で効果があります。
Node.js の HTTP Streaming サポートについては、Public Preview の際にブログにまとめているのでこちらも参照してください。GA しても機能的な差はないはずです。
OpenAI のシナリオだけではなく、ファイルのアップロード・ダウンロードでも効いてくるのでお勧めです。前述の通り gRPC を経由しないのでパフォーマンス面でも有利な可能性があります。
Python での HTTP Streaming サポートが Public Preview
Node.js の HTTP Streaming と同じ仕組みで Python でも HTTP Streaming サポートが Public Preview となりました。HTTP を扱う部分が FastAPI がベースとなっていて、追加のパッケージが必要になっています。
紹介のブログでもやはり OpenAI のストリーミングがサンプルで上がっているので、現在の大きなユースケースとしては Server Sent Events ということになりますが、こちらの方が仕組み上パフォーマンスが良い可能性があるのは変わりません。
Python での SDK Type バインディングが Public Preview
C# ではサポートされているのですが、Python でも Azure SDK で提供されている型をバインディングで受け取る機能が Public Preview となりました。現状は Blob Storage のみサポートしていますが、今後は Queue なども来そうな予感です。
SDK Type バインディングの嬉しいところは、別途クライアントをシングルトンで管理する必要が無く、接続文字列についてもバインディング側で解決できることにあります。
特に Blob の場合はアップロード時にメタデータを追加するシナリオも多いので、直接 BlobClient
を扱いたいケースは多かったはずです。
Container Apps
去年とは異なり、今年は Container Apps 関連のアップデートは少なめでした。機能追加や改善はイベントに関係なく行われるのが App Service 関連の特徴ではあるのですが、ここまで少ないのは少し意外でした。
前述した Azure Functions の Container Apps ホスティングも新機能とは言えますが、個人的に気になったのは Dynamic Sessions ぐらいでした。
Dynamic Sessions が Public Preview
実際には Build の数日前に発表されてしまったのですが、Container Apps に Dynamic Sessions という機能が追加されました。正直名前からどのように使うものなのかが想像しにくいと思いますが、Container Apps の特徴である高速なスタートアップと高度な分離を利用して、LLM などが生成したコードを安全に分離された環境で動かすためのものです。
Dynamic Sandbox とかのがしっくりきそうな気はしますが、Code Interpreter などで生成された信頼できない Python コードを、分離された環境で瞬時に実行できるため安全に扱えるというメリットがあります。
LLM が生成したコード以外にも、ユーザーが入力したコードも同じように安全に扱えそうです。
Static Web Apps
Build のタイミングでは 1 つしか発表が無かった Static Web Apps ですが、実は 3 月に Distributed Functions の追加や Next.js サポートが強化されていたので、今回は順当なアップデートという感じです。
Dedicated Plan が Public Preview
これまで Static Web Apps には Free と Standard という 2 つの Plan が存在していましたが、今回 Dedicated Plan が新しく追加されました。名前の通りコンピューティングリソースを占有するもので、SWA の特徴であるグローバル分散はなくなりますがデータ保管場所を固定しつつ、Managed Functions の Always On が実現されています。
これまで East Asia をリージョンに指定しても、静的なアセットは全てのリージョンに分散してデプロイされていましたが、Dedicated Plan では指定したリージョン内に留まります。これでデータの国外持ち出し禁止といった条件をクリア出来るようになり、更に Always On 対応の Managed Functions は Next.js などのフレームワークを使った際のパフォーマンス改善が期待できます。
*1:場合によっては廃止の可能性もある