京都研究所・TechLabの田中です。マイクロアドでは、先日正式提供を開始した*1UNIVERSE Adsの開発と並行して、UNIVERSE Adsのサービス監視用の基盤も整備してきました。
今回はそんなUNIVERSE Adsの監視基盤の概要をご紹介します。
サービス監視の必要性
UNIVERSE Adsは、24時間365日稼働しており常に大量のトラフィックを高速に処理する大規模システムです。このシステムは、互いに疎結合な関係にある100個以上のコンポーネント（マイクロサービス）から構成されています。そのUNIVERSE Adsがサービスとして正常に機能していることを常に監視するには、ヒトによる目視確認だけは到底不十分で、監視用のシステムが必要です。
さらに、サービスとしての状態を監視するためには、定期実行されるバッチ処理の成否やサーバーの死活監視といったシステム視点の監視だけでは不十分です。アプリケーションのログやミドルウェアのデータを収集した上でサービスの状態を監視する必要があります。
このような監視システムを導入することで、サービスに障害が発生しても素早く検知することができ、「ビジネス側から開発チームへの問い合わせがあって初めて障害が発覚する」といった事態を防ぐことが期待できます。
監視対象となるサービスの構成
監視対象であるUNIVERSE Adsは、図1のようなシステム構成となっています*2。
この中から、サービスの状態を知るために重要な監視箇所を抽出します。そして、対応するアプリケーションのログやミドルウェアのデータを収集し、監視基盤に蓄積していきます。
サービス監視の方針
システムの中でもユーザーに近いところから優先して監視を追加していきました。ここでいうユーザーとは、主にDSPの利用者（社内のビジネスサイドのメンバー/広告代理店/広告主）や、UNIVERSE Adsの接続先SSPのことを想定しています*3。
上図の中でユーザーに近いところとは、基本的にデータフローの終端部分が該当しますが、それに加えて特に重要な機能を担うコンポーネントなども対象となります。
このような観点から、監視するのは各コンポーネントの（内部の挙動ではなく）インプットとアウトプットが中心になります。
また、監視の仕組みがサービスそのものに影響することが無いようにするため、監視基盤はUNIVERSE Adsのシステムから独立した構成をとるようにしました。
監視基盤の構成
UNIVERSE Adsの監視基盤はこのような構成となっています。
監視対象となるシステム（図中のUNIVERSE Ads）に対して、データの収集・ストレージ・可視化・アラート・監視の監視といった要素で構成されます。
監視基盤を開発するにあたって、『入門 監視――モダンなモニタリングのためのデザインパターン』を参考にしました*4。
データの収集
サービス監視のためには、UNIVERSE Adsを構成するさまざまなアプリケーションのログやミドルウェアのデータを収集する必要があります。そのために、データ収集用のPython製アプリケーションを社内で開発しました（下図）*5。
RTBを行う広告配信サーバーや、広告表示・クリックなどを計測する計測系サーバーは、扱うトラフィックが大量にあるためアプリケーションログやアクセスログは膨大な量になります。
そのため、これらは監視基盤のストレージ（後述）に直接転送するのではなく、fluentdを利用してKafkaに投入しています。このKafkaからデータ収集アプリがKafkaのConsumerとしてデータを取り出します。生ログのままでは量が多すぎるため、監視するのに必要十分な粒度に集計した上でストレージに蓄積します。
サーバーのログ以外にも、HDFSやRedis、MySQL、Spark、GCSといった様々なミドルウェアから監視のためのデータを収集します。基本的にミドルウェアのデータはAPIで直接取得した上で、データ量と監視目的に応じて、生データのまま蓄積する場合と集計して蓄積する場合があります。
ストレージ
監視用データのストレージにはElasticsearchを利用しています。
今回の監視では、アクセスログやアプリケーションログに加えてRedisやMySQLなどの各種ミドルウェア上のデータまで、様々な種類のデータが監視対象となります。また、大規模なデータの増加にも対応する必要がありました。
Elasticsearchはデータを高速に検索することができ、スキーマの設計も柔軟に対応できます。Elasticsearchのこのような特性は、今回の利用用途に適していました。
監視目的のデータストレージで重要なのはリアルタイムに近いデータであり、過去のデータを長期間保存する必要はありません。そのため、indexごとに有効期限を設定したり、一定期間経過後にロールアップして別indexに移すなどして、データの容量を調整しています。
可視化
可視化にはKibanaを使用しています。KibanaもElasticsearchも同じElastic Stackのプロダクトなので、Kibanaを使うとElasticsearch上のデータを非常に簡単に可視化することができます。
上図のようなダッシュボードを用途ごとに作成しておき、アラート発報時の確認などに利用しています。
アラート
アラートはElastAlertを使ってSlackに通知するようにしています。
通知先のチャンネルは「#universeads-critical」「#universeads-warn」「#universeads-notice」の3種類を用意しており、障害のレベルに応じて使い分けています。
状況がすぐ把握できるように、アラートメッセージの中にもある程度詳細な情報が表示されるようにしています。
一方で、アラートのタイトルにKibanaのダッシュボードへのリンクを埋め込んでおり、ワンクリックでより詳細な状況（時系列に沿った変化など）を確認できるようにもなっています。
また、監視の要件の中には、ElastAlertのデフォルトの監視ルールでは対応できないものもありました。こういったケースには、独自の監視ルールを開発して対応しました*6。
監視の監視
監視の主な構成要素は、これまで説明してきたデータ収集・ストレージ・可視化・アラートですが、これらからなる監視の仕組みもまた、正常に動いていることを監視する必要があります。
そのために、データの収集処理の挙動や、ストレージの状態、アラートアプリの動作などを中心に監視する仕組みとして「監視の監視」を導入しました。
ツールはPrometheusとGrafanaを使用しており、「監視」の基盤とは別のインフラ上で運用しています。「監視」と「監視の監視」を互いに独立した環境に置くことで、障害などによりどちらも機能しなくなるリスクを減らす意図があります。
最後に
この記事では、UNIVERSE Adsの監視システムの概要を説明してきました。
監視基盤開発で用いた技術の詳細や運用上の工夫など、紹介しきれなかったことも多々ありますが、また別の機会に紹介していければと思っています。
また、監視は一度開発したら終わりというものではなく、継続的な改善が必要不可欠です。今回紹介したUNIVERSE Adsの監視基盤でも、運用しながら見えてきた課題を洗い出し、より良い監視を実現するための取り組みを続けています。
*2:この図は監視対象の概略を示すものであり、実際のシステム構成を正確に描画したものではありません
*3:DSPやSSP、RTBといったアドテクの基本的な概念の説明は、過去記事の 行動データを用いた広告コミュニケーション 行動ターゲティングからフルファネルマネジメントへ - MicroAd Developers Blog や、 RTBにおける落札額・落札確率予測 - MicroAd Developers Blog をご参照ください
*4:京都研究所内でこの本の輪読会も行いました
*5:このアプリを社内では universe-ads-metrics-collector と呼んでいます。
*6:作成した監視ルールの一例をこちらの記事で紹介しています: ElastAlertでカスタムルールを作成する - Qiita
