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インスタンス（1TBのストレージ）で、450ホスト上の約40,000コンテナについて、400,000を超える異なるメトリクスを15秒ごとに監視しています。このホストのダッシュボードを以下に示します。1TBのgp2 SSD EBSボリューム上のディスクIOが、最終的には制限要因になるでしょう。現在のところ、当初の推測よりも大幅にプロビジョニングしすぎていますが、収集されるメトリクスと監視対象のホスト/コンテナの両方で急速に成長しています。

この時点で、テストのために立ち上げたPrometheusサーバーは、以前同じ仕事をしていたInfluxDBクラスターよりもはるかに信頼性が高かったため、単一障害点のリスクを軽減するための基本的な作業を行いました。同じターゲットをすべてスクレイピングする別の同一ノードを追加し、keepalived + DNSアップデートによる簡単なフェイルオーバー方式を追加しました。これにより、以前のシステムよりも可用性が高くなったため、顧客向けのグラフをPrometheusを使用するように切り替え、古いシステムを解体しました。

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

以前のモニタリング設定は信頼性が低く、管理が困難でした。Prometheusを導入してからは、多くのメトリクスをグラフ化するのにうまく機能するシステムを手に入れました。以前使っていたメトリクスシステムを触ることを警戒していたチームメンバーが、突然、新しい使い方について熱心に語るようになりました。

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

ComposeとPrometheusの将来についてはどうお考えですか？

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

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

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

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