はじめに
この記事では、Kubernetesでイベント駆動型スケーリングを実現する KEDA について、基礎から応用（導入）までを解説します。
「KEDAとは何か？」という基本的な疑問に答えるところから始め、KEDAのアーキテクチャやベストプラクティス、さらに実際の導入方法までを 3部構成 で整理し、KEDAの仕組みや運用のポイントを理解できるように構成しています。
【中編】となる本記事では、KEDAのアーキテクチャに焦点を当て、ベストプラクティスについても解説します。
対象読者
- Kubernetesを学習・導入している方
- KEDAって聞いたことがあるけど、「何をどうスケールしてくれるのかわからない」という方
- 「KEDAの導入に興味はあるけど、どこから手をつければいいかわからない」と悩んでいる方
KEDAアーキテクチャ
- KEDAは、Kubernetes標準機能である Horizontal Pod Autoscaler (HPA) を活用しつつ、イベント駆動型のスケーリングを可能にする拡張機能を提供します。その大きな特徴は 0↔1スケール を実現することで、HPAの制限を超えた柔軟なPod管理が可能です。（詳しくは【前編】ゼロから学ぶKEDA：概要と導入目的をご覧ください）
上記の画像はKEDA公式サイトより引用しています。
動作フロー
-
ScaledObjectに登録
ターゲットやトリガー条件を設定し、KEDAに登録します。 -
トリガーの監視
KEDAは指定されたトリガーを定期的にチェックし、条件が満たされた場合に動作します。 -
Podのスケール制御
条件に応じて、HPAを作成し、Podを動的にスケールします。
図全体の構成と流れのイメージ
KEDAの内部構造は以下の 3つの主要コンポーネント で構成され、それぞれが連携してPodのスケーリングを支えています。
| 名前 | 役割、説明 |
|---|---|
| keda-operator | - ゼロスケール時にPod数を 0→1、1→0 に制御 |
| keda-metrics-apiserver | - Scalerが取得した外部メトリクスをHPAに連携 - 実際のスケーリングはHPAが実行（Pod数 1→n、n→1） |
| keda-admission | - リソース構成をバリデーションし、設定ミスを防止 - マニフェストの構成エラーを未然に防ぐ |
動作確認コマンド
KEDAの各コンポーネントが正常に動作しているかを確認するには、以下のコマンドを実行します。
※ KEDAのセットアップ方法については【後編】で詳しく解説します。
> kubectl get po -n keda
NAME READY STATUS RESTARTS AGE
keda-admission-7bd8cb458d-chn7q 1/1 Running 0 5d10h
keda-metrics-apiserver-fbd9dc66f-zvcvz 1/1 Running 0 2d16h
keda-operator-859b7bc75c-2grnt 1/1 Running 0 4d
KEDAのベストプラクティス
KEDAを運用する際のベストプラクティスについて解説します。
（詳細は KEDA公式ドキュメントのベストプラクティス をご参照ください。）
同じターゲットに対して複数のトリガーを使用する
- 設定: ScaledObject内に複数のトリガーを指定可能です。
-
メリット:
- 異なるトリガーの組み合わせにより、柔軟なスケーリングポリシーを構築できる。
- ルールを一箇所で管理しやすい。
KEDAのScaledObjectと独自のHPAを組み合わせて利用しない
- 理由: KEDAが内部で作成するHPAと競合するリスクがあるためです。
-
推奨:
CPUやメモリを基準にスケールする場合は、KEDAの CPUスケーラー や メモリスケーラー を使用しましょう。
まとめ
次回の【後編】では、KEDAの導入手順や設定例について解説します。
【後編】に続く
いいね・コメントお待ちしてます！