KEDA を使用して Grafana Loki クエリを自動スケールする方法

導入

Grafana Loki (https://grafana.com/oss/loki/?pg=blog&plcmt=body-txt) は、Prometheus (https://prometheus.io/) に触発された Grafana Labs のオープンソースログ集約システムです。 Loki は水平スケーラブル、高可用性、マルチテナントを備えています。

Grafana Cloud は、AWS、Microsoft Azure、Google Cloud などのさまざまなリージョンやクラウドプラットフォームに分散されたクラスターを使用して、Grafana Cloud Logs を大規模に運用します。 Grafana Cloud は毎日数百テラバイトのデータを取り込み、数千のテナントにわたってペタバイトのデータをクエリします。さらに、データのクエリと処理によってリソース消費量が日々大きく変動するため、ユーザーの要求に応え、Grafana Cloud にとってコスト効率の良い方法でクラスターを手動で拡張することが非常に困難になります。

このブログ記事では、Grafana Labs のエンジニアが Kubernetes ベースのイベント駆動型オートスケーラー (KEDA(https://keda.sh/)) を使用して、バックエンドで Loki クエリをより適切に処理した方法について説明します。

なぜ自動スケーリングが必要なのでしょうか?

Grafana Cloud Logs クエリの処理を担当する Loki 読み取りパスコンポーネントの 1 つは、LogQL (https://grafana.com/docs/loki/latest/logql/?pg=blog&plcmt=body-txt) クエリをログに一致させるコンポーネントである querier です。ご想像のとおり、このような高いスループットを実現するには、多くのクエリーが必要です。ただし、クラスターのワークロードは 1 日を通して大幅に変化するため、この需要は変動します。最近まで、私たちはワークロードに基づいてクエリを手動でスケーリングしていましたが、このアプローチには 3 つの大きな問題がありました。

1. 増加したワークロードに応じて、クエリーを適切にスケーリングします。

2. クラスターを過剰にプロビジョニングし、クエリーをしばらくアイドル状態のままにしておく場合があります。

3. クエリーを手動でスケールアップおよびスケールダウンする必要があるため、操作が面倒になる可能性があります (https://sre.google/sre-book/eliminating-toil/)。

これらの問題を克服するために、Kubernetes のクエリー展開に自動スケーリング機能を追加することにしました。

KEDAを選ぶ理由

Kubernetes には、Pod を水平方向に自動スケーリングするための組み込みソリューションである HorizontalPodAutoscaler (HPA) が付属しています。 HPA を使用すると、Kubernetes メトリックサーバー (https://kubernetes.io/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#metrics-server) からのメトリックに基づいて、StatefulSet やデプロイメントなどのコンポーネントの自動スケーリングを構成できます。 metrics-server はポッドの CPU とメモリの使用量を公開しますが、必要に応じてさらに多くのメトリックを提供することができます。

CPU とメモリの使用状況のメトリックは、スケールアップまたはスケールダウンするタイミングを決定するのに十分であることが多いですが、考慮すべき他のメトリックやイベントがある場合もあります。私たちの場合、いくつかの Prometheus メトリックに基づいたスケーリングに関心があります。 Kubernetes 1.23 以降、HPA はすでに外部メトリック (https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#scaling-on-custom-metrics) をサポートしているため、Prometheus メトリックに基づいてスケーリングする Prometheus アダプターを選択できます。しかし、KEDA を使用すると、これがはるかに簡単になります。

KEDA はもともと Microsoft と Red Hat によって開発されたオープンソースプロジェクトであり、Grafana Mimir (https://grafana.com/oss/mimir/?pg=blog&plcmt=body-txt) と同様のユースケースで社内で使用されています。馴染みやすさに加えて、より成熟しており、さまざまなソース (Prometheus など) からのイベントとメトリックに基づいて任意の Pod をスケーリングできるため、これを選択しました。 KEDA は HPA 上に構築され、KEDA によって作成された HPA の新しいメトリックを提供する新しい Kubernetes メトリックサーバーを公開します。

クエリャにKEDAを使用する方法

クエリーはクエリスケジューラキューからクエリをプルし、すべてのクエリーで処理します。したがって、次の条件に基づいて拡張することが理にかなっています。

スケジューラキューサイズ
クエリーで実行するクエリ

最も重要なのは、短期的なワークロードの急増によるスケールアップを回避することです。このような場合、クエリはスケーリングに必要な時間よりも速くワークロードを処理する可能性があります。

これを念頭に置いて、キューに入れられたクエリの数と実行中のクエリの数に基づいてスケーリングします。これらをインフライトリクエストと呼びます。クエリスケジューラコンポーネントは、実行中のリクエストを追跡するために、パーセンタイル (https://grafana.com/blog/2022/03/01/how-summary-metrics-work-in-prometheus/?pg=blog&plcmt=body-txt) を使用して、新しいメトリック cortex_query_scheduler_inflight_requests メトリック結果を公開します。パーセンテージを使用すると、メトリックに短期的な急上昇がある場合でもスケーリングを回避できます。

結果のメトリックを使用して、クエリで分位数 (Q) と範囲 (R) のパラメータを使用してスケーリングを微調整できます。 Q が高くなるほど、指標は短期的な急上昇に対して敏感になります。 R が増加すると、時間の経過とともにメトリックの変動が減少します。 R 値を大きくすると、オートスケーラーがレプリカの数を頻繁に変更するのを防ぐことができます。

合計（
最大オーバータイム（
 cortex_query_scheduler_inflight_requests {名前空間= "%s" 、分位数= "<Q>" } [ < R > ]
 ）
 ）

次に、メトリック値に基づいて必要なレプリカの数を計算できるように、しきい値を設定する必要があります。 Querier プログラムはキューからのクエリを処理し、各 Querier は 6 つのワーカーを実行するように構成されます。ピーク時の使用量に余裕を残しておきたいので、これらのワーカーの 75% を使用することを目標としています。したがって、しきい値はクエリ実行者あたり 6 人のワーカーの 75%、つまり 4 人のワーカーになります。

この式は、必要なレプリカの数、メトリック値、および現在のレプリカで構成したしきい値を定義します。

望ましいレプリカ数= ceil [現在のレプリカ数* (現在のメトリック値/しきい値) ]

たとえば、レプリカが 1 つあり、進行中のリクエストが 20 件あり、各ワーカーが使用できる 6 つのワーカーのうち 75% (4 つ) を使用することが目標である場合、必要なレプリカの数は新たに 5 になります。

望ましいレプリカ数= ceil [ 1 * ( 20 / 4 ) ] = 5

これを念頭に置いて、クエリの自動スケーリングを制御する KEDA ScaledObject を作成できるようになりました。次のリソース定義は、KEDA が http://prometheus.default:9090/prometheus からメトリックをプルするように構成します。また、最大 50 クエリまでスケールし、最小 10 までスケールダウンし、実行中のリクエストメトリックに 75% を使用し、2 分間で最大値を集計します。スケーリングしきい値は、クエリ実行者あたり 4 人のワーカーのままです。

 apiバージョン: keda.sh/v1alpha1
種類:スケールオブジェクト
メタデータ:
名前:クエリー
名前空間: <編集済み内部開発環境>
仕様:
最大レプリカ数: 50
最小レプリカ数: 10
ポーリング間隔: 30
スケールターゲット参照:
 種類:デプロイメント
 名前:クエリー
トリガー:
 -メタデータ:
 メトリック名: querier_autoscaling_metric
 クエリ: sum ( max_over_time ( cortex_query_scheduler_inflight_requests { namespace =~ "REDACTED" 、 quantile = "0.75" } [ 2 m ] ) )
 サーバーアドレス: http : // prometheus.default : 9090 / prometheus
 しきい値: "4"
 タイプ:プロメテウス

Grafana k6 Cloud を使用したテスト

社内および本番環境に展開する前に、複数の実験とベンチマークを実行して検証しました。

Grafana k6 Cloud は、エンジニアリングチームによるパフォーマンステストを容易にする、無料かつオープンソースで開発者中心のスケーラブルな負荷テストツールである Grafana k6 の完全マネージドバージョンです。

k6 用の Grafana Loki 拡張機能を使用して、複数の仮想ユーザー (VU、実質的に実行中のスレッド) から Loki 開発クラスターにさまざまな種類のクエリを繰り返し送信する k6 テストを作成しました。次のシーケンスで実際の可変トラフィックをシミュレートしてみます。

1. 2 分以内に VU を 5 から 50 に増やします。

2. 1分間に50 VUを使用します。

3. 30 秒以内に 50 VU から 100 VU に増加し、さらに 30 秒以内に 50 VU に増加して、ワークロードのピークを作成します。

4. 前のスパイクを繰り返します。

5. 最後に、2 分以内に 50 VU から 0 にします。

次の図では、k6 Cloud でのテストの実行方法と、テスト中に実行中のリクエストとクエリレプリカの数がどのように変化したかを確認できます。まず、クエリーはワークロードの増加に応じてスケールアップし、最後に、テストが完了してから数分後にクエリーはバックオフします。

さまざまな種類のクエリを Grafana Loki 開発クラスターに繰り返し送信する Grafana k6 Cloud テスト。

実行中のリクエストの数が増えると (上)、クエリの数も増えます (下)。ワークロードが減少した後のある時点で、クエリ実行者の数も減少します。

私たちのアプローチが期待どおりに機能することを確認した後、次のステップは実際のワークロードで試してみることでした。

展開と微調整

私たちの実装が実際のシナリオでニーズを満たしているかどうかを確認するために、オートスケーラーを社内環境に導入しました。これまで、k6 がすべてのワークロードを作成する分離された環境で実験を行ってきました。次に、レプリカの最大数と最小数の適切な値を見積もる必要があります。

レプリカの最小数については、クエリ使用率 75% を目指して、過去 7 日間の平均実行中リクエストを 75% の時間でチェックしました。

クランプ最小値(天井(
 平均（
 avg_over_time ( cortex_query_scheduler_inflight_requests {名前空間=~ "REDACTED" 、分位数= "0.75" } [ 7 d ] )
 ) /スカラー( floor ( vector ( 6 * 0.75 ) ) )
 ) 、 2 )

レプリカの最大数については、現在のレプリカ数と、最初の 7 日間で実行中のリクエストの 50% を処理するために必要なクエリの数を組み合わせます。各クエリ実行者は 6 つのワーカーを実行するため、実行中のリクエストを 6 で分割します。

クランプ最小値(天井(
 （
 最大（
 max_over_time ( cortex_query_scheduler_inflight_requests {名前空間=~ "REDACTED" 、分位数= "0.5" } [ 7 d ] )
 ) / 6
 >
 max ( kube_deployment_spec_replicas { namespace =~ "REDACTED" 、デプロイメント= "querier" } )
 ）
または
 最大（
 kube_deployment_spec_replicas { namespace =~ "REDACTED" 、デプロイメント= "querier" }
 ）
 ) 、 20 )

最小レプリカ数と最大レプリカ数を見積もった後、オンプレミスにオートスケーラーをデプロイしました。次の図に示すように、期待どおりの結果が得られました。つまり、クエリーはワークロードが増加するとスケールアップし、ワークロードが減少するとスケールダウンします。

デプロイメント内で実行中のリクエストの数が増えると (上)、クエリの数も増えます (下)。労働者の数が減少すると、クエリの数も減少します。

スケーリングメトリックの値の変化により、レプリカ数が頻繁に変動すること (フラッピングとも呼ばれます) に気付いたことがあるかもしれません (https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#flapping)。多数のポッドをスケールアップしてからすぐにスケールダウンすると、ポッドをスケジュールするためだけに Kubernetes で大量のリソースを消費することになります。また、これらのクエリを処理するために新しいクエリを頻繁に開始する必要があるため、クエリの待ち時間に影響する可能性があります。幸いなことに、HPA は、これらの頻繁な変動を軽減するために安定化ウィンドウ (https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#stabilization-window) を構成するメカニズムを提供しており、ご想像のとおり、KEDA にも同様の機能があります。 spec.advanced.horizontalPodAutoscalerConfig.behavior.scaleDown.stabilizationWindowSeconds パラメータを使用すると、クールダウン期間を 0 秒 (即時スケーリング) から 3,600 秒 (1 時間) の間で設定できます。デフォルト値は 300 秒 (5 分) です。アルゴリズムはシンプルです。設定された時間にわたるスライディングウィンドウを使用し、レプリカの数をその時間範囲内で報告された最大数に設定します。この例では、30 分の安定化ウィンドウを構成しました。

仕様:
高度な：
 水平PodAutoscalerConfig :
 行動：
 スケールダウン:
 安定化ウィンドウ秒数: 1800

次の画像は、レプリカの数に関してグラフの形状がより均一になったことを示しています。場合によっては、クエリーはスケールダウンした直後にスケールアップしますが、これが発生するエッジケースが常に存在します。このパラメータには、ワークロードの形状に適した適切な値を見つける必要がありますが、全体的にはピークが少なくなっています。

安定化ウィンドウを構成すると、上図の同様のワークロードと比較して、レプリカの数の変動が少なくなります。

手動で Loki をスケーリングしたときよりもはるかに高いレプリカの最大数を設定したにもかかわらず、オートスケーラーを追加した後はレプリカの平均数は少なくなります。平均レプリカ数が少ないほど、クエリー展開の所有コストが低くなります。

クエリーオートスケーラーを有効にすると、クラスター内で実行されているレプリカの平均数が減少しました。

さらに、オートスケーラーではクエリのレイテンシ低下の問題が発生しないこともわかります。次のグラフは、7 月 21 日 12:00 UTC に自動スケーリングを有効にする前と有効にした後のクエリと範囲クエリの p90 レイテンシ (秒単位) を示しています。

クエリオートスケーラーを有効にした後も、クエリのレイテンシは悪化しませんでした。

最後に、レプリカの最大数をいつ増やすかを知る方法が必要です。これを実現するために、オートスケーラーが設定された最大レプリカ数で長時間実行されたときにトリガーされるアラームを作成しました。次のコードスニペットにはこのメトリックが含まれており、少なくとも 3 時間 true を出力する場合にトリガーされます。

名前: LokiAutoscalerMaxedOut
式: kube_horizontalpodautoscaler_status_current_replicas {名前空間=~ "REDACTED" } == kube_horizontalpodautoscaler_spec_max_replicas {名前空間=~ "REDACTED" }
 3時間
ラベル:
重大度:警告
注釈:
説明: HPA { { $labels .namespace } } / { { $labels .horizontalpodautoscaler } }は、最大レプリカで3時間以上実行されています。これはプロビジョニング不足を示している可能性があります。
概要: HPA は長時間にわたって最大レプリカで実行されています