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

Transcript

1. Victoria Metricsで作る
   大規模・超負荷
   システムモニタリング基盤
   2020/01/15
   Prometheus Meetup#3
   

   View Slide

2. 2
   ● 入江 順也
   ● 株式会社コロプラ(2015年入社)
   ○ インフラチーム所属
   ○ GKEタイトル運用、運用効率化担当
   自己紹介
   

   View Slide

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
   

   View Slide

4. 4
   アジェンダ
   ● 前提・背景
   ● 3rd-party Storage検討
   ● Victoria Metricsとは？
   ● なぜVictoriaMetricsを選んだのか?
   ● Parameter Tuning
   ● その他の工夫
   ● まとめ
   

   View Slide

5. 150Billion
   (1500億)
   

   View Slide

6. 累計Datapoints
   (from 10,000+ Pods)
   

   View Slide

7. 前提・背景
   

   View Slide

8. 8
   Game Title1
   コロプラではKubernetes上の監視に、Prometheus + Grafanaを利用しています
   これまでのPrometheus/Grafanaの運用
   Single Tenant構成
   ゲームタイトルごとに各K8sクラスタ
   K8sクラスタ : Prometheus = 1:1
   API
   Game Title2
   PvP
   API
   Game Title3
   API
   

   View Slide

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
   

   View Slide

10. ある日の負荷試験
    にて・・・
    

    View Slide

11. 11
    想定の¼の負荷試験時・・・
    

    View Slide

12. 12
    開始数分で死ぬPrometheus・・・
    OOMKilled
    

    View Slide

13. 13
    Prometheusのスケールアップで対応するも...
    OOMで死んでしまったので、対応としてとりあえずPrometheusのNodeのスペッ
    クアップとresources.requests, resources.limitをアップ↑
    50G 100G 200G
    ・・・
    結果は...変化なし！
    Prometheusはスペックをいくら上げても、負荷試験でハングアップしてしまう
    Mem
    

    View Slide

14. 14
    Appendix) Prometheus ボトルネック調査
    

    View Slide

15. 15
    Prometheus自体にはSlow Queryを検知する仕組みがないため、
    別の仕組みでPrometheus自体のObservabilityも確保したいところ
    Appendix) Slow Query
    Slow Query
    

    View Slide

16. 3rd-party Storage検討
    

    View Slide

17. 17
    おさらい: Prometheusのarchitecture
    出典: https://prometheus.io/docs/introduction/overview/
    直接アクセス
    に問題あり
    

    View Slide

18. 18
    Prometheusのメモリ負荷軽減へ
    【3rd party製のStorage】
    ・Cortex
    ・Thanos
    ・M3DB
    etc...
    GrafanaからのQueryをオフロードできるプロダクト
    当初構築・検証をしたのは、この中のThanos, M3DBでした。
    

    View Slide

19. 19
    Cortex
    【負荷試験当時の問題点】
    ・複雑性
    ・弊社で実績のない
    componentsが多い
    ・release versionなし
    出典: https://github.com/cortexproject/cortex
    

    View Slide

20. 20
    Thanos
    出典: https://github.com/thanos-io/thanos
    ThanosはImprobable社が開発を行っている
    CNCFでホストされているプロダクトです。
    【負荷試験当時の問題点】
    Grafanaでモニタリング
    ↓
    直近データのQueryは
    Prometheusにも行く
    ↓
    Remote Read API問題※により
    Prometheusのメモリ逼迫
    ↓
    Prometheus OOMKill
    Thanos Queryから参
    照あり

    

    View Slide

21. 21
    Thanos
    出典: https://github.com/thanos-io/thanos
    ThanosはImprobable社が開発を行っている
    CNCFでホストされているプロダクトです。
    【負荷試験当時の問題点】
    Grafanaでモニタリング
    ↓
    直近データのQueryは
    Prometheusにも行く
    ↓
    Remote Read API問題※により
    Prometheusのメモリ逼迫
    ↓
    Prometheus OOMKill
    Thanos Queryから参
    照あり

    通常の2倍近くメモリ消費
    

    View Slide

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
    

    View Slide

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へ送られる
    ①
    

    View Slide

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へ返す
    ②
    

    View Slide

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を２倍使用!!
    

    View Slide

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へ送られる
    ①
    

    View Slide

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へ返す
    ②
    

    View Slide

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効率
    劇的に改善
    

    View Slide

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
    

    View Slide

30. 30
    Victoria Metricsとの出会い
    https://twitter.com/yosshi_
    Victoria Mectricsあるよ！
    コミュニティの力(助言)・・・！
    

    View Slide

31. 31
    ホストエラー以外で落ちることがなくなり、安定化へ
    Victoria Metrics導入後
    

    View Slide

32. Victoria Metricsとは？
    

    View Slide

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
    本番運用から数ヶ月経ちましたが、非常に高い信頼性で動作しています
    

    View Slide

34. 34
    Architecture
    【Mode】
    Single version
    Cluster version
    の2種あります
    右図はCluster ver
    の図になります
    出典:
    https://github.com/Victoria
    Metrics/VictoriaMetrics/blo
    b/cluster/README.md
    

    View Slide

35. 35
    Architecture - VMStorage
    VMStorage
    TSDBにあたる部分
    StatefulSetとして
    デプロイする
    Scale-out可能
    (Scale-in不可)
    出典:
    https://github.com/Victoria
    Metrics/VictoriaMetrics/blo
    b/cluster/README.md
    

    View Slide

36. 36
    Architecture - VMSelect
    VMSelect
    storageに対して
    Queryを発行する
    Grafanaの
    Datasourceには
    VMSelectのLBを
    指定する
    出典:
    https://github.com/Victoria
    Metrics/VictoriaMetrics/blo
    b/cluster/README.md
    

    View Slide

37. 37
    Architecture - VMInsert
    VMInsert
    storageに対して
    Writeを担当
    Prometheusの
    RemoteWriteには
    VMInsertのLBを
    指定する
    出典:
    https://github.com/Victoria
    Metrics/VictoriaMetrics/blo
    b/cluster/README.md
    

    View Slide

38. 38
    Scale-out可能な仕組み
    VMInsert: 1
    VMStorage: 2
    A
    VMSelect: 1
    metric名 Index
    A 0
    B 1
    B
    Consistent hashing
    

    View Slide

39. 39
    Scale-out可能な仕組み
    A
    B
    metric名 Index
    A 0→2
    B 1→0
    A
    B
    VMStorage: 3
    VMInsert: 1 VMSelect: 1
    Consistent hashing
    

    View Slide

40. 40
    Scale-out可能な仕組み
    A
    B
    metric名 Index
    A 2
    B 0
    A
    B
    VMStorage: 3
    VMInsert: 1 VMSelect: 1
    すべてのVMStorageに
    同じQueryを発行
    Consistent hashing
    

    View Slide

41. 41
    Appendix) Scale-out可能な仕組み
    VMInsert:
    Consistent hashing法により、対象のVMStorage(保存先)を決定する
    出典: https://github.com/VictoriaMetrics/VictoriaMetrics/blob/cluster/app/vminsert/netstorage/insert_ctx.go#L166-L188
    

    View Slide

42. 42
    Appendix) Scale-out可能な仕組み
    VMSelect:
    全VMStorageに対して同じQueryを発行する
    出典: https://github.com/VictoriaMetrics/VictoriaMetrics/blob/cluster/app/vmselect/netstorage/netstorage.go#L725-L749
    

    View Slide

43. 43
    Monitoring構成(Single-cluster環境)
    負荷試験初期はSingle-cluster環境で構築し、
    8,000+ pods の環境で問題なく動作していました。
    (Prometheusは1台)
    Remote Write Global Query View
    8,000+ pods
    

    View Slide

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
    

    View Slide

45. 45
    PrometheusとVictoria Metricsの役割分担
    通常のPromethuesはRead + Write(Scrape)を行う
    PrometheusにはScrapeのみ行わせて、データはVictoria Metricsに集約させる
    scrape
    scrape
    scrape
    Remote Write
    

    View Slide

46. なぜVictoria Metrics
    を選んだのか？
    

    View Slide

47. 47
    Victoria Metricsを選んだ理由
    ● Simplicity
    Select, Insert, Storageの3要素のみ
    ● Scalability
    Scale-inはできないものの、Scale-outは簡単にできる
    ● Reliability
    高い信頼性。リソース効率がよく、負荷試験や
    　　本番リリース後もホストエラー以外では落ちることなく稼働
    

    View Slide

48. 48
    Victoria Metricsの課題(2020/1時点)
    ● VMStorageのScale-in実質不可
    Scale-inできるがdataロス発生
    ● Alert機能なし
    現状各Prometheusでalert ruleを設定
    ● WebUI未実装
    Prometheusのような/graph画面がないため
    Queryのdebugがしづらい(Grafana必須)
    

    View Slide

49. Parameter Tuning
    

    View Slide

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
    

    View Slide

51. 51
    Prometheus remote_write設定
    Shards: WALからRemote Storageへ送るときに
    一時的にSampleを格納する
    Appendix) Parameter Tuning
    shard0
    shard1
    Dynamic Queues
    write-ahead log
    (WAL)
    Remote Storage
    

    View Slide

52. 52
    Prometheus remote_write設定
    Shards: WALからRemote Storageへ送るときに
    一時的にSampleを格納する
    Appendix) Parameter Tuning
    shard0
    shard1
    .
    .
    .
    Dynamic Queues
    write-ahead log
    (WAL)
    Remote Storage
    スクレイピング量に応じ
    動的に変化
    shard2
    

    View Slide

53. 53
    Prometheus remote_write設定
    Capacity: 1shardあたりqueuingできるsample数
    Appendix) Parameter Tuning
    . . .
    shard
    . . .
    

    View Slide

54. 54
    Prometheus remote_write設定
    max_samples_per_send: 一度に送る最大sample数
    ex: max_samples_per_send=3のとき...
    Appendix) Parameter Tuning
    shard
    . . .
    

    View Slide

55. 55
    Prometheus remote_write設定
    max_samples_per_send: 一度に送る最大sample数
    ex: max_samples_per_send=3のとき...
    Appendix) Parameter Tuning
    shard
    . . . Remote Storageへ転送
    

    View Slide

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ベースでチューニングするのが簡単です
    

    View Slide

57. その他の工夫
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

61. 61
    Grafanaによるブラウザクラッシュ
    Grafana上で表示するパネル & 描画点が多すぎてブラウザがクラッシュ
    

    View Slide

62. 62
    Grafanaの分析
    処理が時間かかっている箇所は、GraphのRenderをコールする箇所
    → 表示時間を短くするには、Renderingする箇所・時間を減らすしかない
    パネルの分割・Resolutionの削減など
    

    View Slide

63. 63
    Appendix) Grafanaの分析
    Grafanaで時間がかかる部分は、
    PromQLの実行時間を除けば、
    JavaScriptによるスクリプト + 描画
    Angular + React + jQueryの複合
    レンダリングはjQueryのflotを利用
    

    View Slide

64. 64
    GPU性能の良いPCを用意
    

    View Slide

65. まとめ
    

    View Slide

66. 66
    まとめ
    ● PrometheusはScrape専用にしてメモリ負荷軽減
    ● ニーズに応じたプロダクト採用
    → 今回はVictoriaMetricsがマッチ
    ● Insertの負荷試験はAvalancheで実現
    ● Grafanaでは表示するメトリック、時間を絞る
    

    View Slide

67. 67
    Thank you !!
    

    View Slide