JustWatchとのインタビュー

Prometheusユーザーへのインタビューシリーズの続きとして、JustWatchが彼らの監視体制をどのように確立したかについて語ります。

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

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

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

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

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

以前の会社では、私たちの多くは既存のオープンソース監視製品のほとんどすべてに携わってきました。Nagios、Icinga、Zabbix、Monit、Munin、Graphite、その他いくつかのシステムでの豊富な経験があります。ある会社では、Puppetを使って分散Nagiosセットアップを構築するのを手伝いました。このセットアップは、新しいサービスがシステムに自動的に表示されるので良かったのですが、インスタンスを取り除くのはまだ大変でした。システムに何らかの変動がある場合、ホストベースおよびサービスベースの監視スイートはうまく適合しませんでした。Prometheusが採用したラベルベースのアプローチは、私が常に求めていたものでしたが、それまで見つけることができませんでした。

なぜPrometheusに注目することにしたのですか？

JustWatchでは、Prometheusの公開発表がちょうど良いタイミングでした。創業当初の数ヶ月間は、主にブラックボックス監視を行っていました。最も重要な内部メトリクスにはCloudWatchを使用し、サイト全体の障害検知にはPingdomのような外部サービスを組み合わせていました。また、従来のホストベースのソリューションはどれも私たちを満足させるものではありませんでした。コンテナとマイクロサービスの時代において、Icinga、Thruk、Zabbixのようなホストベースのツールは古臭く、仕事には適していないと感じられました。ホワイトボックス監視の調査を開始したとき、幸運にもJuliusとBjörnがPrometheusを発表したGolang Meetupに参加した者がいました。私たちはすぐにPrometheusサーバーをセットアップし、Goサービス（バックエンドにはほとんどGoを使用しています）の計測を開始しました。それがどれほど簡単であったか驚くほどでした。その設計は、第一原理としてクラウドとサービス指向であるように感じられ、決して邪魔になりませんでした。

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

タイミング的に、適切な監視システムがない状態から直接Prometheusに移行できたため、移行はそれほど難しくありませんでした。

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

Prometheusの導入以来、何かが不足していると感じたときや、新しいサービスをゼロから設計する際には、常にメトリクスを確認する傾向があります。

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

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

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

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

時系列と clever な関数の組み合わせにより、素晴らしいアラートのスーパーパワーが実現します。サーバー上で実行される集約機能と、時系列、それらの組み合わせ、さらにはそれらの組み合わせに対する関数を第一級の市民として扱うことで、アラート設定が非常に簡単になります。多くの場合、事後に設定することも可能です。

JustWatchとPrometheusの未来はどうなると思いますか？

Prometheusが「見栄えが良いこと」ではなく、「実際に機能し、価値を提供すること」に焦点を当てており、展開と運用が比較的簡単であるという点を高く評価していますが、特にAlertmanagerにはまだ改善の余地が多くあります。フロントエンドでのインタラクティブなアラート構築と編集の簡素化のような、いくつかの簡単な改善だけでも、アラートの作業をさらにシンプルにする上で大いに役立つでしょう。

リモートストレージを含むストレージレイヤーの継続的な改善を本当に楽しみにしています。また、Project PrismやVulcanで採用されたアプローチが、Prometheusのコアにバックポートされることを期待しています。現在、私たちにとって最も興味深いトピックは、GCEサービスディスカバリ、より簡単なスケーリング、そしてはるかに長い保持期間（より冷たいストレージと古いイベントのクエリ時間が大幅に長くなるというコストを払ってでも）です。

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