MicroAd Developers Blog

マイクロアドのエンジニアブログです。インフラ、開発、分析について発信していきます。

QPS制御の仕組みの改善

こんにちは。京都研究所・Tech Labの郭です。 今回は、マイクロアドが提供するCOMPASS(SSP1)の中に、取り組んでいるQPS制御仕組みの改善を紹介します。

COMPASS

COMPASS紹介

COMPASS

マイクロアドのCOMPASSプロダクトは、メディアの広告配信の最適化と、包括的な管理をすることで広告収益を最大化する、次世代のサプライサイドプラットフォーム(SSP)です。

アドネットワーク広告、各DSP2から提供されるRTB3広告、メディア運営者が独自に販売する純広告や自社広告などを一元管理します。

リアルタイムで広告収益の最大化を実現するフルフラットオークション機能を搭載しています。

QPS制御について

COMPASSに接続する配信DSPパートナーは多数存在し、それぞれに送るRTBリクエストのQPSの上限値は個別で設定されています。

COMPASSの配信システムでは、QPSの上限値を超えないように個別で制御しています。

以前のQPS制御の仕組み

改善前ではRedisを利用してDSP x 秒単位を key に、送信済みのリクエスト数を value に記録する構成でした。

送信済みのRTBリクエスト数はリアルタイムにカウントアップされ、その結果がQPS上限に当たると配信が停止します。

全体像

旧仕組みの全体像

Redis負荷を改善するため、RTBリクエストは1件ずつカウントアップではなく、一定件数(100件など)の予約制を導入しました。 先に100件をRedisにincrして、その100件分のRTBリクエストが送信終了したら再度incrする、という仕組みでした。

その仕組みの問題点

主に以下の2つの問題が存在しています。

  1. COMPASSの配信サーバは数百台あり、全台からRedisの単一キーへのincr操作は負担がかかり、DSP x 秒単位のkey構成では負荷分散できないためボトルネックになりました。
  2. 秒単位でRTBリクエスト数を制御しているため、リクエスト数が多い時間帯には1秒間のうち、約0.8秒から0.9秒は全力で送信される一方、残りの0.1秒から0.2秒ではQPS上限に達して送信が停止します。この送信が停止する時間帯には、リソースに余裕が生まれます。

改善後のQPS制御の仕組み

旧仕組みの問題点を解消するために、以下の目標を設定しました。

  1. Redisの単一負担ボトルネックを解消する。
  2. RTBリクエストの送信ペースを均等化する。

2に関して、考えたのは確率制御です。COMPASSは媒体広告枠から受けた1件1件の広告リクエストに対して、事前に決まった確率でパートナーDSP各社に送信するかどうかを制御する仕組みです。

また、「制御確率」の計算には「PID制御」の仕組みを利用します。 PID制御の紹介は省略しますが、以下のwikiページをご覧ください。

PID制御

全体像

新仕組みの全体像

上記のサイクルを数十秒程度で繰り返し、RTBリクエストの送信QPSを継続的に制御します。

「制御確率」の適用は配信サーバで行われ、その計算はフィードバック制御ストリーム処理で行うため、これら2つの機能は疎結合となっています。

また、Kafka(クラスタ構成)とMySQL(マスター/スレーブ構成)の導入により、負担分散が可能となり、旧仕組みの問題点1のRedisキーの単一負担ボトルネックが解消されます。

詳細説明

① 流量を書き込み

  1. 制御後のQPS流量を配信サーバのメモリ上で一定期間(数秒間)蓄積し、ログに出力します。
  2. 出力されたログは、td-agentを介してKafkaトピックに転送されます。

② 制御量を書き込み

  1. Kafkaトピックから制御後のQPS流量をフィードバック制御ストリーム処理でリアルタイムに読み込みます。
  2. 一定期間(数十秒間)の結果をメモリ上で集計し、その集計結果を制御目標値と比較して、次のサイクルの「制御確率」を計算します。
  3. 計算結果の「制御確率」を外部のMySQLに記録します。

③ 制御量を読み込み

  1. 外部のMySQLサーバに保存された「制御確率」情報は、配信サーバから定期的に(数秒ごとに1回)読み込まれ、DSPパートナー各社に最新の「制御確率」が適用されます。

全体的に、① → ② → ③ → ① ... の順番で処理を繰り返すことで、QPS制御が目標値に近づき、安定します。

結果

改善前

改善前

改善前ではお昼のピーク時間帯にDSPへの送信されるRTBリクエストのQPSは安定しませんでした。

改善後

改善後

改善後のお昼のピーク時間帯において、RTBリクエストのQPSが安定化しました。

残課題

改善後の仕組みには以下の残課題がありますので、今後も引き続き改善を進めていきます。

  1. 新規DSP接続時には、QPSが安定するまで少し時間(数分間)を要します。
  2. PID制御仕組み自体において、QPS上限値を超える時間帯が発生します。

最後に

いかがでしょうか。今回はQPS制御の仕組み改善を紹介しました。ご参考いただければ幸いです。


  1. SSPはSupply Side Platform(サプライサイドプラットフォーム)の略で、媒体の広告枠販売や広告収益の最大化を支援するツールです。
  2. DSPはDemand-Side Platform(デマンドサイドプラットフォーム)の略で、広告主の広告効果の最適化を目指すプラットフォームです。
  3. RTBはReal-Time Bidding(リアルタイムビディング)の略で、オンライン広告の仕組みのことです。