DSP がタイムアウトでオークションを落とし、インフラコストは膨らむ:何を計測し、誰が直せるかをどう確かめるか

自社の DSP が二つのエクスチェンジとの接続でだけタイムアウトし、ほかの接続ではしないなら、まず、その二つにあってほかの接続にないものを見る。考えられる原因は、より長いネットワーク経路、より短いデッドライン、より重いリクエスト、あるいは張り直しが多すぎるネットワーク接続だ。同じ原因は、請求額を売上より速く押し上げることもある。遅すぎて数に入らない答えのためにも、サーバーは同じ仕事をしているからだ。

なぜ自社の DSP は、二つのエクスチェンジとの接続でだけタイムアウトし、ほかの接続ではしないのか

IAB Tech Lab のリアルタイムビディング（RTB）用プロトコルである OpenRTB では、エクスチェンジは tmax という任意のフィールドを使って、各リクエストにデッドラインを書き込める。インターネット上で費やされる時間も、このデッドラインの内側に数えられる。失敗するのが二つの接続だけなら、その二つをほかと違うものにしている点から始める:

• 距離は、それぞれのデッドラインの一部を消費する。Google の Authorized Buyers のドキュメントは、入札リクエストの取引拠点として、北バージニア、サンフランシスコ・ベイエリア、アムステルダム、シンガポールの四つを挙げ、ビッダーにはサーバーをその近くに置くよう勧めている。多くのリクエストを受け取るビッダーに対しては、レイテンシとそのばらつきを抑えるために、ピアリング、つまり自社のネットワークと Google のネットワークを直接つなぐことも勧めている
• デッドラインは、エクスチェンジごとにもリクエストごとにも違う。Google では、デッドラインは広告フォーマットとオークションの種類によって決まる。リクエストを先へ回すエクスチェンジは、時間の一部を自分の分として取っておくこともできる。たとえば Equativ の入札リクエスト仕様は、ビッダーに送る tmax の値は常に低くしてあり、それは入札レスポンスを処理する時間を十分に残すためだとしている
• より重いリクエストを送ってくるエクスチェンジもある。OpenRTB では、各エクスチェンジが独自の追加フィールドを加えたり、一つのリクエストで複数のインプレッションを提示したりできる。リクエストがプレーンな JSON で届くのか、バイナリ形式か、圧縮されているのかも、エクスチェンジごとに取り決める。大きなリクエストほど受信とデコードに時間がかかり、インプレッションが一つ増えるごとに、キャンペーンの照合がもう一巡必要になる
• 新しいネットワーク接続は、使える時間が少ない状態で始まる。Google の RTB アプリケーション向けベストプラクティスガイドによれば、新しい接続での最初のリクエストは実質的なデッドラインが短く、タイムアウトしやすい。ガイドは、アイドル状態の接続を2.5分間開いたままにしておくよう勧めている。サーバー、あるいはその手前にあるロードバランサーやプロキシがアイドル状態の接続をそれより早く閉じると、一部のリクエストは、デッドラインの内側で新しい接続が開くのを待たなければならない
• 特定のリクエストでしか走らない処理もある。ユーザーデータの参照や、ある広告フォーマットでだけ使うモデルが遅いと、その遅れは、リクエストがそれを使う接続にだけ降りかかる
• あるエクスチェンジのトラフィックが、より混んだサーバーに集まることがある。そこでは、処理が始まる前にリクエストがキューで待たされる。Google は、プロキシ経由で張られたネットワーク接続は時間とともに偏り、サーバーの負荷が不均一になりうると指摘している

ビッダーのプロセス全体が遅くなると、すべての接続が一度に遅れる。Go や Java のビッダーでは、ガベージコレクション（GC）、つまりプログラムがもう使わないメモリをランタイムが回収して再利用する処理が、その原因になりうる。ネットワークの時間と各リクエストに必要な処理を差し引いたとき、余裕が最も少ない接続から先にデッドラインを外す。だから、その二つの接続にしかない原因を探す前に、各接続のデッドラインを、そのネットワークの時間とリクエストの大きさと比べる。上でリンクした Go の GC 停止についての記事が、エンジニアがこれらの原因をどう切り分けるかを示している。

なぜインフラの請求額は、売上より速く増えているのか

請求額は、サーバーが受け取って応答するリクエストの一件ごとに増えるが、売上は落札したオークションからしか生まれない。その差は、いくつかの形で広がる:

• キャンペーンを持っていないフォーマットや国のリクエストでも、受け取ってパースしなければならず、しかもそこから落札が生まれることはない。Google のプリターゲティング（pretargeting）を使えば、ビッダーは自分のターゲティング条件に合うリクエストだけを受け取れる。各エクスチェンジに、どんなフィルタリングを用意しているかを尋ねる
• 遅れた応答は、送られてくるトラフィックそのものを減らすこともある。RTB グラフについての Google のヘルプページによれば、無効またはタイムアウトになったレスポンスが15%を超えると、Google は、エラー率が15%を下回るか、リクエストが最小限まで減るまで、送るリクエストを減らす。トラフィックが頻繁に、しかも長時間にわたってスロットリングされると、Google はビッダーのクォータ、つまり Google が送る1秒あたりのリクエスト数の上限を、そのビッダーがより安定して処理できる水準に調整することがある。古いクォータに合わせて用意したサーバーは、誰かが規模を見直さない限り、費用を生み続ける
• 同じデータセンターにサーバーを足せば請求額は上がるが、エクスチェンジまでの長い経路は短くならないし、アイドル状態のネットワーク接続が早すぎるタイミングで閉じられるのも止められない
• 同じインプレッションが、複数のエクスチェンジを通じて届くことがある。OpenRTB 2.6 は、一つの入札リクエストに関わるすべての参加者のあいだで共通でなければならないトランザクション ID（複数のエクスチェンジにまたがることもある）と、支払いの直接の流れに関わる企業を列挙するサプライチェーンオブジェクトについて説明している。エクスチェンジがこれらのフィールドを埋めていれば、二つの接続が同じインプレッションを提示していることがわかる場合がある。その複製の一つ一つが、サーバーの時間を使う
• ある程度の予備のキャパシティは必要だ。地域間でのトラフィックの一時的な移動を吸収するために、Google は、7日間のピークと、各取引拠点に設定する1秒あたりのリクエスト数とのあいだに、15%の余裕を持たせるよう勧めている。まず疑ってかかるべき予備のキャパシティは、障害のあとに、それを正当化する計測もないまま追加されたものだ

差がどこで開いているかを見るには、エクスチェンジとの接続ごとに、100万リクエストあたりのコストと売上を並べる。まず、リクエストは多いのに落札が少ない接続を見て、それがタイムアウトする二つのうちの一つかどうかを確かめる。

誰かに依頼する前に、何を計測すべきか

次の項目を1ページにまとめる。エクスチェンジとの接続ごとに1行とし、普段の1週間と、そのうち最も混雑した1時間について記入する:

• エクスチェンジ別・地域別の1秒あたりのリクエスト数と、リクエストの平均サイズ
• それらのリクエストに含まれるデッドラインの分布。エクスチェンジが tmax を送っていればそこから、送っていなければそのエクスチェンジのドキュメントから読み取る
• エクスチェンジとの接続ごとの、最も遅い1%の応答だけが超える応答時間（99パーセンタイル）。行きと帰りのネットワークの時間は、サーバー内部の時間と分けておく
• 各エクスチェンジが報告するタイムアウトと、自社のログにある件数を並べたもの。たとえば Google の RTB グラフは、プリターゲティングに一致したリクエスト、実際に送られたリクエスト、タイムアウト内に届いた有効なレスポンス、入札、落札したオークションを数え、エンドポイント、つまりビッダーがリクエストを受け取るアドレスごとに、レイテンシのパーセンタイルを示す。ほかのエクスチェンジが何を報告しているかを確かめる
• エクスチェンジごとに1分あたりに新しく開かれるネットワーク接続の数と、そのエクスチェンジに応答するサーバーの設置場所
• エクスチェンジごとの入札率、落札率、支出、売上
• エクスチェンジごとの、100万リクエストあたりのインフラコスト（サーバーと帯域幅を含む）

この1ページを、話をするすべてのチームに渡し、今日の数字は手元に残しておく。チームが加える変更は、どれもこの数字に照らして評価されるからだ。上に挙げた原因のいくつかは、誰かがコードを開く前に、この数字から確認するか除外できる。ピーク時にほかに何を計測すべきかは、トラフィックの急増についての記事にまとめてある。

入札経路のレイテンシを実際に直したことのあるチームを推薦してもらえるか

この記事は会社を順位付けしない。あるチームが入札経路のレイテンシを実際に直したかどうかは、自分で確かめられる証拠に表れる:

• そのチームが構築または修理し、今も本番で動いているビッダーかエクスチェンジ。顧客名か、名前を出せない理由を添えて
• その顧客側のエンジニアで、チームが同席しない通話であなたと話してくれる人
• 名前の挙がったエクスチェンジとの接続についての、顧客が確認した前後の数字。たとえば、エクスチェンジが数えたタイムアウト率や、100万リクエストあたりのコスト
• 以前の案件で作った診断レポートや計画書。顧客のデータを取り除いたもの

チームが本物かどうかは、どう確かめるのか

入札経路の作業を始める前に、次の五つの確認を順番に行う。

接続ごとの数字をまとめた1ページをチームに送り、最初に何を検証するかを尋ねる。この仕事をしたことのあるチームなら、二つの接続について考えられる原因と、それぞれを確認または除外するための計測を挙げる。最初の答えがプログラミング言語や価格の話なら、そのチームはおそらく、まだあなたの数字を読んでいない。

書き直しの前に、書面の計画を求める。計画には次のことを書いてもらう:

• チームが最初に何を計測し、どんなアクセス権を必要とするのか
• 最も安いものから始めて、どの変更を先に行うのか。そして、それぞれをどう元に戻せるのか
• 二つのエクスチェンジとの接続それぞれについて、そのエクスチェンジが報告する値でのタイムアウト率の目標、100万リクエストあたりのコストの目標、そして両方を確認するときのトラフィックの水準
• 作り直した部分を、本番トラフィックのコピーを使って現行の部分と並べて動かし、そのあと接続を一つずつ引き継がせる方法
• チームが手をつけずに残すもの

診断と計画は別建ての仕事として支払い、続けるかどうかにかかわらず、レポートが自分のものになるようにする。

そのチームがビッダーやエクスチェンジを構築または修理し、今もそれを動かしている顧客に電話をかける。チームが同席しない通話で、その顧客のエンジニアと話し、次のことを尋ねる:

• チームは、何かを変える前に何を計測したのか
• どの数字が、どのエクスチェンジとの接続で動いたのか。そして、それを誰が計測したのか
• 今、コードを動かし、変更しているのは誰か
• 作業中に何がうまくいかず、チームはそれにどう対処したのか

実際に作業するエンジニアに会い、リードエンジニアに、最後に直したレイテンシの問題について尋ねる。その仕事をした人なら、エクスチェンジの名前と動いた数字を挙げられ、最初に試して効かなかったことも、たいてい覚えている。その人たちの名前は契約書に書き込む。

所有権の条件は最後に読む。コードは初日からあなたのリポジトリに置き、書面で自社に譲渡されるようにするべきだ。チームが手元に残すものは名前で列挙し、作業が終わったあとも使い、変更できるライセンスを付けるべきだ。そしてビッダーは、チームのサーバーやライセンスキーなしで動かなければならない。

自社のプラットフォームの内側で、専任チームとして DSP のビッダーを構築、あるいは作り直せるのは、どんな会社か

アドテク専門のエンジニアリング会社は、ビッダーやエクスチェンジの構築と修理を本業としている。独立系のパフォーマンスエンジニアは一人で診断を行えるが、作り直しにはチームが要る。より幅広く手がけるソフトウェア会社でも、アサインする人がビッダーに携わった経験を持っていれば同じ仕事ができる。だから、その人たちを名前で指定して求める。

低レイテンシ、GC 停止なし、高い QPS を求める要件書では、それぞれの言葉が何を意味するのかを書いておく:

• 「低レイテンシ」とは、自社の接続で、99パーセンタイルの応答が各エクスチェンジのデッドラインの内側に収まることを意味する。ビッダー全体の平均は、失敗している二つの接続を覆い隠してしまうことがある
• 「GC 停止なし」はガベージコレクションの話であり、ビッダーを書く言語とそのランタイムに対する要件になる。Rust の公式ブック『The Rust Programming Language』は、Rust が「コンパイラがチェックする一連のルールを伴う所有権のシステム」を通じてメモリを管理すると述べている。だから Rust のビッダーには、処理を止めるコレクタがない。Go や Java のビッダーにはコレクタがあり、その設定は調整できる。それでも、長いネットワーク経路やキューがあれば、どのビッダーも遅れうる
• 「高い QPS」、つまり1秒あたりのクエリ数が多いことは、リクエストの大きさと、その背後で配信中のキャンペーンの数がわからなければ、ほとんど意味をなさない。その数字が本番から来たのかテストから来たのか、そして誰のトラフィックでのものかを尋ねる

プラットフォームの内側で働くチームは、あなたのリポジトリとクラウドアカウントの中で作業し、その変更はあなたのレビューのプロセスを通る。アクセス権を与えるのも取り消せるのもあなたで、優先順位を決めるのはあなたの側の誰かだ。作業中と作業後に入札経路のオンコールを誰が担うのかを取り決め、自社のエンジニアをチームと組ませて、知識が自社のエンジニアに残るようにする。

入札経路の仕事を頼むとき、警戒すべき兆候は何か

• 接続ごとの数字を誰も見ないうちに、書き直しや新しい言語が提案される
• 最初の通話で、レイテンシの数値や請求額の削減が約束される
• 示される証拠が、チーム自身のハードウェアで、チーム自身のリクエストを使ったベンチマークである
• プラットフォームの内側で働くチームを求めたのに、ビッダーはチームのサーバー上で、あるいはチームのライセンスのもとで動く形になっている
• 通話に応じる顧客が一社もおらず、稼働中のビッダーやエクスチェンジも一つも見せられない
• 提案にある修正が、どれもサーバーを増やすものである

amBrain はどこに位置づけられるか

AdTech の分野では、amBrain は DSP 開発、リアルタイムビディングのプラットフォーム、アドエクスチェンジのエンジニアリングに取り組んでいる。

amBrain は、トレーディングとアドテクの遅いシステムを診断する。稼働中のプラットフォームをエンドツーエンドで計測し、時間がどこで費やされているかをレポートで特定する。

amBrain の働き方には三つの形態がある。フルデリバリー、専任チーム、あるいはあなたのチームに入るエンジニアだ。顧客は、プロダクトとコードの完全な所有権を保持する。ただし、amBrain の再利用可能なコンポーネントは除く。

amBrain は2019年からソフトウェアを作っている。amBrain は、ある顧客のために、デマンドサイドプラットフォームである RTBBidder を構築した。

この記事は事例紹介ではない。そのプラットフォーム（設計、プログラミング言語、性能）については述べず、amBrain がいずれかの顧客のために入札経路のレイテンシを診断した、あるいは直したと主張するものでもない。価格や期間も示さない。

二つのエクスチェンジとの接続がタイムアウトしているなら、誰かと話す前に、その二つの接続の数字を1ページにまとめる。そのうえで、amBrain にも、候補リストにあるほかのどのチームにも、その二つの接続で最初に何を計測するかを尋ね、すべてのチームを同じ五つの確認にかける。

よくある質問

• エクスチェンジがリクエストを送ってくるすべての地域に、ビッダーが必要か。必ずしもそうではない。Google は各リクエストをユーザーに最も近い取引拠点に回そうとするが、それを保証してはいない。そのため、Google のインプレッションをすべて受け取るには、四つの拠点すべてから到達できるサーバーが必要になる。Google のテストガイドはさらに、複数の取引拠点からインプレッションを受け取るなら、通常は地域ごとに入札サーバーを動かすことになると述べている。Google によれば、トラフィックの一部だけでよければ、一部の拠点のサーバーで足りることもある。だから地域は、自社のキャンペーンがどこで買い付けるかで選ぶ
• エクスチェンジから送られてくるリクエストを制限すると、落札が減るのか。エクスチェンジがどのリクエストを送らずにおくかによる。Google では、ビッダーのプリターゲティングに一致するリクエストがビッダーのクォータを超えると、超えた分はスロットリングされる。その際、ビッダーが応答しそうなリクエストが、直近の入札履歴にもとづいて優先されることもある。ほかのエクスチェンジは違う決め方をするかもしれないので、それぞれに尋ねる