$30 off During Our Annual Pro Sale. View Details »

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

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

inletorder

January 15, 2020
Tweet

Other Decks in Programming

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
    がメモリに展開される

    2倍のメモリ必要
    出典: 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を2倍使用!!

    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