Micrometer/Prometheusによる大規模システムモニタリング #jsug #sf_26

Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved.
2018年10月31日
ヤフー株式会社池田誠
Micrometer/Prometheusによる
大規模システムモニタリング
〜ヤフーインターネット広告システムでの導入事例〜
Spring Fest 2018

自己紹介
2
池田誠
ヤフー株式会社
所属：インターネット広告の開発部
仕事：
インターネット広告システムの共通機能開発
新技術の検証・導入サポート
言語：C, C++, Java, Kotlin, Python, Go(勉強中)
趣味：ゲーム, スキー

はじめに
3
ヤフーのインターネット広告システムでは、Micrometerと
Prometheusを採用したモニタリングシステムを構築し、
3000＋のSpring Bootアプリケーションインスタンスの
パフォーマンスモニタリングをしています。
本日は、MicrometerとPrometheusの簡単な紹介、大規模
システムでの導入事例として、導入時に遭遇したトラブル
や直面している課題をお話しさせていただきます。

システムモニタリングの重要性
4
システムモニタリングを行わないと
どんなトラブル起こりますか？

5
• パフォーマンス問題に気付かない
• エラーの増加に気付かない
• 障害を解析するための情報集めに苦労する
など
サービスを安定して稼働/運用することができない

6
分散システムでは
多数あるアプリケーション内から
異常アプリケーションを早く特定するため
モニタリングがさらに重要

アジェンダ
7
• ヤフーのインターネット広告システム紹介
• 導入背景
• Micrometer/Prometheus説明
• Micrometer/Prometheus採用理由
• モニタリングシステム構成
• 苦労したエピソード・トラブル
• まとめ

アジェンダ
8
• 導入背景
• まとめ

ヤフーのインターネット広告システム紹介
システム概要
9
FE
広告主
広告
配信
オーディエンス
• 複数アプリケーションが協調動作
• 全体で数千インスタンスが稼働
広告
出稿
広告管理システム広告配信システム

システム概要
10
モニタリングシステムは広告管理システムに導入
FE
広告管理システム広告配信システム
広告主
広告
配信
オーディエンス
広告
出稿

アプリケーションの動作プラットフォーム
11
• IaaS (OpenStack)
• 現在の主力プラットフォーム
• PaaS, CaaSに移行中
• PaaS (Pivotal Cloud Foundry)
• CaaS (Kubernetes)

アプリケーションの種類
12
フロントエンドサーバー APIサーバー
(REST or SOAP)
ストリーム処理
publisher
ストリーム処理
subscriber
メッセージブローカー
バッチサーバー
各アプリケーションが協調動作

アジェンダ
13
• 導入背景
• まとめ

導入背景
14
• 既存の独自モニタリングシステム刷新
• SREを推進するための土台作り/道具整備
※既存の独自モニタリングシステムは広告管理システム独自のシステム

導入背景
独自モニタリングシステム刷新
15
• 独自モニタリングシステムの課題
• 属人化
• モニタリング項目追加に開発が必要
• カバー範囲が拡大し範疇外の機能を搭載

導入背景
16
ビジネス
インテリジェンス
システム性能可視化
システム死活監視
(アラート)
独自の
モニタリングシステム
対象領域刷新前の利用ツール
ヤフー全社共通の
死活監視サービス
利用者/対象者
システム運用
(ジョブ実行・ログ確認)
業務運用
(ビジネスサイドの担当者
へアラートなど)
ビジネスサイドの
企画や業務運用者
開発者

導入背景
17
ビジネス
インテリジェンス
システム性能可視化
システム死活監視
(アラート)
独自の
モニタリングシステム
対象領域刷新前の利用ツール
専用ツール利用
新モニタリングシステム
刷新後の利用ツール
移行
利用者/対象者
システム運用
(ジョブ実行・ログ確認)
業務運用
(ビジネスサイドの担当者
へアラートなど)
移行
ジョブコントローラー/
ワークフローエンジン利用
(NiFiやAirflowなど)
各アプリケーションごと実施
移行
移行
継続
ビジネスサイドの
企画や業務運用者
開発者

導入背景
Site Reliability Engineering (SRE)
18
• アプリケーション信頼性とユーザー体験を向上させる活動
• モニタリングと改善のサイクル
• レイテンシ、エラー率、トラフィック、リソース(CPU、メモリー、N/Wトラフィック…)
エンジニアアプリケーションモニタリング
改善

導入背景
Site Reliability Engineering (SRE)
19
• SREを推進するためのモニタリング
• 性能低下の検知
• エラー増加傾向の検知
• アプリケーションアップデート前後の性能比較
• 需要予測、キャパシティプランニング

アジェンダ
20
• 導入背景
• まとめ

Prometheus
21
• 時系列DB + モニタリングシステム
• pull方式でメトリクス収集
• 監視対象はメトリクスが記載されたテキストを返却
定期的にPull (HTTP)
Prometheus 監視対象
# HELP node_cpu Seconds the cpus spent in each mode.
# TYPE node_cpu counter
node_cpu{cpu="cpu0",mode="iowait"} 2.94
node_cpu{cpu="cpu0",mode="system"} 937.24
node_cpu{cpu="cpu0",mode="user"} 2583.65
# …
※時系列DBは時系列データの格納・検索に特化したDB

Prometheus
データモデル
node_cpu{cpu="cpu0",mode="guest"} 0
# …
22

Prometheus
データモデル
23
node_cpu{cpu="cpu0",mode="guest"} 0
# …
メトリクス名データサンプルラベル名、ラベル値

Prometheus
検索/可視化
24
• 収集したメトリクスはPromQL(独自クエリー)で検索/可視化
※CPU使用率を可視化した例

Prometheus
UI
25
• UIとしてGrafanaと連携
• ダッシュボードを作成・保存可能
Grafana Prometheusエンジニア

Prometheus
注意点
27
• Prometheus単独では冗長化できない
• 内蔵の時系列DBが冗長化できない
• 公式ドキュメントでの冗長化手段
• 同じ設定のPrometheusをもう１台設置
• 時系列DBを他製品に切り替える
※冗長化に関する公式ドキュメント
<https://prometheus.io/docs/introduction/faq/#can-prometheus-be-made-highly-available>

Micrometer
28
• メトリクス収集ライブラリ
• Dependency追加＆多少の設定追加で動作
• 様々なモニタリングシステムと連携可能(※)
• Prometheus, Netflix Atlas, CloudWatch, Datadog,
Graphite, Ganglia, JMX, Influx/Telegraf, New Relic,
StatsD, SignalFx, and Wavefront
※micrometer公式サイトより引用 <https://micrometer.io/>

Micrometer
利用方法(SpringBoot1.5系)
29
Maven or Gradleの設定でdependency追加 application.yml or propertiesに設定追加
※Prometheusと連携する場合の例
これだけでメトリクス収集が開始

Micrometer
利用方法(SpringBoot2系)
30
※Prometheusと連携する場合の例
これだけでメトリクス収集が開始
Maven or Gradleの設定でdependency追加 application.yml or propertiesに設定追加

Micrometer
収集メトリクス
31
• デフォルトで収集されるメトリクス(一部)
• Web Controller(実行回数/レスポンスタイム)
• RestTemplate(実行回数/レスポンスタイム)
• Spring Cloud Streamのpub/subカウント
• JVM(各種メモリ使用状況、スレッド数、GC)
• OSリソース(CPU)
※1 上記はソースコード修正なしで収集
※2 その他の収集可能なメトリクスは以下を参照
<https://spring.io/blog/2018/03/16/micrometer-spring-boot-2-s-new-application-metrics-collector>

Micrometer
カスタムメトリクス
32
• 独自メトリクスを簡単に作成可能
private final MeterRegistry registry;
public SampleServiceImpl(MeterRegistry registry) {
this.registry = registry;
}
// カスタムメトリクス( jobTypeごとに集計)
public void execute(Job job) {
// sample_job_total{job_type="JOB1",} 3.0
// sample_job_total{job_type="JOB2",} 5.0
Counter.builder("sample_job").tags("job_type", job.getJobType().toString())
.register(registry).increment();
}

アジェンダ
33
• 導入背景
• まとめ

モニタリングシステムへの要件
34
• 複数のプラットフォームで導入できること
• IaaS, PaaS, CaaS
• 監視対象アプリケーションへの導入が容易であること
• 可能であればコード修正なしで導入
• 例えばDependency or アノテーションを追加するだけ
• 閾値超えアラートを利用できること
• グラフで可視化できること(当たり前)
• 任意の監視項目・グラフを自由に追加できること

Micrometer
採用の決め手
35
• アプリケーション内部でしか収集できないメトリクスを収集
• コード修正なしで基本的なメトリクスを自動で収集
• 簡単にカスタマイズできて任意のメトリクスを追加可能
• 様々なモニタリングシステムと連携
• Prometheus, Atlas, CloudWatch, Influx, New Relic …
• Spring Boot公式サポートなので安心

Micrometer
要件に対する可否
36
○ 複数のプラットフォームで導入できること
• Javaなのでプラットフォームに左右されない
○ 監視対象アプリケーションへの導入が容易であること
• コード修正不要
ー閾値超えアラートを利用できること
• Micrometerはメトリクス収集が役割なので検討範囲外
ーグラフで可視化できること(当たり前)
• Micrometerはメトリクス収集が役割なので検討範囲外
○ 任意の監視項目・グラフを自由に追加できること
• カスタムメトリクスで任意項目を追加

Prometheus
採用の決め手
37
• 時系列DBなのでグラフ描画用途に最適
• Pull方式なのでエージェントレス
• 大規模システム利用可能
• 1万ノード監視の実績
• SRE本で紹介
• コミュニティーが活発

Prometheus
要件に対する可否
38
△ 複数のプラットフォームで導入できること
• pull方式のためPaaS監視で課題あり(※)
○ 監視対象アプリケーションへの導入が容易であること
• Micrometerとの連携の場合、コード修正不要
○ 閾値超えアラートを利用できること
• アラート機能あり
○ グラフで可視化できること(当たり前)
• Grafanaとの連携でダッシュボードを利用
○ 任意の監視項目・グラフを自由に追加できること
• Grafanaとの連携で任意グラフを追加
※PaaSにデプロイされたインスタンス監視は一手間加えており詳細を後述

アジェンダ
39
• 導入背景
• まとめ

モニタリングシステム詳細
構成
40
エンジニア
Grafana Prometheus
Alertmanager
アラート
アラート
(Eメール、チャットツール)
参照
データ取得
各アプリケーションのインスタンス
pull
※1 PaaSにデプロイされたインスタンス監視は一手間加えており詳細を後述
※2 CaaSは対応作業中

構成
41
エンジニア
Grafana Prometheus
Alertmanager
アラート
アラート
参照
データ取得
pull

構成
42
エンジニア
Grafana Prometheus
Alertmanager
アラート
アラート
参照
データ取得
pull

構成
43
エンジニア
Grafana Prometheus
Alertmanager
アラート
アラート
参照
データ取得
pull

数千インスタンス監視の運用課題
44
• 数千インスタンスをPrometheusに設定する運用コストが高
• インスタンスの増減のたびに設定変更する運用が大変
# Prometheusの設定ファイル
- targets:
- app10.localdomain:8080
# …
# 以下省略
# 数千台を並べる

サービスディスカバリ(実装中)
45
• サービスディスカバリ (Netflix-Eureka) を導入
• Prometheusの監視対象を変更する運用コストの削減
Prometheus
アプリケーションのインスタンス
Eurekaサーバー
ホスト登録 (インスタンス起動時)
pull
Eureka連携ツール
設定ファイル登録
(ホスト一覧)
Spring Bootの
eureka-client-
starterを利用

特徴
46
• Grafanaに共通ダッシュボードを用意
• 監視対象の追加後すぐに基本的なグラフは参照可能
• 利用者は権限の制約なしで自由に利用可能
• 利用者は任意のメトリクス/グラフを自由に追加可能
• 利用者は全アプリのグラフを参照可能

実際の動作画面紹介

モニタリングシステム構成
稼働状況
48
• 監視インスタンス数
• 3400インスタンス
監視対象を約500台追加したこと
でFDのMaxOpenFilesを超過して
しまい数時間、データ収集失敗

稼働状況
49
• ディスク使用量
• 1週間で約15GB増加

稼働状況
50
• 1回(※)で収集されるメトリクス(サンプル)数
• 120万＋
※１分に1回収集

稼働状況
51
• Prometheusサーバースペック
• VM (IaaS)
• CPU: 2.10GHz 8core
• Memory: 16GB
• Storage: 500GB (OpenStack Cinder Volume)
• 必要に応じて増量

アジェンダ
52
• 導入背景
• まとめ

事例1: PaaS上インスタンス監視
課題
53
• インスタンス狙い撃ちでメトリクス収集できない
• PaaSにデプロイしたアプリへの接続はアプリごと割り当てたFQDNで接続
• リクエストはルーターによって毎回バランス
• 個別のインスタンスにはFQDNが割り当て不可能
PaaSのルーター
Prometheus
PaaS
メトリクス収集
FQDN (app1.localdomain)
リクエストごとに異なる
インスタンスにバランス

Pushgateway方式
54
• Pushgatewayを使いPaaS内部からpush
PaaSのルーター
Prometheus
PaaS
Pushgateway
push
メトリクス収集
push
Micrometerは設定の
追加だけで定期的にPush
PushgatewayはPrometheusのサブプロダクトで一時的にメトリクスを保存するサーバー

Pushgateway導入後の構成
55
エンジニア
Grafana Prometheus
Alertmanager
アラート
アラート
参照
データ取得
pull
IaaS
PaaS
push
Pushgateway

補足
56
Pushgatewayの多用は
オススメされていないので、
引き続き、
別の方式を検討中

事例2: メトリクスが増えすぎGC連発
発生トラブル
57
• Micrometer導入後リリースして数時間するとGC連発
• APIのレイテンシが超悪化
• サービス継続不可

発生条件
58
• JAX-RSを使っている
• Micrometerがv1.0.4以下である
• Spring Bootがv2.0.2以下である
• Pathパラメーターを利用しているAPIを作成している
// APIの例
@GET
@Path("/info/{userId} ")
String userInfo(@PathParam("userId") String userId) {
// ...
}
※トラブル当時、Micrometer v1.0.3を利用

原因
59
• Pathパラメーターを利用すると
メトリクス(ラベル)が爆増しメモリ圧迫(※)
http_server_requests_seconds_count{exception="None",method="GET",status="200",uri="/info/1",} 1.0
http_server_requests_seconds_sum{exception="None",method="GET",status="200",uri="/info/1",} 0.004786132
http_server_requests_seconds_max{exception="None",method="GET",status="200",uri="/info/1",} 0.004786132
# ・・・
# 爆増
※Micrometerは収集したメトリクスをオンメモリで保存

解決方法
60
• Micrometerと連携(に介入)する
Apache CXFのインターセプターを自作
• Pathのパターンごとにメトリクス収集
http_server_requests_seconds_count{exception="None",method="GET",status="200",uri="/info/{userId}",} 1.0
http_server_requests_seconds_sum{exception="None",method="GET",status="200",uri="/info/{userId}",} 0.004786132
http_server_requests_seconds_max{exception="None",method="GET",status="200",uri="/info/{userId}",} 0.004786132
※JAX-RS実装はApache CXFを利用

補足事項
61
• Spring Web MVCを使っている場合は
手を加えなくてもPathパターンごとにメトリクスを収集
• どの程度までメトリクス数(ラベル)を増やせるか検証
• 3〜5万メトリクス(ラベル)が限界の目安
• メモリ枯渇以前にpullした時のレスポンスが数秒になる
# @RequestMapping("/info/{userId}")
http_server_requests_seconds_count{…., uri="/info/{userId}",}

補足事項
62
• Micrometer1.0.5からはJAX-RSの場合、
uriが全て”UNKNOWN”にされるのでメモリ枯渇はおきない
• これも課題になったが自作インターセプターの利用で解決
http_server_requests_seconds_count{…, uri="UNKNOWN",} 1.0
http_server_requests_seconds_sum{…, uri="UNKNOWN",} 0.004786132
http_server_requests_seconds_max{…, uri="UNKNOWN",} 0.004786132

補足事項
63
カスタムメトリクス作成時
メトリクス数が爆増しないように
ラベル付けにも注意

事例3: 現在対応中の性能問題
問題/発生条件
64
Prometheusで性能問題発生
• 問題
• 複雑なクエリーのレスポンスが悪化 (数分)
• 複雑なクエリーを並列実行するとOOMキラー発動
• ボトルネックは、CPU (1coreが100%張りつき)、メモリ
• 発生条件
• 1時系列あたりデータ数が数万になるメトリクス対して集計
• 集計コストが高いクエリーを実行
• 集計期間が長い (数週間分)
※サーバースペック：2.10GHz 8core、16GB メモリー

高コストクエリー
65
• 1時系列あたりの集計対象メトリクス(データサンプル)数=約40000
• アプリは約1000インスタンスで構成
• アプリ全体の５分ごとの平均レスポンスタイム(累計レスポンスタイム÷実行回数)を集計
• ステータスコード、URI、methodごとに集計する
sum(increase(http_server_requests_seconds_sum{job="app1"}[5m])) by (status,uri,method)
/
sum(increase( http_server_requests_seconds_count{job="app1"}[5m])) by (status,uri,method)
ステータスコード、URI、methodごとの、5分間の累計レスポンスタイム
ステータスコード、URI、methodごとの、5分間の累計実行回数

解決方法(検証中)
66
• Prometheusの１次集計機能(RecordingRule)を利用
groups:
- name: example
interval: 60s # 1次集計間隔
rules:
# 5分間あたりのアプリ全体の累計レスポンスタイムをstatus、uri、methodごとに一次集計する
- record: job:http_server_requests_seconds_sum:app1:increase5m:sum
expr: sum(increase(http_server_requests_seconds_sum{job="app1"}[5m])) by (status,uri,method)
# 5分間あたりのアプリ全体の累計実行回数をstatus、uri、methodごとに一次集計する
- record: job:http_server_requests_seconds_count:app1:increase5m:sum
expr: sum(increase(http_server_requests_seconds_count{job="app1"}[5m])) by (status,uri,method)

改善効果(検証結果)
67
• 改善効果
約45秒
約0.4秒

アジェンダ
68
• 導入背景
• まとめ

良かった点
69
• 監視対象側の導入は簡単・低コスト
• 手順はDependencyの追加程度なのであっという間に利用アプリが増えた
• カスタマイズ性抜群 = 属人化が解消
• アプリ開発者がカスタムメトリクスを使い必要なメトリクスを追加してくれた
• アプリ開発者が見たいグラフを自由に追加してくれた

苦労した点
70
• PromQL習得に学習コストがかかる
• ナレッジ/ドキュメント不足で調査に苦労した
• 例えばPushgatewayにpushする設定方法はソース解析

本日持ち帰っていただきたいこと
71
Micrometer/Prometheusは
•監視対象側の導入は簡単・低コスト
•カスタマイズ性が抜群
•大規模システムにおいても難なく利用可能(※)
※大量メトリクスに対して複雑な集計をする場合は、1次集計する工夫が必要

ご静聴ありがとうございました

Micrometer/Prometheusによる大規模システムモニタリング #jsug #sf_26

More Related Content

What's hot

Similar to Micrometer/Prometheusによる大規模システムモニタリング #jsug #sf_26

More from Yahoo!デベロッパーネットワーク

Micrometer/Prometheusによる大規模システムモニタリング #jsug #sf_26