JustWatch インタビュー

Prometheus ユーザーへのインタビューシリーズとして、JustWatch がどのようにモニタリングを確立したかについて語ります。

自己紹介と JustWatch がどのような事業を行っているか教えていただけますか？

消費者向けには、JustWatch は、映画やテレビ番組をオンラインや劇場で合法的に視聴できる場所を見つけるためのストリーミング検索エンジンです。Netflix、HBO、Amazon Video、iTunes、Google Play などの主要なストリーミングプロバイダーや、その他の多くのプロバイダーで、17カ国で映画コンテンツを検索できます。

映画スタジオやビデオオンデマンドプロバイダーなどのクライアントに対しては、国際的な映画マーケティング会社として、消費者向けアプリから世界中のファンの購入行動や映画の嗜好に関する匿名化されたデータを収集しています。スタジオが適切なオーディエンスにコンテンツを広告するのを支援し、無駄なカバレッジを最小限に抑えることで、デジタルビデオ広告をはるかに効率的にします。

2014年のローンチ以来、マーケティングに1ドルも費やすことなく、国際的なトップ20,000ウェブサイトの一つへと成長しました。わずか2年足らずで世界最大のストリーミング検索エンジンになりました。現在、わずか10名のエンジニアリングチームで、約50のマイクロ・マクロサービスからなる完全にDocker化されたスタックを構築・運用しており、そのほとんどは Kubernetes 上で実行されています。

Prometheus導入前のモニタリング経験について教えてください。

以前の会社では、私たちはほとんどすべてのオープンソース監視製品で作業した経験があります。Nagios、Icinga、Zabbix、Monit、Munin、Graphite およびその他のシステムで作業した経験があります。ある会社では、Puppet を使って分散 Nagios セットアップの構築を支援しました。このセットアップは、新しいサービスがシステムに自動的に表示されるため良かったのですが、インスタンスを削除するのは依然として困難でした。システムのばらつきが少しでもあると、ホストベースおよびサービスベースの監視スイートはうまく適合しません。Prometheus が採用したラベルベースのアプローチは、私がずっと欲しかったものでしたが、それ以前は見つかりませんでした。

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

JustWatch では、Prometheus の公開発表がまさに適切なタイミングで hit しました。最初の数ヶ月間は、ほとんどブラックボックス監視でした。一部の最も重要な内部メトリクスには CloudWatch を使用し、サイト全体の障害を検出するために Pingdom のような外部サービスを組み合わせていました。また、Icinga、Thruk、Zabbix のような従来のホストベースのソリューションは、時代遅れで仕事に適していないと感じていました。ホワイトボックス監視を調査し始めたとき、幸運にも Golang Meetup に参加し、Julius と Björn が Prometheus を発表したのを聞きました。すぐに Prometheus サーバーをセットアップし、Go サービス（バックエンドではほぼ Go のみを使用）のインストルメンテーションを開始しました。それがどれほど簡単だったか驚きました。設計は、クラウドおよびサービス指向を第一原理としており、決して妨げにならないものでした。

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

移行はそれほど難しくありませんでした。タイミング的に、関連する監視がまったくない状態から直接 Prometheus に移行できたのは幸運でした。

Prometheus への移行は、主に Go クライアントをアプリに含め、HTTP ハンドラーをラップすることでした。また、node_exporter やクラウドプロバイダー API 用のいくつかのエクスポーターなど、いくつかのエクスポーターを記述してデプロイしました。私たちの経験では、監視とアラートは決して終わりのないプロジェクトですが、作業の大部分は数週間でサイドプロジェクトとして完了しました。

Prometheus をデプロイして以来、何かを見逃したときや、新しいサービスをゼロから設計するときに、メトリクスに注目する傾向があります。

PromQL とラベルの概念の優雅さを完全に理解するには時間がかかりましたが、その努力は本当に報われました。

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

Prometheus は、ホワイトボックス監視とラベルベースのカナリアデプロイメントのメリットを非常に簡単に享受できるようにしてくれました。多くの Golang の側面（HTTP Handler、Go Runtime）の標準装備のメトリクスは、非常に迅速な投資収益率（ROI）をもたらしました。ゴルーチンメトリクスだけでも、何度も危機を救ってくれました。以前から気に入っていた唯一の監視コンポーネントである Grafana は、Prometheus と自然に連携し、非常に役立つダッシュボードを作成することを可能にしました。Prometheus が車輪の再発明を試みず、既存の最高のソリューションと完璧に連携したことを評価しています。以前のシステムからのもう一つの大きな改善は、Prometheus が実際に数学（パーセンタイルなど）を正しく計算することに焦点を当てたことです。他のシステムでは、提供される操作が理にかなっているかどうか確信が持てませんでした。特にパーセンタイルは、マイクロサービスのパフォーマンスを理解するための自然で不可欠な方法であり、それらが一級の扱いを受けたことは素晴らしいと感じました。

統合されたサービスディスカバリにより、スクレイプターゲットの管理が非常に簡単になります。Kubernetes の場合、すべてが標準装備で機能します。まだ Kubernetes 上で実行されていないその他のシステムについては、Consul ベース のアプローチを使用しています。アプリケーションを Prometheus で監視するために必要なことは、クライアントを追加し、/metrics を公開し、コンテナ/Pod に 1 つの簡単なアノテーションを設定することだけです。この低結合性は、開発と運用の間の多くの摩擦を取り除きます。多くのサービスは、シンプルで楽しく、最初からうまくオーケストレーションされています。

時系列データと巧妙な関数の組み合わせは、素晴らしいアラートの超能力をもたらします。サーバーで実行される集計と、時系列データ、それらの組み合わせ、さらにはそれらの組み合わせに対する関数をすべて一級市民として扱うことで、アラートは簡単になります。多くの場合、事後でも。

JustWatch と Prometheus の将来について、どのようにお考えですか？

Prometheus が派手であることに焦点を当てるのではなく、実際に機能し、価値を提供することに重点を置いていることを高く評価していますが、特に Alertmanager はまだ改善の余地が多くあります。フロントエンドでのアラートの対話的な構築と編集の簡素化のような単純な改善だけでも、アラートとの連携をさらに容易にするために大きく役立つでしょう。

ストレージレイヤー、特にリモートストレージの継続的な改善に本当に期待しています。また、Project Prism や Vulcan で採用されているアプローチの一部が、コア Prometheus にバックポートされることを期待しています。現時点で最も興味深いトピックは、GCE サービスディスカバリ、より簡単なスケーリング、および（コールドストレージや古いイベントのクエリ時間の長期化を犠牲にしてでも）より長い保持期間です。

また、Prometheus をより多くの非技術部門でも使用できることを楽しみにしています。ほとんどの KPI を Prometheus でカバーし、誰もが美しいダッシュボードやアラートを作成できるようにしたいと考えています。現在、新しい内部ビジネスプロジェクトのために、優れたアラートエンジンを悪用することさえ計画しています。続報にご期待ください！