Rakuten Developer Meetup vol.03 大規模クラウドの仕組みと秘密 https://rakuten.connpass.com/event/254762/

1. 大規模なリアルタイム監視の導入と展開
Sep. 29th , 2022
Wei He
User Support Section
Cloud Platform Enablement Department
Rakuten Group, Inc.

2. 2
About Me
2016年 新卒入社 インフラエンジニア
サーバーの構築、仕様の標準化や自動化に取り組んでいる
TAMとしては、楽天市場、楽天ブックス、楽天Car等を担当
好きな言語はGo
趣味は登山と写真撮影
Wei He ( ギ・ヘ )
ユーザーサポート課
テクニカルアカウントマネジメントグループ

3. 3
TAMの仕事内容
インフラを利用する上でのPoint of Contact
サービス開発者
こういうことを実現したい
この機能をこう使いましょう
こういうアーキテクチャにしましょう
必要に応じてエスカレーション
監視
課題発見
対策
試験 地道な改善を繰り返す
サービスのシステム改善
TAM インフラ開発者
ときにはツールやシステムも作成も行う

4. 4
CONTENTS
1. 新しいメトリクス監視システムの実現
2. 社内デファクトスタンダードへの展開

5. 5
CONTENTS
1. 新しいメトリクス監視システムの実現
2. 社内デファクトスタンダードへの展開

6. 6
従来のメトリクス監視システムと課題
従来のメトリクス監視システム
• Ruby による内製
• SNMP を通してメトリクスを収集
• RRD Tool で NAS にメトリクスを保存
• メトリクス保存期間は２年
課 題
• メトリクス収集が Ruby の内製プログラムのため、
拡張が困難で、監視対象がOSと一部のミドルウェア
に限定されている
• メトリクスの間隔が5分に1回で、リアルタイムの
データがとれない
• 監視システムの開発後に利用しはじめた
Kubernetesに非対応
• 監視情報に欠損が出てしまうことがある
監視システム
可視化層
データ層
収集層
監視対象

7. 7
• CNCF (Cloud Native Computing Foundation )のCortex を採用
• マルチテナント対応
• 長期間保存
• クラスタリングによる高可用性と水平拡張性
新しいメトリクス監視システムのアーキテクチャ
• サーバーやKubernetesのpodに各種の
Prometheus Exporterを起動
• メトリクスを公開
• Prometheus を採用
• サーバーやKubernetesのメトリクスを収集
• TSDB(Time-series Database)に書き込み
- Remote writeを利用
• Grafanaを採用
• TSDB (Time-series Database)からメトリクスを取得
従来のシステムの課題を解決できるPrometheusを中心に設計
監視システム
可視化層
データ層
収集層
監視対象

8. 8
新しいメトリクス監視システムでの工夫
1. 各サーバーに適切なexporterを
簡単にインストールさせる
2. 障害耐性を高める

9. 9
1. 各サーバーに適切なexporterを簡単にインストールさせる
背 景 既存も含む大量のサーバーに適切なexporterを定めインストールするのは不可能
• Node exporterなら問答無用にインストールできるが、OS領域でしか使えない
• 各種のミドルウェアのexporterのインストールに毎回人の判断が必要
どの環境でも問答無用にインストールでき、
90%以上のユースケースを満たすexporterを導入し、管理コストを削減する
https://www.netdata.cloud/
• OSSの分散リアルタイム監視システムNETDATAを導入
• OS及び各種のミドルウェアを自動で監視
- ミドルウェアはすべて自動検知
- サーバー別の設定は不要
- 1時間内の1秒単位のメトリクスを収集
• Prometheusと連携可能
• 導入が簡単
目 的
手 段

10. 10
Netdataのミドルウェアの自動検知
jobs:
- name: local
url: http://localhost/server-status
- name: local
url: http://localhost/nginx-status
自動検知の仕組み
• 可能性のあるパターンを全て設定ファイルに記述
• 一般的なパターンは事前定義済み
• 一致したパターンのみメトリクスを収集
パターン設定の例：Nginx の status 監視
• いずれかのURLがnginxのstatusを返せば、
nginxを検出し監視
• 全部返せない場合はnginxが動作していないとみなす
⇒ 標準が異なるサーバーも同じ設定で監視可能

11. 11
2. 障害耐性を高める
監視システムが依存している他のシステムが落ちると監視システムも落ちる
背 景
依存している他のシステムが一部落ちた時でも、最低限の監視を可能にする
手 段 Prometheus+Thanosを採用
目 的
https://prometheus.io/ https://thanos.io/

12. 12
障害耐性の実現方法 (1/2)
• マルチテナント対応
• 大量のデータの保存
• 長期間保存
• Cache によるクエリの高速化
• クラスタリングによる
高可用性と水平拡張性を実現
• システムが複雑
1. ) コンポーネントが多数
2. ) 外部依存が多数
- Kubernetes, object storage, load balancer, etc.
監視システムは Cortex が落ちても最低限の動作の保証が必要
Cortexの利点 Cortexの課題
通常利用時
Cortexにアクセス
Server
Server

13. 13
通常利用時
Cortexにアクセス
Server
Server
②障害耐性の実現方法 (2/2)
• Prometheus の local storage を利用
- Cortexがなくても短期間のメトリクスはアクセス可能
• Thanosを利用
- 複数の Prometheus を跨ってクエリ
- Object Storageの機能は不使用
LBも障害時にサーバー
に直接アクセス
Cortexが障害時に
アクセス
収集層は Prometheus + Thanos

14. 14
CONTENTS
1. 新しいメトリクス監視システムの実現
2. 社内デファクトスタンダードへの展開

15. 15
社内への展開
監視システム データの間隔 保存期間 利用の場合
従来のシステム 5分 2年 長期の傾向を把握したい時
新規のシステム 15秒 14日 通常の監視時
Netdata※ 1秒 1時間 リアルタイムの情報が必要な時
いきなり全て置き換えると抵抗がある人たちもいるので、
PoCを実施しながら、少しずつ導入。
従来のシステムとの違いを活かし共存を目指した。
３つのシステムの違い
※Netdataは新規のシステムの一部

16. 16
小規模からデファクトスタンダードへ
① 小規模サービスへ導入
POCをして小さいサービスから導入。
フィードバックを元にシステムを改善。
② 中規模サービスへの導入
機能性と利便性が高く評価され、利用希望者が増加。
徐々に中規模サービスにも導入。
③ デファクトスタンダード化
口コミが社内で広がり、利用希望者がさらに増加。
全サービスに導入。 ① ② ③
小規模導入
中規模導入
デファクト
スタンダードへ

17. 17
まとめ
社内デファクトスタンダードへの展開
新しいメトリクス監視システムの開発
• 既存システムと共存
• 小規模から導入し、フィードバックを元に改善
• 段階的に利用者を増やし、全社展開へ
• Netdata を exporter として採用し、管理コストを削減
• Cortex と Thanos を組み合わせ、障害耐性を実現
新卒でも、課題を見つけ、解決できるシステムを
開発すれば、全社に展開することができた！！！