Datawire インタビュー

Prometheus ユーザーへのインタビューシリーズを続けます。Datawire の Richard Li 氏が、どのように Prometheus に移行したかについて語ります。

ご自身と Datawire について教えていただけますか？

Datawire では、開発者が Kubernetes 上でより速くコーディングできるよう支援するオープンソースツールを作成しています。当社のプロジェクトには、Kubernetes サービスのローカル開発のための Telepresence、Kubernetes ネイティブ API ゲートウェイで Ambassador に基づいた Envoy Proxy、およびビルド/デプロイシステムである 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 を構成する方法をトレーニングする必要があります。これが、何が機能し、何が機能しないかを理解する上での実験の領域になるだろうと予想しています。