この記事はNikkei Advent Calendar 2022 の 20 日目の記事です。
こんにちは。SRE チームの清水です。
普段は共通アプリケーション基盤 Vessel の開発や、監視基盤の整備、社内のセキュリティ対策などを行なっています。なお、アプリケーション基盤開発の最近の活動については、 Google Innovators Live Japan でもご紹介しておりますので、ぜひご覧ください。
さて、日経の SRE チームでは、全社での運用や監視の共通化、可観測性を高める活動を推進しています。その一環として、共通メトリクス基盤 Titan の設計・開発を進めています。この記事では、共通基盤化に至るまでのメトリクス監視における課題や、 Titan の基本設計、設計思想、現在の開発状況についてお伝えできればと思います。
日経におけるメトリクス監視の課題
日経では、日経電子版をはじめとする様々なサービスを提供しています。そして、それを支えるバックエンド基盤、ID 基盤や決済基盤、データ基盤などの数多くの基盤が稼働しており、収集すべき・したいメトリクスも大量です。
こうして、日々流れ込んでくるメトリクスの量も気がつけば、一部のチームでは、秒間数万オーダーとなっていました。日経では、OSS の活用による柔軟かつスケーラブルな監視を見据え、メトリクス監視システム Prometheus を積極的に活用しています。しかしながら、こういった環境のもとで、以下のような課題感が生まれてきました。
- メトリクス基盤の管理コストが高い
- そもそもアプリケーション開発者は、メトリクス基盤のメンテナンスをしたいわけではない
- メトリクスの増減に応じて、ストレージの再設計や再構築が必要になる
- 長く保存できて、安定しているメトリクスの保存先が現状存在しない
- 大量のメトリクスの流入に基盤が耐えきれない
- メトリクスが大量すぎて、高速な SSD を使っても基盤側のディスク IO が追いつかない
- TSDB が容易に壊れてしまい、修復が難しい場合がある
- リテンションを長く取ることが難しい
- SSD などを利用して基盤を構築した場合、ストレージが高価なことがある
- Prometheus の設計思想上、TSDB は壊れると作り直すことが基本となっている
- メトリクスの活用が難しい
- メトリクスの種類が多く、どの値を使うべきか指針がない
- PromQL の使い方についてガイダンスがない
- ラベルに全社的な統一感がない
- 組織横断的に活用できない・マルチテナントな基盤ではない
- 基盤の設定が、一部のマイクロサービス群などの設定に強く依存した設定となっていて汎用化できない
- ラベルの付与の方法に全社的な一貫性や分離性がない
これらの課題感を解決すべく、SRE チームが共通のメトリクス基盤を開発・運用することが提案されました。この提案によって生まれた基盤が、共通メトリクス監視基盤 Titan です。
共通監視基盤 Titan
設計のコンセプト
Titan は Prometheus の Remote Storage として動作するように設計しています。日経全社で利用することを前提としており、クラウド・オンプレ問わず、あらゆる環境からのメトリクスを受け入れ、組織横断で閲覧できることを目指しています。
誰もが簡単にメトリクスを扱える足回りを整えることで、メトリクスの民主化を目指し、可観測性の向上、ひいては信頼性の向上に寄与したいと考えています。また、メトリクスベースのアラートもより容易・安全に仕掛けられる環境を整えることで、信頼性の向上につながると考えています。
基本設計
Titan は、中央に設置する中央集約基盤と、各 VPC やサブネットワークに設置する Agent で構成しています。
中央集約基盤は Prometheus メトリクスの長期保存・高可用性を実現する OSS である Thanos を Google Cloud Kubernetes Engine (GKE) 上に展開する形を取っています。また、これらのメトリクスは Cloud Storage に保管され、安価に長期間保存され、過去のメトリクスについても一定期間参照できる環境を整える計画です。外部から見たときは Prometheus の Remote Write Storage としての形を取っており、開発者はここに書き込みを行うことで利用できるようになっています。
また、参照やアラートについても、この環境から行うことができるようになっています。可視化のダッシュボードや Alertmanager によるアラート機能を提供し、統一かつ環境横断の閲覧環境やアラート環境を提供できる仕組みです。
最後に、各 VPC に設置する Agent の実態は純粋な Prometheus です。Titan としては、設定のテンプレートを提供予定としています。ただし、実際にはメトリクスを保つ必要もないため、より軽量な Prometheus Agent モードの活用を検討しています。
中央集約基盤の設計
中央集約基盤は OSS である Thanos を GKE の Autopilot を用いて展開する設計となっています。こうすることにより、GKE クラスタの管理コストは削減しつつ、 Thanos による Prometheus メトリクスの長期保存・高可用性のメリットを享受することができます。
また、上記の図では、前段に Cloud Load Balancer を設置しているのがおわかりになるかと思います。これは、メトリクスの異常な大量送信や、クエリの大量試行から基盤を保護するために設置しています。
さらに、 Prometheus の Alertmanager と同等の機能を提供する Thanos Ruler も内部に設置します。この設定をアラート設定を管理する GitHub リポジトリと逐次同期して、環境を横断するアラートも簡単に仕掛けられる足回りを整備する予定です。
Agent の設計
Agent は各 VPC ごとに設置します。こうしておくことで、VPC レベルで Titan への通信の許認可を設定できるようになります。これにより、各環境のネットワーク設定に柔軟性を維持することが可能です。
また、Agent の区別は クラウドベンダ、AWSアカウント名 (GCP Project ID)、VPC ID をキーに行うようにします。これを実現するのが、 Prometheus の Remote Write 機能が備える write_relabel_configs です。ここで上記の情報を Agent 側から送信させるようにし、中央集約基盤でどこの Agent から来たメトリクスなのか区別できるようにしておきます。これにより、中央集約基盤側でも、 VPC レベルやクラウド環境レベルで区別してクエリできますし、逆に環境を横断してクエリすることも可能になります。
また Agent そのものの情報も中央基盤に送信します。これにより、Agent の監視も可能となり、より安定した監視を実現できると考えています。
設計思想・技術の採用基準
基本的にメトリクス基盤は、安定性、使い勝手、価格、管理しやすさなどのトレードオフから、どのような方法を採用するか検討されることが一般的と考えられます。一例として、我々の検討事例を紹介します。
- 安定性と価格
より安定した Prometheus Remote Storage としては、Amazon Managed Service for Prometheus や Managed Service for Prometheus なども非常に良い選択肢でした。特に、安定性という観点では抜群に良い選択肢であり、各クラウド環境の利用者にとっては、オペレーションスイートなどと統合されているなどの利点も享受できます。
このため、日経でも各サービスレベルでの採用事例は多数あり、特に強い安定性や操作性が求められる場合では重宝されます。一方で、広く横断的にメトリクスを収集しておくという場合では、上記の構成の方が安価に収集できるという試算となり、Titan の構築に至りました。
- 管理しやすさと価格
日経では、EC2 環境に Prometheus を構築する事例がありましたが、EBS の性能不足などにより、しばしばデグレーションを起こすことがありました。また、メトリクスの増加に伴い、ストレージやリソースの設計見直しが必要、環境の構成変更に伴う設定変更が大量に発生する、環境に強く依存した設定が入り込むなどのトイルも抱えていました。
ただし、EC2 と EBS で構成されているのみのため、価格としては相当安価であったことも注目すべきです。また、AWS では gp3 という EBS インスタンスタイプが登場し、安価でも高速な IO が実現できるようになりました。こういった技術を応用することで、安価でも十分活用可能な環境を実現できるかもしれません。
現在の開発状況
現在、Titan は開発版としてメトリクスの収集やクエリができる仕組みを整備しつつある状況です。また、大量のメトリクスを Cloud Storage に蓄えたり、長期間のクエリを高可用かつ透過的に実行することもできる環境が整いつつあります。
今後、統一的なアラートやダッシュボード、Agent のテンプレートなど周辺ツールを整えながら、実際のワークロードへ投入していく予定です。
おわりに
日経では、全社での運用や監視の共通化、可観測性を高める活動の一環として、共通メトリクス基盤 Titan の設計・開発を進めています。Prometheus メトリクスの長期保存・高可用性を実現する OSS である Thanos を GKE Autopilot 上に展開し、メンテナンスコストを抑えつつ、柔軟な監視基盤を構築しています。
本記事では、Titan の設計・構成や設計思想・技術の採用基準、開発状況などをお伝えしました。
ぜひ日経のエンジニアリングや SRE 活動にご興味がありましたら、JOBSからインターンやカジュアル面談にお気軽にご参加いただけたら幸いです。
次回は玉越さんの「BigQuery にニアリアルタイム連携を導入しようとしている話」です！
みなさま、今年も一年ありがとうございました！ 来年も素敵な一年をお過ごしください！
