NIKKEI TECHNOLOGY AND CAREER

Blog

現場の技術をのぞいてみる

GKE Workload Metricsが実現する柔軟なメトリクス収集の世界

この記事は、Nikkei Advent Calendar 2021の 13 日目の記事です。

こんにちは。API、SREチームの清水です。

普段は日経電子版のAPIの改善や監視基盤の整備、共通アプリケーション基盤の開発・運用・BCP対策などを担当しています。

昨日のSREチーム 山崎の記事でも紹介しておりますが、日経のSREチームでは運用や監視の共通化を進めています。その一環としてGoogle Kubernetes Engine (GKE) を用いた共通アプリケーション基盤 Vesselを開発しています。その中で、日々監視や可観測性のあり方を探り、より安定したサービス提供を目指しています。

今回は、GKEの可観測性を大幅に拡張する「GKE Workload Metrics」の検証の取り組みについてご紹介します。本年10月にPublic Previewとして公開されたばかりの新機能です。ぜひ、今後のGKE運用にお役立て頂ければ幸いです。

GKE Workload Metrics とは

GKE Workload Metricsは、GKE内部のワークロードの Prometheus メトリクスを簡単かつ拡張性高くCloud Monitoringで収集するための拡張機能です。2021/10/06 に Public Preview として公開され利用可能となりました。

これまでCloud Monitoringで提供されていたGKEやGCPの標準的なメトリクスに加え、内部のワークロードやアプリケーション独自の Prometheus メトリクスを簡単な準備と設定で収集できる仕組みとなっています。

なお現在、Prometheusのメトリクス形式は、OpenTelemetry[1]の中で標準化が進んでいます。これに伴い、Cloud Nativeの文脈のなかでデファクトスタンダードになる可能性もある状況です。したがって、この形式のメトリクスをGoogle Cloudの機能として容易に収集できるようになることは、今後さまざまな面で大きなメリットになる可能性があります。

これまでの収集手段との違い

Workload Metrics登場以前、GKE内部のPrometheusメトリクスを収集するためには、 以下の手順が必要でした。

  1. GKE内にPrometheusをDeploymentとして建てる
  2. Stackdriver Prometheus Sidecar と呼ばれるサイドカーを用意してCloud Monitoringへメトリクスを送信する

したがってこの方法では、追加となるコンポーネントの管理コストが発生してしまうデメリットがありました。

Workload Metricsでは、GKEに対して規定のカスタムリソース定義 (CRD: Custom Resource Definition) に基づいたカスタムリソースを投入するだけで、簡単にPrometheusメトリクスの収集とCloud Monitoringへの送信を実現できるようになります。このカスタムリソースはPodMonitorと呼ばれ、収集対象の特定はもちろん、メトリクスの収集やフィルタの方法も柔軟に定義することが出来ます。

このように、Workload Metricsは、メトリクスの収集を行うPrometheusの管理コストを省ける、Cloud Monitoringへのメトリクス送信を容易にできるなど、さまざまなメリットがあります。

GKE Workload Metricsでできるようになること

この機能を用いると、GKE内部の様々なメトリクスを容易に収集できるようになります。Vessel基盤では、証明書管理のためにcert-managerや各種アプリケーションの自動デプロイのためArgo CDを管理用のワークロードとしてGKE上で稼働させています。これらのアプリケーションは、自身の状態を独自のPrometheusメトリクスで公開しています。例えば、Argo CDでは、アプリケーションの同期状態や死活状況を公開しています[2]。これらのメトリクスをCloud Monitoringに収集して活用することができるようになります。

また、Prometheusの規定[3]に従ってExporterを作成すれば、アプリケーション独自のメトリクスを収集することも出来ます。更に、Prometheusには各種ミドルウェアやリソース向けにサードパーティのExporter[4]もあるため、これらを活用することでメトリクス監視の内容を拡張することが出来ます。

利用するための事前準備

Workload Metricsの利用方法については、ワークロード指標としてドキュメントが公開されており、基本的な運用および設定変更については、ここに記されています。

まず、GKEの要件を確認し GKE 1.20.8-gke.2100 以降であることを確認します。この条件が満たされていれば、Workload Metricsを利用することができます。 本機能の有効化は以下の手順で行います。

  1. Kubernetes Engineの「クラスタ」パネルから有効化したいクラスタを選択します
Workload Metrics有効化手順1
  1. 「Cloud Monitoring」の行の編集ボタンを選択します
Workload Metrics有効化手順2
  1. プルダウンメニューから「ワークロード」を選択して「OK」を選択します
Workload Metrics有効化手順3
  1. 最後に「変更を保存」を選択して設定を反映します
Workload Metrics有効化手順4

以上のステップで、GKEクラスタでWorkload Metricsが有効化されます。 実際に利用可能か確認するためには、以下のコマンドを実行します。KIND: PodMonitorが追加されていれば、Workload Metricsを利用できる状態となっています。

$ kubectl api-resources
NAME                               SHORTNAMES         APIVERSION                             NAMESPACED   KIND
...
podmonitors                                           monitoring.gke.io/v1alpha1             true         PodMonitor
...

これらの作業の後は、監視対象の追加作業として、PodMonitor カスタムリソースを追加する手順になります。

監視対象の追加

監視対象の追加は、カスタムリソース定義によって定義された PodMonitor と呼ばれるカスタムリソースを運用者が投入することで行います。例えば、証明書管理を行うcert-managerは以下のようにマニフェストを作成し、当該のクラスタに対してkubectl applyを行うことで監視対象に設定できます。

apiVersion: monitoring.gke.io/v1alpha1
kind: PodMonitor
metadata:
  name: cert-manager
  namespace: cert-manager
spec:
  selector:
    matchLabels:
      app: cert-manager
  podMetricsEndpoints:
    - path: /metrics
      scheme: http

このPodMonitorのカスタムリソースを投入した後、しばらくするとCloud Monitoringに当該メトリクスが流入してきます。以下に示すMetrics Explorerでクエリできる他、ダッシュボード等での利用も可能となっています。

Workload Metrics流入例1

拡張性の高い設定

このようにPodMonitorリソースを投入する方法を取ることで、収集設定の拡張性が高められています。例えば、収集システムのベースとなっているPrometheusでは、一例として以下のような設定を変更することが出来ます。

  • スクレイプの設定 scrape_config
    • メトリクスの収集を行う間隔 (秒) scrape_interval など
  • ラベルの書き換え relabel_config
    • 正規表現マッチによる対象ラベルの特定 regex
    • ラベルの書き換え文字列 target_label
    • ラベル書き換えの動作 relabel_action など

上記の設定はPrometheusの運用でも特に頻繁に使われる機能です。必要/不要なラベルやメトリクスを定義し、必要分のみストレージを使用するようにしたり、使いにくいラベル名を書き換えて利活用性を向上させることが出来ます。

GKE Workload Metricsでも上記のPrometheusの機能を利用することができます。それはKubernetesのカスタムリソースとして PodMonitorを適用することで簡単に利用できます。例えば、以下のように設定すると、「120秒ごとにメトリクスを収集し .*_count に該当するメトリクス名を持つもののみを保存する」といった設定となります。

apiVersion: monitoring.gke.io/v1alpha1
kind: PodMonitor
metadata: 
  name: cert-manager
  namespace: cert-manager
spec: 
  selector:
    matchLabels:
      app: cert-manager
  podMetricsEndpoints:
    - path: /metrics
      scheme: http
      # 以下、収集間隔の変更
      interval: 120s
      # 以下、ラベルの書き換え機能を使ったメトリクスの絞り込み
      metricRelabelings:
        - sourceLabels: [__name__]
          regex: .*_count
          action: keep

これにより、必要最低限のみメトリクスを保持することができるようになり、Cloud Monitoringの使用料金を削減することが出来ます。上記の設定では、以下のように元々流入していたworkload/certmanager_certificate_expiration_timestamp_secondsのメトリクスが送信されなくなっていることが確認できます。

Workload Metrics流入例2

Workload Metricsで収集した指標については、標準で収集されているシステム指標とは異なり、取り込みサンプル数に応じた課金が行われます (料金表)。この点には注意が必要です。

このように、ベースとなっているPrometheusの柔軟な動作制御の設定を GKE Workload Metrics でも利用することが出来ます。また、Kubernetesマニフェストとして管理できることから、コードベースでの監視対象の管理も容易になっています。

Vessel基盤での活用の検討事例

Vessel基盤では、Workload Metricsの活用により、様々な監視の拡張や管理の容易化を検討しています。先述の通り、この基盤上では、証明書の管理のためにcert-manager、継続的デプロイのためにArgo CDなど、いくつかのミドルウェアを導入しています。これらから得られるメトリクスを使うと、以下のような監視が実現できます。

証明書の有効期限を監視する

cert-managerが管理する証明書の有効期限は、監視対象の追加章のようにPodMonitorを設定すると workload/certmanager_certificate_expiration_timestamp_seconds として収集することが出来ます。これをMQLで以下のようにクエリすると、メトリクスが記録された時刻と比較して、証明書の有効期限切れまでの期間を知ることが出来ます。この値に対してアラートを設定することで、期限切れをCloud Monitoringのみで事前に察知することができます。

fetch k8s_container
| metric 'workload.googleapis.com/certmanager_certificate_expiration_timestamp_seconds'
| value [sub(val(), scale(end(), "s"))]
cert-manager有効期限監視1

このクエリを実行すると証明書の有効期限切れまでの時間が秒として取得することが出来ます。今回の場合では、概ね 5799610秒 (=約67.125日) の残り時間があることがわかります。

Argo CDが管理するアプリケーションの状態を監視する

Argo CDはKubernetes用の継続的デリバリーツールです。これが管理するアプリケーションの状態や Sync (GitHub等のリポジトリの内容と実際に稼働しているリソースの状態の同期状況) も監視できます。以下は、Argo CDが元々持っているWebコンソールです。これを見ると、このクラスタ上では、Argo CDが管理下で3つのアプリケーションが動作していることがわかります。

Argo CD UI1

以上のようにアプリケーションの状態はArgo CDのWebコンソールで監視することもできます。しかしながら、Argo CDはPrometheusのメトリクスエンドポイントを持っています。そのため、Workload Metricsを活用してCloud Monitoringへ同様の内容を継続的に送信することが出来ます。以下、設定例としてのPodMonitorのマニフェストです。

apiVersion: monitoring.gke.io/v1alpha1
kind: PodMonitor
metadata:
  name: argocd
  namespace: argocd
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: argocd-application-controller
  podMetricsEndpoints:
    - path: /metrics
      port: argocd-app
      scheme: http
      interval: 60s

これを投入すると、以下のようにCloud Monitoring側にメトリクスが送信されてきます。メトリクスにはラベルが付与されており、metric.nameとしてアプリケーション名がセットされています。また、metric.sync_statusにはSyncの状況、metric.health_statusにはアプリケーションの死活状況が示されています。これをアラートとして設定することで、異常なアプリケーションの終了やArgo CDでのSyncの失敗を監視し、継続的に検出することができるようになります。

Argo CD Cloud Monitoring

Vesselでの活用のこれから

まず、本稿で例示したcert-managerとArgo CDでは、今回例として挙げたメトリクス以外にも以下のようなものも収集することが出来ます。

  • cert-manager
    • certmanager_certificate_ready_status: 証明書の状態 など
  • Argo CD
    • argocd_app_reconcile: アプリケーションのReconcileの状況
    • argocd_cluster_events_total: Argo CDのクラスタが行ったイベントの状況 など

これらを収集して、更に監視環境を拡充することも考えています。 また、その他にもVessel内部で稼働する日経の各種アプリケーションにメトリクスのエンドポイントを設定し、Cloud Monitoringにそれら独自のメトリクスを収集させることも可能です。このように、共通アプリケーション基盤である Vessel では、監視の拡充のためさまざまな活用方法を考えています。

おわりに

本稿では、Google Kubernetes Engine (GKE) の可観測性を大幅に拡張する「GKE Workload Metrics」の 共通アプリケーション基盤 Vessel上での検討事例をご紹介させて頂きました。この機能は、より低負荷で管理のしやすいPrometheusメトリクス収集環境を容易に構築することが出来ます。

日経では、常に新しい技術やモダンな開発手法を取り入れながら、日々開発活動に取り組んでいます。 私も今年4月入社の新卒1年目ですが、この1年間、常に先端の技術に触れ、自分が関わりたいワクワクするような仕事と開発に取り組み続けることが出来ました。

日経の技術や働き方に関心を持っていただけた方、エンジニアを目指している学生の方など、もし日経で働くことに興味を持っていただけましたら、お気軽に JOBS ページよりご連絡いただければ嬉しいです。ぜひ、お待ちしております！

明日は谷出さんの「P2PでローカルのHTTPサーバーへ外部からトンネリングする」です。どうぞお楽しみに！ そして、良いお年を！

参考文献

[1]: "OpenTelemetry" https://opentelemetry.io/

[2]: "Metrics | Argo CD - Declarative GitOps CD for Kubernetes" https://argo-cd.readthedocs.io/en/stable/operator-manual/metrics/

[3]: "Writing exporter | Prometheus" https://prometheus.io/docs/instrumenting/writing_exporters/

[4]: "Exporters and Integrations | Prometheus" https://prometheus.io/docs/instrumenting/exporters/#third-party-exporters

清水赳
ENGINEER清水赳

Entry

各種エントリーはこちらから

キャリア採用
Entry
新卒採用
Entry
短期インターン
Entry
カジュアル面談
Entry