Kubernetes Event-driven Autoscaling

Kubernetes Event-driven Autoscaling（イベント駆動オートスケーリング）は、CPU/メモリの使用率だけでなく、「処理すべきイベント量」（例：キューのメッセージ数、ストリームのラグ、外部サービスのリクエスト数など）に応じて Pod 数を増減させる考え方です。 Kubernetes 標準の HPA（HorizontalPodAutoscaler）でも外部/カスタムメトリクスを使ったスケーリングは可能ですが、イベントソース連携やスケール制御を“作り込む”必要が出やすい領域です。そのため実運用では、イベント駆動の代表的実装として KEDA（Kubernetes Event-driven Autoscaling）を用いるケースが多いです。 HPA を置き換えるのではなく、HPA と並走して機能を拡張する設計です。

何ができる？（価値）

外部イベントに合わせて 0 〜 N までスケールでき、アイドル時に scale-to-zero できる点が大きな特徴です。
スケール対象は Deployment / StatefulSet / Job だけでなく、/scale サブリソースを持つカスタムリソースにも対応します。
キューやデータベース、監視基盤など多様なイベントソースに接続する scaler（スケーラ）を利用できます。
公式サイトでは 70+ のビルトインスケーラがあることが示されています。

仕組み

KEDA は主に 2 つのコンポーネントで構成されます。

KEDA Operator
- イベントソースやスケール設定（後述の CRD）を監視し、ワークロードのスケール制御をオーケストレーションします。
Metrics Server（外部メトリクスアダプタ）
- HPA が参照できる形で external metrics（外部メトリクス）を提供し、HPA によるスケーリング判断を可能にします。

そして Kubernetes 側では、HPA がワークロード（Deployment など）を更新して Pod 数を調整する“標準の仕組み”が動きます。 HPA 自体は、定期的な制御ループでメトリクス API（resource/custom/external）を問い合わせ、目標値に合わせてレプリカ数を増減します。

運用上の注意点（重要）

Kubernetes の仕組み上、外部メトリクスアダプタは 1 つだけという制約があり、KEDA を使う場合は KEDA がその唯一の external metric adapter になる必要があると説明されています。
同一ワークロードに対して KEDA の ScaledObject と、別途作った HPA を併用するのは推奨されず、競合して不自然なスケール挙動になり得るとされています（KEDA は内部で HPA を使うため）。