KEDA を使用して Kubernetes で自動エラスティック スケーリングを実現する方法を学びます

こんにちは、皆さん。私はルガです。今日は、クラウド ネイティブ エコシステムに関連するテクノロジーである Auto Scaling、または「エラスティック スケーリング」についてお話します。

変動するワークロードと動的なトラフィック パターンが当たり前となった今日のクラウド ネイティブ エコシステムでは、従来の IT インフラストラクチャは大きな課題に直面しています。この予測不可能な動作により、インフラストラクチャの管理方法を再考する必要が生じます。

従来の静的インフラストラクチャとは異なり、最新のクラウド ネイティブ ソリューションは、より柔軟で自動化された弾力的なスケーリング機能を提供します。コンテナ化技術とKubernetesなどのオーケストレーションツールを使用することで、負荷需要の変化に応じて自動的にスケーリングし、リソースの弾力的な割り当てを実現できます。

Kubernetes オートスケーリングとは何ですか?

Kubernetes 自動スケーリングは、ワークロードの需要に基づいてコンピューティング リソースを自動的に調整する、Kubernetes コンテナ オーケストレーション システムの動的な機能です。この機能により、リソース割り当てのバランスを取り、最適化することで、金銭的な無駄を回避しながらアプリケーションのパフォーマンスを維持できます。トラフィックの急増に対応するためにリソースを追加することで最適なパフォーマンスを確保し、アイドル期間中に展開するリソースを減らすことでコストを節約します。

Kubernetes 自動スケーリングの利点には、リソース使用率の最大化、コスト効率の向上、アプリケーションの継続的な可用性の確保などがあります。 Kubernetes を使用する組織は、特にアプリケーションがビジー期間とアイドル期間を切り替えるときに、自動スケーリングのメリットを享受できます。

自動スケーリングの主な利点の 1 つは、実際の需要に基づいてリソースを動的に調整し、弾力性と俊敏性を実現することです。負荷が増加すると、自動スケーリングは迅速に対応し、現在の需要を満たすためにアプリケーションのレプリカの数を自動的にスケーリングします。この拡張性により、アプリケーションは高負荷の状況を処理するのに十分なリソースを確保できるため、パフォーマンスのボトルネックやユーザー エクスペリエンスの低下を回避できます。逆に、負荷が減少すると、自動スケーリングによってアプリケーションのレプリカの数が自動的に縮小され、コストが節約され、リソースの使用率が向上します。

さらに、自動スケーリングによりコスト効率も向上します。実際のニーズに応じてリソースの割り当てを調整することで、リソースの不必要な浪費を回避できます。ピーク時には、需要を満たすためにリソースを追加することで最適なパフォーマンスを確保できますが、アイドル時にはリソースを削減してコストを節約できます。この動的なリソース管理戦略により、リソースの最適な利用が実現し、コスト効率が向上します。

2. KubernetesネイティブH/VPAオートスケーリングのデメリット

Kubernetes の HPA (Horizo​​ntal Pod Autoscaler) と VPA (Vertical Pod Autoscaler) は自動スケーリング機能を提供しますが、以下に示すように、潜在的なボトルネックや制限もいくつかあります。

1. レイテンシと応答時間

HPA および VPA の自動スケーリング プロセスでは、指標を監視して調整を行うために一定の時間が必要であり、負荷が突然増加または減少すると一定の遅延が発生し、変更に即座に対応できない場合があります。この遅延により、パフォーマンスが低下したり、リソースが浪費されたりする可能性があります。

2. インジケーターの選択と設定

同時に、HPA と VPA の自動スケーリングは、インジケーターの選択と構成に依存します。不適切なメトリックを選択したり、メトリックしきい値を誤って構成したりすると、スケーリングが不正確になる可能性があります。したがって、メトリックを正しく選択して構成することは、オートスケーラーの効果的な動作を保証する上で重要な要素です。

3. インフラストラクチャバインディング

HPA と VPA は、基盤となるインフラストラクチャのスケーラビリティと弾力性に依存します。基盤となるインフラストラクチャが自動スケーリングの要件を満たすことができない場合、たとえば、基盤となるノードのリソースが限られている場合や、ネットワーク帯域幅が不十分な場合、自動エラスティック スケーリングの効果は制限されます。

4. アプリケーション設計の制限

実際のビジネス シナリオでは、特に永続的な状態や特定のスケジュール要件を持つアプリケーションなど、自動スケーリングに適さないアプリケーションがしばしば存在します。これらのアプリケーションでは、自動スケーリングによって発生する状態管理やデータ永続性の問題を処理するために、追加の手順を実行する必要がある場合があります。

5. 実装の複雑さ

一般的に言えば、H/VPA のカスタム インジケーターを作成するのは難しい場合があります。このプロセスでは、Kubernetes の内部構造をある程度理解する必要があり、開発者は関連するインターフェースを詳細に研究し、複雑なコード変更を行う必要があります。したがって、関連する経験のない開発者にとっては難しい作業になる可能性があります。この追加の複雑さにより、長期的にはメンテナンスが困難になる可能性があります。

3. KEDA とは何ですか? また、KEDA はどのような問題を解決しますか?

先ほど、Kubernetes が提供する組み込みソリューションはコストや実用性の点で非常に限られていると述べました。イベント駆動型アプリケーションをよりエレガントに拡張したい場合は、別の方法を探す必要があります。おそらく、KEDA は珍しい選択肢です。

では、KEDA とは何でしょうか?

KEDA (Kubernetes ベースのイベント駆動型オートスケーラー) は、Microsoft と Red Hat によって作成されたオープンソース プロジェクトであり、現在は Cloud Native Computing Foundation (CNCF) を卒業し、Apache 2.0 ライセンスを採用しています。 KEDA の主な目標は、Kubernetes 上で実行されるイベント駆動型アプリケーションに、より優れたスケーリング オプションを提供することです。

現在の Kubernetes 環境では、Horizo​​ntal Pod Autoscaler (HPA) は、CPU やメモリの使用量などのリソースベースのメトリック、またはカスタム メトリックにのみ反応します。ただし、バースト的なデータ フローが発生する可能性のあるイベント駆動型アプリケーションの場合、HPA のスケーリングはかなり遅くなる可能性があります。さらに、データフローが遅くなると、HPA はスケールダウンして余分なポッドを削除する必要があり、不要なリソースに対して引き続き料金が発生します。

KEDA の出現により、このギャップは埋まります。イベント駆動型の自動エラスティックスケーリングメカニズムを導入することで、Kubernetes 上で実行されるイベント駆動型アプリケーションをより効率的に拡張できます。 KEDA は、イベント ストリームのレートと規模に基づいて、負荷の需要を満たすためにアプリケーション レプリカの数を動的に調整できます。つまり、アプリケーションが大量のイベントを処理する必要がある場合、KEDA は迅速にスケーリングし、Pod インスタンスを自動的に追加して、高いスループットと低いレイテンシを確保できます。

KEDA のもう 1 つの利点は、Azure キュー、Kafka、RabbitMQ などの複数のイベント ソースをサポートし、アプリケーションがさまざまなソースからイベントを受信できることです。これにより、開発者はアプリケーションのニーズに基づいて適切なイベント ソースをより柔軟に選択できるようになります。

以下は、Prometheus インジケーターを使用して、KEDA に基づく自動スケーリング メカニズムをトリガーする例です。

 apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: devops spec: scaleTargetRef: apiVersion: argoproj.io/v1alpha1 kind: Rollout name: keda-devops-demo triggers: - type: prometheus metadata: serverAddress: http://<prometheus-host>:9090 metricName: http_request_total query: envoy_cluster_upstream_rq{appId="300", cluster_name="300-0", container="envoy", namespace="demo3", response_code="200" } threshold: "50" idleReplicaCount: 0 minReplicaCount: 1 maxReplicaCount: 10

上記の ScaledObject および KEDA 定義では、Prometheus メトリックを使用して KEDA 自動スケーリングを構成するために ScaledObject のインスタンスを指定しました。デプロイメント オブジェクト「keda-devops-demo」は、Prometheus メトリック「sum(irate(by_path_counter_total{}[60s]))」に基づいて HTTP リクエストの数を監視します。このメトリックの値が 50 を超えると、KEDA はリクエストを処理するために必要に応じて新しいポッドを作成します。このメトリックの値が 50 未満の場合、KEDA はリソース使用率を最大限に高めるために必要に応じて余分な Pod を削除します。

この例では、KEDA を使用して Prometheus メトリックに基づいてアプリケーションを動的にスケーリングする方法を示します。 KEDA は、さまざまなビジネス ニーズを満たす柔軟な構成オプションを提供します。

この構成により、システムは実際の HTTP 要求負荷に基づいてアプリケーションのサイズを動的に調整できます。負荷が増加すると、自動スケーリング メカニズムによってリクエストを処理するためのポッドがさらに作成され、アプリケーションのパフォーマンスと可用性が維持されます。負荷が軽減されると、自動スケーリング メカニズムによってポッドの数を適時に削減し、リソースとコストを節約します。

では、KEDA は SRE チームと DevOps チームのどのような問題や問題点の解決に役立つのでしょうか?具体的には、次の参考資料があります。

1. コストを削減する

KEDA は、イベント駆動型アプリケーションの自動スケーリングにおいて、より高い柔軟性と精度を提供します。到着率とイベントの規模に基づいてアプリケーション レプリカの数を動的に調整し、変化する負荷条件に適応できます。 KEDA には、保留中のイベントがない場合にポッドの数をゼロに減らす機能があります。対照的に、標準 HPA を使用してこれを実現するのは困難です。この機能は、リソースの効率的な利用とコストの最適化を保証し、最終的にクラウド コンピューティングの料金を削減するのに非常に役立ちます。

2. ユーザビリティの向上

現在、KEDA は 59 個の組み込みスケーラーと 4 個の外部スケーラーをサポートしています。これらの外部スケーラーには、KEDA HTTP や KEDA Scaler for Oracle DB などが含まれます。 KEDA は、外部イベントをトリガーとして使用することで、特に支払いゲートウェイや注文システムなどのメッセージ駆動型マイクロサービスに対して効率的な自動スケーリングを可能にします。

さらに、KEDA は柔軟性が高いため、あらゆる DevOps ツール チェーンにシームレスに統合できます。 Jenkins、GitLab、Prometheus、その他の DevOps ツールのいずれを使用する場合でも、KEDA を統合して、自動スケーリングを開発および展開プロセス全体の一部にすることができます。このようにして、KEDA の自動スケーリング機能を最大限に活用し、プロセスの継続性と一貫性を維持しながら効率的なアプリケーション管理を実現できます。

3. パフォーマンスを向上させる

KEDA を使用すると、SRE チームと DevOps チームは負荷の変動に基づいてアプリケーション リソース構成を動的に調整できます。 KEDA は、迅速な応答と自動スケーリング機能により、アプリケーションが負荷の変化に対応するために常に十分なリソースを確保し、高いシステム パフォーマンスを維持できるようにします。一方、監視およびメトリック収集機能により、SRE チームと DevOps チームはアプリケーションのパフォーマンスをリアルタイムで監視および最適化できます。

4. KEDA はどのように機能しますか?

Kubernetes のイベント駆動型自動スケーリング ツールである KEDA は、アプリケーションのイベント ソースに基づいて Pod の数を自動的に調整できます。 KEDA は簡単に導入できます。 Kubernetes クラスターで ScaledObject を作成するだけで済みます。 ScaledObject オブジェクトには、イベント ソース、スケーリング ルールなどを含む KEDA の構成情報が含まれています。

KEDA がデプロイされると、スケーラーはセンチネルのように動作し、イベント ソースを継続的に監視し、トリガー イベントが発生するとメトリックをメトリック アダプターに渡します。メトリック アダプターは翻訳者のように機能し、メトリックをコントローラー コンポーネントが理解できる形式に適合させて、コントローラー コンポーネントに提供します。コントローラー コンポーネントは、ScaledObject に設定されたスケーリング ルールに基づいてスケーリングの決定を行い、その決定を Pod で実行します。

一般的に言えば、KEDA、Kubernetes Horizo​​ntal Pod Autoscaler (HPA)、外部イベント ソース、Kubernetes データ ストレージ間の連携は、次の図に示されています。

上記の参照フローチャートは、KEDA が HPA と連携してアプリケーション ポッドを自動的にスケーリングする方法を説明しています。ここでは、この実装アーキテクチャ図を簡単に分析します。具体的な実施プロセスは以下のとおりです。

• Kubernetes API サーバーは、KEDA の自動エラスティック スケーリング機能と Kubernetes のリソース管理機能を組み合わせ、KEDA と Kubernetes 間の統合ブリッジとして機能します。 KEDA は、ScaledObject オブジェクトを通じて、自動エラスティック スケーリング メカニズムと Kubernetes リソース オブジェクトを組み合わせます。 KEDA のコア コンポーネントには、インジケーター アダプター、コントローラー、スケーラー、アドミッション Webhook が含まれます。
• メトリック アダプターと Admission Webhook は、ScaledObject オブジェクトで定義されたトリガー タイプに応じて、外部トリガー ソースからメトリックを収集します。メトリック アダプターはメトリックを Kubernetes メトリックに変換し、コントローラーに公開します。 Admission Webhook は、KEDA が自動エラスティック スケーリングを正しく実行できるように、ScaledObject オブジェクトを検証および変更する役割を担います。
• コントローラーとスケーラーは、メトリック アダプターによって収集されたメトリックに基づいて、自動的な弾性スケーリングを担当します。コントローラーは、エラスティック タスクをスケーラーに送信する役割を担います。 Scaler は、Kubernetes リソース オブジェクトにスケーリング タスクを適用する役割を担います。
• 外部トリガー ソースは、Apache Kafka、Prometheus、AWS CloudWatch など、メトリック データを提供できる任意のソースにすることができます。外部トリガーは、実行中のサービスからシステム メトリックを直接収集する役割を担います。ワークロードが高い場合、Pod はスケールアウトされます。ワークロードが低い場合は、Pod をスケールダウンします。ワークロードがまったくない場合は、Pod が削除され、最終的にインフラストラクチャ リソースが最適化されます。

一般的に言えば、KEDA コアは次の 3 つの主要コンポーネントで構成されています。

1. メトリクスアダプタ

KEDA の Metrics Adapter は、イベント データを Kubernetes メトリックに変換するコンポーネントです。メトリック アダプターは、「イベント駆動型」設計コンセプトを採用して、イベント データを Kubernetes メトリックに変換し、Kubernetes API サーバーを介して水平 Pod オートスケーラーに公開します。

2. 入場ウェブフック

KEDA の Admission Webhook は、Kubernetes オブジェクトの検証と変更を担当するコンポーネントです。 Admission Webhooks を使用すると、ScaledObject オブジェクトを検証および変更して、KEDA が自動的に正しくスケーリングできることを確認できます。

KEDA は 2 種類の Admission Webhook 接続を提供します。1 つは ScaledObject オブジェクトの検証と変更に使用される ScaledObject Admission Webhook タイプで、もう 1 つは Trigger オブジェクトの検証と変更に使用される Trigger Admission Webhook タイプです。

3.エージェント

KEDA のエージェントは、イベント ソースを監視し、イベント データを KEDA コントローラーに渡す役割を担うコンポーネントです。 KEDA は、さまざまなイベント ソース要件を満たすさまざまなエージェントを提供します。通常、イベントがない場合、エージェント コンポーネントはリソースの無駄を避けるためにデプロイメントをゼロ コピーに調整します。

進化するクラウドネイティブ アプリケーション環境では、動的なワークロードに適応することが重要です。 Kubernetes は、自動スケーリングを実現するための HPA や VPA などのネイティブ ツールを提供していますが、CPU や RAM 以外のメトリックによって駆動される負荷を処理する場合には制限があります。

KEDA は、HPA と VPA の制限を克服し、より柔軟で包括的な自動スケーリング ソリューションを提供する Kubernetes の拡張機能です。 KEDA は、HTTP リクエストの数、メッセージ キューの長さ、データベース接続の数など、あらゆるメトリックに基づいてスケーリングできます。さらに、KEDA は、ゼロへのスケールダウン、Kubernetes ジョブのトリガー、診断用のリアルタイム イベントの発行、認証プロバイダーを介した安全な接続の維持をサポートします。

HPA および VPA と比較して、KEDA には次の利点があります。

• より柔軟: KEDA は任意のメトリックに基づいてスケーリングできますが、HPA と VPA は CPU と RAM のメトリックに制限されます。
• より包括的: KEDA は、ゼロへのスケールダウン、Kubernetes ジョブのトリガー、診断用のリアルタイム イベントの発行、認証プロバイダーを介した安全な接続の維持をサポートします。
• 使いやすさの向上: KEDA の構成はよりシンプルになり、Kubernetes カスタム メトリックを使用する際にユーザーが直面する一般的な障壁が軽減されます。

上記はKEDAの関連分析です。詳細については、以降の記事を参照してください。ありがとう！

参考文献: [1] https://keda.sh/docs/2.12/concepts/