Datawire とのインタビュー

Prometheus ユーザーへのインタビューシリーズの続編として、Datawire の Richard Li が、Prometheus への移行方法について語ります。

あなた自身と Datawire の事業内容について教えていただけますか？

Datawireでは、開発者がKubernetes上でより速くコードを書けるようにするオープンソースツールを開発しています。私たちのプロジェクトには、Kubernetesサービスのローカル開発用のTelepresence、Envoy Proxy上に構築されたKubernetesネイティブのAPI GatewayであるAmbassador、そしてビルド/デプロイシステムであるForgeがあります。

私たちはオープンソース活動を支援するために、AWS の Kubernetes 上で多くのミッションクリティカルなクラウドサービスを運用しています。これらのサービスは、1日に数十もの Kubernetes クラスターを動的にプロビジョニングするといったユースケースをサポートしており、それらのクラスターは自動テストインフラストラクチャによって使用されます。

Prometheus導入以前の監視経験はどのようなものでしたか？

AWS CloudWatch を使用していました。設定は簡単でしたが、より分散型の開発モデル (マイクロサービス) を採用するにつれて、より高い柔軟性と制御が必要だと感じました。たとえば、各チームが運用担当者の助けを借りずに、必要に応じて監視をカスタマイズできるようにしたかったのです。

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

私たちには2つの主な要件がありました。1つ目は、ここにいるすべてのエンジニアが、自分のサービスに対して運用上の制御と可視性を持てるようにしたかったことです。私たちの開発モデルは意図的に高度に分散されており、エンジニアが何かを完了するために別のエンジニアを待つ必要がある状況を避けようとしています。監視に関しては、エンジニアがメトリクスインフラストラクチャに対して多くの柔軟性と制御を持てるようにしたかったのです。2つ目の要件は、強力なエコシステムでした。強力なエコシステムとは、一般的に確立された（そして文書化された）ベストプラクティス、継続的な開発、そして行き詰まったときに助けてくれる多くの人々がいることを意味します。

Prometheus、特にPrometheus Operatorは、私たちの要件に合致しました。Prometheus Operatorを使えば、各開発者が運用担当者の助けなしに（ボトルネックなしに！）必要に応じて独自のPrometheusインスタンスを作成できます。私たちはまた、KubernetesとEnvoyコミュニティで多くの経験を持つCNCFのメンバーでもあるため、Prometheusという別のCNCFコミュニティに目を向けるのは自然なことでした。

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

PrometheusをAPI Gatewayと統合することから始めたいと考えていました。API GatewayはプロキシにEnvoyを使用しており、Envoyはstatsdプロトコルを使用して自動的にメトリクスを発行します。私たちはPrometheus Operatorをインストールし（詳細なメモはこちら）、Envoyからの統計情報の収集を開始するように設定しました。また、別のAmbassadorコントリビューターによる一部の作業に基づいてGrafanaダッシュボードも設定しました。

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

当社のエンジニアはL7トラフィックを可視化できるようになりました。また、Prometheusを使用して、カナリアデプロイメントの遅延とスループットを比較することで、新しいバージョンのサービスがパフォーマンスの低下を引き起こさないことをより確信できるようになりました。

Datawire と Prometheus の将来についてどう思いますか？

Prometheus Operator の使用はまだ少し複雑です。私たちのサービスチームにとっての運用上のベストプラクティス（いつPrometheusをデプロイするか？）を見つける必要があります。次に、これらのベストプラクティスについてエンジニアを教育し、彼らのニーズに合わせてOperatorを設定する方法を訓練する必要があります。何が機能し、何が機能しないかを解明するにつれて、これはいくつかの実験の領域になると予想しています。