KEDAを使いKubernetes上でイベント駆動処理を実現する

Kubernetes

2020.06.11

この記事を書いたメンバー：

大友佑介

KEDAを使いKubernetes上でイベント駆動処理を実現する

大友(@yomon8)です。

今回はKubernetesを基盤としたプロジェクトで実際に利用している、KEDAというコンポーネントについてご紹介します。

KEDAとは

KEDAはKubernetesに導入可能なコンポーネントの名前です。語源は「Kubernetes Event-driven Autoscaling」で、その名前の通り、Kubernetes上でイベント駆動のオートスケールを実現します。（この辺りは後述）

ロゴとホームページは以下になります。

https://keda.sh/

MicrosoftとRed Hatが中心となり開発を初めて、現在はオープンソースとして、GitHubでApache License 2.0で公開されています。2019年11月にv1.0.0がリリースされており、これを書いている時点での最新はv1.4.1です。

https://github.com/kedacore/keda

最近では今年、2020年4月にCNCF(Cloud Native Computing Foundation)のSandbox Projectとして採用されてニュースになっていました。

https://cloudblogs.microsoft.com/opensource/2020/04/06/kubernetes-event-driven-autoscaling-keda-cncf-sandbox-project/

KEDAの使いどころ

KEDAの概要はこの辺りにして、使いどころについて見ていきたいと思います。

KEDAの語源にもなっている「Kubernetes Event-driven Autoscaling」にある、イベント駆動（Event-driven）とは何かのイベントに応じて処理を行う仕組みのことです。この記事では、わかりやすい例として不定期に大量メッセージを受け取るシステムを考えてみます。

このシステムの場合、WEBサーバのように常にメッセージを待ち受けていると、大半の時間は処理するものが何も無いのでリソースが無駄になってします。しかし、最小限のリソースで待っていると、いざ大量のメッセージが来た時に処理しきれなくなってしまいます。

こういったシステムの場合、キューを利用した構成を取ることで効率的な処理が実現できる場合があります。

キューにメッセージが無い状態なら何も動かない、メッセージが大量に投入されれば、そのメッセージ数に応じて処理を並列させて動かす。これができるなら、リソースを有効活用できます。

これは、パブリッククラウドの世界では、AWSなら SQSとLambda、AzureならServiceBusとAzure Functions、GCPならPub/SubとCloud Functionsなど、よく利用される代表的なパターンです。

このようなイベント駆動の処理のスケールをKubernetes上で実現させるためのコンポーネントがKEDAということになります。

KEDAによるイベント駆動処理

KEDAはKubernetes上にインストールして利用します。

以下の例ではKEDAとAzureのServiceBusのキューとで連携をしています。キューの中のメッセージ数を定期的に確認して、メッセージ数に応じた数の処理（Pod）を実行します。

メッセージが0件ならPodは起動されませんし、大量にメッセージがあれば、それに応じた数のPodを起動します。（上限値等は設定可能です）

イベント駆動のPodを動かしてみます

実際に動きを見た方が理解が早いと思いますので、動きをgif動画にしました。

動画の説明は画像に書いてあります。

送信ボタンを押すと、押した数だけメッセージがキューに入ります。キューのメッセージ数（左上）に応じてPod数（右上）が変化するのを確認してみてください。

※メッセージの投入に使っているのはServiceBusExplorerというツールですhttps://github.com/paolosalvatori/ServiceBusExplorer/

実際の動画です。最後に沢山ボタン押してま15件くらいのメッセージがキューに入った状態になりますが、Podが複数起動してメッセージを処理しているのがわかります。メッセージが0件の時にはPodも起動していない状態であることも確認してみてください。

まとめ

Kubernetesでイベント駆動処理を可能にするKEDAについて書いていきました。

今回の例では処理に当たるPod数を決めるの元情報として、AzureのServiceBusのキューに入ったメッセージ数を利用していました。

こういった、スケールの元情報となっているものをKEDAではScalerと呼んでいます。Scalerは拡張可能な仕様になっていて様々なサービス、コンポーネントに対応しています。

実際に、記事書いている時点でも以下のように様々なサービスやソフトウェアに対応しており、KEDAが特定のサービスに依存したものではなく、汎用的に利用できるコンポーネントとなっていることがわかります。Kubernetesでイベント駆動で処理動かしたいという場合は、検討の対象に入れてみても良いかもしれません。

– Apache Kafka
– AWS CloudWatch
– AWS Kinesis Stream
– AWS SQS Queue
– Azure Blob Storage
– Azure Event Hubs
– Azure Monitor
– Azure Service Bus
– Azure Storage Queue
– External
– Google Cloud Platform Pub/Sub
– Huawei Cloudeye
– Liiklus Topic
– MySQL
– NATS Streaming
– PostgreSQL
– Prometheus
– RabbitMQ Queue
– Redis Lists