ShowMax インタビュー

これは、Prometheus ユーザーへのインタビューシリーズの第2弾で、Prometheus の評価と使用の経験を共有してもらいます。

ご自身と ShowMax の事業内容について教えていただけますか？

アントニン・クラールです。ShowMaxの研究とアーキテクチャを統括しています。それ以前は、過去12年間、アーキテクトやCTOの職務を務めてきました。

ShowMaxは、2015年に南アフリカでローンチされたサブスクリプションビデオオンデマンドサービスです。20,000エピソード以上のTV番組や映画を含む広範なコンテンツカタログを持っています。現在、当社のサービスは世界65カ国で利用可能です。競合他社がアメリカやヨーロッパで激戦を繰り広げている中、ShowMaxはより困難な問題と戦っています。それは、サハラ以南のアフリカの、かろうじてインターネット接続がある村で、どうやってイッキ見を実現するかということです。すでに世界中のビデオの35%がストリーミングされていますが、この革命がまだ到達していない場所が数多く残されています。

CoreOSを中心に構築されたプライベートクラスター上で、約50のサービスを管理しています。これらのサービスは主にクライアント（Android、iOS、AppleTV、JavaScript、Samsung TV、LG TVなど）からのAPIリクエストを処理しますが、一部は内部的に使用されています。最大の内部パイプラインの1つはビデオエンコーディングで、大量の取り込みバッチを処理する際には400台以上の物理サーバーを占有することがあります。

バックエンドサービスの大部分はRuby、Go、またはPythonで書かれています。Rubyでアプリを書く際にはEventMachine（MRIではGoliath、JRubyではPuma）を使用しています。Goは通常、大量のスループットを必要とし、ビジネスロジックがあまりないアプリで使用されます。Pythonで書かれたサービスにはFalconを非常に満足して使用しています。データはPostgreSQLとElasticSearchクラスターに保存されています。リクエストのルーティングにはetcdとカスタムツールを使用してVarnishを設定しています。

Prometheus導入前のモニタリング経験はどのようなものでしたか？

監視システムの主なユースケースは次の通りです。

• アクティブモニタリングとプロービング（Icinga経由）
• メトリクス取得とこれらのメトリクスに基づくアラート作成（現在はPrometheus）
• バックエンドサービスからのログ取得
• アプリからのイベントとログ取得

最後の2つのユースケースは、当社のロギングインフラストラクチャによって処理されます。これは、サービスコンテナ内で動作し、ローカルのUnixソケットをリッスンするコレクターで構成されています。このソケットは、アプリが外部にメッセージを送信するために使用されます。メッセージはRabbitMQサーバーを介してコンシューマーに転送されます。コンシューマーはカスタム作成されたものか、hekadベースのものです。主なメッセージフローの1つは、サービスElasticSearchクラスターに向かい、Kibanaやアドホック検索でログにアクセスできるようにします。また、処理されたすべてのイベントをGlusterFSに保存し、アーカイブ目的やさらなる処理に利用しています。

以前は、2つのメトリクス取得パイプラインを並行して実行していました。1つはCollectd + StatsD + Graphite + Grafanaをベースとし、もう1つはCollectd + OpenTSDBを使用していました。どちらのパイプラインでもかなりの苦労をしました。GraphiteのI/Oの貪欲さや、OpenTSDBの複雑さと不十分なツールに対応しなければなりませんでした。

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

以前の監視システムでの問題を教訓に、代替となるものを探しました。最終候補に残ったソリューションは数少ないものでした。Prometheusは最初の候補の1つでした。当時、当社の運用責任者であったイジー・ブルンクラー（Jiri Brunclik）が、Googleの元同僚からPrometheusについて個人的な推薦を受けていたからです。

コンセプト実証はうまくいきました。非常に迅速に動作するシステムを構築できました。また、主要なシステムとして、そしてPrometheusの長期保存先としてInfluxDBも評価しました。しかし、最近の開発状況から、これはもはや当社にとって実行可能な選択肢ではないかもしれません。

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

当初は当社のサービスサーバーの一つでLXCコンテナを使用していましたが、すぐにHetznerの専用サーバーに移行しました。そこでは当社のサービスの大部分をホストしています。Intel® Xeon® E3-1270 v3 Quad-Core Haswellと32GB RAMを搭載したPX70-SSDを使用しており、Prometheusを実行するのに十分な能力があります。SSDを使用することで、保持期間を120日に設定できます。当社のロギングインフラは、ログをローカルで取得し（Unixソケットで受信）、様々なワーカーにプッシュするように構築されています。

このインフラが利用可能になったことで、メトリクスのプッシュは論理的な選択となりました（特にPrometheus以前の時代）。一方、Prometheusは主にメトリクスをスクレイピングするというパラダイムを中心に設計されています。我々は一貫性を保ち、当初はすべてのメトリクスをPrometheusにプッシュしたかったのです。そこで、prometheus-pusherというGoデーモンを作成しました。これは、ローカルエクスポーターからメトリクスをスクレイピングし、Pushgatewayにプッシュする役割を担っています。メトリクスのプッシュにはいくつかの良い点（例：サービスディスカバリの簡素化）がありますが、ネットワークパーティションとクラッシュしたサービスの区別が難しいなど、かなりの欠点もあります。prometheus-pusherはGitHubで公開していますので、ご自身で試してみてください。

次のステップは、ダッシュボードとグラフの管理に何を使用するかを決定することでした。Grafanaの統合は気に入りましたが、Grafanaがダッシュボードの構成を管理する方法はあまり好きではありませんでした。GrafanaをDockerコンテナで実行しているため、すべての変更はコンテナの外に保持する必要があります。もう1つの問題は、Grafanaに履歴追跡機能がないことでした。

そこで、gitで管理されているYAMLを受け取り、Grafanaダッシュボード用のJSON設定を生成するジェネレーターを作成することにしました。さらに、コンテナに保存された変更を必要とせずに、新しいコンテナで起動されたGrafanaにダッシュボードを展開することも可能です。これにより、自動化、再現性、監査機能が提供されます。

このツールが、Apache 2.0 ライセンスの下、GitHubでも利用可能になったことを発表できることを嬉しく思います。

移行後、どのような改善がありましたか？

すぐに目にした改善点は、Prometheusの安定性でした。以前はGraphiteの安定性とスケーラビリティに苦戦していたため、それが解決できたことは私たちにとって大きな勝利でした。さらに、Prometheusの速度と安定性により、開発者はメトリクスに非常に簡単にアクセスできるようになりました。Prometheusは、DevOps文化を取り入れる上で本当に役立っています。

当社のバックエンド開発者の一人であるトマシュ・チェレフカは、JRuby を使用してサービスの新しいバージョンをテストしていました。彼は、その特定のサービスのヒープ消費量を素早く確認する必要がありました。彼はその情報を瞬時に取得することができました。私たちにとって、このスピードは不可欠です。

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

PrometheusはShowMaxのモニタリングに不可欠なものとなっており、近い将来も使い続ける予定です。我々はメトリックストレージ全体をPrometheusに置き換えましたが、取り込みチェーンはプッシュベースのままです。そこで、Prometheusのベストプラクティスに従い、プルモデルに切り替えることを検討しています。

アラートについてもすでに試しています。このトピックにもっと時間をかけ、より洗練されたアラートルールを考案したいと考えています。