Prometheusユーザーへのインタビューシリーズの続きとして、Datawire社のRichard Li氏が、どのようにPrometheusへ移行したのかについて語ります。
あなた自身とDatawire社の事業内容について教えてください。
Datawire社では、開発者がKubernetes上でより速くコーディングできるように支援するオープンソースツールを開発しています。当社のプロジェクトには、Kubernetesサービスのローカル開発のためのTelepresence、Envoy Proxy上に構築されたKubernetesネイティブのAPIゲートウェイであるAmbassador、およびビルド/デプロイシステムであるForgeなどがあります。
当社は、オープンソースの取り組みをサポートするために、AWSのKubernetesで多数のミッションクリティカルなクラウドサービスを運用しています。これらのサービスは、自動テストインフラストラクチャで使用される、1日に数十のKubernetesクラスターを動的にプロビジョニングするなどのユースケースをサポートしています。
Prometheus導入前の監視経験について教えてください。
私たちはAWS CloudWatchを使用していました。これは簡単にセットアップできましたが、より分散型の開発モデル（マイクロサービス）を採用するにつれて、より柔軟性と制御が必要であることがわかりました。たとえば、運用部門の助けを借りずに、各チームが必要に応じて監視をカスタマイズできるようにしたいと考えました。
Prometheusを検討しようと思った理由は何ですか？
主な要件は2つありました。1つ目は、すべてのエンジニアが自分のサービスを運用管理し、可視化できるようにしたかったことです。当社の開発モデルは、設計上高度に分散化されており、エンジニアが何かを完了するために別のエンジニアを待つ必要がある状況を避けようとしています。監視に関しては、エンジニアがメトリクスインフラストラクチャを柔軟に制御できるようにしたいと考えました。2つ目の要件は、強力なエコシステムでした。強力なエコシステムとは、一般的に、確立された（そして文書化された）ベストプラクティス、継続的な開発、そして困ったときに助けてくれる多くの人々がいることを意味します。
Prometheus、特にPrometheus Operatorは、当社の要件を満たしていました。Prometheus Operatorを使用すると、各開発者は運用部門の助けを借りずに（ボトルネックなし！）、必要に応じて独自のPrometheusインスタンスを作成できます。また、私たちはCNCFのメンバーであり、KubernetesおよびEnvoyコミュニティで多くの経験を積んでいるため、Prometheusの別のCNCFコミュニティに注目するのは自然なことでした。
どのように移行しましたか？
私たちは、まずPrometheusをAPIゲートウェイと統合することから始めたいと考えていました。当社のAPIゲートウェイはプロキシにEnvoyを使用しており、Envoyはstatsdプロトコルを使用してメトリクスを自動的に発行します。Prometheus Operatorをインストールし（詳細なメモはこちら）、Envoyから統計情報を収集するように設定しました。また、別のAmbassadorコントリビューターによる作業を基にしたGrafanaダッシュボードもセットアップしました。
移行後、どのような改善が見られましたか？
当社のエンジニアは、L7トラフィックを可視化できるようになりました。また、Prometheusを使用して、カナリアデプロイのレイテンシーとスループットを比較し、新しいバージョンのサービスがパフォーマンスの低下を引き起こさないという確信を深めることができます。
Datawire社とPrometheusの将来について、どうお考えですか？
Prometheus Operatorの使用は、まだ少し複雑です。サービスチームの運用上のベストプラクティス（いつPrometheusをデプロイするか）を理解する必要があります。次に、これらのベストプラクティスについてエンジニアを教育し、Operatorをニーズに合わせて構成する方法についてトレーニングする必要があります。これは、何がうまくいき、何がうまくいかないのかを理解するにつれて、いくつかの実験が行われる分野になると予想しています。