先日のブログ記事で、Microsoftは、Kubernetes-based event-driven autoscaling (KEDA)コンポーネントの1.0バージョンを発表した。Kubernetesクラスタ上で動作し、すべてのPodやアプリケーションに対して詳細な自動スケーリング(ゼロ動作を含む)機能の提供が可能なオープンソースプロジェクトだ。Kubernetes Metrics Serverとしての動作も可能で、専用のKubernetesカスタムリソース定義を使って自動スケール用ルールを定義することができる。
ブログ記事を書いたAzure Serverless担当のプリンシパルPMマネージャであるJeff Hillan氏がInfoQに説明してくれた。
KEDAは当社のサーバレス戦略の重要な部分です。オープンソースとして提供中のAzure Functionsランタイムと合わせることで、ベンダロックインのないサーバレスランタイムとスケーリング機能を提供します。これによって企業は、従来では不可能であった、完全マネージドなクラウドとエッジをまたぐハイブリッドなサーバレスアプリケーションを開発することが可能になります。
Microsoftは今年初め、Red Hatと共同でKEDAを発表し、ユーザやコミュニティからの歓迎を受けていた。Hollan氏は言う。
KEDAはコミュニティの大規模なコラボレーションから生まれました。KEDAがOpen Shiftで良好に動作する上で、私たちRed Hatは、設計とコード開発の両面で大きな貢献をしています。新しいイベントソースやドキュメント、サンプル、機能の開発にも、当社はさまざまな形で協力しました。その結果、単独の企業では決してなし得ないような、すばらしいツールが完成しました。その過程で私たちの得たオープンとコラボレーションの姿は、今後の開発においても極めて重要なものとなります。
Kubernetesはオーケストレータで、いくつかのクラウドプラットフォーム上でマネージドサービスとして提供されている。デフォルトのKubernetesは、CPUやメモリのような運用メトリクスに基づいたスケール機能を備えるのみで、キュー上で数千のメッセージが処理を待っているというような、アプリケーションレベルのメトリクスについては考慮されていないので、開発者がHPA(Horizontal Pod Autoscalers)を作成して、自らのデプロイメントのスケール要件を定義しなければならない — それには、必要なソースからメトリクスを取得するためのメトリクスアダプタを実行する必要があり、ソースが複数存在する場合には、その実行自体が問題となると同時に、より多くのインフラストラクチャが必要になっていた。
KEDAを使用すれば、さまざまなソースから取得したメトリクスと、それに関する知識に基づいて、Podをスケールすることが可能になる。例えばキューから情報を取得して処理を待っているメッセージ数を確認し、それに基づいてCPUロードが上昇する前にスケールアップする、ということができる。スケーリングはアプリケーションデプロイメントの０～ｎインスタンスまで、ScaleObjectの設定に基づいて行われる。これを実現するため、KEDAには、デプロイメントのインスタンス数を増やすのに必要なHPAが追加されている。インスタンスが必要なくなれば、HPAは削除される。
CoditのAzure Architectであり、KEDAの主要コントリビュータのひとりであるTom Kerkhove氏は、次のように指摘している。
HPAはメトリックアダプタでも使用可能ですが、どれが必要かを特定しなければならない上に、同時に複数のアダプタを実行することはできません — KEDAはこの問題を、さまざまなソースを集約することで解決しているのです。
出典: https://blog.tomkerkhove.be/2019/11/19/keda-v1-autoscaling-made-simple/
KEDAの使用には他にもメリットがある、Ketkhove氏は言う。
- もうひとつの大きなメリットとして、これまでは、James Sturtevant氏のOSSプロジェクト以外に公式のAzure Monitorメトリックアダプタがありませんでした。あるいは、PrometheusとPrometheusメトリックアダプタを経由してPromitorを使用する必要がありました。
- 運用レベルの認証機能としてTriggerAuthenticationが提供されるようになりました。Azure Managed IdentityのようなPodアイデンティティをサポートすることで、認証情報の再利用が可能になります。それによって、アプリケーションにアサインした認証とKEDAが必要とするものとを分離することが可能になり、外部漏洩リスクを低減できます。
- Helm 2.xと3.0を使用することで、デプロイも非常に簡単になります。いずれもhub.helm.shで入手可能です。また、現在のKEDAはOperator SKDがベースですが、近々Operator Hubに移行する予定です。
- デプロイメントだけでなく、ジョブのスケーリングもサポートしています。
- 近日中にCNCFに寄贈される予定です。そうなれば他のベンダも、スケーラの追加やユーザビリティの向上といった面で、プロダクトの向上に参加できるようになります。
KEDAに関する詳細はKEDA.sh、あるいは"step-by-step QuickStartで学ぶことが可能だ。