マイクロアドの RTB 開発チームに所属しており, 普段は『Universe Ads』や『COMPASS』などの広告配信アプリを開発している酒井です。この記事では、普段広告配信アプリの開発をしている際に発生する問題への対処や、その時に用いるツールに関して紹介します。

RTB に関して

私たちは普段 RTB 開発チームで RTB (Real Time Bidding) の開発をしています。ここではまず RTB に関して軽く触れることができればと思います。 RTB は、リアルタイムに Web ページから送られてきたリクエストを元に広告を返す処理をするアプリケーションで、私たちが普段見ている Web ページで様々なコンテンツを表示するまでに広告の通信を完了しておく必要があるため数十ミリ秒でのレスポンスが求められます。そんなRTBを24時間止めることなく日々新たな機能の開発をしていますが、仕様上は問題なく動作していても、その日の広告在庫やユーザのリクエスト数に応じて負荷などの状況は変わり、突然問題が起こったりすることはアプリ開発あるあるです。その際に我々が使っている調査の方法やツールの一部をこの記事では紹介します。

もっとRTB開発チームについて知りたい方はこちらの記事もぜひご覧ください。マイクロアドの広告配信アプリ開発チーム「RDU」を新卒視点で語りたい記事

ログ

まずは基本的なことですが、ログについて説明します。アプリケーションでは常に様々なログを出しており、処理中に発生したエラー理由はもちろんのこと、DB から正常にデータを取得できたことを知らせるログやその時の広告在庫数のログなど、異常系のログだけでなく正常系のログも出ています。また、一時的に設定を切り替えることで現状受けているリクエストと、それに対応するレスポンスの内容など、より詳細な情報をだすこともできるようになっています。また、アプリケーションのログ以外にも RTB では処理速度が非常に重要となるため、マクロを仕込み、各メソッドの処理時間に関するログも出していたりします。マクロに関してはこちらの記事をご覧ください。Scala マクロアノテーションに入門するための準備体操

可視化

上記で出力したログは社内の監視基盤の方に転送され、異常なログがないかの検知や、どのようなログが出ていたかの可視化などがされています。例えば突然レスポンスが遅くなった場合、可視化されたログを確認することで、過去のどの時間帯にどのような異常が発生したかの調査が楽になっています。監視・可視化に関してはこちらの記事をご覧ください。 UNIVERSE Adsの監視基盤

メモリ

一時的に使うスクリプトのようなものなどであればあまり問題になりませんが、RTB のように 24 時間 365 日稼働し続けるようなアプリケーションですと、例えばアプリ起動直後は問題ないが、一週間経つと突然 OutOfMemoryError が発生してアプリケーションが落ちてしまうなどということがあります。この際、何かのオブジェクトが解放できず膨れている場合が多いですが、リリースの頻度が高い場合どのタイミングの修正でそのようなバグを含ませてしまったかを特定するのは大変です。そこで弊社では JFR(Java Flight Recorder) を使い、メモリを確保しているオブジェクトやそれに紐づくクラスなどから逆算していきバグの発生場所の特定を行っています。

以前は Memory Analyzer を使った調査を行っていましたが、最近ではほぼ全て JFR で調査が可能なのでかなり便利になりました。

Java Flight Recorder

以前は複数のツールを使って CPU やメモリの調査をしていましたが、Java 8u262 以降から JFR (Java Flight Recorder) が利用可能になったので非常に楽になりました。主に JDK Mission Control を用いてアプリケーションに接続し、JFR を使用しています。

CPU

CPU の使用率などに関しても 100% で頭打ちになってしまったり、スレッドの占有などが発生すると処理がつまりレスポンス速度の悪化につながるので気にする必要があります。直近では、以下のように定期的なタイミングで CPU の使用率がスパイクしていることが発見されました。該当時間のログを調査したところ、MySQL からの定期的なスケジュール実行されている処理のタイミングと一致していることがわかり、仕様を満たす形で処理の流れを少し変更することで CPU 使用率を下げることができました。