Slide 1
Slide 1 text
Victoria Metricsで作る
大規模・超負荷
システムモニタリング基盤
2020/01/15
Prometheus Meetup#3
Slide 2
Slide 2 text
2
● 入江 順也
● 株式会社コロプラ(2015年入社)
○ インフラチーム所属
○ GKEタイトル運用、運用効率化担当
自己紹介
Slide 3
Slide 3 text
3
第 9 回 Google Cloud INSIDE Games & Apps
GKEとCloud Spannerが躍動するドラゴンクエストウォーク
告知: 最近の発表
https://www.slideshare.net/GoogleCloudPlatformJP/gke-cloud-spanner-9-google-cloud-inside-game-apps
Slide 4
Slide 4 text
4
アジェンダ
● 前提・背景
● 3rd-party Storage検討
● Victoria Metricsとは？
● なぜVictoriaMetricsを選んだのか?
● Parameter Tuning
● その他の工夫
● まとめ
Slide 5
Slide 5 text
150Billion
(1500億)
Slide 6
Slide 6 text
累計Datapoints
(from 10,000+ Pods)
Slide 7
Slide 7 text
前提・背景
Slide 8
Slide 8 text
8
Game Title1
コロプラではKubernetes上の監視に、Prometheus + Grafanaを利用しています
これまでのPrometheus/Grafanaの運用
Single Tenant構成
ゲームタイトルごとに各K8sクラスタ
K8sクラスタ : Prometheus = 1:1
API
Game Title2
PvP
API
Game Title3
API
Slide 9
Slide 9 text
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
Slide 10
Slide 10 text
ある日の負荷試験
にて・・・
Slide 11
Slide 11 text
11
想定の¼の負荷試験時・・・
Slide 12
Slide 12 text
12
開始数分で死ぬPrometheus・・・
OOMKilled
Slide 13
Slide 13 text
13
Prometheusのスケールアップで対応するも...
OOMで死んでしまったので、対応としてとりあえずPrometheusのNodeのスペッ
クアップとresources.requests, resources.limitをアップ↑
50G 100G 200G
・・・
結果は...変化なし！
Prometheusはスペックをいくら上げても、負荷試験でハングアップしてしまう
Mem
Slide 14
Slide 14 text
14
Appendix) Prometheus ボトルネック調査
Slide 15
Slide 15 text
15
Prometheus自体にはSlow Queryを検知する仕組みがないため、
別の仕組みでPrometheus自体のObservabilityも確保したいところ
Appendix) Slow Query
Slow Query
Slide 16
Slide 16 text
3rd-party Storage検討
Slide 17
Slide 17 text
17
おさらい: Prometheusのarchitecture
出典: https://prometheus.io/docs/introduction/overview/
直接アクセス
に問題あり
Slide 18
Slide 18 text
18
Prometheusのメモリ負荷軽減へ
【3rd party製のStorage】
・Cortex
・Thanos
・M3DB
etc...
GrafanaからのQueryをオフロードできるプロダクト
当初構築・検証をしたのは、この中のThanos, M3DBでした。
Slide 19
Slide 19 text
19
Cortex
【負荷試験当時の問題点】
・複雑性
・弊社で実績のない
componentsが多い
・release versionなし
出典: https://github.com/cortexproject/cortex
Slide 20
Slide 20 text
20
Thanos
出典: https://github.com/thanos-io/thanos
ThanosはImprobable社が開発を行っている
CNCFでホストされているプロダクトです。
【負荷試験当時の問題点】
Grafanaでモニタリング
↓
直近データのQueryは
Prometheusにも行く
↓
Remote Read API問題※により
Prometheusのメモリ逼迫
↓
Prometheus OOMKill
Thanos Queryから参
照あり
Slide 21
Slide 21 text
21
Thanos
出典: https://github.com/thanos-io/thanos
ThanosはImprobable社が開発を行っている
CNCFでホストされているプロダクトです。
【負荷試験当時の問題点】
Grafanaでモニタリング
↓
直近データのQueryは
Prometheusにも行く
↓
Remote Read API問題※により
Prometheusのメモリ逼迫
↓
Prometheus OOMKill
Thanos Queryから参
照あり
通常の2倍近くメモリ消費
Slide 22
Slide 22 text
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
Slide 23
Slide 23 text
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へ送られる
①
Slide 24
Slide 24 text
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へ返す
②
Slide 25
Slide 25 text
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を２倍使用!!
Slide 26
Slide 26 text
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へ送られる
①
Slide 27
Slide 27 text
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へ返す
②
Slide 28
Slide 28 text
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効率
劇的に改善
Slide 29
Slide 29 text
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
Slide 30
Slide 30 text
30
Victoria Metricsとの出会い
https://twitter.com/yosshi_
Victoria Mectricsあるよ！
コミュニティの力(助言)・・・！
Slide 31
Slide 31 text
31
ホストエラー以外で落ちることがなくなり、安定化へ
Victoria Metrics導入後
Slide 32
Slide 32 text
Victoria Metricsとは？
Slide 33
Slide 33 text
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
本番運用から数ヶ月経ちましたが、非常に高い信頼性で動作しています
Slide 34
Slide 34 text
34
Architecture
【Mode】
Single version
Cluster version
の2種あります
右図はCluster ver
の図になります
出典:
https://github.com/Victoria
Metrics/VictoriaMetrics/blo
b/cluster/README.md
Slide 35
Slide 35 text
35
Architecture - VMStorage
VMStorage
TSDBにあたる部分
StatefulSetとして
デプロイする
Scale-out可能
(Scale-in不可)
出典:
https://github.com/Victoria
Metrics/VictoriaMetrics/blo
b/cluster/README.md
Slide 36
Slide 36 text
36
Architecture - VMSelect
VMSelect
storageに対して
Queryを発行する
Grafanaの
Datasourceには
VMSelectのLBを
指定する
出典:
https://github.com/Victoria
Metrics/VictoriaMetrics/blo
b/cluster/README.md
Slide 37
Slide 37 text
37
Architecture - VMInsert
VMInsert
storageに対して
Writeを担当
Prometheusの
RemoteWriteには
VMInsertのLBを
指定する
出典:
https://github.com/Victoria
Metrics/VictoriaMetrics/blo
b/cluster/README.md
Slide 38
Slide 38 text
38
Scale-out可能な仕組み
VMInsert: 1
VMStorage: 2
A
VMSelect: 1
metric名 Index
A 0
B 1
B
Consistent hashing
Slide 39
Slide 39 text
39
Scale-out可能な仕組み
A
B
metric名 Index
A 0→2
B 1→0
A
B
VMStorage: 3
VMInsert: 1 VMSelect: 1
Consistent hashing
Slide 40
Slide 40 text
40
Scale-out可能な仕組み
A
B
metric名 Index
A 2
B 0
A
B
VMStorage: 3
VMInsert: 1 VMSelect: 1
すべてのVMStorageに
同じQueryを発行
Consistent hashing
Slide 41
Slide 41 text
41
Appendix) Scale-out可能な仕組み
VMInsert:
Consistent hashing法により、対象のVMStorage(保存先)を決定する
出典: https://github.com/VictoriaMetrics/VictoriaMetrics/blob/cluster/app/vminsert/netstorage/insert_ctx.go#L166-L188
Slide 42
Slide 42 text
42
Appendix) Scale-out可能な仕組み
VMSelect:
全VMStorageに対して同じQueryを発行する
出典: https://github.com/VictoriaMetrics/VictoriaMetrics/blob/cluster/app/vmselect/netstorage/netstorage.go#L725-L749
Slide 43
Slide 43 text
43
Monitoring構成(Single-cluster環境)
負荷試験初期はSingle-cluster環境で構築し、
8,000+ pods の環境で問題なく動作していました。
(Prometheusは1台)
Remote Write Global Query View
8,000+ pods
Slide 44
Slide 44 text
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
Slide 45
Slide 45 text
45
PrometheusとVictoria Metricsの役割分担
通常のPromethuesはRead + Write(Scrape)を行う
PrometheusにはScrapeのみ行わせて、データはVictoria Metricsに集約させる
scrape
scrape
scrape
Remote Write
Slide 46
Slide 46 text
なぜVictoria Metrics
を選んだのか？
Slide 47
Slide 47 text
47
Victoria Metricsを選んだ理由
● Simplicity
Select, Insert, Storageの3要素のみ
● Scalability
Scale-inはできないものの、Scale-outは簡単にできる
● Reliability
高い信頼性。リソース効率がよく、負荷試験や
本番リリース後もホストエラー以外では落ちることなく稼働
Slide 48
Slide 48 text
48
Victoria Metricsの課題(2020/1時点)
● VMStorageのScale-in実質不可
Scale-inできるがdataロス発生
● Alert機能なし
現状各Prometheusでalert ruleを設定
● WebUI未実装
Prometheusのような/graph画面がないため
Queryのdebugがしづらい(Grafana必須)
Slide 49
Slide 49 text
Parameter Tuning
Slide 50
Slide 50 text
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
Slide 51
Slide 51 text
51
Prometheus remote_write設定
Shards: WALからRemote Storageへ送るときに
一時的にSampleを格納する
Appendix) Parameter Tuning
shard0
shard1
Dynamic Queues
write-ahead log
(WAL)
Remote Storage
Slide 52
Slide 52 text
52
Prometheus remote_write設定
Shards: WALからRemote Storageへ送るときに
一時的にSampleを格納する
Appendix) Parameter Tuning
shard0
shard1
.
.
.
Dynamic Queues
write-ahead log
(WAL)
Remote Storage
スクレイピング量に応じ
動的に変化
shard2
Slide 53
Slide 53 text
53
Prometheus remote_write設定
Capacity: 1shardあたりqueuingできるsample数
Appendix) Parameter Tuning
. . .
shard
. . .
Slide 54
Slide 54 text
54
Prometheus remote_write設定
max_samples_per_send: 一度に送る最大sample数
ex: max_samples_per_send=3のとき...
Appendix) Parameter Tuning
shard
. . .
Slide 55
Slide 55 text
55
Prometheus remote_write設定
max_samples_per_send: 一度に送る最大sample数
ex: max_samples_per_send=3のとき...
Appendix) Parameter Tuning
shard
. . . Remote Storageへ転送
Slide 56
Slide 56 text
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ベースでチューニングするのが簡単です
Slide 57
Slide 57 text
その他の工夫
Slide 58
Slide 58 text
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
Slide 59
Slide 59 text
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
Slide 60
Slide 60 text
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
Slide 61
Slide 61 text
61
Grafanaによるブラウザクラッシュ
Grafana上で表示するパネル & 描画点が多すぎてブラウザがクラッシュ
Slide 62
Slide 62 text
62
Grafanaの分析
処理が時間かかっている箇所は、GraphのRenderをコールする箇所
→ 表示時間を短くするには、Renderingする箇所・時間を減らすしかない
パネルの分割・Resolutionの削減など
Slide 63
Slide 63 text
63
Appendix) Grafanaの分析
Grafanaで時間がかかる部分は、
PromQLの実行時間を除けば、
JavaScriptによるスクリプト + 描画
Angular + React + jQueryの複合
レンダリングはjQueryのflotを利用
Slide 64
Slide 64 text
64
GPU性能の良いPCを用意
Slide 65
Slide 65 text
まとめ
Slide 66
Slide 66 text
66
まとめ
● PrometheusはScrape専用にしてメモリ負荷軽減
● ニーズに応じたプロダクト採用
→ 今回はVictoriaMetricsがマッチ
● Insertの負荷試験はAvalancheで実現
● Grafanaでは表示するメトリック、時間を絞る
Slide 67
Slide 67 text
67
Thank you !!