既に Ignite 2022 が終わってしばらく経ってしまいましたが、App Service 周りで興味深いアップデートがひっそりと行われているので、Ignite の前後に発表された内容を含めて個人的に気になったものだけまとめます。
Ignite 2022 に合わせて発表された App Service のアップデートは、以下の公式ブログのエントリを参照して貰えれば大体把握できます。Azure Functions 向けにも同じようなエントリが公開されていましたが、ほぼ目新しいものはなかったので今回は含まれていません。
これまでのいくつか書いてきましたが App Service がリリースされてから 10 年が経過して、プラットフォームとアーキテクチャに流石に古さが見え始めてきたのですが、最近はプラットフォーム側への投資が凄まじい勢いで行われています。Web Worker の Cloud Services から VMSS への移行も順調に進んでいるようですし、そのタイミングで可用性ゾーンへの対応も果たしています。今後また 10 年戦う準備が出来つつあるなと、個人的には強く感じています。
既に膨大なユーザーコードが動作しているサービスのアップデートは困難を極めますが、App Service チームは確実に一つずつ乗り越えていっています。そういう点も私がサービスとチームを信頼している理由です。
個人の主観が入りまくった話はこのくらいにして、これからは個人的に気になったものをまとめていきます。
Frontend が Kestrel と YARP への移行
正確には Ignite 2022 の前に発表されたアップデートとなりますが、これまで App Service は TLS 終端や Web Worker へのリバースプロキシを実現する Frontend として、IIS と ARR を使って実装してきました。
10 年前は現実的に IIS と ARR を使う方法以外は存在しなかったので間違いではないのですが、今となってはパフォーマンスも他が非常に高くなってしまい、最新の機能にもなかなか追従できない状態でしたが、ついに ASP.NET Core の進化によって C# 実装の Kestrel と YARP で全て実現できるようになったという話です。
詳細は公式ブログを読んで欲しいのですが、ある程度補足しておくと IIS を Kestrel に、ARR を YARP に置き換えたという分かりやすい構図です。元記事では OS について情報がありませんでしたが、Kestrel を IIS の後ろに置くメリットと、Kestrel と YARP の組み合わせを Windows でホストする理由も存在しないので Linux に移行していると考えています。
同時に Linux Web Worker も Kestrel と YARP にアップグレードしたという話がありましたが、個人的にはこっちが先に行われた気配があります。
とにかく Frontend が Kestrel と YARP に移行されたことでパフォーマンスは大きく向上し、柔軟に機能が提供しやすくなるようです。予告されているだけでもエラーページのカスタマイズと後述する TLS Cipher Suite のカスタマイズがあります。今後のアップデートにも期待が高まります。
弱い TLS Cipher Suite の無効化
Frontend が Kestrel と YARP に移行したことで、これまで ASE のような占有環境でしか出来なかった TLS Cipher Suite のカスタマイズが、マルチテナントの App Service でもサポートされました。
まだプレビュー扱いなので、GA までに少し設定方法や内容が変わる可能性があります。
当然ながら Azure Portal から設定は出来ないので Azure CLI や ARM Explorer を使って行います。設定方法は詳しく書かないので、公式ブログのエントリを参照してください。
設定項目としては minTlsCipherSuite だけなので非常にシンプルです。このプロパティに TLS Cipher Suite 名を設定すると、リスト内での設定より上の TLS Cipher Suite のみが使われるようになります。ASE のように自由に指定することは出来ませんが、これで必要十分な機能だと思います。
昨今の事情を鑑みると、現実的には minTlsCipherSuite には TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 かTLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 のどちらかを追加することになると思います。現代の TLS セキュリティにはエフェメラルキーと認証付き暗号が必須となっているので、ECDHE と GCM が含まれた Cipher Suite を選ぶ必要があるからです。
何故かデフォルトのリストでは TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 を選んだ場合には TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 が上位にあるので使われる可能性があります。CBC モードは安全と見做されていないので GCM を優先して欲しいのですが謎です。
TLS Cipher Suite の話はこれくらいにして、実際に TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 を shibayan.jp の minTlsCipherSuite に設定した後の Qualys SSL Labs の結果が以下の通りです。
秘密鍵が RSA 2048bit なので RSA を指定していますが、楕円曲線暗号を使えば ECDSA が利用可能になるはずです。以前 App Service に ECC 証明書のアップロードを蹴られてから試していませんが、少なくとも Key Vault 経由なら動作するはずです。
現時点で確実に Weak 扱いの Cipher Suite を排除できるのは RSA の時だけっぽいです。
HTTP ベースのオートスケーリングサポート
実際には去年の時点でプレビューが開始されていましたが、今年中に Azure Portal から簡単に設定できるようになるという予告です。
App Service はオートスケーリングには CPU 使用率やメモリ使用量といった一般的なメトリックを使っていましたが、App Service でも Azure Functions のように HTTP リクエスト数ベースでのオートスケーリングに対応しています。ただし Portal が未対応だと設定が少し面倒です。
基本的なスケーリングアルゴリズムは Azure Functions で HttpTrigger を使った時と同じだと期待できますが、そもそもアルゴリズムの詳細が公開されていないので、どのようなタイミングで発動するのか若干謎です。単純に HTTP リクエスト数だけではなく、それ以外のメトリックも参照していると思いますが、もう少し情報が欲しいですね。
Web アプリケーションでは HTTP リクエスト数でのオートスケーリングが出来た方が楽なケースが多いので、この機能自体には期待しています。Azure Portal とアルゴリズムの詳細情報が公開されるのを待ちます。
Node 18 LTS / PHP 8.1 / Python 3.10 サポート
この辺りは最近定番となって来た Early Access を利用したサポートが追加されたという話です。ちなみに Node 18 LTS だけは Windows でもサポートされています。
Windows の場合は Node 18 LTS を選んでも、実際には Node.js 18.3.0 が使われるので LTS ではない罠があります。Linux を選んだ場合には LTS 版が使われるようになるはずです。
例によって Early Access なので初回は Docker Image のプルが走るので少しオーバーヘッドが発生しますが、その後は Web Worker が変わらない限りキャッシュされるので無視できます。将来的には App Service OS のアップデートで事前にキャッシュされるようになります。
App Service での Go 再サポート
少し驚いたのが App Service の Linux 版で Go の実験的なサポートが追加されました。昔は Windows にも Go がインストールされていて利用出来たのですが、需要が無かったということで廃止された経緯がありました。
こちらも他の追加された言語と同じく Early Access 扱いなので、コールドスタートには注意しましょう。
ベースに使われている Docker Image と Dockerfile が不明なので、どのような形式でデプロイすると動くのか少し疑問です。Oryx でビルドされるのかどうかという点も気になります。
ASE v3 (Isolated v2) に更に大きな SKU が追加予定
元々の ASE v3 でも 8 vCPU / 32GB までインスタンスサイズを選ぶことが出来ましたが、今年中にさらに大きなインスタンスとして 16 vCPU / 64 GB、32 vCPU / 128 GB、64 vCPU / 256GB の 3 種類が追加されるようです。命名規則的には I[4-6]v2 となると思われます。
CPU とメモリ搭載量の関係から、Dv4 か Dv5 が内部的に使われることになるのかと思います。オンプレからの移行で Windows Containers を利用する場合には、より多くの CPU とメモリが必要になることが多いため、主な用途は移行と大規模なコンテナー向けかと考えています。
Azure Portal のアップデート
最後には軽い話題を持ってきました。夏あたりから Azure Portal の App Service 設定に Preview 付きの項目が増えています。最近は Custom domains と Certificates のアップデートが多かったです。
最近新しく見つけたのは Networking の中にある Access Restriction のプレビュー版です。この Networking 設定自体も少し前に大幅リニューアルしたので、中身も改善していくようです。
思ったよりも大きく変更されているので、実際に触ってみてもらいたいです。他のサービスと同様にパブリックアクセスを一括で無効化する設定が用意され、ARM レベルでもプロパティが追加されていたのでネットワーク周りは今後も手が入りそうです。
