京都研究所・TechLabの石浦です。マイクロアドでは、広告配信システムの監視の整備に取り組んでいます。 最近では、社内にある監視基盤を活用し、広告配信システムから実際に配信されている広告そのものを監視対象にしながら配信が正常かをチェックするようにしています。 なお、監視基盤については以前ブログで紹介していますので、ご参照ください*1
外形監視と広告実配信
広告が表示されるまでには様々な手続きが行われていますが、その詳細は伏せて最終的な広告表示が正常に表示されているかだけをチェックしたいことがあります。 このようにシステムの内部状態を直接確認するのではなく、システムの外部から入力と出力の関係性に焦点を当てて監視するアプローチを外形監視と言います。
去年、自社の広告配信システムに対して、外形監視を行う仕組みを導入しました。 本番の配信を経由しなければ見つけられない不具合があるという問題に取り組むためです。
開発時の開発・ステージング環境は本番の広告配信とは広告の計測環境が異なるなどの条件が一致していなかったので、 計測環境も含めて一致させる環境を作るために自社SSPの本番サービスに自社のテストサイトの枠を追加しました。 さらに自社DSP（Universe Ads）のアカウントを使用し、この枠に常に広告を実配信させる環境を整えました。 この環境に対して、広告の配信が正常かを判定する監視を導入することになりました。
この形での外形監視では、「RTBー広告画像表示ークリック遷移」までの一連のフローをひとつのシステムとして捉え、システムの出力が期待される広告表示の結果と一致するかを定期的に監視し続けます。もし期待する動作と異なる場合は、アラートが飛び、エンジニアが問題を調査します。
また、広告表示の正常性を定期的にチェックし続ける監視のクライアント側は、実際のユーザの環境に似せて、ブラウザを用います。 ブラウザで、広告画像を定期的に表示し、広告をクリックし、遷移させたページの結果をチェックするプログラムを走らせることになります。
上の図のテスト環境と書かれている箇所に広告種別に応じた実配信用のページをそれぞれ用意しておき、 定期的にアクセスして監視用のデータを収集するアプリケーションを開発します。得られた収集結果をElasticSearchに蓄積し、ElastAlertで監視する部分は以前紹介した監視基盤の記事 *1 の説明通りです。 以下では、開発を少し振り返って内容を紹介します。
監視に何を使うか
広告のパターンに応じてテストサイトからデータを収集するプログラムを開発するため、まずはブラウザ操作ソフトウェアの選定から始めました。 ブラウザ操作には昔からあるSeleniumが代表的ですが、最近開発されたPuppeteerのようなChrome DevTools Protocol (CDP) を用いるNode.jsライブラリも選択肢に加えました。
Puppeteer について詳しく見たのですが、社内で使っている監視基盤がPythonを用いており、Node.jsよりもPythonで扱えるものが良いです。 その一方でPlaywrightというのがあり、これはPupeteerとほぼ同じ立ち位置で開発されているNode.jsライブラリですが、開発チームがPython versionを同時にリリースするという特徴があったので、Puppeteerを外してこちらを候補に加えました。 なお、SeleniumについてはWebDriverの仕様に沿ったSelenium Python binding が存在し、その実績も多いため候補に加えました。
- PythonからWebDriverのChromedriverを用いる案
- PythonからPlaywrightを使う。ブラウザはPlaywrightに同梱されているChromiumを使用する案
SeleniumとPlaywrightの調査
次に、開発要件を踏まえ、WebDriverを使用するSeleniumとCDP(Chrome DevTools Protocol)を用いるPlaywrightのどちらが適しているかを検討します。
開発要件としては「レンダリングされた広告画像のスクリーンショットを取る」「広告を自動的にクリックして遷移するのを確認する」などが考えられますが、これらは比較的簡単な要件なので、検討の際には一旦忘れ、以下の点に絞って考えました。
- アクセス時にダウンロードされるオリジナルの画像パーツをレンダリング前に記録したい（画像表示の問題を特定するため）
- 動画の再生完了後に結果を確認する
左側がオリジナルの画像で右側の赤く囲ったものがテスト広告で表示する画像です。ただし、右上のオプトアウトの箇所だけ異なります。
まず、オリジナル画像の記録ですが、レンダリング前の通信情報を取得するのはWebDriverの仕様では難しいことがわかりました。通信を記録するためにはBrowserMob Proxyという別のソフトウェアと連携する必要があります。一方、PlaywrightはChromeのDevToolsプロトコルを使っており、ネットワークリクエストを監視し、通信記録をHAR（HTTP Archive）形式で保存する機能があります。このHARには、base64でエンコードされたjpgやmp4ファイルが含まれているため、レンダリング前の情報を監視目的で記録するのが容易でした。
次に、動画の再生の正常終了の判定を検討しました。 はじめは気づきにくい点だったのですが、Chromiumはオープンソースで開発されているためライセンスに制限があり、一部の動画のコーデック（圧縮・解凍技術）を内蔵していませんでした。 最初はここの考慮がなくChromiumで動画を表示させようと奮闘しました。 Chromedriverだと動画コーデックを内蔵しているため動画は苦労せずに再生できました。 Playwrightは動画再生に関する問題が残っているものの、HAR形式で通信を記録する部分はPlaywrightの標準機能なので、ここは選択肢としてはプラス点です。 さらにPlaywrightのCDPを用いてChromedriverを操作するという少し変わった手順を試して再生を確認しました(起動オプションに --remote-debugging-port を追加します)。これがきっかけでChromium側を調べはじめたのですが、最終的に動画コーデックの情報にたどり着きました。
Playwrightから呼び出すブラウザをChromiumからGoogle Chromeに切り替えるには、channel という機能を利用します*2 。 これを行うとGoogle Chromeが呼び出され、動画の再生が無事確認できました。動画が正常に終了したかの判定はスクリプトで簡易的に行いました。 Playwrightのchannel方式は、ブラウザの起動・終了をPlaywrightが管理してくれて便利です。そのため、Google Chrome を監視環境にセットアップし、Playwrightを構成するという手順を選択しました。
Playwrightで監視の開発を進めてみて
外形監視の目的は、システムの出力が期待される結果と一致しているかどうかを確認することです。具体的には、レンダリングされた広告画像が予想される結果と同じかどうかを判定すれば良いです。画像のチェック自体は、画像のスクリーンショットのハッシュ値を比較するだけで十分目的を達成できました。このとき、下記の図の赤線で示したLoadイベントの発火タイミングを基準に画像のチェックを行っていたのですが、広告の種類によっては、そのタイミングではまだ画像の取得が完了していないケースがありハッシュ値のチェックでアラートが飛びました。
この問題に対応するため監視を改修し広告画像の取得が完了するタイミングを記録するようにしました。 この修正はHAR形式で記録された情報をもとに監視のロジックを調整するだけで可能でした。 このように、HAR形式で通信の情報を記録しておけば、様々な監視のロジックを実装できるでしょう。
またPlaywrightはプログラムで明示的にスクリーンショットを取得するのとは別に、内部で一定時間ごとにスクリーンショットを連続的に取得して、それを繋げて動画にする機能をもっています。 動画を保存しておくと、広告がどのように表示されているかや、画像の読み込みが遅延しているかなどの状況を、直接動画で確認できます。これにより、問題の状況を理解するのが非常に直感的です。
また、アラートの対象になるような想定と異なる結果が得られた時はデバッグ情報を監視側で残すようにしているのですが、 以下の画像の青枠に示したプログラムのコードの場所と赤枠のような実際の広告表示のタイミングが対応づけられた状態で閲覧できるTraceViewer*3というツールが提供されています。 これはタイミングに依存した問題を調査するのに非常に役立っています（赤枠の下側は遷移ページ先の画面表示になっています）。
最後に
自社で広告の配信をチェックするのにPlaywrightを使っているという内容の紹介でした。 Playwrightはサイトにアクセスして色々な情報が取得できるので監視や調査の用途には強力なツールになるでしょう。 ウェブサイトにアクセスし、何らかの監視を必要とする人にとって、Playwrightを選択肢の1つとしてご検討いただければ幸いです。
