Observability Conference 2022、TVerによるNew Relic One導入事例を紹介

Observability Conference 2022から、動画配信サービスの株式会社TVerが導入したNew Relic Oneに関するセッションを紹介する。セッションを担当したのはTVerのSREである加我貴志氏だ。

動画：月間動画再生数 2億回を支えるTVerのオブザーバビリティ

TVerは民放キー局の番組をインターネットからスマートフォン、PC、コネクテッドテレビに向けて配信を行うサービスであり、月間動画再生数2億回、累計のアプリケーションダウンロード数は4000万を誇る。

TVerのインフラストラクチャーはAWS、バックエンドの開発はGo

TVerのインフラストラクチャーはAWSで実装されており、バックエンドの開発言語はGo、ソースコードの管理はGitLabという構成だ。動画そのものは外部のSaaS及びCDNから配信されているという。

AWSの中にFargateで実装されているアプリケーション

TVerはその成長に従って、システムのモニタリングだけではなく、ユーザーがどのような利用体験をしているのかを知り、問題が発生した際には迅速な対応及び解決ができるようにするため、オブザーバビリティが必要であることが明らかになってきたという。これを実現するために、オブザーバビリティのサービスであるNew Relic Oneを導入したというのが経緯だ。

サービスの成長に従って明らかになった課題

New Relic Oneを導入した理由の1番目に「強力なフロントエンドモニタリング」を挙げているが、これはスマートフォン及びブラウザーにおける観測が強力なことという意味だろう。またログからメトリクス、APM（Application Performance Monitoring）までカバーするプラットフォームであるというのがポイントだろう。

New Relic Oneを導入した理由を説明

New Relicのプレゼンテーションから引用する形でNew Relic Oneの優秀さを解説しているが、単にNew Relic製の独自のエージェントだけではなくオープンソースのオブザーバビリティソフトウェアからもテレメトリーデータを収集できる点は特に解説はされなかった。この点は、現時点でオープンソースのオブザーバビリティツールを使っているユーザーにとっては参考になる情報だろう。

New RelicのエージェントだけではなくOSSからもデータ収集が可能

New Relic Oneの導入は2021年12月ということで、発表時点までの運用期間は約3か月と短いが、この時点ですでに外形監視に加えてブラウザーエージェント、モバイルエージェント、インフラストラクチャーエージェントからテレメトリーデータが収集されていることがわかる。またAWSのインテグレーション部分のデータは一部だけが収集されていることも見てとれる。

2021年12月の導入状況

ここで「そもそもオブザーバビリティとは何か？」をNew RelicとGoogleの情報をベースに解説。New Relicの用語で言えば、MELT（Metrics、Event、Logs、Traces）を基本的なデータであるとして、それらをすべて計測することが必要だとしている。Googleからは、モニタリングは状況の監視、オブザーバビリティはシステムをデバッグするためのツールであると定義している部分を引用した。Googleが、運用においてもオペレーション（操作）ではなくコードで自動化しようとしていることがよく表れている解説だが、TVerにおいてGoogle的な自動化がどこまで達成されているのかは特に解説されていない。

Googleが考えるオブザーバビリティの引用

ここから初期のオブザーバビリティからの改善点として、AWSのインテグレーションデータをすべて収集すること、APMの追加、ログ管理の強化を行ったことを説明した。

オブザーバビリティの強化を実施

New Relic Oneをさらに活用することで、オブザーバビリティを改善したことを説明。開発言語であるGoのエージェントを使って、開発しているアプリケーションからより詳細なデータ収集が可能になったことを紹介した。またAPMからログへの検索を可能にするLogs in Contextを導入しようと計画したが、Longs in ContextについてはFargateからCloudWatch Logsにデータを流すことで代用したという。この辺りは開発スピードを止めたくないアプリケーション開発チームと、より詳細なデータを取るためにアプリケーションに手を入れて欲しいSREチームの駆け引きがあったことが想像できる。

Logs in Contextについては以下に示した約4分の動画が参考になるだろう。

参考：Troubleshooting Performance Issues With Logs in Context

結果として、オブザーバビリティについてはMELTのカバレッジが拡大したと説明した。この図表における数値はあくまでもエンジニアの肌感覚の数値であり、定量的な計測によるものではないことは留意されたい。

エンジニアがみたオブザーバビリティの改善の度合い

結果として当初から比べて多くの部分でオブザーバビリティが拡大しているという。

現状のNew Relic Oneの適用範囲を解説

次にAPMを導入した際のエピソードとして、Goで書かれたアプリケーションに対する変更の工数が多くなるという苦労を紹介した。結果としてはすべてのファンクションにNew Relic用のコードを挿入するのではなく、メインのファンクションだけに挿入することで、ある程度のデータは収集できることが判明したという。

APM導入時の苦労話を紹介

ここから実際にNew Relic Oneのダッシュボードのスクリーンショットを使ってAPMで可視化される情報について解説を行った後、その効果について解説を行った。

APMの効果を解説

APIのパフォーマンス改善、呼び出し回数と実行時間の可視化、エラー調査が速くなったことなどを挙げて、APMによってTVerのユーザー体験が改善できることを説明した。

またブラウザーモニタリング、モバイルモニタリングの効果についても、外部サービスから提供される動画配信SaaS関連のユーザー体験が可視化されたという利点を挙げた。

モバイルモニタリングで動画配信のユーザー体験を可視化

まとめとしてNew Relicが提唱するMELTデータ（Metrics、Events、Logs、Traces）を収集することが最優先であることなどを解説してセッションを終えた。

TVerのオブザーバビリティ（New Relic One）導入のまとめ

このセッションでは、オブザーバビリティの評価においてSLO/SLIなどの数値データの扱い、組織に関する解説に関しては特に解説がなかったが、New Relic Oneの導入事例としては良くまとまっていたのではないだろうか。オブザーバビリティをオープンソースソフトウェアだけで行うにはAPMがどうしても埋められない大きな穴となってしまうが、その部分にモバイルエージェント、ブラウザーエージェントを使うことで素早く効果を出したTVerの選択は正しかったように思える。