インターン生が見た、DSP開発での「桁違い」なトラフィックとの付き合い方

こんにちは！CARTA ZERO プロダクト管轄 DSP部で11月から長期インターンをしている足利（あっしー）です。

突然ですが皆さんはWebエンジニアの仕事といわれて、どのようなものを想像しますか？

ReactやVue.jsで使いやすいUIを作り込んだり、あるいはユーザーが抱える課題を解決する新機能をリリースして喜んでもらったり…。
私もインターンに参加するときには、そういった開発風景を想像していました。
しかし、配属されたインターネット広告の世界は、想像していたWeb開発とは少しだけ景色が違っていました。

特にインターネット広告の世界では、データ駆動であること、そして高スループット・低レイテンシであることが求められています。
この記事では、私がインターン中に目撃した実際のデータや文化を通じて、DSP特有の技術とマインドセットについて書きます。

なお、DSPそのものの意義や仕組みについては、こちらの記事で非常に丁寧に説明されています。

techblog.cartaholdings.co.jp

データ駆動で測定する文化

DSP部に来て、「ここが一番パフォーマンスを支えている」と直感したのが、徹底されたデータ駆動な文化です。

Webアプリケーションの開発において、インフラコストはもちろん重要な指標ですが、フェーズによっては「機能要件を満たすこと」が最優先される場面も多いと思います。例えば、新しい決済機能を追加したり、便利な管理画面を作ったりすることで、顧客単価が上がったり新規契約が取れたりします。つまり、エンジニアのリソースを「0.01円のインフラコスト削減」に使うより、「売上を作る新機能」に投資したほうが、ビジネスとしての投資対効果が良いケースです。

しかしDSPは違います。ここで扱う商材は1回の広告表示であり、その入札リクエスト1回あたりの期待収益は、わずか 0.001円〜0.1円の世界です。機械的な取引を大量に繰り返すビジネスモデルであるため、もしコードが非効率で、1リクエストあたりの処理コストがわずか0.001円上がってしまったら、それだけでビジネスの利益が吹き飛びかねません。

また、秒間数万回というリクエストが飛んでくるため、個別のログを目視でデバッグすることは不可能ですし、あまり意味がありません。ビジネスの正解を導くには、統計学を用いて全体の傾向を把握するアプローチが必須となります。

データ基盤の活用

この文化を象徴するのが、AWSのログの集計や、データウェアハウスであるSnowflakeの活用ぶりです。

チームのSlackでは、日常的にSQLクエリが飛び交っていました。
インターン中の私のとあるプルリクエストでのレビューでも、「この実装だとエッジケースが心配」という話題が出たときにに対し「実際にAWSで過去のログを確認しましたが、そのケースが発生した痕跡はないのでレアケースっぽいね」といった、事実に基づいた議論が行われていました。

専任のデータ基盤チームが存在するなど、データ駆動な開発を行うための投資も積極的に行われています。

コスト会

個人的に一番面白いと感じた習慣が、隔週で開催されるコスト会です。エンジニアみんなで集まって、各種インフラの利用コストなどを眺め、どの部分が高くなっているか、コスト改善策はどの程度効果をもたらしたか、などを共有します。

私は業務システム開発の現場で、業務をうまく回せなかった際のログ、生の業務データを読み合わせてどういう改善が必要かを話し合ったり、プロダクトを使いやすくするためのUI改善点を共有したりする会を見たことがあります。他にも、技術を重視する現場や研究室では関連論文の読み合わせをすることもあります。

しかし、DSP部では統計データ（エラー率の推移とインフラコストの増減）の読み合わせを隔週で行っていました。「1円を笑う者は1円に泣く」を地で行くシビアさと、それをエンジニアリングで解決しようとする姿勢を強く感じました。

実際、Zen of Zucksという大事にしている考え方にも「推測するな計測せよ」という有名な格言が書かれています。

github.com

高スループット・低レイテンシ特有のアーキテクチャ

DSPとOpenRTBの簡単解説

DSPは、メディア側のシステムであるSSPからの入札リクエストを受け取り、瞬時に入札額と広告クリエイティブを返すシステムです。この通信は OpenRTB という標準プロトコルで行われます。
実は我々がメディアを閲覧するたびに裏側で超高速でオークションが行われているのです。

オークションを短時間で終わらせるための制約がtmax（タイムアウト制限）です。これは、bidリクエストのJSONのフィールドに含まれています。SSPから指定される tmax は100msのオーダーです。ここからネットワークのレイテンシを差し引くと、DSP内部で処理に使える時間はごくわずかです。

しかも、やってくるリクエスト全てに入札するわけではありません。リクエスト総数に対して実際に入札するのはごくわずかです。つまり、送られてくるリクエストの9割以上を、ミリ秒単位で「価値なし」と判断して切り捨てる処理を行っています。

ここまで、特に証拠も出さずに「秒間数万リクエスト」などと書いてきましたが、せっかくなのでデータ駆動で見てみましょう。社内ではインターン生でも簡単にクエリを叩いて分析できる環境が用意されていました。

Bid-Requestにおけるレスポンスまでの最大時間(tmax)をざっくり調べてみました。特定の時間の100件だけの平均ですが、それでもおおよそ600ms程度らしいです。この限られた時間内にSSPに届くような処理速度が求められます。

ちなみにbid-request総数はシステム監視のシステムから確認することができて、10M rpmを超えるようなリクエストが来ていることが分かりました。

データから規模感が分かってきたのではないでしょうか！

メモリ上に配信データを配置

この超高速なフィルタリングを実現するために、DSPでは広告配信の設定データをメモリ上に展開しています。

一般的なWeb開発の感覚だとデータベースに入れてSQLで検索すればいいと考えがちです。しかし、ここではSQLは使えません。
ディスクベースのDBへのクエリ往復（数ms〜数十ms）が積み重なると非常に遅くなります。しかも、「iOSのバージョン18以上」「特定のアプリ面を除く」「過去1時間に10回以上見た人を除く」といった複雑な条件を、秒間数万回以上も判定する必要があります。

そこで、DSP部ではEC2のメモリ上やKVSのインメモリDBに配信情報を配置して、CPUの計算力を最大限活用するアーキテクチャを採用しています。

なお、RDBを直接利用せずにS3から定期的に同期するのは可用性を高めるという理由もあるようです。

インターネット事業者との類似性

インターンを通じて感じたのは、広告配信のネットワークを支えるという意味で、私たちはインターネット事業者に近い仕事をしているということです。
これまでの私は、サービス開発といえば「お客様が特定の○○をできるようにする」ことだと想像していました。UIがあり、ユーザーのアクションがある、という世界です。

しかしDSPにおいては、広告主がやりたいことは広告効果の最大化（ROI向上）であり、インターフェース（OpenRTB）も決まっています。
これは、通信事業者がパケットを高品質・低遅延で伝送したいと考えるのとそっくりです。
サーバーが入札リクエストの中身を見て、価値を判断し、最適な広告をルーティングする、と捉えると、高度なネットワークとしてとらえられますよね。

構造が似ているな、と感じました。

インターネットインフラ企業がデータ駆動でトラフィックを監視し、品質を担保するように、私たちもデータ駆動で経済の流れを監視し、最適化しているのです。

インターン生としての感想

ビジネスの目線から企業文化を理解する

一番の学びは、事業構造こそが、求められるエンジニア像を規定するということです。

データが多く統計が有効な分野だからこそ、システムをマクロにみて、事実ベースで物事を進める習慣が身につきやすいのです。

就職活動などで企業の説明を聞くと、「ウチは技術志向な人が多くて〜」といったカルチャーの話をよく耳にします。
それが単なる標語なのか、本当に信頼できる事実なのかは、ビジネスを成立させるための必然性として文化を説明できるかで判断できると考えています。
例えば「リクエストが膨大だから、目の前の1件のエラーに一喜一憂せず、統計的に判断できる人が多い」みたいな説明ができると信頼できますよね。

高トラフィック領域の面白さ

純粋なコンピュータサイエンスの力が、そのままビジネスの改善に繋がりやすいという点が魅力的でした。
トラフィックが桁違いに多いので、アルゴリズムを少し改善したり、インフラコストを分析して施策を行ったり、という技術的な改善が大きなお金のインパクトを生み、それが数字としてすぐに見えてくるのです。
エンジニアとして腕を振るうエキサイティングさを感じられて面白いんじゃないでしょうか。