MicrosoftはAzure Container Apps上で動作するAzure Functionsに対し、カスタムKEDAスケールルールのオーバーライド機能を正式サポートした。allowScalingRuleOverride プロパティを true に設定するだけで、Service Bus・Kafka・Cronをはじめとする60以上のKEDAスケーラーを自由に組み合わせられる。プラットフォームが自動生成していたスケールルールを超え、きめ細かなスケール制御が現実のものとなった。

KEDAとAzure Container Apps——基礎の整理

KEDA（Kubernetes Event-driven Autoscaling）は、Kubernetes上でイベント駆動型のオートスケールを実現するOSSプロジェクトで、現在はCloud Native Computing Foundation（CNCF）のインキュベーションプロジェクトとして管理されている。Azure Container AppsはこのKEDAを基盤に持っており、キューの深さ・メッセージ数・HTTPリクエスト数などのメトリクスに応じてコンテナのレプリカ数を0から自動的にスケールアウト・スケールインする仕組みを提供してきた。

これまでAzure Container Apps上のAzure Functionsは、Functionsランタイムが自動的に適切なKEDAスケールルールを生成していた。この自動化は便利な反面、「もっと複雑なスケーリング条件を設定したい」「複数のトリガーを組み合わせたい」というニーズに応えられなかった。

何が変わったのか——allowScalingRuleOverride の効果

今回の新機能の核心は allowScalingRuleOverride プロパティだ。このプロパティを true に設定すると、Functionsランタイムが自動生成するスケールルールへの依存をやめ、ユーザー自身が定義したカスタムKEDAスケールルールが適用されるようになる。

具体的には以下のことが可能になる：

  • Service Bus スケーラー: キュー内の未処理メッセージ数に基づいてワーカー数を制御
  • Kafkaスケーラー: コンシューマーグループのラグ（遅延）に応じてスケール
  • Cronスケーラー: 時間帯や曜日ベースでのスケジュール制御
  • 複合スケールルール: 複数のスケーラーを AND/OR 条件で組み合わせるカスタム構成

60以上のKEDAスケーラーが利用可能であり、MySQLやPostgreSQLのクエリ結果、Prometheusメトリクス、外部HTTPエンドポイントの値などを基準にスケールさせることもできる。

設定方法の概要

azure.yaml または Bicep/ARM テンプレートでの設定例は以下のようなイメージだ（実際のスキーマはドキュメントを参照）：

出典: この記事は Custom KEDA Scale Rules for Azure Functions on Azure Container Apps の内容をもとに、筆者の見解を加えて独自に執筆したものです。