RTB ビッダーにおける Go の GC 停止 ― mark assist、デッドライン、そして Rust という判断

平均が健全に見えるのにタイムアウトでオークションを落とすビッダーは、間違った数字で説明されている。デッドラインはエクスチェンジのものであり、往復両方向のネットワークを含む。コレクタはプロセスの属性なので、その停止はすべての接続に一度に課される。一本の接続だけに出るスパイクには、別の説明が要る。

Rust で書き直すか、ランタイムを調整するか。これは誰も問うていない質問に対する二つの答えのあいだの選択である。デッドラインのどの部分が、何に使われているのか。以下では、予算とコレクタ、コレクタとスケジューラ、そして書き換えとそれに値するコンポーネントを切り分ける。

デッドラインはエクスチェンジのものであり、往復を含む

OpenRTB の仕様は tmax を、インターネットの latency を含めて入札を受け取るためにエクスチェンジが許す最大時間（ミリ秒）と定義し、その値は事前のどんなガイダンスにも優先すると述べている。予算はリクエストごとに届く往復時間である。

あなたが判定されるしきい値は、自分のダッシュボードにある数字ではない。Google の Authorized Buyers のドキュメントは、取引拠点で計測してレスポンスの 85 percent がデッドラインの内側に届くことを要求し、それを外したビッダーにはスロットリングをかける。向こうの時計とこちらの時計のあいだには、計算でないものすべてが挟まっている:

• エクスチェンジとのあいだの往復。これはエンジニアリングである前に、地理とピアリングの問題である
• keepalive が切れたときの接続確立。オークションの予算の内側で TLS ハンドシェイクをやり直すことは、そのオークションを落とすことだからだ
• ハンドラがリクエストを見るまでの、accept キューでの時間。これは最も忙しいときにこそ伸びる
• デシリアライズ。そのコストを決めるのはリクエストの大きさではなく、そのうちどれだけをオブジェクトに変えるかである

だから内部のデッドラインは、その接続で答えを返すのにかかると自分のヒストグラムが示す分だけ、tmax より下に置く。しかも全台に一度決めるのではなく、エクスチェンジごとに導き直す。デッドラインは容量計画ではない。デッドラインで打ち切った仕事は、すでに CPU を使ってしまっている。

過負荷のもとでは、それは誰も数えないレスポンスに全額を払うことを意味する。だから欠けている修理はアドミッション制御である。tmax を読み、実測したキューの遅延と突き合わせ、計算が合わないときは no-bid を返す。速い no-bid は 85 percent に算入されるが、遅れた入札は算入されない。

一つのコレクタがすべての接続を受け持つ。だから一本の接続だけの現象は、別の障害である

ガベージコレクタはプロセスの属性なので、どの接続で引き起こされたサイクルでも、すべての接続に課される。最初に間に合わなくなるのは、tmax が最も厳しく、リクエストが最も重い接続である。コレクタが無くても同じ絵を作るものを、まず除外する:

• 一つのエクスチェンジからの接続が少なすぎること。HTTP/1.1 は一度に一つのリクエストしか運ばないからだ。接続あたりの QPS にハンドラの時間を掛けた値が1に近づくと、キューは接続の上にできる
• 単一の HTTP/2 接続。パケットが一つ失われるだけで、それを共有するすべてのストリームが止まる ― RFC 9114 が2022年に HTTP/3 の存在理由として挙げた head-of-line blocking である
• keepalive が切れること。障害というより既定値であることのほうが多い。http.Server.IdleTimeout はゼロのとき ReadTimeout に落ちる。一方で Google は 2.5-minute のアイドルタイムアウトを求め、nginx は 75 seconds で閉じる
• 一部のエクスチェンジでのみ発生する同期の特徴量参照。その裾はあなたのものではなく、リモートストアのものである

四つのいずれも、コレクタの設定では直らない。そして分解には道具がある。CPU プロファイルはコレクタの請求をシンボルごとに分ける。ハンドラへの課金は runtime.gcAssistAlloc、バックグラウンドのマーキングは runtime.gcBgMarkWorker である。stop-the-world の時間は /sched/pauses/total/gc:seconds、実行可能状態での待ちは /sched/latencies:seconds、そして accept キューはプロセスの外から ListenOverflows で読む。

mark assist は、あなたの入札リクエストが払う請求書である

Go のコレクタは並行であり、公式ガイドは停止の長さがヒープサイズに比例しないと明言している。だから stop-the-world の遷移は短い。効いてくる発生源は assist のほうである。アロケーションが速いとき、goroutine はコレクタを手伝う。バックグラウンドのマーキングにはプロセッサの決まった四分の一しか与えられず、足りない分がアロケートした側に課されるからだ。

速度が、これを傾きではなくしきい値にする。アロケーション率は QPS に入札リクエストあたりのバイト数を掛けたものであり、固定されたバックグラウンドの取り分と向き合う。だからトラフィックが五分の一のときには一度も assist しないコードが、100K QPS ではほぼすべてのリクエストで assist しうる。

マーキングのコストは、ごみではなく生きているポインタのグラフに比例する。そしてビッダーは、そのために都合の悪い形を抱えている。キャンペーンのインデックス、オーディエンスセグメント、フリークエンシーのキャッシュだ。Discord は2020年に同じ結論を公開しており、そこではコレクタが、メモリが空いているかを判断するために LRU キャッシュ全体を走査していた。一つの言葉の下に、五つの仕組みが隠れている:

• stop-the-world の遷移。同じ瞬間にすべての接続へ平らなスパイクとして現れるが、それ単独でオークションを落とすほど長いことはまれである
• mark assist。トレースには停止がまったく現れず、ハンドラの時間が伸びるだけである ― GC CPU に占める assist の割合から読み取る
• マーキングのコスト。アロケーションは増えていないのに生きているヒープが増えると上がる GC CPU であり、これを動かすのはフラットな配列であって、ごみを減らすことではない
• スケジューラの競合。実行可能なまま走らずに待つリクエストであり、スケジューラの latency メトリクスには現れるが、停止のメトリクスには現れない
• 強制サイクル。静かなインスタンス上でおよそ2分周期に現れるスパイクであり、指しているのはあなたのトラフィックではなく、回収の下限である

これは五つの別々の請求書として読む。コレクタの設定で片づくのはちょうど一つであり、分解を測る前に言語を変えて片づくものは一つも無い。

クローズドループは、必要だった証拠を消してしまう

Gil Tene はこの失敗を coordinated omission と名付けた。クローズドループは応答を待ち、停滞のあいだ送信を止めるため、測定する側が被測定システムと歩調を合わせ、外れ値を測らずに済ませてしまう。ScyllaDB は2021年に比較を公開しており、あるワークロードの p99 はクローズドループで 249 microseconds、補正付きのオープン負荷で 665 ms と、約2,700倍のずれがあった。

• 一定レートのオープンループ負荷。latency は、リクエストが出て行った瞬間ではなく、本来送るはずだった時刻から数える
• 生成器が送り損ねたリクエストをキューに積まない場合は、HdrHistogram 方式の補正をかける
• 平均ではなく p99 と p99.9 を見て、自分のファンアウトも数に入れる。Dean と Barroso は2013年に、p99 が1秒のサーバー100台に触れると、リクエストの 63 percent が遅いままになることを示した
• 問題が出ているエクスチェンジからそのまま写し取ったトラフィックプロファイルを、強制回収の間隔より長く、同じ cgroup クォータのもとで流す

応答を待つ負荷生成器は、まさに見つけようとしていた停滞のあいだに送信を止め、その沈黙を平均として結果に溶かし込む。あとから印字されるパーセンタイルは、あなたのビッダーではなく生成器を説明している。

まずアロケーションを減らし、それから三つのつまみを回す

チューニングを始める前に、どこで止めるかの数字を決める。消耗の末に決まった書き換えは、判断ではないからだ。数字は一つではなく二つある。assist を左右するリクエストあたりのヒープアロケーションと、マーキングを左右する生きているヒープである。

順序は、大きく勝てるところからではなく、上限より先に発生源である。assist が生まれる場所から始める。入札経路でのエスケープ解析、確保し直さず再利用するバッファ、そして新しいオブジェクトグラフを作らず必要なフィールドだけを読むコーデックだ。そのスライスは短命に保つ。リクエストバッファへのスライスは、入札が生きているあいだ、そのバッファ全体を固定してしまう。

• sync.Pool は圧力を和らげるが、何も約束しない。要素はいつでも通知なしに取り除かれうるし、プールされたオブジェクトは、返却されてから追い出されるまでのあいだ、なおマークの対象である
• 請求書は生きている集合である。キャンペーンとセグメントのインデックスを、ホットパスの外でフラットな配列に作り直し、マークされるグラフがキャンペーン数とともに増えないようにする
• GOGC はメモリとコレクタの CPU を交換する。その割合はガイドがはっきり述べている。値を2倍にすると GC の CPU コストはおよそ半分になり、assist の割合もそれに伴って下がる
• GOMEMLIMIT は、その交換を上限に対して行うものであり、設計上ソフトである。ハードな上限は、ヒープの急増を無期限の停滞に変えてしまうからだ
• コンテナ内の GOMAXPROCS。Go 1.25 は cgroup の CPU limit を読み、CPU requests は明示的に読まない。だから requests だけで limit の無い Pod は、以前の挙動のままである

この手法には天井がある。Uber は2021年、コンテナのメモリ上限に対して GOGC を調整した結果、ミッションクリティカルなサービス全体で約 70,000 cores を回収したと報告している。これはコストの成果であって、パーセンタイルの成果ではない。

Rust のホットパスで手に入るもの、そしてそのために払うもの

RTB House は2025年6月、JVM の入札サービスについて記している。マイクロサービスへの分割が小さなリクエストを大量に生み、追加される latency は平均で約 2.5 ms のリクエストに対して 7 ms 以内に収める必要があったが、頻発する G1 の停止で98パーセンタイルと99パーセンタイルが崩れた。彼らは世代別 ZGC へ移り、その対価をメモリで払った。

その修理に何が必要だったかに注目したい。切り替え先となる二つ目のコレクタである。Go が積んでいるコレクタは一つで、差し替えはできない。だから Go の梃子は、アロケーション率、生きている集合の形、そして GOMEMLIMIT に対する GOGC になる。代わりに Rust のホットパスが取り除くものは、はっきりしている。assist が無く、バックグラウンドのマーキングが無く、強制サイクルが無い。消えないもののほうは、多くのチームの予想より長い:

• アロケータ、加えてページフォールトと NUMA の配置。Rust の標準ライブラリは既定のグローバルアロケータが未規定であると述べており、多数のスレッドのもとでの malloc は裾の発生源である
• スケジューリング。ワーカープールを持つ非同期ランタイムは、ブロックするタスクがワーカーに載った瞬間に、Go のスケジューラと同じ現象を再現するからだ
• メモリの勘定。GOMEMLIMIT が覆うのは Go ランタイムのメモリだけだからだ。同じプロセス内の Rust のアロケータはあなたの上限の外にあり、強制は OOM killer に移る
• 人である。つまり、夜間にホットパスのオンコールに誰が就くのか、そして一つのリポジトリで二つのツールチェーンを抱える費用はいくらか、ということだ
• Go を外に残す場合の境界。Cockroach Labs は2015年、cgo 呼び出しを 171 ns、Go の呼び出しを 1.83 ns と計測した。生き残るのはこの比である

裾がリクエストのパース、エクスチェンジへの接続、あるいはスケジューラのキューイングにあるなら、Rust はそのミリ秒を一つも返してくれない。間違ったコンポーネントを書き直せば、同じタイムアウト率を保つために四半期を一つ費やすことになる。

だから移すのはサービスではなく、アロケーションを抱える最小の部品である。インプレッションの評価ループとそのインデックス、候補の選択、ターゲティング、フリークエンシーと予算の参照、スコアリングだ。境界の費用は横断1回あたりで見積もる。フラットなバッファで入札リクエストごとに1回であって、ターゲティング規則ごとに1回では決してない。検証はミラーしたストリームを流す別インスタンスで行い、被測定プロセスの内側では決して行わない。そこではシャドウ経路が、測っている二つの量を倍にしてしまう。

これを直せる会社は、まずタイムアウトレポートを求める

問いの後半、この種の仕事を誰がやるのかには、ベンダー一覧を必要としない試験がある。GC が原因の latency を直す会社は、書き換えを売る会社とは振る舞いが違う:

• リポジトリを求める前に、tmax の分布とエクスチェンジ別のタイムアウトレポートを求める
• 言語を提案する前に、ハンドラ・スケジューラ・ワイヤという分解と、そのうちどれがミリ秒を持っていると見ているかを述べる
• 自前のオープンループ生成器とトラフィックプロファイルを持ち込み、クローズドループのパーセンタイルを証拠として受け付けない
• 終了条件をあらかじめ名指しする。どのエクスチェンジか、どのパーセンタイルか、その tmax に対してどれだけの余裕か、千リクエストあたりどれだけのメモリか
• 書き換えたあとも、ホットパスに人を置ける。夜間に誰もオンコールでない書き換えは、二件目の障害になるからだ

どれも信頼を必要としない。いずれも最初の打ち合わせで求められる文書であり、曖昧なものが返ってきたなら、診断が飛ばされているということだ。

だから最初の問いは、どの言語かではない。タイムアウトする接続で失われているミリ秒を持っているのは、ハンドラ・スケジューラ・ワイヤという三つの合計のどれか、そしてそこに手を入れたとき、入札リクエストあたりのアロケーションバイト数が動くか、である。

amBrain が公に裏付けられること:amBrain は、トレーディングプラットフォーム、matching engine、リアルタイムビディングのシステム、そしてカジノプラットフォームのエンジニアリングを専門とするソフトウェア開発会社であり、2019年からソフトウェアを作ってきた。AdTech で私たちが作るのは、DSP 開発、リアルタイムビディングのプラットフォーム、アドエクスチェンジのエンジニアリングである。働き方は三つの形態がある。フルデリバリー、専任チーム、あるいはあなたのチームに入るエンジニアだ。書き換えとチューニングを天秤にかけているなら、価値のある話は、言語を選ぶ前に分解を走らせることから始まる。