Prometheusユーザーへのインタビューシリーズを続け、今回はJustWatchがどのようにモニタリングを確立したかについて話を聞きました。
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ランタイム）のすぐに使えるメトリクスは、非常に迅速に投資収益率を上げるのに役立ちました。goroutineメトリクスだけでも、何度も危機を救ってくれました。以前実際に気に入っていた唯一のモニタリングコンポーネントであるGrafanaは、Prometheusに自然に適合し、非常に役立つダッシュボードを作成することができました。Prometheusが車輪の再発明を試みるのではなく、 むしろ既存の最良のソリューションに完全に適合していることを高く評価しました。先行製品に対するもう1つの大きな改善点は、Prometheusが実際に計算を正しく行うことに焦点を当てていることです（パーセンタイルなど）。他のシステムでは、提供される操作が理にかなっているかどうか、確信が持てませんでした。特にパーセンタイルは、マイクロサービスのパフォーマンスについて推論するための自然で必要な方法であるため、それらが最優先事項として扱われていることは素晴らしいと感じました。
統合されたサービスディスカバリにより、スクレイプターゲットの管理が非常に容易になります。Kubernetesの場合、すべてがそのまま動作します。まだKubernetesで実行されていない他のシステムでは、Consulベースのアプローチを使用しています。Prometheusによってアプリケーションを監視するには、クライアントを追加し、`/metrics`を公開し、コンテナ/ポッドに1つの簡単なアノテーションを設定するだけです。この低結合により、開発と運用の間の摩擦が大幅に軽減されます。多くのサービスは、シンプルで楽しいので、最初からうまく調整されて構築されています。
時系列と巧妙な関数の組み合わせにより、素晴らしいアラート機能が実現します。サーバー上で実行される集計、時系列、それらの組み合わせ、さらにはそれらの組み合わせに対する関数までもが第一級オブジェクトとして扱われるため、アラートが簡単になります。多くの場合、事後的にです。
JustWatchとPrometheusの将来はどのようなものになると考えていますか？
Prometheusは、派手であることではなく、実際に機能し、デプロイと運用が reasonably easy であると同時に価値を提供することに焦点を当てていることを高く評価していますが、特にAlertmanagerはまだまだ改善の余地があります。フロントエンドでインタラクティブなアラートの作成と編集を簡素化するなど、簡単な改善だけでも、アラートの操作がさらに簡単になります。
リモートストレージを含む、ストレージレイヤーの継続的な改善に本当に期待しています。Project PrismとVulcanで採用されているいくつかのアプローチが、コアPrometheusにバックポートされることも期待しています。現在、私たちにとって最も興味深いトピックは、GCEサービスディスカバリ、スケーリングの容易化、および（コールドストレージと古いイベントのクエリ時間がはるかに長くなることを犠牲にしても）はるかに長い保持期間です。
また、Prometheusを技術以外の部門でも使用することを楽しみにしています。Prometheusを使用してKPIのほとんどをカバーし、誰もが美しいダッシュボードとアラートを作成できるようにしたいと考えています。現在、新しい社内ビジネスプロジェクトにも素晴らしいアラートエンジンを悪用することを計画しています。乞うご期待！