Compose インタビュー

Prometheus ユーザーへのインタビューシリーズとして、Compose が Graphite と InfluxDB から Prometheus への監視ジャーニーについて語ります。

自己紹介と Compose の事業内容について教えていただけますか？

Compose は、世界中の開発者に本番環境対応のデータベースクラスターをサービスとして提供しています。アプリケーション開発者は私たちのもとへ来て、数回のクリックで、マルチホストで高可用性、自動バックアップ、セキュアなデータベースを数分で利用できるようになります。これらのデータベースデプロイメントは、需要の増加に応じて自動的にスケールアップするため、開発者はデータベースの運用ではなく、素晴らしいアプリの構築に時間を費やすことができます。

AWS、Google Cloud Platform、SoftLayer のそれぞれに少なくとも2つのリージョンにわたる数十のホストクラスターがあります。各クラスターは、サポートされている場合はアベイラビリティゾーンにまたがり、プライベートネットワーク内に約1000の高可用性データベースデプロイメントを収容しています。さらに多くのリージョンとプロバイダーが計画中です。

Prometheus導入前のモニタリング経験について教えてください。

Prometheus の前に、さまざまなメトリクスシステムが試されました。最初に試したのは Graphite です。当初はかなりうまく機能していましたが、保存する必要があるメトリクスの膨大な量と、Whisper ファイルがディスクに保存およびアクセスされる方法が相まって、すぐにシステムが過負荷になりました。Graphite は比較的簡単に水平スケーリングできることは認識していましたが、高価なクラスターになるだろうと考えていました。InfluxDB の方が有望に見えたため、その初期バージョンを試してみると、しばらくの間うまく機能しました。Graphite にはさようならを告げました。

InfluxDB の初期バージョンでは、時々データ破損の問題がありました。ほぼ定期的にすべてのメトリクスを削除する必要がありました。通常、壊滅的な損失ではありませんでしたが、イライラしました。実現されなかった機能の継続的な約束は、率直に言って私たちをうんざりさせました。

Prometheusを検討することにした理由は何ですか？

他の選択肢よりも、効率と運用の単純さが優れているように思えました。

プルベースのメトリクス収集は最初は戸惑いましたが、すぐにその利点を理解しました。当初は、各ホストに多数のコンテナがあり、それぞれにメトリクスがある環境では、スケールが非常に重くなる可能性があるように思えましたが、Telegraf と組み合わせることで、各ホストがすべてのコンテナ（および全体のリソースメトリクス）のメトリクスを単一の Prometheus スクレイプターゲット経由でエクスポートするように手配できます。

どのように移行しましたか？

私たちは Chef を使用しているため、大きな EBS ボリュームを備えた大型インスタンスを起動し、Prometheus 用の コミュニティ Chef クックブック をすぐに利用しました。

Prometheus がホスト上で稼働したら、Chef API を使用してすべてのホストをクエリし、Prometheus ターゲット設定ファイルを出力する小さな Ruby スクリプトを作成しました。このファイルと file_sd_config を使用して、すべてのホストが Chef に登録され次第、検出およびスクレイピングされるようにします。Prometheus のオープンなエコシステムのおかげで、Telegraf を標準で簡単に設定でき、ホストレベルのメトリクスを直接エクスポートできました。

単一の Prometheus がどこまでスケールするかをテストしており、それが限界に達するのを待っていました。しかし、限界は来ませんでした！実際、約450ホストの新しいインフラストラクチャのホストレベルメトリクスを15秒ごとにスクレイピングする負荷を、リソース使用量をほとんどかけずに処理しました。

各ホストには多くのコンテナがあるため、それらのメモリ使用量メトリクスをすべて追加した後に Prometheus のシャーディングを開始する必要があると考えていましたが、Prometheus は問題なく動作し続け、リソースを飽和させるまでには至りませんでした。現在、m4.xlarge の Prometheus インスタンス1台と 1TB のストレージで、450ホストの約40,000コンテナの400,000以上の個別のメトリクスを15秒ごとに監視しています。このホストのホストダッシュボードを以下に示します。1TB gp2 SSD EBS ボリュームのディスク IO が最終的な制限要因になるでしょう。初期の推測では、現時点では十分すぎるほどプロビジョニングされていますが、収集するメトリクスと監視するホスト/コンテナの両方で急速に成長しています。

この時点で、テストのために起動した Prometheus サーバーは、以前同じ job を行っていた InfluxDB クラスターよりもはるかに信頼性が高かったため、単一障害点にならないように基本的な作業を行いました。同じターゲットをすべてスクレイピングする別の同一ノードを追加し、keepalived + DNS 更新を備えたシンプルなフェイルオーバースキームを追加しました。これで、以前のシステムよりも高可用性が実現されたため、顧客向けのグラフを Prometheus に切り替え、古いシステムを解体しました。

切り替え以降、どのような改善が見られましたか？

以前の監視セットアップは信頼性が低く、管理が困難でした。Prometheus により、多くのメトリクスをグラフ化するのにうまく機能するシステムがあり、以前使用していたメトリクスシステムに触れることを恐れるのではなく、新しい利用方法に興奮しているチームメンバーがいます。

クラスターも、単に2つの同一ノードで、よりシンプルになりました。成長するにつれて、より多くの Prometheus ホストに作業をシャーディングする必要があることはわかっており、いくつかの方法を検討しています。

Compose と Prometheus の将来について、どのように考えますか？

現時点では、以前のシステムで収集していたメトリクスのみをレプリケートしています。顧客コンテナの基本的なメモリ使用量と、運用担当者向けのホストレベルのリソース使用量です。次の論理的なステップは、データベースチームが DB コンテナ内部からローカル Telegraf インスタンスにメトリクスをプッシュできるようにすることです。これにより、スクレイピングするターゲットの数を増やさずに、データベースレベルの統計も記録できます。

また、Prometheus に取り込みたい他のシステムがいくつかあり、より良い可視性を得たいと考えています。私たちは Mesos 上でアプリを実行しており、基本的な Docker コンテナメトリクスはすでに統合されていますが、これは以前よりも改善されています。しかし、Mesos クラスターのインフラストラクチャコンポーネントの多くを中央 Prometheus に記録するようにしたいとも考えています。これにより、ロードバランサーからアプリメトリクスまで、サポートシステム全体の健全性をすべて示す集中ダッシュボードを作成できます。

最終的には Prometheus をシャーディングする必要があるでしょう。私たちはすでに、さまざまな理由で顧客デプロイメントを多くの小さなクラスターに分割しているので、論理的なオプションは、単一のグローバルな Prometheus ではなく、クラスターごとに小規模な Prometheus サーバー（または冗長性のためにペア）に移行することになるでしょう。

ほとんどのレポートニーズでは、これは大きな問題ではありません。通常、同じダッシュボードに異なるクラスターのホスト/コンテナを必要としないためです。しかし、保持期間をはるかに長くした小規模なグローバルクラスターを維持し、各クラスターの Prometheus から Recording Rules を使用して、ダウンサンプリングおよび集約された適度な数のメトリクスのみを記録するかもしれません。