[Prometheus Meetup#3] Victoria Metricsで作りあげる大規模・超負荷システムモニタリング基盤 / Monitoring Platform With Victoria Metrics

Transcript

1. Victoria Metricsで作る 大規模・超負荷 システムモニタリング基盤 2020/01/15 Prometheus Meetup#3
2. 2 • 入江 順也 • 株式会社コロプラ(2015年入社) ◦ インフラチーム所属 ◦ GKEタイトル運用、運用効率化担当 自己紹介
3. 3 第 9 回 Google Cloud INSIDE Games & Apps GKEとCloud Spannerが躍動するドラゴンクエストウォーク 告知: 最近の発表 https://www.slideshare.net/GoogleCloudPlatformJP/gke-cloud-spanner-9-google-cloud-inside-game-apps
4. 4 アジェンダ • 前提・背景 • 3rd-party Storage検討 • Victoria Metricsとは？ • なぜVictoriaMetricsを選んだのか? • Parameter Tuning • その他の工夫 • まとめ
5. 150Billion (1500億)
6. 累計Datapoints (from 10,000+ Pods)
7. 前提・背景
8. 8 Game Title1 コロプラではKubernetes上の監視に、Prometheus + Grafanaを利用しています これまでのPrometheus/Grafanaの運用 Single Tenant構成 ゲームタイトルごとに各K8sクラスタ K8sクラスタ : Prometheus = 1:1 API Game Title2 PvP API Game Title3 API
9. 9 Game Title1 コロプラではKubernetes上の監視に、Prometheus + Grafanaを利用しています これまでのPrometheus/Grafanaの運用 Single Tenant構成 ゲームタイトルごとに各K8sクラスタ K8sクラスタ : Prometheus = 1:1 API Game Title2 PvP API Game Title3 API max1,500 pods
10. ある日の負荷試験 にて・・・
11. 11 想定の¼の負荷試験時・・・
12. 12 開始数分で死ぬPrometheus・・・ OOMKilled
13. 13 Prometheusのスケールアップで対応するも... OOMで死んでしまったので、対応としてとりあえずPrometheusのNodeのスペッ クアップとresources.requests, resources.limitをアップ↑ 50G 100G 200G ・・・ 結果は...変化なし！ Prometheusはスペックをいくら上げても、負荷試験でハングアップしてしまう Mem
14. 14 Appendix) Prometheus ボトルネック調査
15. 15 Prometheus自体にはSlow Queryを検知する仕組みがないため、 別の仕組みでPrometheus自体のObservabilityも確保したいところ Appendix) Slow Query Slow Query
16. 3rd-party Storage検討
17. 17 おさらい: Prometheusのarchitecture 出典: https://prometheus.io/docs/introduction/overview/ 直接アクセス に問題あり
18. 18 Prometheusのメモリ負荷軽減へ 【3rd party製のStorage】 ・Cortex ・Thanos ・M3DB etc... GrafanaからのQueryをオフロードできるプロダクト 当初構築・検証をしたのは、この中のThanos, M3DBでした。
19. 19 Cortex 【負荷試験当時の問題点】 ・複雑性 ・弊社で実績のない componentsが多い ・release versionなし 出典: https://github.com/cortexproject/cortex
20. 20 Thanos 出典: https://github.com/thanos-io/thanos ThanosはImprobable社が開発を行っている CNCFでホストされているプロダクトです。 【負荷試験当時の問題点】 Grafanaでモニタリング ↓ 直近データのQueryは Prometheusにも行く ↓ Remote Read API問題※により Prometheusのメモリ逼迫 ↓ Prometheus OOMKill Thanos Queryから参 照あり

21. 21 Thanos 出典: https://github.com/thanos-io/thanos ThanosはImprobable社が開発を行っている CNCFでホストされているプロダクトです。 【負荷試験当時の問題点】 Grafanaでモニタリング ↓ 直近データのQueryは Prometheusにも行く ↓ Remote Read API問題※により Prometheusのメモリ逼迫 ↓ Prometheus OOMKill Thanos Queryから参 照あり
 通常の2倍近くメモリ消費
22. 22 Appendix) Thanos Remote Read API問題(> v2.13.0) 2.13.0以前はStreaming非対応 ↓ Prometheus, Thanos Sidecar の両方にqueryのresponse がメモリに展開される ↓ ２倍のメモリ必要 出典: https://prometheus.io/blog/2019/10/10/remote-read-meets-streaming TSDB Server Thanos Sidecar
23. 23 Appendix) Thanos Remote Read API問題(> v2.13.0) 出典: https://prometheus.io/blog/2019/10/10/remote-read-meets-streaming TSDB Prometheus Thanos Sidecar Thanos Query ①. Thanos QueryからのrequestはThanos Sidecarを 通してPrometheusへ送られる ①
24. 24 Appendix) Thanos Remote Read API問題(> v2.13.0) 出典: https://prometheus.io/blog/2019/10/10/remote-read-meets-streaming TSDB Prometheus Thanos Sidecar Thanos Query ②. TSDBからmetricsをselect 　　↓ Prometheus内で結果をすべてメモリに展開してから responseとしてThanos Sidecarに渡し 最終的にThanos Queryへ返す ②
25. 25 Appendix) Thanos Remote Read API問題(> v2.13.0) 出典: https://prometheus.io/blog/2019/10/10/remote-read-meets-streaming TSDB Prometheus Thanos Sidecar Thanos Query ②. TSDBからmetricsをselect 　　↓ Prometheus内で結果をすべてメモリに展開してから responseとしてThanos Sidecarに渡し 最終的にThanos Queryへ返す ② Memoryを２倍使用!!
26. 26 Appendix) Thanos Remote Read API問題(<= v2.13.0) Streaming対応 出典: https://prometheus.io/blog/2019/10/10/remote-read-meets-streaming TSDB Prometheus Thanos Sidecar Thanos Query ①. Thanos QueryからのrequestはThanos Sidecarを 通してPrometheusへ送られる ①
27. 27 Appendix) Thanos Remote Read API問題(<= v2.13.0) Streaming対応 出典: https://prometheus.io/blog/2019/10/10/remote-read-meets-streaming TSDB Prometheus Thanos Sidecar Thanos Query ②. TSDBからmetricsをselect 　　↓ 結果の一部をメモリに展開してから チャンクレスポンスとしてThanos Sidecarに渡し 順次Thanos Queryへ返す ②
28. 28 Appendix) Thanos Remote Read API問題(<= v2.13.0) Streaming対応 出典: https://prometheus.io/blog/2019/10/10/remote-read-meets-streaming TSDB Prometheus Thanos Sidecar Thanos Query ②. TSDBからmetricsをselect 　　↓ 結果の一部をメモリに展開してから チャンクレスポンスとしてThanos Sidecarに渡し 順次Thanos Queryへ返す ② Memory効率 劇的に改善
29. 29 M3DB M3DBはPrometheusのスケール問題を 解決するためにUberが開発した Remote Writeのプロダクトです。 etcdクラスタを組んだ上で、 M3DBをOperatorやHelm Chartで 構築していきます 【負荷試験当時の問題点】 ・構築、管理コスト高い ・Namespaces, Shards等の固有の 　 概念もあり学習コスト高い 出典: https://static.sched.com/hosted_files/kccnceu19/e0/M3%20and%20Prometheus% 2C%20Monitoring%20at%20Planet%20Scale%20for%20Everyone.pdf
30. 30 Victoria Metricsとの出会い https://twitter.com/yosshi_ Victoria Mectricsあるよ！ コミュニティの力(助言)・・・！
31. 31 ホストエラー以外で落ちることがなくなり、安定化へ Victoria Metrics導入後
32. Victoria Metricsとは？
33. 33 Victoria Metrics Victoria Metrics is ... THE BEST LONG-TERM REMOTE STORAGE FOR PROMETHEUS 公式ページ: https://victoriametrics.com/ Features ・SIMPLIFIES MONITORING ・GLOBAL QUERY VIEW ・DESIGNED TO BE FAST ・NATIVE PROMQL SUPPORT ・LONG TERM STORAGE ・LOW RESOURCE USAGE 本番運用から数ヶ月経ちましたが、非常に高い信頼性で動作しています
34. 34 Architecture 【Mode】 Single version Cluster version の2種あります 右図はCluster ver の図になります 出典: https://github.com/Victoria Metrics/VictoriaMetrics/blo b/cluster/README.md
35. 35 Architecture - VMStorage VMStorage TSDBにあたる部分 StatefulSetとして デプロイする Scale-out可能 (Scale-in不可) 出典: https://github.com/Victoria Metrics/VictoriaMetrics/blo b/cluster/README.md
36. 36 Architecture - VMSelect VMSelect storageに対して Queryを発行する Grafanaの Datasourceには VMSelectのLBを 指定する 出典: https://github.com/Victoria Metrics/VictoriaMetrics/blo b/cluster/README.md
37. 37 Architecture - VMInsert VMInsert storageに対して Writeを担当 Prometheusの RemoteWriteには VMInsertのLBを 指定する 出典: https://github.com/Victoria Metrics/VictoriaMetrics/blo b/cluster/README.md
38. 38 Scale-out可能な仕組み VMInsert: 1 VMStorage: 2 A VMSelect: 1 metric名 Index A 0 B 1 B Consistent hashing
39. 39 Scale-out可能な仕組み A B metric名 Index A 0→2 B 1→0 A B VMStorage: 3 VMInsert: 1 VMSelect: 1 Consistent hashing
40. 40 Scale-out可能な仕組み A B metric名 Index A 2 B 0 A B VMStorage: 3 VMInsert: 1 VMSelect: 1 すべてのVMStorageに 同じQueryを発行 Consistent hashing
41. 41 Appendix) Scale-out可能な仕組み VMInsert: Consistent hashing法により、対象のVMStorage(保存先)を決定する 出典: https://github.com/VictoriaMetrics/VictoriaMetrics/blob/cluster/app/vminsert/netstorage/insert_ctx.go#L166-L188
42. 42 Appendix) Scale-out可能な仕組み VMSelect: 全VMStorageに対して同じQueryを発行する 出典: https://github.com/VictoriaMetrics/VictoriaMetrics/blob/cluster/app/vmselect/netstorage/netstorage.go#L725-L749
43. 43 Monitoring構成(Single-cluster環境) 負荷試験初期はSingle-cluster環境で構築し、 8,000+ pods の環境で問題なく動作していました。 (Prometheusは1台) Remote Write Global Query View 8,000+ pods
44. 44 Monitoring構成(Multi-cluster環境) 合計10,000+ podsの環境で正常に動作しており、 Global Query ViewによりMulti-clusterを意識す ることなくQueryを発行することができます。 (Prometheusは各Clusterに1台) Remote Write Global Query View ・ ・ ・ 1,000~3,000 pods 1,000~3,000 pods 1,000~3,000 pods
45. 45 PrometheusとVictoria Metricsの役割分担 通常のPromethuesはRead + Write(Scrape)を行う PrometheusにはScrapeのみ行わせて、データはVictoria Metricsに集約させる scrape scrape scrape Remote Write
46. なぜVictoria Metrics を選んだのか？
47. 47 Victoria Metricsを選んだ理由 • Simplicity Select, Insert, Storageの3要素のみ • Scalability Scale-inはできないものの、Scale-outは簡単にできる • Reliability 高い信頼性。リソース効率がよく、負荷試験や 　　本番リリース後もホストエラー以外では落ちることなく稼働
48. 48 Victoria Metricsの課題(2020/1時点) • VMStorageのScale-in実質不可 Scale-inできるがdataロス発生 • Alert機能なし 現状各Prometheusでalert ruleを設定 • WebUI未実装 Prometheusのような/graph画面がないため Queryのdebugがしづらい(Grafana必須)
49. Parameter Tuning
50. 50 Prometheus remote_write設定 queue_config: max_shards: 30 capacity: 20,000 max_samples_per_send: 10,000 ↓ • 最大 600,000 samples キューイング • Capacityサイズの半分溜まったらRemote Storageへ転送 Parameter Tuning 400k+ samples per second
51. 51 Prometheus remote_write設定 Shards: WALからRemote Storageへ送るときに 一時的にSampleを格納する Appendix) Parameter Tuning shard0 shard1 Dynamic Queues write-ahead log (WAL) Remote Storage
52. 52 Prometheus remote_write設定 Shards: WALからRemote Storageへ送るときに 一時的にSampleを格納する Appendix) Parameter Tuning shard0 shard1 . . . Dynamic Queues write-ahead log (WAL) Remote Storage スクレイピング量に応じ 動的に変化 shard2
53. 53 Prometheus remote_write設定 Capacity: 1shardあたりqueuingできるsample数 Appendix) Parameter Tuning . . . shard . . .
54. 54 Prometheus remote_write設定 max_samples_per_send: 一度に送る最大sample数 ex: max_samples_per_send=3のとき... Appendix) Parameter Tuning shard . . .
55. 55 Prometheus remote_write設定 max_samples_per_send: 一度に送る最大sample数 ex: max_samples_per_send=3のとき... Appendix) Parameter Tuning shard . . . Remote Storageへ転送
56. 56 Victoria Metrics VMSelect • maxConcurrentRequests: 2*vCPU 同時Request数はコア数の2倍までが推奨 • maxUniqueTimeseries: 1,000,000 (default: 300,000) Parameter Tuning cannot find tag filter matching less than 300001 time series; either increase -search.maxUniqueTimeseries or use more specific tag filters
 天井にあたったParameter名が表示されるので Logベースでチューニングするのが簡単です
57. その他の工夫
58. 58 Prometheus& Victoria Metrics専用の NodePool(Node Instance Group)を用意 Scheduling上の工夫 Kubernetes cluster backend pool ZoneA ZoneB Instance Group label: back taint: back Instance Group label: back taint: back app pool ZoneA ZoneB Instance Group label: app taint: app Instance Group label: app taint: app prometheus pool ZoneA ZoneB Instance Group label: prom taint: prom Instance Group label: prom taint: prom system pool ZoneA ZoneB Instance Group label: system taint: system Instance Group label: system taint: system
59. 59 収集Metricsが増えすぎて、kube-state-metricsがOOMKilled → kube-state-metrics専用のNodeを確保 Scheduling上の工夫 Kubernetes cluster backend pool ZoneA ZoneB Instance Group label: back taint: back Instance Group label: back taint: back app pool ZoneA ZoneB Instance Group label: app taint: app Instance Group label: app taint: app kube-state-metrics pool ZoneA ZoneB Instance Group label: metric taint: metric Instance Group label: metric taint: metric prometheus pool ZoneA ZoneB Instance Group label: prom taint: prom Instance Group label: prom taint: prom
60. 60 Prometheus負荷試験 Prometheus&水平スケール用プロダクトで問題ないかを検証するため、擬似的に TimeSeriesを生成し、Prometheus&水平スケール用プロダクトがその負荷に耐えら れるかどうかの試験を実施しました。 その時、利用したのがOSSのツール「Avalanche」です。 Avalanche: https://github.com/open-fresh/avalanche 参考記事: https://blog.freshtracks.io/load-testing-prometheus-metric-ingestion-5b878711711c metric-count series-count interval ... Avalanche scarape_configs: - job_name: avalanche ... 疑似Metrics生成 Scrape
61. 61 Grafanaによるブラウザクラッシュ Grafana上で表示するパネル & 描画点が多すぎてブラウザがクラッシュ
62. 62 Grafanaの分析 処理が時間かかっている箇所は、GraphのRenderをコールする箇所 → 表示時間を短くするには、Renderingする箇所・時間を減らすしかない パネルの分割・Resolutionの削減など
63. 63 Appendix) Grafanaの分析 Grafanaで時間がかかる部分は、 PromQLの実行時間を除けば、 JavaScriptによるスクリプト + 描画 Angular + React + jQueryの複合 レンダリングはjQueryのflotを利用
64. 64 GPU性能の良いPCを用意
65. まとめ
66. 66 まとめ • PrometheusはScrape専用にしてメモリ負荷軽減 • ニーズに応じたプロダクト採用 → 今回はVictoriaMetricsがマッチ • Insertの負荷試験はAvalancheで実現 • Grafanaでは表示するメトリック、時間を絞る
67. 67 Thank you !!