HPAの外部メトリクスにNew Relicを使ってみた - ecbeing labs（イーシービーイング・ラボ）

はじめに

1年ぶりです。おとです。 2022年12月に、New Relic を使った Kubernetes (以下、「k8s」という。) の監視についての記事を書きました。

blog.ecbeing.tech

今回もNew Relicとk8sを絡めたお話をしたいと思います。

k8sはコンテナオーケストレーションツールであり、自動スケーリング機能があります。リソースの効率的な利用とアプリケーションのパフォーマンス維持に不可欠な機能です。

この記事では、k8sの自動スケーリング機能の1つであるHorizontal Pod Autoscaler (HPA) の基本から、New Relicを利用した外部メトリクスによるスケーリングの実装までを紹介します。

はじめに
HPAの基本
カスタムメトリクスの必要性
メトリクスソリューションの選択
New Relic メトリクスアダプターの導入と設定
実装結果
おわりに

HPAの基本

HPAは、指定したメトリクスに基づいてPodの数を自動で調整するk8sの機能です。

（PodやDeploymentといったk8sの用語についてはリンク先のk8s公式サイトをご確認ください。）

水平Pod自動スケーリング | Kubernetes

k8sの標準メトリクスでは、CPUやメモリの使用率が閾値を超えたときにPodの数を増やし、逆に使用率が下がったら減らす、ということができます。

しかし、標準メトリクスだけでは、アプリケーションのパフォーマンス維持に十全に対応できるわけではありません。

カスタムメトリクスの必要性

例えば、アプリケーションのアクセス数が急増した際に適切にスケーリングするには、CPUやメモリ以外の指標が必要です。

このような場合、カスタムメトリクスに基づいてスケーリングできるようにする必要がありますが、これを実現するためにはメトリクスアダプターが必要になります。

メトリクスソリューションの選択

カスタムメトリクスの収集・管理には多くのツールがありますが、k8s公式から提供されているものはなく、よく使われているのはPrometheusのようです。

しかし、今回はせっかくなのでNew Relicが提供しているメトリクスアダプターを使ってみました。

New Relic メトリクスアダプターの導入と設定

New Relicのメトリクスアダプターをk8sに導入する過程は比較的シンプルです。

New Relicの公式ドキュメントに導入手順が用意されています。

Kubernetes を使用してインフラストラクチャを自動スケールする | New Relic Documentation

以下のコードはk8sクラスターとNew Relicエージェントをデプロイするためのマニフェストファイルの該当箇所を一部抜粋したものです。

---
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: newrelic-bundle
  namespace: newrelic
spec:
  releaseName: newrelic-bundle
  chart:
    spec:
      chart: nri-bundle
      reconcileStrategy: ChartVersion
      sourceRef:
        kind: HelmRepository
        name: newrelic
  values:
    newrelic-k8s-metrics-adapter:
      lowDataMode: true
      personalAPIKey: "New RelicのAPIキー"
      config:
        accountID: "New RelicのアカウントID"
        externalMetrics:
          requests_count:
            query: "SELECT COUNT(*) FROM Log SINCE 5 minutes ago"

「requests_count」という名前で外部メトリクスを定義しています。

次に、HPA側の設定をします。

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-front-hpa
spec:
  minReplicas: 1
  maxReplicas: 3
  metrics:
  - type: External
    external:
        metric:
          name: requests_count
          selector:
            matchLabels:
              proxy_upstream_name: demo1-api-service
        target:
          type: AverageValue
          averageValue: 50
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: demo1-api-deployment

メトリック名に先ほど定義した「requests_count」を指定します。

matchLabelsに指定したKeyValueは、NRQLのWHERE条件として適用されるので、New Relicに発行されるクエリは

SELECT COUNT(*) FROM Log WHERE proxy_upstream_name = 'demo1-api-service' SINCE 5 minutes ago

となり、この取得結果をアクセス数とします。

(今回はIngress-Nginxを使用してPodへの通信をルーティングさせており、Ingress-NginxのログもNew Relicに連携しています。 proxy_upstream_nameはIngress-Nginxのログの属性の1つであり、Podに紐づくServiceの名前が入っています。 'demo1-api-service'を指定することで、demo1-api-deploymentのPodへのアクセスログの件数をアクセス数として取得しています。)

targetをAverageValueとしているので、アクセス数をPodの数で除算した値を閾値と比較して、いくつまでスケールするかを決めることができます。

今回の例でいうと、averageValueが50でmaxReplicasが3なので以下のような挙動となります。