マルチクラウド、マルチクラスタ構成の k8s環境で監視システムを運用していく話 グリー株式会社 岩堀草平 グリー株式会社 柳澤良輔

岩堀草平 全社向けの監視基盤を提供するチームのリーダー 来年開催されるSRE NEXT 2025のCo-Chairも やります（有明でお会いしましょう） グリー株式会社 シニアリードエンジニア 2

柳澤良輔 グリーグループのインフラ（オンプレ・クラウ ド）運用・監視調整を担当。 ものづくりがすき。 グリー株式会社 エンジニア 3

目次・アジェンダ ● インフラストラクチャ部とMonitoring Unit ● k8s監視基盤の概要 ● kube-prometheus-stackの活用 ● k8s監視基盤を運用していく上での課題 ● pintの導入 ● Recap 4

インフラストラクチャ部と Monitoring Unit 5

Monitoring Unitとは 6

Monitoring Unitとは ● プロダクト横断で監視基盤の提供を行っているインフラストラクチャ部内 のチーム ● 環境ごとに標準のスタック構築運用 + カスタマイズで提供 ● 細かく意識せずとも共通の監視基盤、アラートルールなどが 導入できるように ● 10人未満のチームで運用 7

Monitoring Unitが提供するコンポーネント ● 監視基盤=主にGrafana(OSS/Cloud)/Prometheusを中心としたスタック + 多数の独自コンポーネント ● オンプレ / VMベース（EC2 on AWS） / コンテナベース（EKS/GKE） ● AWS環境はSaaSを利用したログ基盤もあわせて提供 ● 今回はEKS/GKE環境についてお話します 8

k8s監視基盤の概要 9

EKS環境のモニタリング構成 10

EKS環境のモニタリング構成 11

EKS環境のモニタリング構成 12

EKS環境のモニタリング構成 13

EKS環境のモニタリング構成 ● 2015年頃〜のEC2運用で作り込んだ監視用EC2インスタンスを利用 ● メトリクスはEBSボリュームで持つ ● メトリクスの精度と保持期間 ○ 15秒精度：70日間 ○ 1時間精度：400日間 ● ログアラートはLambdaを経由してすべてのアラートは共通基盤に集約 ● プロダクトごとにPrometheus/GrafanaがありALB+Cognitoで社内の 認証基盤と連携 14

GKE環境のモニタリング構成 15

GKE環境のモニタリング構成 16

GKE環境のモニタリング構成 17

GKE環境のモニタリング構成 18

GKE環境のモニタリング構成 ● GrafanaCloudを利用することで高精度メトリクスを長期間保持 ● メトリクスの精度と保持期間 ○ 15秒精度：13ヶ月 ● 中間コンポーネントを経由してすべてのアラートはAWSと同じ 共通基盤に集約 ● プロダクトごとにGrafanaCloudのスタックがありそれぞれSAMLで 社内の認証基盤と連携 19

Grafana Cloudの構成 ● プロダクトごとにスタックを作成 ● 権限や費用の分離 ○ EntraID + SAMLを利用 ○ Viewer/Editorのロール割当 ○ AdminはGrafanaのorgで管理 ○ 使い終わったら一式まるごと削除 ● スタックの構築はTerraform + 一部手作業 20

Grafana Cloudの管理 ● Terraformで管理 ○ 基本構成 ○ アラートルール ○ ダッシュボード ○ サービスアカウント ● 手動管理 ○ スタックごとのSAML構成 ○ 定期的な証明書更新などが ある 21

マニフェストの管理 ● 監視導入のためのマニフェストは 一箇所で全プロダクト設定を管理 ● kube-prometheus-stackを 利用 ● Helmfileからkustomizeへ移行中 ● ArgoCDで反映する 22

マニフェストの管理 23

マニフェストの管理 24

ここまでのまとめ ● グリーでは少人数のチームで全社向けの監視基盤をメンテしている ● オンプレ / AWS / GCPでそれぞれ異なった技術スタックを採用しながら Prometheus/Grafanaエコシステムを利用することで近いユーザー体験を 提供する ● EKSは既存資産を活かすためにEC2運用、GKEは高カーディナリティ メトリクスの安定運用のためGrafanaCloudを選択 ● k8s環境（GKE/EKS）ではkube-prometheus-stackをベースとして マニフェストを可能な限り共通化して効率化 ● 後半で運用の課題などについてさらにお話していきます 25

kube-prometheus-stackの活用 26

kube-prometheus-stackとは ● prometheus-operatorの他にalertmanagerや各種exporterを ひとまとめにしたhelmchart ● prometheus-operatorはprometheusを含む様々なCRDを 提供してくれている ● これにより、prometheusやスクレイプ設定をk8sリソースの形で 簡潔に定義することができる 27

monitoring.coreos.com/v1/podmonitor prometheusのスクレイプ設定をk8sリソースの形で簡単に記述することができる 28 apiVersion: monitoring.coreos.com/v1 kind: PodMonitor metadata: name: apache-exporter labels: release: kube-prometheus-stack spec: namespaceSelector: any: true selector: matchExpressions: - key: apache-exporter operator: In values: ['true'] podMetricsEndpoints: - port: web-telemetry path: /metrics - job_name: podMonitor/monitoring/apache-exporter/0 scrape_interval: 15s scrape_timeout: 10s metrics_path: /metrics relabel_configs: - source_labels: [job] separator: ; regex: (.*) target_label: __tmp_prometheus_ job_name replacement: $1 action: replace - source_labels: [__meta_kubernetes_pod_phase] separator: ; regex: (Failed|Succeeded) replacement: $1 action: drop … PodMonitor 生成されるPrometheusのConfig

kustomize/helmを用いてEKS/GKE間の環境の差異を吸収 29 prometheus: enabled: true prometheusSpec: resources: requests: # This is minimum resources. # overwrite for each product cpu: 200m memory: 510Mi scrapeInterval: 15s retention: 12h resources: {} remoteRead: [] remoteWrite: [] … prometheus: serviceAccount: name: prometheus annotations: # GCPはWorkloadIdentityの設定が必要 iam.gke.io/gcp-service-account: "[email protected]" … Base Overlay/GKE prometheus: serviceAccount: name: prometheus # AWSは特にannotationsの設定の必要はない … Overlay/EKS

k8s監視基盤を運用していく上での課題 30

運用で必要なこと ● kubernetesは定期的なアップデートが必須 ● それに応じて、kube-prometheus-stackのバージョンも上げていく必要 がある 31

アップデートにまつわる課題 ● アップデートに伴い、exporterで出力されるメトリクス名が 変更されたり、削除されていたりすることがある ● 特に、アラートで利用しているメトリクスがサイレントに消えてしまうと 大変困る → 必須メトリクスがきちんと取れていることを、継続的に監視できないか？ 32

pintの導入 33

pintとは ● Cloudflare社が開発している、Prometheusのルールを解析するツール ● 実際にPrometheusにクエリを送信し、必要なメトリクスが存在するかを チェックしてくれる ● 継続的にチェックし、チェック結果をメトリクスとして出力してくれる 34

pintのChecks alerts/absent absent()評価の利用に際し、forが正しいか alerts/annotation アラートのannotationが正しく設定されているか alerts/comparison アラートの条件に正しく比較演算子が使われている か alerts/external_lables アラートで参照しているラベルが実在するかどうか promql/counter counterタイプのメトリクスが正しく扱われている か promql/range_query 評価している時間範囲が適切かどうか promql/regexp 正規表現にムダや誤りがないか promql/series アラートやルールで利用しているメトリクスが実在す るかどうか query/cost クエリ実行時のコストが許容範囲かどうか rule/dependency 削除したルールに依存した他のルールがないか 35 etc…

pintの実行 - lintモード 36 アラートルールのあるディレクトリを指定すると、自動でパースしてPrometheusにクエリを投げてくれる $ pint -c config.hcl -l DEBUG lint /path/to/rules/ … level=INFO msg="Configured new Prometheus server" name=local uris=1 uptime=up tags=[] include=[] exclude=[] level=DEBUG msg="Running prometheus query" uri=http://localhost:9090 query=count(my_metric{environment="production"}) level=DEBUG msg="Parsed response" uri=http://localhost:9090 query=count(my_metric{environment="production"}) series=0 … /path/to/rules/my_alert.yml:10 Bug: `local` Prometheus server at http://localhost:9090 didn't have any series for `my_metric` metric in the last 1w. (promql/series) 10 | expr: sum by (instance_id, instance_type, region) (my_metric{environment="production"}) == 0

pintの実行 - watchモード 37 watchモードでは、継続的にPrometheusにクエリを送り、lint結果をメトリクスとして出力すること ができる

pintを導入したことで Before: ● アップデート実施後、複数のダッシュボードを巡回し、問題がないことを 手動で確認 After: ● Pintのエラーを確認することで、最低限問題ないことを確認 38 アップデート実施後の正常性の確認が非常に簡単になった

依然として残る課題 ● pintのエラーのうち、仕方ないもの等も存在するので その扱いをどうするか ● アラート等のメトリクスは保証できるようになったが、ダッシュボードで 利用しているメトリクスについても確認できるようにしたい ● 環境の数が増えるにつれ、人力でアップデートして回るのは 大変になっていく 39

Recap 40

Recap ● グリーでは少人数のチームでマルチクラウド向けの監視基盤を提供、 メンテナンスしている ● kube-prometheus-stackをベースに、kustomizeを活用してEKS/GKEで の差分を管理することでマニフェストを共通化している ● kube-prometheus-stackのバージョンアップはpintを利用することで 安全性を担保する取り組みを開始した 41

ご清聴ありがとうございました 42

No content