この記事は TVer アドベントカレンダー 2024 10日目の記事です。
こんにちは、TVer 広告事業本部でインフラエンジニア・SRE をしている髙品です。 9日目の記事は @smizuno2018 の 独自実装した FeatureFlag によるシステム移行でした。
10日目の記事では、TVer 広告プロダクト開発タスクの SRE になってからの1年間を振り返り、2024 年の SRE の取り組みを点検しつつ、2025 年の SRE の取り組みを考えてみたいと思います。
まえがき
個人的なことですが、私が TVer 広告プロダクト開発タスクに参加したのは 2023年11月なので、この記事を書いている時点で TVer に入社してから丸1年以上経過しました。昨年 TVer のアドベントカレンダーに参加して New Relic の Change Tracking を紹介する記事*1を書くついでに、私が理想とするチームの在り方について語っていたのですが、今年もアドベントカレンダーの季節がやってきて、昨年語った理想にどれだけ近づけたのか振り返ってみたくなりました。
このような思いつきから記事を書くことに決めて1年間の業務を振り返ってみたところ、あるシステムの新規開発段階から New Relic の利用を推進したことで負荷試験が捗ったことを思い出しました。New Relic のおかげでボトルネックを容易に特定することができたという体験を提供できたことで New Relic に関心を持ってくれる開発者が増えました。昨年のアドベントカレンダーに書いていた、チームメンバー全員で New Relic のダッシュボードを見るという理想が近づいてきています。自画自賛は気後れしますが、このエピソードによって私は2024年の自分の仕事に一定の満足感を得ることができました。
入社から間もない頃に語った理想に近づけていることが分かって良かったのですが、自己満足な振り返りだけだと記事がここで終わってしまうので、この記事では以下について書いてみることにします。
- New Relic に関心を持ってくれる開発者が増えた経緯
- 2024 年の SRE の取り組みを点検し、2025 年の SRE の取り組みを考える
New Relic に関心を持ってくれる開発者を増やせた経緯
先に New Relic を利用してボトルネックを容易に特定することができたおかげで New Relic に関心を持ってくれる開発者が増えたと書きました。しかし、昨年アドベントカレンダーを書いたときは New Relic に関心がある開発者はほとんどいなくて、どうすれば関心を持ってくれる開発者が増えるか考えている状況でした。ちなみに、New Relic に関心を持ってくれる開発者を増やしたい理由は昨年のアドベントカレンダーに書いていて、当時から全く考えを変えていません。以下が理由です。
私は、信頼性と生産性を共に最適化できるチームにおいて、システムの状態はメンバー全員の関心事であるべきだと考えているので、チームの全員にNew Relicの画面を見てほしいと思っています。そこで、チームでNew Relicのダッシュボードを見て、アプリケーションのレイテンシーやスループット、エラー率といったパフォーマンス指標の傾向を知ることでシステムの状態を把握する定点観測の時間を作ろうとしています。いずれは、SREのサービスレベルの考え方をチームのシステム運用に導入することを見据えての活動です。
オブザーバビリティツールに限らず、チームに何かツールを紹介して使い始めようというときは、そのツールが便利であるとか、役に立つのであるとか説明するだけではなかなか使ってはもらえないもので、利便性を実感してもらうことがツールの導入において重要ですが、ツールの価値を理解するきっかけになる出来事はそう都合よく降ってきません。実際、昨年アドベントカレンダーで紹介した Change Tracking は、開発者に New Relic の利便性を実感してもらうには至りませんでした。
広告プロダクト開発タスクにおいて、New Relic に関心を持ってくれる開発者が増えたきっかけは負荷試験でした。この記事の主題ではないので負荷試験の詳細は省きますが、記事を分かりやすくするために、負荷試験において New Relic を利用してボトルネックを容易に特定できたエピソードを簡単に紹介します。
ログ書き込みがボトルネックになっていた
広告プロダクト開発タスクでは、2023年10月から2024年11月にかけて新しいシステムを開発してきました。どのようなシステムであるかはこの記事で書きたいことに関係ないので省略しますが、TVer の広告事業にとって非常に重要なシステムです。このシステムにはレイテンシー・スループットに関する明確な性能要件が存在していたので、負荷試験を実施して要件を満たせているか検証する必要がありました。
負荷試験は約半年間も続き、レイテンシーの目標を達成できないが、ボトルネックがどこにあるのか分からない状況に度々直面しました。アプリケーションは GKE で動いており、GKE の Pod, Node の CPU 使用率や、外部データベース（Memorystore, Bigtable）との通信時間に問題がないにも関わらず、アプリケーションのレイテンシーが遅くなり、ひどいときはロードバランサーでタイムアウトして 504 エラーが発生したりすることもありました。
そのような状況でボトルネックの調査に利用したのが、New Relic APM のトランザクショントレースです。負荷試験の対象となっているアプリケーションは Go 言語で書いているので、New Relic APM の Go agent をアプリケーションにインストールして、処理時間を計測するためのコード*2をアプリケーションに書き加えていきました。
トランザクショントレースによって、アプリケーションのどの処理で時間がかかっているか可視化されたことで、レイテンシーのボトルネックを容易に特定できるようになりました。いくつかのボトルネックがありましたが、特に印象に残っているのがログ書き込みがボトルネックになっているケースです。
以下は New Relic APM で取得できた、あるトランザクショントレースです。トランザクションとセグメントの名前は隠しています。極端に遅いトレースをピックアップしているのですが、ログ書き込み全体で 100 秒もかかってしまっています。この記事はログ書き込みが遅くなる原因と対処方法を書くことが目的ではないので、どのようにして改善したのかは書きませんが、APM でトランザクショントレースをとってみるまでは、まさかログ書き込みがボトルネックになっているとは想定していなかったので非常に驚きました。
ログ書き込みが遅くなる原因は常に同じではなくて、ログ書き込みがボトルネックになる度にロギングライブラリを直したり、GKE の構成を変更したり、と色々なことをやりましたが、そのような手を打てたのは New Relic APM でアプリケーションのボトルネックを可視化できたからです。このような体験があったおかげで、開発者が New Relic の利便性を実感でき、結果として New Relic に関心を持ってくれるようになったと考えています。
2024 年の SRE の取り組みを点検し、2025 年の SRE の取り組みを考える
2024 年は、New Relic に関心を持ってくれる開発者を増やそうとし、個人的には満足のいく結果を得ることができました。ところで、2024 年に私がやってきた SRE の取り組みは、個人や組織が SRE を開始し、成熟度を高めていく正しいやり方だったのでしょうか。
「私はサイトリライアビリティエンジニアリングを仕事にしている」と意識をして、実際 SRE という肩書のエンジニアになってから 3 年が経つので、慣れやこれまでの経験の反復で仕事をしていないか？と考えることがあります。そこで、仕事のやり方を間違えていないか、今年の 10 月に刊行された『SREをはじめよう 個人と組織による信頼性獲得への第一歩』*3を頼りにして点検しつつ、2025 年の取り組みを考えてみます。
『SREをはじめよう』の 14 章で Dickerson の信頼性の階層構造が紹介されています。階層構造は階層の一番下から始めて、下の階層が「強固」とみなされるようになった時点で初めて上の層に進むというものです。
監視/オブザーバビリティが第1階層である理由を本では次のように述べています。
第一階層は、もっとも簡潔に言えば「状況は良くなっているのか、それとも悪くなっているのか」ということです。監視は、システムの信頼性に関する客観的なデータや、あなたの取り組みが信頼性に及ぼしている短期的・長期的な影響に関する最良の情報源です（あるいは、そうあるべきです）。あなたが行った変更（新しいソフトウェアのバージョン、構成の変更、環境の修正など）が、システムの信頼性にプラス、マイナス、あるいは中立の影響を与えているかどうかを判断するために必要です。次に向かうべき方向を理解するのに役立ちます。*4
監視/オブザーバビリティ基盤に蓄積されるデータが間違っていると、システムの信頼性について正しい判断ができない、という言説はその通りであると思います。
さて、点検結果について書きます。2024 年の広告プロダクト開発タスクにおける SRE の取り組みは、信頼性の第1階層を強固にするために役に立っていると思われるので、私の仕事は間違っていなかったと言ってよいと思います。なぜなら、負荷試験を通じて開発者が New Relic に関心を持ってくれるようになったことは、監視/オブザーバビリティ基盤を強固にするためにプラスに働くと思うからです。システムの信頼性に関する判断を下すための最良の情報源であるところの New Relic が、開発者にとっての関心事でなかったら、信頼性の階層構造を積み上げていく以前の問題です。
最後に、2025 年の SRE の取り組みについて書きます。2025 年の SRE の取り組みは、引き続き信頼性の第1階層の監視/オブザーバビリティを強固にしていくことだと考えます。New Relic に関心を持ってくれる開発者が増えたことで、私だけではなく、チームで New Relic を最良の情報源にしていく準備ができました。
監視/オブザーバビリティを強固にしていくためには、データの収集、可視化、分析のサイクルを回して改善を続ける必要があると考えます。そのために、2025 年はパフォーマンス定点観測会を始めます。これは、昨年のアドベントカレンダーに実現したいことの1つに挙げていたもので、週1回システムダッシュボードを確認してメトリクスのトレンドを把握し、1週間のイベント（デプロイ, アクセスパターンの変化など）とメトリクスの相関関係の有無を確認する定例です。定期的にダッシュボードを確認することで、不足しているメトリクス, ログ, トレースを見つけたり、メトリクスの統計を見直したりなど、監視/オブザーバビリティを強固にするために必要なアクションを発見することができます。
また、定期的なダッシュボード確認によってシステムメトリクスのトレンドを把握することは、システムの信頼性に関する正しい判断を下すことに繋がり、さらにはインシデント対応の質を向上させることにも繋がると考えています（第2階層の取り組み）。インシデントが発生したときには各種メトリクスを必ず見ることになりますが、それらのメトリクスが普段どのように推移しているのか知っているのと知っていないのとでは、対応に大きな差が出ます。普段からメトリクスを良く見ていると、ちょっとした違和感から問題解決につながる気づきが得られるものなのです。
あとがき
2024 年は新しいシステムの開発・構築に注力していて、AWS / Google Cloud のアーキテクチャ設計とインフラ構築、バックエンド開発、負荷試験をやっていたので、システム運用はほとんどやっていませんでしたが、2025 年からは新しいシステムを安定運用することが最重要業務になります。記事作成を通して 2024 年を振り返ってみたら意外とシステム運用に向けた準備ができていたことが分かり、2025 年の SRE の取り組みを考えることもできたので、今年もアドベントカレンダーに参加してよかったなと思います。
