Scalefastrとの対談

Prometheusユーザーへのインタビューシリーズの続きとして、Scalefastrのケビン・バートン氏にPrometheusの活用方法について語っていただきます。

ご自身とScalefastrの業務内容について教えていただけますか？

ケビン・バートンと申します。ScalefastrのCEOを務めています。私の専門は分散システムで、以前はペタバイト規模の分散型ソーシャルメディアクローラーと検索エンジンを構築するDatastreamerという会社を経営していました。

Datastreamerでは、インフラストラクチャに関する拡張性の問題に直面し、Debian、Elasticsearch、Cassandra、Kubernetesをベースにした高性能クラスターを構築しました。

多くのお客様もインフラストラクチャに苦労していることが分かり、AWSやGoogle Cloudで大量のコンテンツをホストするためにどれだけ費用を支払っているかに驚きました。

私たちは継続的にクラウドで実行するコストを評価しましたが、私たちにとってのホスティングコストは現在の5〜10倍になるはずでした。

そこで、Kubernetes、Prometheus、Elasticsearch、Cassandra、Grafana、Etcdなどのオープンソースおよびクラウドネイティブ技術に基づいた新しいクラウドプラットフォームを立ち上げることを決定しました。

現在、数社のお客様をペタバイト規模でホスティングしており、今月中に新しいプラットフォームをソフトローンチする予定です。

Prometheusを導入する前のモニタリング経験について教えていただけますか？

Datastreamerでは、メトリクスが迅速なイテレーション能力の鍵であることが分かりました。プラットフォームの可観測性は私たちが受け入れたものとなり、プラットフォームの分析開発を容易にするためにDropwizard Metricsなどのツールを統合しました。

KairosDB、Grafana、および独自の（シンプルな）可視化エンジンに基づいたプラットフォームを構築し、これはかなり長い間非常にうまく機能しました。

KairosDBに関する主要な問題は、Prometheusに対する採用率と顧客の需要でした。

さらに、Prometheusの良い点は、プロジェクト自体またはコミュニティによって実装されたエクスポーターをサポートしていることです。

KairosDBでは、独自のエクスポーターを構築するのに苦労することがよくありました。KairosDBのエクスポーターがすでに存在している可能性は、Prometheusと比較してかなり低かったのです。

例えば、KairosDBにはCollectDのサポートがありますが、Debianではあまりうまくサポートされておらず、CollectDには本番環境で信頼性高く動作するのを妨げる実用的なバグがあります。

Prometheusを使えば、かなり迅速に稼働させることができます（システムはかなり簡単にインストールできます）、そしてプラットフォーム用のエクスポーターがすでに用意されている可能性はかなり高いです。

さらに、Scalefastrのようなホスト型プラットフォームがPrometheusメトリクスを標準化されたサポート製品として統合すれば、顧客アプリケーションがPrometheusメトリクスを標準化し始めることを期待しています。

アプリケーションのパフォーマンスを可視化することは極めて重要であり、それを実現するためにはPrometheusの高いスケーラビリティが必要です。

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

当初、他の人々がどのようにKubernetesとコンテナアプリケーションを監視しているのか興味がありました。

コンテナの主要な課題の1つは、コンテナが迅速に出現・消滅し、分析する必要のあるログとメトリクスの両方のデータを残すという事実です。

コンテナファーストのアーキテクチャと、エクスポーターやダッシュボードのサポートと併せて、Prometheusが本番環境で成功裏に利用されているのを見たとき、分析バックエンドとしてPrometheusを検討すべきだと明らかになりました。

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

Scalefastrはグリーンフィールド環境なので、移行は私たちにとってある程度痛みがありませんでした。

ほとんどのアーキテクチャは新しく、制限要因はほとんどありません。

私たちの主な目標はベアメタルに展開することですが、既存の標準化されたハードウェアの上にクラウド機能を構築することです。

すべての分析をPrometheusによってクラスター内でバックアップするという考えです。

お客様には、Prometheus、Grafana、Elasticsearch、Kibana、およびKubernetesコントロールプレーンを含む独自の「管理」インフラストラクチャを提供します。このシステムはAnsibleでオーケストレーションされ、初期のマシンセットアップ（ssh、コアDebianパッケージなど）とベースライン構成を処理します。

その後、Prometheus、顧客の構成に必要なすべてのエクスポーター、さらにGrafana用のダッシュボードを展開します。

少し問題があると感じたことの1つは、Grafana.com上の一部のダッシュボードがPrometheus 1.x向けに作成されており、2.xにきれいに移植できなかったことです。2.xシリーズに存在しない機能はほんのわずかしかなく、その多くは少しだけ調整すればよいことが分かりました。さらに、一部のダッシュボードはGrafanaの以前のバージョン向けに作成されていました。

これを解決するために、今週、Cassandra、Elasticsearch、OS、そしてPrometheus自体のようなツール向けのPrometheus向けダッシュボードを標準化および改善するプロジェクトを発表し、これをオープンソース化して先週Githubに公開しました。

これにより、他の人々がPrometheusに簡単に移行できるようになることを願っています。

改善したいことの1つは、Grafanaバックエンドとの自動同期だけでなく、これらのダッシュボードをGrafana.comにアップロードすることです。

また、Prometheusの設定も公開しました。これにより、ラベルがGrafanaテンプレートで正しく機能するようになります。これにより、プルダウンメニューでクラスター名、インスタンス名などのより具体的なメトリクスを選択できます。

移行してからどのような改善がありましたか？

展開の容易さ、高性能、および標準化されたエクスポーターにより、私たちは簡単に切り替えることができました。さらに、バックエンドの構成が比較的簡単であること（基本的にデーモン自体だけ）と、動的な部分が少ないことが、容易な決定につながりました。

ScalefastrとPrometheusの未来についてどうお考えですか？

現在、ElasticsearchとCassandraをベアメタルに直接デプロイしています。これらをKubernetes上で直接コンテナで実行し、Container Storage Interface (CSI) を使用してこれを可能にするよう取り組んでいます。

これを行う前に、Prometheusサービスディスカバリーを機能させる必要がありますが、これはまだ試していません。現在、PrometheusはAnsibleを介してデプロイおよび構成していますが、ワークロードの変化に応じてコンテナが生成・消滅するため、Kubernetesではこれではスケーリングしない（または機能しない）ことは明らかです。

また、標準ダッシュボードとアラートの改善にも取り組んでいます。追加したい機能の1つ（おそらくコンテナとして）は、ホルト・ウィンターズ予測に基づいたアラートのサポートです。

これにより、本質的に深刻なパフォーマンス問題を発生する前に予測できるようになります。ディスク容量不足のように何かが失敗するのを待ってから修正措置を取るのではなく、事前に対応できます。

ある程度、Kubernetesはこの問題に役立ちます。なぜなら、ウォーターマークに基づいてクラスターにノードを追加できるからです。リソース使用率が高すぎると、自動的にスケーリングできます。

特に2.xシリーズへの移行が進み、CNCFとの連携が順調に進んでいるように見えるため、Prometheusの未来に非常に期待しています。