はじめまして、エンジニアの黒瀬と申します。
弊社では、これまでバックエンドの監視にNew Relicを利用してきましたが、今回データ基盤にも導入を開始しました。
この記事では、その経緯についてご紹介したいと思います。
背景と課題
弊社ではTVerのサービス利用状況を日々収集し、それをBigQueryを中心としたデータ基盤に集約・可視化することで、日々のサービス改善に活用しています。
このプロセスは、おおむね次のような役割分担となっています。
これらのうちデータチームでは、集約処理を構成するバッチごとにアラートを実装していましたが、下記のような問題がありました。
バッチごとに異なった方法でアラートを実装していたため、保守がしにくい
アラートの通知先が散らばっており、毎回メンバーに周知する必要があるため、スケールしない
方針
そこで、既にバックエンドチームで導入されていたNew Relicを導入することで、アラートを共通化することにしました。
これによって、上記の課題を次のように解決することをねらいました。
集約処理では、アラートの対象となるログをCloud Loggingに出すだけで済むようにすることで、統一的な方法でアラートが設定できるようにする
アラートの通知先を一か所にまとめることで、新しいバッチが実装されてもそこだけを見ておけばよいようにする
構成
GCPからNew Relicへのログ送信には、New Relicへのログ転送用URLとPub/Subの連携を利用しました*1。
Cloud LoggingのSinkにPub/Sub Topicを指定し、そのTopicの宛先としてインジェストURLを指定することで、GCPのログをNew Relicに転送することができます。
そして、GCPから送られたログに対してNew Relicでアラートを設定し、そのアラートの通知先を一つのSlackチャンネルに集約するようにしました。
実現できたこと
今回の施策により、バッチとしてはCloud Loggingにエラーログが出しておくだけで済むようになり、また通知先も一つにまとめることができました。
例えば、バッチを実装しているCloud Runのエラーを下記のように通知させています。
今後について
今回のNew Relic導入を礎にして、今後はさらに監視を改善すべく、下記についてSREと検討中です。
- データシステムのメトリクス監視: 現状、メトリクス監視はバッチを構成するCloud Run Serviceなどのリソースごとにコンソールから確認していますが、こちらについてもNew Relicに統合していこうと考えています。
- データシステムを俯瞰するダッシュボード構築: 収集から集約に至るまでの各箇所において、システムの正常性を統一的に俯瞰できるようなダッシュボードの構築を考えています。
お知らせ
TVerではシステムを一緒に開発するエンジニアを募集中です。ご連絡をお待ちしております！
