Tweet
Tweet

Slide 1

Slide 1 text

で構築する 複数Kubernetesの監視基盤 in CNDT 2020 CyberAgent, Inc. Speakers: Riku Gemba, Katsuya Kawabe #CNDT2020_C

Slide 2

Slide 2 text

AGENDA 1. 自己紹介 2. AKEの紹介と背景 3. VictoriaMetricsとPrometheus 4. 監視基盤のアーキテクチャ 5. 監視基盤の運用

Slide 3

Slide 3 text

自己紹介 - 川部 勝也 - CIU (CyberAgent group Infrastructure Unit) 所属 - インフラエンジニア - 2020年新卒入社 - 趣味: カラオケ - 源波 陸 - CIU所属 - インフラエンジニア - 2020年新卒入社 - 特技: マインスイーパー

Slide 4

Slide 4 text

AGENDA 1. 自己紹介 ✔ 2. AKEの紹介と背景 3. VictoriaMetricsとPrometheus 4. 監視基盤のアーキテクチャ 5. 監視基盤の運用

Slide 5

Slide 5 text

AKE の紹介

Slide 6

Slide 6 text

AKE の紹介 AKEについてより詳しく知りたい方は @makocchi, @amsy810 お二人の資料を漁ってください

Slide 7

Slide 7 text

AKE のアーキテクチャ AKE Client master node node node Pod Pod Pod Pod Pod Pod Pod Pod Pod Ingress controller Pod Ingress VM external network VM

Slide 8

Slide 8 text

✱ マネージドサービスとしての質を高めたい ✱ 監視ツールを用いて障害に即時対応 ✱ 横断監視で Datadog を使用するのは、費用が高くなりやすい ✱ プロダクトが増えるごとにコストが増加する ✱ クラスタが増えればもっと増える 背景

Slide 9

Slide 9 text

背景: 複数のDatadogで監視するメトリクスが重複 横断監視用Datadog プロダクトAのメトリクス プロダクトBのメトリクス プロダクトCのメトリクス プロダクトDのメトリクス ・・・ ・・・ プロダクトAのDatadog プロダクトAのメトリクス プロダクトBのDatadog プロダクトBのメトリクス

Slide 10

Slide 10 text

背景: PrometheusとGrafana Datadog のダッシュボードが横断監視用とプロジェクト用で乱立し、 費用が高くなる、同じメトリクスを二つのAPIキーで 送信しなければならないといった問題が発生する Prometheus と Grafana を用いれば、 横断監視しつつ、ダッシュボードをプロダクト毎に払い出すことができる

Slide 11

Slide 11 text

AGENDA 1. 自己紹介 ✔ 2. AKEの紹介と背景 ✔ 3. VictoriMetricsとPrometheus 4. 監視基盤のアーキテクチャ 5. 監視基盤の運用

Slide 12

Slide 12 text

VictoriaMetrics と Prometheus

Slide 13

Slide 13 text

こいつは何者？ VictoriaMetrics と Prometheus

Slide 14

Slide 14 text

ログを永続化 Prometheus Prometheusのみで横断監視する場合 Storage PodやDeployment といったユーザの管理するリ ソースから kubelet や kube-proxyといった Kubernetesのコンポーネントも監視 Federation 機能を使って複数Prometheusのログを 集約可能

Slide 15

Slide 15 text

ログを永続化 Prometheus Prometheusのみで横断監視する場合 Storage PodやDeployment といったユーザの管理するリ ソースから kubelet や kube-proxyといった Kubernetesのコンポーネントも監視 1サーバなのでいつか限界がくる

Slide 16

Slide 16 text

Storage Victoria Metrics メトリクスを永続化 Prometheusの収集したメトリクスを さらに集約して永続化する機構 Prometheusのみで横断監視する場合

Slide 17

Slide 17 text

VictoriaMetricsのアーキテクチャ Load Balancer vmselect vmselect vmstorage vmstorage vminsert vminsert Load Balancer 図参考: https://github.com/VictoriaMetrics/VictoriaMetrics/wiki/Cluster-VictoriaMetrics 読み込みフロー: Grafana や Prometheus からのクエリは vmselect が vmstorage からデータを読み込み、マージして返す vmselect はステートレス 書き込みフロー: remote write や OpenTSDB の put protocol をサポート ConsistentHash を用いて vmstorage への負荷分散を行う vminsert はステートレス 実データを保存するストレージプロセス データはファイルシステムにファイルとして保存される ステートフル ・・・ ・・・ ・・・

Slide 18

Slide 18 text

vmstorageのデータと対応ストレージ vmstorage データの実態は vmstorage が 動くマシンのファイルシステムに 保存される つまり GCS や S3 を FUSEで ファイルシステムとして マウントすればバックエンドスト レージとして使用可能 当然 NFS も使用可能

Slide 19

Slide 19 text

VictoriaMetricsのデータ圧縮の工夫 ✱ VictoriaMetrics独自の圧縮アルゴリズムを採用 ✱ Gorilla(Prometheus や InfluxDB で使われている時系列DB)の圧縮手法より node exporter のデータ圧縮率が10倍である ✱ 符号化したデータに更に zstd で圧縮をかけている ✱ Prometheus の Counter メトリクスをデルタ符号化で圧縮 参考: https://medium.com/faun/victoriametrics-achieving-better-compression-for-time-series-data-than-gorilla-317bc1f95932 https://hnakamur.github.io/blog/2017/02/12/tried-facebook-gorilla-time-series-database-compression/

Slide 20

Slide 20 text

VictoriaMetricsのデータ圧縮の工夫 Gorilla による浮動小数点以下の圧縮 VictoriaMetrics による浮動小数点以下の圧縮 浮動小数点以下に 10^N を乗算し、整数化することで ランレングス符号化やハフマン符号化による圧縮がより機能しやすくなる

Slide 21

Slide 21 text

VictoriaMetricsによるデータ圧縮のパフォーマンス 画像出典: https://victoriametrics.com/ 2TBのディスクに2年間保存できるサンプルの量は80万超 となっており、既存の時系列DBに比べて圧倒的。

Slide 22

Slide 22 text

競合のOSS (Thanos, Cortex)

Slide 23

Slide 23 text

✱ Cortex ✱ DynamoDB, Google Bigtable, Cassandra, S3, GCS, Microsoft Azure など 多様なストレージに対応 ✱ HA対応のアーキテクチャ ✱ インメモリキャッシュによる高速なクエリの処理 ✱ Helmで運用可能 ✱ Thanos ✱ GCS, S3 にメトリクスを保存 ✱ Prometheus のデータを ObjectStorage に保存する Gateway を冗長可能 ✱ Operator, Helmで運用可能 競合のOSS (Thanos, Cortex)

Slide 24

Slide 24 text

✱ Consul、Memcache、DynamoDB、BigTable、Cassandraなど多くのサードパー ティソフトウェアに依存していて、アーキテクチャが複雑で運用負荷が高い ✱ Helmのチャートが新しいKubernetesのバージョンで動かなかったりする ✱ VictoriaMetricsに比べてCPU, Memory使用率が高い ✱ サンプルの圧縮率が低い Why not Cortex 参考 : https://promcon.io/2019-munich/slides/remote-write-storage-wars.pdf

Slide 25

Slide 25 text

✱ データ損失すると最大2時間分消失する可能性がある ✱ ThanosサイドカーをデプロイするのとPrometheusのデータ圧縮を無効化する必要 があり、Prometheusの性能を低下させてしまう可能性がある ✱ VictoriaMetricsよりCPU, Memoryを使用率が高い Why not Thanos 参考 : https://promcon.io/2019-munich/slides/remote-write-storage-wars.pdf

Slide 26

Slide 26 text

Why VictoriaMetrics 色々検証しましたが・・・

Slide 27

Slide 27 text

Why VictoriaMetrics ✱ シンプルなアーキテクチャによる運用のしやすさ ✱ 高圧縮なアルゴリズム ✱ 必要十分な可用性、耐障害性、スケール性

Slide 28

Slide 28 text

AGENDA 1. 自己紹介 ✔ 2. AKEの紹介 ✔ 3. VictoriMetricsとPrometheus ✔ 4. 監視基盤のアーキテクチャ 5. 監視基盤の運用

Slide 29

Slide 29 text

横断監視基盤の構成: メトリクスの書き込み K8s Cluster K8s Cluster K8s Cluster Load Balancer vmselect vmselect vmstorage vmstorage vminsert vminsert Load Balancer ・・・ ・・・ ・・・

Slide 30

Slide 30 text

横断監視基盤の構成: クエリの実行 Load Balancer vmselect vmselect vmstorage vmstorage vminsert vminsert Load Balancer ・・・ ・・・ ・・・ vmalert alertmanager AKE Developer 通知 可視化

Slide 31

Slide 31 text

横断監視基盤の構成: メトリクスの書き込み K8s Cluster K8s Cluster K8s Cluster Load Balancer vmselect vmselect vmstorage vmstorage vminsert vminsert Load Balancer ・・・ ・・・ ・・・

Slide 32

Slide 32 text

横断監視基盤の構成: よくあるクラスタ Client

Slide 33

Slide 33 text

横断監視基盤の構成: よくあるクラスタ Client LoadBalancer も監視したい

Slide 34

Slide 34 text

AKE のアーキテクチャ AKE Client master node node node Pod Pod Pod Pod Pod Pod Pod Pod Pod Ingress controller Pod Ingress VM external network VM

Slide 35

Slide 35 text

Ingress はクラスタに紐づくリソースだが、 実態のVMやプロセスがクラスタの外部に存在する しかし、VM上で動作するプロセスやVMのパフォーマンスに関す るメトリクスを Prometheus で監視したい Ingress の監視

Slide 36

Slide 36 text

横断監視基盤の構成: クラスタ内部の監視構成 kube-state-metrics AKE Prometheus node exporter kube-proxy kubelet Core DNS etcd Pull Ingress VM VM 様々な exporter 様々な exporter

Slide 37

Slide 37 text

横断監視基盤の構成: クラスタ内部の監視構成 kube-state-metrics AKE Prometheus node exporter kube-proxy kubelet Core DNS etcd Pull Ingress VM VM 様々な exporter 様々な exporter ✱ どうやってIngress VMのIPアドレスを リ ソースの作成に応じてディスカバリするのか ✱ VMはユーザによって減ったり増えたりする可能性もある

Slide 38

Slide 38 text

✱ Prometheus のみではクラスタ外部に構成されている、ロードバランサの実態とし て作成される複数のVMをディスカバリできない ✱ static_configs や file_sd_configs を使用すれば明示的にIPアドレスを指定でき る ✱ static_configs や file_sd_configs を自動的に埋めたい クラスタ外に立つリソースの監視手法

Slide 39

Slide 39 text

✱ AKE Prometheus は Prometheus Operator を用いてデプロイされている ✱ Operatorは static_configs, file_sd_configs を Secret で管理している ✱ つまり、Secretをなんとかして書き換えてあげれば AKE Prometheus が動的に Ingress VM の Exporter の Job をPullすることができる クラスタ内部の監視構成 これを実現する CronJob を実装すればやりたいことはできる！

Slide 40

Slide 40 text

✱ AKE Prometheus は Prometheus Operator を用いてデプロイされている ✱ Operatorは static_configs, file_sd_configs を Secret で管理している ✱ つまり、Secretをなんとかして書き換えてあげれば AKE Prometheus が動的に Ingress VM の Exporter の Job をPullすることができる クラスタ内部の監視構成 これを実現する CronJob を実装すればやりたいことはできる！ Custom Controller に 実装する手もあったが、責任の分 散と実装、デバッグのしやすさから CronJob を選択

Slide 41

Slide 41 text

クラスタ内部の監視構成

Slide 42

Slide 42 text

Ingressの監視 static_configs が書かれたyamlの実態は secretに格納されている

Slide 43

Slide 43 text

Base64エンコードされたyamlを書き換える 元のSecret Data Ingress監視Jobを追加したSecret Data Ingressの監視

Slide 44

Slide 44 text

Ingressの監視: CronJobの動作 Ingress HeatStack Resource AKE Prometheus Secret Services Cronjob 1. Heatstack リソースを列挙 する 2. VM の IP を Heatstack リ ソース毎に抽出する

Slide 45

Slide 45 text

Ingressの監視: CronJobの動作 Ingress HeatStack Resource AKE Prometheus Secret Services Cronjob 3. PrometheusのSecretを取得する 4. Heatstack リソースごとに static_configs の job を追加して、 Secret の data を更新する

Slide 46

Slide 46 text

Ingressの監視: CronJobの動作 Ingress HeatStack Resource AKE Prometheus Secret Services Cronjob 5. Service を列挙して label から AKE Prometheus を特定する

Slide 47

Slide 47 text

Ingressの監視: CronJobの動作 Ingress HeatStack Resource AKE Prometheus Secret Services Cronjob 6. Service から Endpoint を指定し、 Prometheus のリロードAPIを叩く POST or PUT https://ake-prometheus.kube-system.svc.cluster.local:9090/-/reload

Slide 48

Slide 48 text

✱ クラスタ毎の Prometheus と VictoriaMetrics によって横断監視を実現 ✱ Kubernetesクラスタとは独立したロードバランサの監視は CronJob によって実現 横断監視基盤の構成

Slide 49

Slide 49 text

余談: ingress-nginxに簡単なパッチを当てた話

Slide 50

Slide 50 text

✱ NginxのプロセスはLuaスクリプトでリクエストのメトリクスをバッファリングしている ✱ その件数が1秒間最大1万件でハードコーディングされていた ✱ プロダクトではその数倍のリクエスト数が想定されていたのでオプション化 ✱ Luaスクリプト書いたり、そのテストも書いたり ✱ 0.34.0以上で使えるようになってる 余談: ingress-nginxに簡単なパッチを当てた話

Slide 51

Slide 51 text

KuberhealthyというOSSにもパッチを当てて Kubernetes 1.16以上で動くようにしたのですが、 まだマージされていないので別の機会に・・・ 余談: kuberhealthy

Slide 52

Slide 52 text

AGENDA 1. 自己紹介 ✔ 2. AKEの紹介と背景 ✔ 3. VictoriaMetricsとPrometheus ✔ 4. 監視基盤のアーキテクチャ ✔ 5. 監視基盤の運用

Slide 53

Slide 53 text

通知システムの構成 AKE Developer

Slide 54

Slide 54 text

Grafana Dashboard

Slide 55

Slide 55 text

Grafana Dashboard

Slide 56

Slide 56 text

4. 横断監視基盤の構成: Kubernetes の監視 node exporter kube-state-metrics kubelet Master Components k8s Node Resources のメトリクス CPU, Memory, I/O, etc... k8s Resources のメトリクス deploy, sts, ds, pod, pv, etc… k8s Components のメトリクス kube-apiserver, etcd, kubelet, coredns, etc,...

Slide 57

Slide 57 text

4. 横断監視基盤の構成: Ingressの監視 systemd exporter bird exporter node exporter nginx metrics Calicoやingress-nginxが Dockerで正常に動いているか BGPのPeer Linkが 正常に貼られているか Ingress VMのCPUや メモリのメトリクス Ingress-nginxが持つ リクエストやコネクション のメトリクス

Slide 58

Slide 58 text

✱ Critical ✱ 即時対応 ✱ 業務時間外は PagerDuty による輪番制 ✱ Warning ✱ 日中帯対応（休日含む） ✱ 業務時間外は PagerDuty による輪番制 ✱ Informational ✱ 翌営業日対応 横断監視基盤の構成: アラート優先度

Slide 59

Slide 59 text

✱ 1ヶ月あたり130GB ✱ クラスタ数 30+ ✱ ノード数 200+ ✱ ポッド数 3500+ ✱ 必要ないメトリクスは可能な限り絞る ✱ exporter の起動オプションで指定可能 ✱ --no-collector.hoge VictoriaMetrics のメトリクスサイズ

Slide 60

Slide 60 text

✱ Datadog を使用 ✱ サードパーティの監視 ✱ Dashboard とアラート設定 VictoriaMetrics を監視する

Slide 61

Slide 61 text

✱ アラートしきい値 ✱ 「実は異常が起こっていたが気づかなかった」は避けたい ✱ あとから調整していけばいいよね・・・ ✱ 結果夜中に何度もたたきおこされる ✱ 監視が必要ないクラスタ ✱ むしろアラートがうるさい ✱ 検証クラスタを立てるたびに silence を入れるのは面倒 ✱ アラート発砲させないオプションは必須 (隠し flag など) 監視基盤構築の苦労話 1, 2

Slide 62

Slide 62 text

✱ 毎朝9時に大量のアラート ✱ 急激に VictoriaMetrics の負荷が上がってメトリクスが途切れる ✱ 多くのクラスタの Prometheus と疎通がとれず ✱ よくよく調べると vmstorage がメモリリークしていた... 監視基盤構築の苦労話 3

Slide 63

Slide 63 text

✱ クラスタのアップデートで突然 Grafana のダッシュボードが消える ✱ AlertManager の silence も消えてアラートが鳴りまくる ✱ Grafana と AlertManager のストレージが pv になっておらず pod のリスタートが走りデータが消失した ✱ 意図せず Grafana のバージョンが 7系にアップデートされる 監視基盤構築の苦労話 4

Slide 64

Slide 64 text

本日のまとめ

Slide 65

Slide 65 text

✱ Datadog にたよらず独自に横断監視を VictoriaMetrics と Prometheus で実現 することでプロダクトの増加による追加コストを抑えることができる ✱ VictoriaMetrics は Prometheus や InfluxDB より高圧縮かつ高速な読み書きの ストレージを実現 ✱ シンプルなアーキテクチャによって高可用性、耐障害性を持つ ✱ クラスタ外のエンドポイントの監視は CronJob でディスカバリする処理を動かす ✱ KaaS特有の監視項目を含めながら運用されている まとめ

Slide 66

Slide 66 text

Thank you for listening !