Scalefastr氏へのインタビュー
2018年2月8日筆者: Brian Brazil
Prometheusユーザーへのインタビューシリーズとして、ScalefastrのKevin Burton氏がPrometheusの利用方法について語ります。
ご自身とScalefastrについてお聞かせください。
私の名前はKevin Burton、ScalefastrのCEOです。Scalefastr。私は分散システムを専門としており、以前はペタバイト規模の分散ソーシャルメディアクローラーおよび検索エンジンを構築した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では、独自のエクスポーターの構築に苦労することがよくありました。Prometheusと比較すると、KairosDBのエクスポーターが既に存在する可能性はかなり低かったです。
たとえば、KairosDBにはCollectDのサポートがありますが、Debianではあまりサポートされておらず、CollectDには実用的なバグがあり、本番環境で信頼性高く動作させることを妨げています。
Prometheusを使用すると、かなり迅速に稼働させることができ（システムはインストールが比較的簡単です）、プラットフォームのエクスポーターが利用可能である可能性はかなり高いです。
さらに、Scalefastrのようなホスト型プラットフォームが、標準化されサポートされた製品として統合されるようになれば、顧客アプリケーションはPrometheusメトリクスに標準化し始めると予想しています。
アプリケーションパフォーマンスの可視性を確保することは極めて重要であり、それを実現するためにはPrometheusの高いスケーラビリティが必要です。
Prometheusを検討することにした理由は何ですか？
当初、他の人々がKubernetesやコンテナアプリケーションをどのように監視しているのか興味がありました。
コンテナの主な課題の1つは、それらが迅速に出入りし、分析が必要なログとメトリクスデータの両方を残していくという事実です。
人々がコンテナファーストのアーキテクチャとともにPrometheusを本番環境で成功裏に使用していること、およびエクスポーターとダッシュボードのサポートを見たとき、Prometheusを分析バックエンドとして調査すべきであることが明らかになりました。
どのように移行しましたか？
Scalefastrはグリーンフィールド環境であるため、移行は比較的スムーズでした。
アーキテクチャはほとんどが新しく、制限要因はほとんどありません。
私たちの主な目標は、ベアメタルにデプロイすることですが、既存および標準化されたハードウェアの上にクラウド機能を作成することです。
すべての分析をクラスター内でPrometheusでバックアップするという考えです。
お客様には、Prometheus、Grafana、Elasticsearch、Kibana、そしてKubernetesコントロールプレーンを含む独自の「管理」インフラストラクチャを提供しています。Ansibleでこのシステムをオーケストレーションし、初期マシンセットアップ（ssh、コアDebianパッケージなど）とベースライン構成を処理します。
次に、Prometheus、顧客構成に必要なすべてのアダプター、およびGrafana用のダッシュボードをデプロイします。
Grafana.comの一部のダッシュボードはPrometheus 1.x向けに書かれており、2.xにきれいに移行しないという問題がありました。2.xシリーズには存在しない関数がいくつかありますが、それらのほとんどは少しの調整で済みます。さらに、一部のダッシュボードは、Grafanaの以前のバージョン向けに書かれていました。
それを解決するために、今週、Cassandra、Elasticsearch、OS、そしてPrometheus自体のためのPrometheus向けのダッシュボードを標準化および改善するプロジェクトを発表しました。これはオープンソース化され、先週GitHubに公開されました。
これにより、他の人々がPrometheusに移行しやすくなることを願っています。
改善したいことの1つは、Grafanaバックエンドとの自動同期、およびこれらのダッシュボードをGrafana.comにアップロードすることです。
また、ラベルがGrafanaテンプレートと正しく連携するように、Prometheus構成も公開しました。これにより、クラスター名、インスタンス名などのより具体的なメトリクスを選択するためのプルダウンメニューを使用できます。
切り替え以降、どのような改善が見られましたか？
デプロイの容易さ、高性能、標準化されたエクスポーターのおかげで、切り替えが容易でした。さらに、バックエンドの構成が比較的簡単（基本的にデーモン自体のみ）で、多くの可動部品がないことも、簡単な決断でした。
ScalefastrとPrometheusの将来についてどうお考えですか？
現在、ElasticsearchとCassandraをベアメタルに直接デプロイしています。これらをKubernetes上で直接コンテナとして実行できるように作業しており、Container Storage Interface（CSI）を使用してこれを実現することを目指しています。
これを実行するには、Prometheusサービスディスカバリを機能させる必要がありますが、これはまだ試していません。現在、PrometheusはAnsibleでデプロイおよび構成していますが、ワークロードが変化するにつれてコンテナが出入りするため、これはKubernetesではスケーリング（あるいは機能）しません。
標準ダッシュボードとアラートの改善にも取り組んでいます。追加したい機能の1つ（おそらくコンテナとして）は、Holt-Winters予測に基づいたアラートのサポートです。
これにより、本質的に、深刻なパフォーマンス問題を事前に予測できるようになります。たとえば、ディスク容量不足のような問題が発生してから対処するのではなく、事前に対処できるようになります。
ある程度、Kubernetesは、ウォーターマークに基づいてクラスターにノードを追加するだけでよいので、この問題に役立ちます。リソース使用率が高すぎると、自動スケーリングできます。
Prometheusの将来、特に2.xシリーズに進んでおり、CNCFとの連携も順調に進んでいることを考えると、非常に期待しています。