kubernetesaks
· 読了 10分

KEDA + AKSでスケーリング設計を再考する

HPAとの使い分けと、イベント駆動スケーリングの実運用パターンをまとめて比較。Azure Service Bus・Prometheus・CRONスケーラーの具体的な設定例付き。

HPAだけでは足りないケース

HPA（Horizontal Pod Autoscaler）はCPU/メモリベースのスケーリングには十分ですが、以下のケースには不向きです：

  • キュー消費ワーカー：メッセージ数に応じてPodを増減させたい
  • バッチ処理：深夜だけPodを立てて昼間はゼロにしたい
  • 外部メトリクス：Prometheus の custom metric やDBのコネクション数に反応させたい

KEDAはこれらをシンプルな ScaledObject 定義で解決します。

KEDAのアーキテクチャ

External Source (Service Bus / Prometheus / etc.)
       ↓
  KEDA Scaler (trigger評価)
       ↓
  ScaledObject → HPA (replicaCount調整)
       ↓
  Deployment (Pod増減)

KEDAはHPAを置き換えるのではなく、HPAのメトリクスソースを拡張するツールです。ScaledObjectを作るとKEDAが裏でHPAを自動生成します。

AKSへのインストール

# Helmでインストール
helm repo add kedacore https://kedacore.github.io/charts
helm repo update

helm install keda kedacore/keda \
  --namespace keda \
  --create-namespace \
  --set podIdentity.azureWorkload.enabled=true

Workload Identity連携を有効にしておくと、Azure Service BusへのアクセスにシークレットなしでManaged Identityが使えます。

スケーラーパターン3選

1. Azure Service Busスケーラー

メッセージ数に応じてワーカーPodをスケールアウト。Workload Identityで認証。

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: servicebus-worker-scaler
spec:
  scaleTargetRef:
    name: message-processor
  minReplicaCount: 0   # ゼロスケール許可
  maxReplicaCount: 20
  pollingInterval: 15
  cooldownPeriod: 60
  triggers:
    - type: azure-servicebus
      authenticationRef:
        name: keda-workload-identity
      metadata:
        queueName: order-processing
        namespace: myservicebus.servicebus.windows.net
        messageCount: "5"  # 5メッセージにつき1 Pod

2. Prometheusスケーラー

カスタムメトリクスに基づくスケーリング。リクエストレイテンシやエラーレートをトリガーにできます。

triggers:
  - type: prometheus
    metadata:
      serverAddress: http://prometheus.monitoring.svc:9090
      metricName: http_requests_total
      query: sum(rate(http_requests_total{service="api"}[2m]))
      threshold: "100"  # 100 req/s につき1 Pod

3. CRONスケーラー（スケジュールスケーリング）

業務時間帯だけPodを立てる。ゼロスケールと組み合わせてコスト削減に。

triggers:
  - type: cron
    metadata:
      timezone: Asia/Tokyo
      start: "0 8 * * 1-5"   # 月〜金 8:00
      end: "0 20 * * 1-5"    # 月〜金 20:00
      desiredReplicas: "3"

ゼロスケール運用での注意点

minReplicaCount: 0にすると最大のコスト削減ができますが、コールドスタートが発生します。初回リクエストが遅い場合の対策：

  1. Readiness Probe を短くする：アプリ起動を高速化
  2. ScaledJob を使う：バッチ処理は ScaledObject より ScaledJob が適切
  3. minReplicaCount: 1 に変える：常時1台待機でコールドスタート回避

HPAとの使い分けまとめ

条件推奨
CPU/メモリだけでスケールできるHPA のみ
キューのメッセージ数に反応したいKEDA
夜間ゼロスケールしたいKEDA (CRON)
外部カスタムメトリクスKEDA
PrometheusメトリクスKEDA

まとめ

KEDAはHPAの上位互換ではなく、イベントソースの豊富さが強みです。Service Bus / SQS / Kafka / Prometheusなど50以上のスケーラーが揃っているため、「何かのイベントに反応してPodを増やしたい」という要件はほぼ全部カバーできます。AKSであればWorkload Identityとの相性も良く、導入コストは低めです。

← 一覧に戻る