KEDAで実現するイベント駆動でスケーラブルなJob実行

KEDAで実現するイベント駆動で スケーラブルなJob実行 K8s Novice Tokyo #40 竹田

自己紹介 氏名：竹田舜（X：https://x.com/TKDDDDDS ） 所属：株式会社ラクス 業務 インフラ〜プラットフォーム、時々アプリ・LLM関連 これ関連の 仕事してます

• https://x.com/TKDDDDDS

今日はKEDAの話

KEDAとは？ Kubernetes Event-driven Autoscaling 名前の通り、イベント駆動でPodを増やしたり、Job実行・Jobの並列起動数のキューに 応じた変更が可能 ※ https://keda.sh/

主なカスタムリソース MQ、DB、メトリクスなど様々な値でスケールが可能 - ScaledObject - - 常駐ワーカーを伸縮 基本的に起動しっぱなしの Podなどを増やし、処理可能な量を増やす 0個にするのも可能 ScaledJob - イベントに応じて Job を増やす キュー数に応じて起動する Jobを増やす キューをポーリングして毎回起動するので、コールドスタート分の起動時間コストはかかる

主なカスタムリソース MQ、DB、メトリクスなど様々な値でスケールが可能 - ScaledObject - 常駐ワーカーを伸縮 基本的に起動しっぱなしの Podなどを増やし、処理可能な量を増やす 0個にするのも可能 今日はこっちの話！ - ScaledJob - イベントに応じて Job を増やす キュー数に応じて起動する Jobを増やす キューをポーリングして毎回起動するので、コールドスタート分の起動時間コストはかかる

具体的なユースケース 例：LLMアプリケーションで考える ユーザーと同期的なやりとりをしない場合や処理時間が長い場合 →非同期にする選択肢（例えばcronjobにしたり、常駐Podにロジック記述する）

KEDA導入のメリット ・非同期を実現するキュー関連のロジックをアプリケーション側に記述せず、プラット フォーム側で吸収できる ・アプリケーションが周りのmanifestが書かれている場合、Operator導入& ScaledJob manifest作成で素早く導入できる ・Nodeのオートスケールの仕組みと組み合わせれば、スケーラブルなシステムを作れる KEDAを利用すれば、イベント駆動を簡単に実現できる。

SQS(elastic-mq)とつなぐときの注意点 本物のSQSにつなぐ場合はIAMポリシーの設定に注意！ ScaledJobを起動するか判断するために使うポリシーはKEDA-Operator側のService Accountに付与されてる必要があります ※ ただ、これはPod側の権限を使うようにもできるよう？ ScaledJobで起動するアプリが使うSA ≠ Scaleを判断するSA

sample-appで実際に動作を試してみる サンプルアプリケーションを作ってみました enqueueアプリがキューを詰め、ScaledJobで起動するdequeueでキューを読んで、内 容をDBに保存します。 今回はシンプルですが、dequeue側を作り込めばそのままイベント駆動のアプリケー ションを作れます

サンプルの構成

デモ https://github.com/tkeshun/keda-kind

• https://github.com/tkeshun/keda-kind

まとめ - KEDA：イベント駆動をK8s上で実現するOperator 導入が簡単 LLMアプリケーション時代の非同期ユースケースにマッチするかも？？？ ぜひアプリケーションで作り込みする前に試してみて！