Weaveworksとのインタビュー

2017年2月20日筆者: Brian Brazil

Prometheusユーザーへのインタビューシリーズの続編として、WeaveworksのTom Wilkie氏がPrometheusをどのように選択し、現在どのように構築しているかについて語ります。

Weaveworksについて教えていただけますか?

Weaveworksは、オープンソースプロジェクトとSoftware as a Serviceの組み合わせを通じてマイクロサービスを「運用可能」にするサービスであるWeave Cloudを提供しています。

Weave Cloudは以下で構成されています。

  • Weave Scopeによる視覚化
  • Weave Fluxによる継続的デプロイメント
  • コンテナSDNであるWeave Netによるネットワーキング
  • オープンソースの分散Prometheus-as-a-ServiceであるWeave Cortexによる監視

Weave Cloudを60日間無料でお試しいただけます。最新製品情報については、当社のブログTwitter、またはSlack招待)をご覧ください。

Prometheus導入前の監視経験について教えてください。

Weave Cloudはゼロからの実装であったため、以前の監視システムはありませんでした。以前の職場では、MuninやNagiosのような一般的なツールを使用していました。Weave Cloudは、Scopeのマルチテナントホストバージョンとして始まりました。ScopeにはCPUやメモリ使用量などの基本的な監視機能が含まれているため、それを使用していたと言えるでしょう。しかし、Scope自体を監視するための何かが必要でした...

なぜPrometheusに着目しようと思ったのですか?

元Google SREのスタッフが多数おり、Borgmonの経験が豊富でした。また、元SoundClouderのスタッフはPrometheusの経験がありました。私たちはKubernetes上にサービスを構築しており、その動的にスケジュールされる性質に「フィットする」ものを探していたため、Prometheusは迷うことなく選択肢となりました。PrometheusとKubernetesがどのように連携して機能するかについて、PrometheusとKubernetesがいかにうまく連携するかというブログ記事シリーズの最初の記事を執筆しました。

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

Prometheusを使い始めた当初、KubernetesのサービスディスカバリはまだPR段階で、ドキュメントもほとんどありませんでした。しばらくの間カスタムビルドを実行し、手探りで作業を進めていきました。最終的に、ロンドンで開催されたPrometheusミートアップで、当社の経験について講演し、ブログ記事シリーズを公開しました。

Prometheusを実行するためのほとんどすべての異なるオプションを試しました。最初は、埋め込み構成で独自のコンテナイメージを構築し、GrafanaとAlert Managerと一緒に1つのPodでそれらをすべて実行しました。時系列データには、Pod内の一時的なストレージを使用しました。その後、ダッシュボードを変更するたびにPrometheusを再起動する必要がないように(そして履歴を失うことなく)、これを異なるPodに分割しました。最近では、アップストリームイメージを使用し、構成をKubernetes構成マップに保存するように変更しました。これは、変更されるたびにCIシステムによって更新されます。Prometheus Podに小さなサイドカーコンテナを使用して、構成ファイルを監視し、変更されたときにPrometheusにpingを送信します。これにより、Prometheusを頻繁に再起動する必要がなく、ストレージに特別なことをしなくても済み、履歴を失うこともありません。

Prometheusの履歴が定期的に失われるという問題は依然として私たちを悩ませ、Kubernetesボリュームや定期的なS3バックアップなどの利用可能なソリューションにはすべて欠点がありました。Scopeサービスを監視するためにPrometheusを使用する素晴らしい経験とともに、これが私たちに、クラウドネイティブな分散バージョンのPrometheus、つまり、アップグレード、シャッフル、ホスト障害に耐え、履歴を失うことなく稼働できるものを構築するきっかけとなりました。そして、それがWeave Cortexの誕生秘話です。

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

Cortexはさておき、HA Alert Managerの導入には特に興奮しました。主に、それが当社のゴシップおよび協調レイヤーであるWeave Meshを最初に利用したWeaveworks以外のプロジェクトの1つだったからです。

また、Fabianによるバージョン2のKubernetesサービスディスカバリの変更にも特に注目しました。これは、Consul Podを監視する際に、同じPod上で複数のポートをスクレイピングする必要があるという、私たちにとって切実な問題を解決してくれました。

そして、リモート書き込み機能(私が担当した機能)に言及しないのは失礼でしょう。これにより、PrometheusはWeave Cortex自体の中核コンポーネントとなり、ターゲットをスクレイピングしてサンプルを私たちに送信します。

WeaveworksとPrometheusの将来についてはどうお考えですか?

私にとって当面の未来は、WeaveworksのPrometheus as a ServiceであるWeave Cortexです。社内で広く使用しており、かなりのクエリパフォーマンスを達成し始めています。現在、実ユーザーを対象に本番環境で稼働しており、まもなくアラートのサポートを導入し、上流のPrometheusと同等の機能を実現する予定です。そこから、年央の一般提供に向けて、安定化のためのベータプログラムに入ります。

Cortexの一部として、PromQLのオートコンプリートとJupyterのようなノートブックを備えたインテリジェントなPrometheus式ブラウザを開発しました。これをより多くの人々に提供し、最終的にオープンソース化することを楽しみにしています。

また、Lokiという小さなサイドプロジェクトも持っています。これはPrometheusのサービスディスカバリとスクレイピングをOpenTracingにもたらし、分散トレーシングを簡単かつ堅牢にします。3月末にベルリンで開催されるKubeCon/CNCFConで、これについて講演を行います。