KEDA（Kubernetes-based Event Driven Autoscaler）は、Kubernetesのオートスケーリング機能を拡張するオープンソースプロジェクトです。Kubernetesの組み込みのHorizontal Pod Autoscaler（HPA）はCPUやメモリに基づくスケーリングに優れていますが、KEDAはキューの深さやAPIトラフィックなど、カスタムメトリクスに基づいてスケーリングを可能にすることで、さらに一歩進んでいます。

KEDAが注目される理由は以下の通りです：

  • イベント駆動型スケーリング：リソース使用量だけでなく、実際のイベントに反応
  • ゼロからヒーロー：負荷がないときはゼロポッドからスケール
  • メトリクスの柔軟性：Prometheus、Azure Monitor、AWS CloudWatchなど、さまざまなソースからのメトリクスを使用可能
  • 簡単な統合：既存のKubernetesデプロイメントとシームレスに連携

KEDAの始め方

KEDAを試してみたいですか？セットアッププロセスを見てみましょう：

1. KEDAのインストール

まず、クラスターにKEDAをセットアップしましょう。Helmを使うと簡単にインストールできます：


helm repo add kedacore https://kedacore.github.io/charts
helm repo update
helm install keda kedacore/keda --namespace keda --create-namespace

または、YAMLを使いたい場合：


kubectl apply -f https://github.com/kedacore/keda/releases/download/v2.8.1/keda-2.8.1.yaml

2. ScaledObjectの定義

次に、スケーリングの方法を定義します。KEDAは、スケーリングの動作を決定するためにScaledObjectというカスタムリソースを使用します。以下は、RabbitMQキュー内のメッセージ数に基づいてデプロイメントをスケールする例です：


apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: rabbitmq-scaledobject
  namespace: default
spec:
  scaleTargetRef:
    deploymentName: my-deployment
  pollingInterval: 15
  cooldownPeriod:  30
  maxReplicaCount: 30
  triggers:
  - type: rabbitmq
    metadata:
      queueName: myqueue
      host: amqp://guest:[email protected]:5672/
      queueLength: "5"

このScaledObjectは、"my-deployment"デプロイメントを"myqueue" RabbitMQキューの長さに基づいてスケールするようにKEDAに指示します。キューに5つ以上のメッセージがある場合、KEDAはデプロイメントをスケールアップします。

KEDAの実践：実際のシナリオ

KEDAが活躍する実用的なユースケースを見てみましょう：

シナリオ1：APIトラフィックスケーリング

APIが断続的なトラフィックの急増を経験する場合を想像してください。KEDAを使用すると、受信リクエスト数に基づいてスケールできます：


apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: api-scaler
spec:
  scaleTargetRef:
    deploymentName: api-deployment
  triggers:
  - type: prometheus
    metadata:
      serverAddress: http://prometheus.monitoring:9090
      metricName: http_requests_total
      threshold: "100"
      query: sum(rate(http_requests_total{job="api-gateway"}[2m]))

この設定は、2分間のウィンドウで受信リクエストのレートが1秒あたり100を超えると、APIデプロイメントをスケールします。

シナリオ2：バッチジョブ処理

バッチ処理ジョブの場合、保留中のタスク数に基づいてワーカーをスケールできます：


apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: batch-job-scaler
spec:
  scaleTargetRef:
    deploymentName: batch-worker
  triggers:
  - type: postgresql
    metadata:
      connectionFromEnv: POSTGRES_CONNECTION
      query: "SELECT COUNT(*) FROM jobs WHERE status='pending'"
      targetQueryValue: "10"

このScaledObjectは、PostgreSQLデータベース内の保留中のジョブ数に基づいてbatch-workerデプロイメントをスケールします。

KEDAをマスターするためのプロのヒント

KEDAの旅を始めるにあたり、以下のヒントを心に留めておいてください：

  1. 小さく始める：非クリティカルなワークロードから始めて、KEDAの動作に慣れましょう。
  2. 注意深く監視する：スケーリングパターンを監視し、トリガーを微調整しましょう。
  3. HPAと組み合わせる：KEDAはHPAと一緒に使用することで、さらに柔軟なスケーリングが可能です。
  4. コスト最適化のためのスケーリングジョブを使用する：作業がないときにデプロイメントをゼロにスケールすることで、コストを節約できます。
  5. カスタムスケーラーを探求する：組み込みのスケーラーがニーズに合わない場合、カスタムスケーラーを作成できます。

潜在的な落とし穴：注意が必要！

KEDAは強力ですが、注意すべき点がいくつかあります：

  • 過度なスケーリング：クールダウン期間が適切であることを確認し、急激なスケーリングの上下を避けましょう。
  • メトリクスの信頼性：スケーリングメトリクスが信頼でき、短期的な変動に耐えられることを確認しましょう。
  • リソース制限：ポッドのリソース要求と制限を設定し、クラスターのリソース枯渇を防ぎましょう。
"大きなスケーリング力には大きな責任が伴う。" - もしアンクル・ベンがDevOpsエンジニアだったら

オートスケーリングの未来：KEDAの次のステップは？

KEDAは積極的に進化しており、新機能や改善が期待されています。注目すべきエリア：

  • より多くのクラウドネイティブイベントソースのサポート強化
  • サービスメッシュとの統合の改善
  • 高度な予測ベースのスケーリングアルゴリズム

最新の更新情報や機能については、KEDA GitHubリポジトリをチェックしてください。

まとめ：KEDAはあなたに適しているか？

KEDAは、Kubernetesのオートスケーリングに新たな柔軟性と応答性をもたらします。アプリケーションが可変のワークロード、イベント駆動型アーキテクチャ、またはカスタムメトリクスに基づくスケーリングを必要とする場合、KEDAはKubernetesのパズルの欠けたピースかもしれません。

オートスケーリングは科学であると同時に芸術でもあります。KEDAを制御された環境で試し、その動作を注意深く監視し、スケーリング戦略を繰り返し改善してください。気がつけば、Kubernetesクラスターが夢のようにスケールし、ワークロードの変動に優雅に対応するようになるでしょう。

さあ、Kubernetesのオートスケーリングを次のレベルに引き上げる準備はできましたか？KEDAを試して、クラスターがスリムで効率的なスケーリングマシンになるのを見てみましょう！

さらなる学習

スケーリングを楽しんでください、Kubernetes愛好家の皆さん！