CloudFlareのグローバルネットワークをPrometheusで監視する

Matt Bostock氏がSREcon 2017 Europeで行なった講演で、メトリックベースの監視ツールであるPrometheusが、CDNとDNS、およびDDoS対策プロバイダであるCloudFlareの持つ世界規模の分散インフラストラクチャおよびネットワーク監視においてどのように利用されているか、という話題が取り上げられた。

メトリックベース監視プロジェクトであるPrometheusは、2012年頃に立ち上げられたオープンソースプロジェクトで、Cloud Native Computing Foundation (CNCF)のメンバである。Prometheusは、動的構成と問合せ言語のPromQLを備えているため、警告に複雑なクエリを記述することができる。CloudFlareはCDN(Content Delivery Network)と分散DNS、およびDDoS対策サービスを提供するプロバイダであり、そのインフラストラクチャは世界規模に広がっている。このようなインフラストラクチャとネットワークの監視はいきおい複雑なものになる。講演では、この中でPrometheusが果たす役割が説明がされた。CloudFlareでは、それまでNagiosが使用されていた部分の87パーセントがPrometheusにリプレースされている。

CloudFlareはAnycastを使用して、CDNと同じようなサービスを提供する。Anycast DNSはユーザに最も近いサーバからのDNSクエリ配信を、Anycast HTTPはユーザに最も近いサーバからのコンテンツ提供を、それぞれ可能にする。ユーザとWebサイトの中間で動作することで、CloudFlareは、ビジタのトラフィックに脅威パターンがあるかどうかも同時にチェックできる。同サービスには150ヶ国に116ヶ所のデータセンタがあり、毎秒500百万のHTTPリクエストと120万のDNSリクエストを処理している。これは世界中のインターネットリクエストの10パーセントを占める数値である。各PoP(point-of-presence)ではHTTP、DNS、攻撃緩和(attack mitigation)、キーバリューストアを提供する。これを監視するため、講演の時点で188のPrometheusサーバが稼働されている。

画像提供 - https://promcon.io/2017-munich/talks/monitoring-cloudflares-planet-scale-edge-network-with-prometheus/

Prometheusはメトリクスベースである。すなわち、時系列メトリクスを収集し、他の機能はこのメトリクスを基盤として構築されている。監視対象の各サーバ上でエクスポータ(exporter)と呼ばれるプロセスが動作し、収集したメトリクスをHTTP経由で提供する、というプルモデルで動作する。CloudFlareではサービスドメイン毎にひとつのエクスポータを展開し、システム(CPU、メモリ、TCP、ディスク)、ネットワーク(HTTP、ping)、ログ検索(エラーメッセージ)、およびコンテナとネームスペースのメトリクスを収集している。最終段階では、Googleのオープンソースプロジェクトであるcadvisorが使用されている。Prometheusのデータ保持期間は無期限ではなく、今この時点(here-and-now)の監視という観点がより重視される。CloudFlareのセットアップでは、ダウンサンプリングなしで15日間のデータが保持されている。

CloudFlareコアデータセンタのサービスリストには、Marathon、Mesos、Chronos、Docker、Sentry、Ceph(ストレージ用)、Kafka、Spark、Elasticsearch、Kibanaで構成されるスタックによるログアクセス、分析、APIなどが挙げられている。各PoPではPrometheusが、エクスポータを通じてサーバおよびサービスのメトリクスを問い合わせる。PoP単位の高可用性は、複数のPrometheusサーバを使用することによって担保する。

Prometheusの警告マネージャは、アラートマネージャ(Alertmanager)という分かりやすい名前だ。CloudFlareのデプロイメントでは、Prometheusサーバがプッシュするイベント毎にひとつのアラートマネージャが用意されている。このセットアップの高可用性については現在作業中である。警告は過去データを使ってテストし、正常な動作を確認する。この機能は、Bosunなどの新しい監視ツールの一部でもある。その他の警告に関する優れた特徴としては、説明的な(descriptive)名称、明確性、受信者が即座に対応可能な情報量、などが挙げられる。

CloudFlareチームはjiralertsを使って、JIRAチケットシステムをアラートマネージャに統合している。JIRAはワークフローをカスタマイズできるので、警告を監視するために、監視ワークフロー用の特別なステートを含めることが可能だ。別のツールであるalertmanagere2sが警告を受信してElasticsearchに取り込むことにより、後で検索や解析を行なうことが可能になる。CloudFlareではアラートマネージャ用に、unseeという独自のダッシュボードを開発している。

Prometheus自体の監視はどうするのだろう？2つのアプローチがある。ひとつは、同じデータセンタ内のPrometheusが相互に監視する、メッシュ的なアプローチである。もうひとつは、トップレベルのPrometheusサーバがデータセンタレベルのPrometheusサーバ群を監視するという、トップダウンのアプローチだ。

CloudFlare SREチームが現在取り組んでいることのひとつは、環境やクラスタなどのようなラベルの早期の標準化と、それによるグループ化である。その他としては、可視性の確立や、同業者やステークホルダによるバイインを生み出すことに関連するものがある。立ち上げ時にチームが関与することにより、監視システムのサービスへの統合が短期間で可能になる。警告の内容自体のチューニングや改善には複数のイテレーションを必要とするため、現在も進行中のプロセスである。