こんにちは。Yahoo!広告 ディスプレイ広告エンジニアの川崎です。
ユーザーに最適な広告を配信するプラットフォームの開発をしています。

この記事では、広告配信にTensorFlow Servingを導入して生産性改善した事例をご紹介します。

Yahoo!広告 ディスプレイ広告とは？

Yahoo!広告では、Yahoo! JAPANのさまざまなサービスや提携パートナーサイトに広告を掲載できます。Yahoo!広告は、検索広告とディスプレイ広告に大別されます。本記事で扱うディスプレイ広告は、例えば以下の図ようにYahoo! JAPAN トップページなどに掲載される広告です。

広告配信の仕組み

広告配信システムの概略図を以下に示します。

広告配信サーバーは広告リクエストごとに

• ユーザーの興味関心度合い
• 広告効果
• メディア収益性

を考慮した最適な広告を選びます。具体的には、広告主が設定した入札額と広告スコアを使ってランキングして配信する広告を決定します。広告スコアは、ユーザーと広告の関連度合（相性）を数値化したもので、機械学習モデルを使って算出されます。

広告配信ログやユーザーの広告に対するアクションログは、Message Queue経由でHadoopへ蓄積されます。モデル学習サーバーは、Hadoopのログを集計しモデルのパラメータを出力します。出力したモデルパラメータは、全社ストレージサーバーへアップロードします。アップロードされたモデルパラメータは、広告配信サーバーが取得して広告配信に利用します。広告配信サーバーにはモデルのアルゴリズムが組み込まれており、全社ストレージサーバーから取得したモデルパラメータと組み合わせて広告スコアを計算します。

広告スコアを計算する機械学習モデルの精度によって、ユーザーの興味関心度合い・広告効果・メディア収益性に影響を与えるため、日々改善を行っています。改善のために、複数のABテストを並行して実施しています。モデルのABテストイメージを以下に示します。ユーザーをAとBに分けてそれぞれに対応するモデルを割り当てて、ユーザー群ごとのKPIを比較してモデルの改善を行っています。

広告配信のABテストにおける課題

しかし、以前はABテストまでの工数が高いことが課題となっていました。実際に以下のような工程で検証サイクルを回していました。

システム概略図のように、モデルのアルゴリズムが広告配信サーバーに組み込まれており、アルゴリズムやパラメータを修正するたびに広告配信サーバーの開発・試験・デプロイが必要でした。広告配信サーバーは、モデル以外のさまざまな機能を持っていたため、開発やデプロイに時間がかかっていました。 さらに、度重なるABテストで古いモデルのアルゴリズムが蓄積されソースコードの保守コストが増加していました。

そこでこれらのコスト削減のため、モデルのアルゴリズムとパラメータを広告配信サーバーから切り出すことを考えました。モデルをマイクロサービス化することで、スケーラビリティ向上につながると考えました。他社事例や自社技術との相性の良さを検討したところ、TensorFlow Servingを採用することにしました。

TensorFlow Serving導入にあたり、これまで利用してきた機械学習ライブラリからTensorFlowライブラリに乗り換えることにしました。TensorFlowライブラリへの乗り換えは、従来のアルゴリズムが流用できたため問題ありませんでした。加えて、ニューラルネットワークのアルゴリズムが利用できるため、改善の打ち手を増やすことができると考えました。

TensorFlow Servingとは

TensorFlow Servingは、Googleが開発したOSSで、プロダクション環境向けに機械学習モデルをAPI経由で提供できます。具体的には、TensorFlowモデルのアルゴリズムとパラメータを1つにまとめたSavedModelファイルをホスティングすると、それがサーバー上で動くようになり、他のシステムからAPIとして使えます。実際にGoogleでも導入されているようです。

TensorFlow Servingの導入

下図のようにモデルの処理を全てTensorFlow Servingに切り出しました。これによりモデル学習サーバーがSavedModelファイルを更新すれば、モデルのアルゴリズムとパラメータが全て更新され、広告配信サーバーの開発やデプロイが必要なくなりました。

導入にあたって苦労したこと

TensorFlow Servingは素晴らしいソフトウェアですが、広告配信に導入する上でいくつかシステム上の課題がありました。これらの課題を解決するためにTensorFlow Servingのソースコードに修正を加えることにしました。実際の修正内容は、OSSへのPull Requestのリンクを併記していますので、ご参照ください。

REST APIの通信量削減

TensorFlow ServingはREST APIを提供していますが、生のJSONしか扱えずクエリが肥大化していたため、ロードバランサのキャパシティーが不足していました。

そこでREST APIでprotocol bufferでシリアライズした文字列を扱えるよう修正しました。これにより、約40％クエリサイズを削減でき、通信のレイテンシも改善できました。
Pull Request - Supports serialized POST body messages in protocol buffer format（外部サイト）

監視メトリクスの拡充

TensorFlow ServingはPrometheus APIを提供していますが、メトリクス項目の種類が少なく、本番環境で運用するには不安がありました。

そこで、Prometheus APIに本番環境で必要なメトリクス項目を追加しました。具体的には、モデル別の処理レイテンシやリクエストの成功・失敗数などを追加しました。広告配信では高いサービス水準が求められ、モデルのレイテンシや可用性が重要な指標になります。メトリクスを追加したことで、システムに異常があったときにアラート検知できるようになりました。
Pull Request - Add metrics to the Prometheus API（外部サイト）

モデルのインターフェース互換性維持

TensorFlow Servingは、クエリの特徴量とモデルで利用する特徴量のインターフェースが完全一致していないとリクエスト失敗とみなします。モデル改善する上で、特徴量の追加や削除は頻繁に行われるため、クエリのインターフェースに柔軟性を持たせたいと考えました。

具体的には、モデルが最低限必要とする特徴量さえあれば、クエリが受け付けられるようにしました。広告配信サーバーはTensorFlow Servingへ利用可能な特徴量を全てクエリで送り、実際に特徴量を利用するかどうかはモデルに委ねられるようになりました。これにより、モデルで利用可能な特徴量の取捨選択の度に広告配信サーバーの開発をしなくてよくなり、検証を効率的に進められます
Pull Request - Loosen model interface checks（外部サイト）

改善した効果

TensorFlow Servingの導入によって、改善サイクルに必要な工程を削減できました。具体的には下図の灰色の工程を削減できました。モデルのアルゴリズムやパラメータの検証時に、広告配信サーバーの開発・試験・デプロイが必要なくなりました。

実際に約45％工数削減でき改善サイクルの回数が増加しました。また、改善サイクルを重ねたことによって売上向上に貢献することもできました。

その他、TensorFlow Servingで便利だと感じた点としては、S3 APIによるモデル更新機能が備わっており、S3互換のWeb APIを備えた社内ストレージとの相性が良かったことです。定期的にストレージサーバーの更新をチェックして取得する機能を開発せずに済んだのは楽でした。

まとめ

TensorFlow Servingの導入によって、生産性改善と売上向上に貢献することができました。

現在、ディスプレイ広告の広告スコアは全てTensorFlow Serving上のモデルで計算されています。また、広告スコア計算だけでなく、ユーザーの属性推定などにも同様の仕組みが用いられています。

今後もこの仕組みで機械学習モデルの改善サイクルを回していきたいと考えています。本記事が、機械学習モデルの本番運用事例として参考になれば幸いです。

写真：アフロ