Uploaded byRakuten Group, Inc.
大規模なリアルタイム監視の導入と展開
Rakuten Developer Meetup vol.03 大規模クラウドの仕組みと秘密 https://rakuten.connpass.com/event/254762/
More Related Content
![[AWS Summit 2012] クラウドデザインパターン#6 CDP クラウド監視編](https://cdn.slidesharecdn.com/ss_thumbnails/aws-summit-cdp-06-121001114848-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
大規模なリアルタイム監視の導入と展開
- 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.
- 5.
- 6. 6 従来のメトリクス監視システムと課題 従来のメトリクス監視システム • Ruby による内製 •SNMP を通してメトリクスを収集 • RRD Tool で NAS にメトリクスを保存 • メトリクス保存期間は２年 課 題 • メトリクス収集が Ruby の内製プログラムのため、 拡張が困難で、監視対象がOSと一部のミドルウェア に限定されている • メトリクスの間隔が5分に1回で、リアルタイムの データがとれない • 監視システムの開発後に利用しはじめた Kubernetesに非対応 • 監視情報に欠損が出てしまうことがある 監視システム 可視化層 データ層 収集層 監視対象
- 7. 7 • CNCF (CloudNative Computing Foundation )のCortex を採用 • マルチテナント対応 • 長期間保存 • クラスタリングによる高可用性と水平拡張性 新しいメトリクス監視システムのアーキテクチャ • サーバーやKubernetesのpodに各種の Prometheus Exporterを起動 • メトリクスを公開 • Prometheus を採用 • サーバーやKubernetesのメトリクスを収集 • TSDB(Time-series Database)に書き込み - Remote writeを利用 • Grafanaを採用 • TSDB (Time-series Database)からメトリクスを取得 従来のシステムの課題を解決できるPrometheusを中心に設計 監視システム 可視化層 データ層 収集層 監視対象
- 8.
- 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.
- 15. 15 社内への展開 監視システム データの間隔 保存期間利用の場合 従来のシステム 5分 2年 長期の傾向を把握したい時 新規のシステム 15秒 14日 通常の監視時 Netdata※ 1秒 1時間 リアルタイムの情報が必要な時 いきなり全て置き換えると抵抗がある人たちもいるので、 PoCを実施しながら、少しずつ導入。 従来のシステムとの違いを活かし共存を目指した。 ３つのシステムの違い ※Netdataは新規のシステムの一部
- 16. 16 小規模からデファクトスタンダードへ ① 小規模サービスへ導入 POCをして小さいサービスから導入。 フィードバックを元にシステムを改善。 ② 中規模サービスへの導入 機能性と利便性が高く評価され、利用希望者が増加。 徐々に中規模サービスにも導入。 ③デファクトスタンダード化 口コミが社内で広がり、利用希望者がさらに増加。 全サービスに導入。 ① ② ③ 小規模導入 中規模導入 デファクト スタンダードへ
- 17. 17 まとめ 社内デファクトスタンダードへの展開 新しいメトリクス監視システムの開発 • 既存システムと共存 • 小規模から導入し、フィードバックを元に改善 •段階的に利用者を増やし、全社展開へ • Netdata を exporter として採用し、管理コストを削減 • Cortex と Thanos を組み合わせ、障害耐性を実現 新卒でも、課題を見つけ、解決できるシステムを 開発すれば、全社に展開することができた！！！