モニタリングプラットフォーム開発の裏側
Jan 27th, 2022
藤井 大助
Cloud Platform Dept.
Rakuten Group, Inc.

2
目次
1. はじめに
1. 自己紹介
2. グループとミッション
3. チーム編成
4. モニタリングプラットフォーム
2. メイントピック
1. Cortex導入の道のり
2. Prometheus OOMとの戦い

3
自己紹介
プロダクトオーナ：Mon-aaS (Monitoring as a Service)
#2020年 楽天に転職
#サーバ管理→アプリ開発→ITアーキテクト→プロジェクト／プロダクトマネージャ
#バスケ大好き
#楽天に応募するまでTOEIC受けたことすら無かったw

4
モニタリングプラットフォームグループ
楽天グループ全体のモニタリングソリューションの統合と効率化
• モニタリングプラットフォームの開発運用
• 可観測性のためのデータ統合と効果的活用
• 既存モニタリングツールの統合
グループとミッション

5
SCRUM
チーム編成
PO/SM
私
DEV TEAM
４人
• エンジニアが少なくて、困ってますw
• モニタリングの重要度は増す一方、それに特化したスキルを持っている人は意外に少ない
• モニタリングをプラットフォーム/サービスとして捉え、一緒に開発してくれる人、募集中！
開発プロセスはSCRUM/KANBAN 主なエンジニア役割
・プラットフォーム設計・開発
・ユーザインタフェース設計・開発（主にAPI）
・ユーザサポート
コミュニケーション
• エンジニアは全員外国人
• 英語でコミュニケーション
• 日本語できる人同士なら日本語

6
モニタリングプラットフォームについて
現在、我々が開発しているモニタリングプラットフォームを、
Monitroing as a Service = Mon-aaS（モンアース）
と呼ぶ。モンアース

7
• Mon-aaSは、現在、PrometheusベースのMetrics, ElasticsearchベースのLogs, 今後、Tracesもサポート予定
• 守備範囲としては、こんな感じ
可観測性の３本柱 - The three pillars of Observability -
Metrics Logs
Traces
Mon-aaS

8
規模感
BM数
30,000+
Container数
40,000+
VIP数
8,000+
• Mon-aaSのモニタリング対象は、現時点で次のような規模感
VM数
30,000+
*bare-metal servers *virtual machine servers

9
アーキテクチャ

10
モニタリングプラットフォーム開発の実録を苦労話を交えて２つ紹介したい。
• Cortex導入の道のり
• Prometheus OOMとの戦い
今日、お話したいこと

11
Cortex導入の道のり
Thanos → Cortex
The winding road from High Mickley to Hedley on the Hill
cc-by-sa/2.0 - © Oliver Dixon - geograph.org.uk/p/6092746

12
Long-term Storageとは、Prometheusが収集したmetricsを長期保存するためのストレージ。
• Prometheusは、metricsをメモリ/ディスクに保持するが永続化の目的ではない。
• metricsを永続化するためには、長期ストレージをPrometheusとは別に用意しないといけない。
長期ストレージとは
k8s
exporter
e.g., kube-state-metrics 長期ストレージ
scrape store
Grafana
query

13
Thanosは、metricsの長期ストレージの一つ。約2年前、Mon-aaSはThanosを使ってスタートした。
• 保存先としてS3オブジェクトストレージを利用する
• アーキテクチャが比較的シンプル
• マルチテナンシーはサポートしていない
Thanos
k8s
exporter
e.g., kube-state-metrics 長期ストレージ
scrape store
Grafana
query

14
Thanosを運用する中で、次のような課題があった。
• テナント数分のThanosの管理が必要。
• テナント全体で見たときに、リソースの利用効率が悪い。
• スケーラビリティに難あり、スケールアウトができない。
Thanosの課題
Tenant A
Tenant B
Tenant C
Tenant D
……
Grafana
query

15
Cortexは、metricsの長期ストレージの一つ。Thanosよりも後発のオープンソースプロダクト
Cortex
k8s
exporter
e.g., kube-state-metrics
長期ストレージ
scrape store
Grafana
query
Thanos: Open source, highly available Prometheus setup with long term storage capabilities.
Cortex: Horizontally scalable, highly available, multi-tenant, long term storage for Prometheus.
これ全部、解決するんじゃね？
Thanosを運用する中で、次のような課題があった。
• テナント数分のThanosの管理が必要。
• テナント全体で見たときに、リソースの利用効率が悪い。
• スケーラビリティに難あり、スケールアウトができない。

16
Cortexは、マルチテナンシーな設計なのでコンピュータリソースを共有できる。
• 管理対象が一つなので、維持管理コストは一定（テナント数に比例しない）
• マルチテナンシーなシェアードアーキテクチャなので、リソース効率が良い
• スケーラビリティがあり、各コンポーネントでスケールアウト可能
Thanos → Cortex
Tenant A
Tenant B
Tenant C
Tenant D
……
Tenant A
Tenant B
Tenant C
Tenant D
……
Shared

17
余談
Why Mon-aaS 2.0 will adopt Cortex
Point of View Cortex Thanos
architecture complex simple
multi-tenant support native support new cluster for each tenant
architecuture with multi-tenant complex x 1 simple x N
management only need to manage single cluster need to manage all clusters
scale out
easy to scale-out by adding nodes or
replicas
can't simply scale-out compactor,
ruler and receiver
query reliability
only need to access ingesters and
NoSQL
need to access all receivers and store
gateway
query speed fast (have cache) slow
retention policy global only per tenant
storage efficiency store single data store N replicas
• Query-Speed
• Scalability
• Efficiency (results in reducing cost and ease-to-manage)
Deciding factors for that are:
下記は、当時（約2年前）のCortexとThanosを比較したもの。現在、CortexとThanosは双方の良さを補完しあっ
ており、最終的には一つになりそうな予感です。
例えば：
• クエリキャッシュ
• Cortex → Thanos
• リテンション
• Thanos → Cortex

18
Prometheus OOMとの戦い
Prometheus sharding
出典：https://pixabay.com/illustrations/abstract-dark-tech-chaos-shards-539960/

19
スクレイプするメトリクス数が増えれば増えるほど、使用メモリが増える。そして、最終的にOOMになる。
• Exporterが大量のメトリクスをExposeする。例）Kubernetes clusterに大量のPodが動いているなど
• スクレイプ対象のExporter数が多い。例）監視対象のサーバ数が多いなど
ちなみに、長期ストレージに対してクエリする設計だが、もし、Prometheusに直接クエリする設計なら、
もっとメモリを消費するはず。
Prometheus OOM
k8s
exporter
e.g., kube-state-metrics
長期ストレージ
scrape
store
Grafana
query
exporter
e.g., kube-state-metrics
scrape
store

20
スケールアップの限界
現在、Prometheusの使用メモリが増えるとスケールアップすることで対応している。k8s上で運用しているの
でスケールアップ自体は簡単だが、最終的にはノードの物理メモリのリミットにヒットする。
なので、スケールアウトする方法を考えないといけない。その方法として、
• 大きなPrometheusを小さい破片（Shard）に分割する（一般的にShardingと呼ぶ）
使用メモリ
Shard数
1
使用メモリ
Shard数
1 2 3 4 5
• 使用メモリは一定
• Shard数が変動
• Shard数が１つ
• 使用メモリが変動
スケールアップ スケールアウト

21
Prometheus Sharding
Target Exporter
Target Exporter
Target Exporter
Target Exporter
Prometheus shard #0
Prometheus shard #1
Target Exporter
Prometheus shard #0
Prometheus shard #1
Prometheusをスケールアウトさせる場合、対象となるExporterの数にも注意が必要。例えば、でかいExporter
が一つある場合は、いくらPrometheusをスケールアウトさせても意味がない。その場合は、そのExporterも
Shardingにより分割させる必要がある。
Prometheusを複数のShardに分割する場合、サービスディスカバリを使って自動的にTargetとなるExporterを見
つける必要がある。これがないと、単に手作業で分割しただけになる（これもShardingではあるが・・）
ちなみに、Prometheus自身はShardingをサポートしていないので、独自に実装するなどしないといけない。

22
Prometheus v2.32からAgent Modeが利用できるようになった。この場合、Prometheusは、
• メトリクスを長期ストレージに送信するだけのエージェントとして動作
• メトリクスを保持する必要がないため、メモリをほとんど必要としない（はず。まだ未検証）
余談：Prometheus Agent Mode
k8s
exporter
e.g., kube-state-metrics
長期ストレージ
scrape
store
Grafana
query
exporter
e.g., kube-state-metrics
scrape
store
Agent Modeにより、使用メモリが小さくなれば、
OOMの問題も起こらないはず

23
余談：Promxy
アラート設定に関して、Prometheusにアラートルールを設定してAlertmanager経由でアラート送信するのが一
番ベーシックな使い方だが、既に長期ストレージなどにメトリクスが既にある場合、
• Promxyを使えば、Prometheusを介さずにアラート設定できる。つまり、Prometheusのものが不要になる。
その他にも、用途は幅広い。
• 数週間分のメトリクスを見て、アラート設定したい
• 複数データソースからクエリしたメトリクスをもとに、アラート設定したい
k8s
exporter
e.g., kube-state-metrics 長期ストレージ
scrape store
Grafana
query
Alertmanager
query
Promxy

24
さまざまな規模のユーザが存在し、使い方も様々、その中でどうやってプラットフォームとして
広く構え、制約を設けるかということが難しい部分であり、また、楽しい部分でもある。
最後に、私たちの経験から簡単にアドバイスできることをまとめますw
• Cortex導入の道のり
• シンプルに小さく使うならThanos
• 複雑に大きく使うならCortex
• Prometheus OOMとの戦い
• Prometheus OOMは一般的な問題（誰もが一度は通る道）
• ターゲット（Exporter）が多いことによるOOMなら、PrometheusShardingが有効
• ターゲット（Exporter）あたりのメトリクスが多いことによるOOMなら、Exporterの
Shardingを最初に考えるが吉
最後に