先週開催された Build 2022 で日本向けセッションとして、ブチザッキの中の人ぶちぞう RD と三宅さんと自分の 3 人で Azure Updates と Azure Serverless を使ったモダンなアーキテクチャについて話してきました。
セッションの動画は既に公開されているので、Build 2022 のサイトから見ることが出来ます。
日本向けのテーブルトーク 1 発目だったからか、プロデューサーとかが完全に慣れていなかったようで、レコーディング開始が遅れた結果として自己紹介部分は失われています。
セッションの開始と終了がよく分からなかったというか指示がゼロだったので、30 分経過しても楽屋裏トークをしばらく続けていましたが、そこはカットされていました。当日参加されていた方限定トークです。
ブチザッキまとめとセッション動画
とりあえず Build 2022 での Azure アップデートはいつものようにブチザッキを読んでおけば良いです。
セッション動画は YouTube にもアップロードされていたので、こっちを埋め込んでおきます。
Teams を使って入る方式だったのでチャットも利用出来たのですが、アーカイブ動画には含まれていませんでした。続々と参加者の方が入ってくるのを見ているのは、オフラインイベントを少し思い出しました。
ここから先はいつものようにセッションの 30 分では話しきれなかったことを書きます。
App Service / Azure Functions アップデートまとめ
何故か App Service / Azure Functions は Build や Ignite のタイミングで大きなアップデートの発表は行わないので、今年の Build でも発表されたのはマイグレーション系中心でした。
直前に App Service Team のブログでも公開されたのですが、今回の Build では gRPC のサポートが大きなトピックとなります。ぶっちゃけ gRPC のサポートは些細なことで、重要なのは HTTP リバースプロキシの実装が YARP と Kestrel に変わることです。
Over the last few months Azure App Service has been upgrading the platform’s worldwide HTTP reverse proxy layer to leverage YARP and Kestrel.
既に数か月に亘って HTTP リバースプロキシの実装を YARP と Kestrel にアップグレードしているようです。gRPC サポートは Linux の App Service から実装されることが発表されているので、ここでいう HTTP リバースプロキシは Web Worker の内部でコンテナーに振り分けるために使われているものかなと思っています。
YARP が App Service で使われていることは、既に YARP 1.0 がリリースされた時に公表されていました。
Announcing YARP 1.0 Release - .NET Blog
- Alternatively, for highly custom environments the YARP request forwarder can be called directly, bypassing the routing, load-balancing modules etc. For example, this is how YARP is being used by Azure App Service for routing requests to specific instances, where the instances are spun up on demand.
これまでは Antares Proxy という自作っぽいリバースプロキシが使われていましたが、YARP と Kestrel にアップグレードされたことで HTTP/2 と gRPC に対応出来るようになったという話のようです。パフォーマンス向上はもちろん、今後は HTTP/3 や WebTransport などへの対応も期待できます。
そして予告編となりますが、将来的に YARP と Kestrel の採用によってマルチテナントの App Service でも TLS Cipher Suites を調整出来るようになるようです。
In the future, we also plan to add the ability for all developers to fine-tune an application’s supported TLS cipher suites, building upon the YARP + Kestrel adoption.
同じ YARP と Kestrel の文脈のようですが、TLS Cipher Suites は現在 ARR と IIS が担っている部分の話になるので、Web Worker の前段にあるリバースプロキシが YARP と Kestrel になることを示唆しています。
Kestrel で TLS Cipher Suites を調整するために利用する CipherSuitesPolicy クラスが Windows ではサポートされていないので、リバースプロキシの OS が Windows から Linux に変わることもほぼ確実でしょう。
ちなみに App Service Environment では TLS Cipher Suites は既に変更可能です。YARP と Kestrel の採用は ASE にも段階的に適用されていくのではないかと思います。
このように gRPC サポートだけかと思いきや、意外にドラスティックな App Service アーキテクチャの変更予告になっていたのでした。今後のアップデートが楽しみです。
Azure Functions に関しては Build のタイミングでは Durable Functions 周りのアップデートが多かったのですが、Azure Functions のエンジニアリングマネージャが Twitter でロードマップを書いていたので、こちらを参照した方が楽しいです。
In #azurefunctions our #1 priority is support the tens of thousands of customers who use the product everyday. We also continue to enhance the value prop, here is a thread of some features we have just released or going to be releasing in the next month or so. A thread:
— Anirudh Garg (@anirudhgarg) 2022年5月28日
Retry Policy がようやく GA することや、Private Preview 中の Target Based Scaling などが紹介されています。まだ Retry Policy が Preview だったことに驚いていますが、GA するのは素直に嬉しいです。
Azure Container Apps が GA
キーノートでも話がありましたが Azure Container Apps が GA です。同時に Japan East にも来たので日本国内から使いやすくなっていますし、いつの間にかにゾーン冗長のオプションも用意されていました。
思ったより GA まで早かったという認識なので、まだ機能が足りない部分もあると思いますが GitHub でフィードバックや不具合報告を行えるので、積極的に書いていきたいです。
セッション中に Container Apps の課金について話がありましたが、vCPU 秒と GiB 秒の組み合わせは若干分かり難いと思います。計算ツールが結構分かりやすい気がするので、こちらで計算するのが良さそうです。
1 つのコンテナーが vCPU を 1 か月の秒換算以上の秒数を消費することは出来ないので、そういう観点で計算すると 1 コンテナー当たりの最大料金を計算できるはずです。
実際にはアイドル状態もあるので、最大からは減ることが多いと思います。セッション中は半額ぐらいと言いましたが、確認したら 1/10 でした。ちなみにアイドル状態は以下のように定義されています。
A replica is active when vCPU usage is above 0.01 cores or when data received is above 1000 bytes per second.
Azure Container Apps - Pricing | Microsoft Azure
課金体系が処理時間によるものなので、Container Apps 向けのアプリケーションはパフォーマンスを意識して実装しないと、思わぬ課金が発生して驚くことになりそうです。アプリケーションの実装はもちろん、言語やフレームワークの選択も重要になりそうです。
Cosmos DB アップデートまとめ
個人的に激アツだったのが Cosmos DB のアップデートです。毎回 Cosmos DB は良いアップデートが多いのですが、今回は特にテンションが上がる機能がありました。
発表された中では Burst Capacity が待望の機能という感じでした。これまでも Autoscale や Serverless で RU 消費のスパイクへの対応が出来ていましたが、Autoscale は 1 時間単位での課金となり割高、Serverless は常時ある程度 RU が消費されるシナリオでは単価が高いため採用しにくいものでした。
Burst Capacity は現時点では過去 5 分間のアイドル RU を蓄積して、最大 3000 RU/s で消費出来るので Autoscale よりも効率的にスパイクへの対応が行えます。IoT 用途など遅延が発生しやすいシナリオでは、データが減った直後にまとまって流れてくることが多いので Burst Capacity が向いているはずです。
この仕様のまま GA されると、本番向けでは Autoscale + Burst Capacity の組み合わせが最適になると思います。まだ変更される可能性も高いですが、かなり期待の機能です。
Burst Capacity の Preview を利用するにはサインアップが必要になっていますが、同時に追加された Azure Monitor のメトリックは既に誰でも使えるようになっています。
追加された PhysicalPartitionThroughput メトリックを使うと物理パーティション当たりの RU/s を簡単に調べることが出来るので、急に 429 が発生するようになった場合に調査が楽になります。
もう一つは Partition Merge です。これを使うと断片化した Partition を解消することで、Cosmos DB 全体のスループットを改善することが出来ます。
PhysicalPartitionThroughput メトリックを見ると分かるように、Cosmos DB に割り当てた RU は物理パーティション単位で割り振られます。物理パーティションはデータサイズの上限があるため、ある程度のサイズになると Cosmos DB によって自動的に増えますが、TTL の変更やデータ削除によって断片化が発生します。
物理パーティションが多いと 1 つに割り当てられる RU が減るので、結果として 429 が発生する可能性が高まります。Partition Merge を行うことで 1 つ当たりの RU 割り当てを増やすことが出来るので、スループットが改善できるという仕組みです。
Cosmos DB のパフォーマンスを最適化する場合には物理パーティションへの理解が必須になって来た感があるので、暇な時にでもまとめておきたいと思います。
Service Connector が GA
最後は Service Connector に触れておきます。地味に面倒な Managed Identity や接続文字列の設定を自動でやってくれるという便利機能です。
Service Connector は単独のリソースとして提供されているので、Azure Portal 以外からでも利用できるのが特徴です。UI 上で実装された機能ではないという意味です。
GA した Azure Container Apps にも Preview として Service Connector が追加されています。
誰でも Service Connector を使うと安全な設定が簡単に行えるので便利なのですが、IaC との相性が少し不安なのと Azure Functions との連携が弱いのが残念なポイントです。
セッションで話したフィードバックは特に反映されていなかったのが残念です。Azure Portal からリソースを作成する場合は Service Connector を使い、Bicep や Terraform ではこれまで通りというのが良さそうです。
