直すか、マネージドサービスに移るか、作り直すか:広告イベントパイプラインがピーク時にイベントを失うとき、それぞれの選択肢にかかるコスト

広告イベントパイプラインがトラフィックのピーク時にインプレッションやクリックを失っているなら、選択肢は三つある。漏れている部分を直すか、イベントを運んで保存するサーバー（多くの場合 Kafka と ClickHouse）をマネージドサービスに移すか、外部の会社とパイプラインを作り直すかだ。どの選択肢を取るかで、誰に依頼するかも決まる。修正に必要なのはあなたのチームの中で働くエンジニアであり、作り直しに必要なのは、パイプライン全体を納品して引き渡せる会社だ。選ぶ前に、アトリビューションレポートとビッダーのログの差の年間コストを金額で出す。そのうえで、それぞれの選択肢を、費用、手元に残るコントロール、そして請求のもとになる数字がどれだけ早く正しい状態に戻るかで比べる。

アトリビューションレポートとビッダーのログの差には、いくらのコストがかかっているのか

コストの大半は請求書に表れるので、まずそこから始める。1か月分を取り出し、三つの数を並べる:広告主に請求したインプレッション、各エクスチェンジから請求されたインプレッション、そしてビッダーが記録した落札だ。

何に支払うかを決めるのはエクスチェンジだ。エクスチェンジとビッダーが広告をリアルタイムで取引するために使う IAB Tech Lab の標準規格 OpenRTB 2.6 は、エクスチェンジが課金通知を送るのは「落札した入札が、エクスチェンジ固有のビジネスポリシーに基づいて課金対象となったとき」だとしている。各エクスチェンジは自らのポリシーに従い、自らの記録にもとづいて請求してくる。一方、広告主への請求はあなたのレポートにもとづく。パイプラインが失うインプレッションは、どれも支払い済みなのに請求されないままになる。二重に数えられたインプレッションは二重に請求され、広告主自身の集計と合わなければ、その分をクレジットとして返すことになる。

誰かの実データではなく、切りのいい数字で考えてみる。あるプラットフォームが月に5億インプレッションを買い、1,000インプレッションあたり2ドルで広告主に再販しているとする。インプレッションのイベントの3%を失えば、1,500万インプレッションが請求されないままになる。重複とクレジットを計算に入れる前の段階で、月30,000ドル、年360,000ドルだ。

さらに二つのコストは、金額にしにくい。一つは、社員が毎月、広告主やエクスチェンジに差を説明するのに費やす時間。もう一つは、不完全なデータにもとづいて決めた入札だ。どちらも合計の横に書き留めておく。

この年間の合計が、一つの選択肢にかけてよい費用のおおよその上限になる。取り除く差よりも費用のかかる選択肢には、別の理由が必要だ。たとえば、今のパイプラインでは運びきれないトラフィックの伸びである。

選択肢に値段を付ける前に、差を分解する。ビッダーのログと合わないレポートについての記事では、再集計を説明している。ビッダーのログにある落札の一つひとつを、オークション ID、つまり各エクスチェンジがオークションに付ける ID で、レポートのインプレッションと突き合わせる方法だ。再集計で、差のうちどれだけが失われたイベントで、どれだけが双方の数え方の違いから来ているのかがわかる。数え方の違いは、一組のルールに合意し、どのパイプラインを動かしていてもそれを適用することで解消する。マネージドサービスに移っても、新しいパイプラインにしても、集計ルールは変わらない。

それぞれの選択肢には、お金がいくらかかるのか

修正と作り直しは、主にプロジェクトとして費用を払う。マネージドサービスでは、使っているあいだずっと毎月の請求が加わる。

今のパイプラインを直すのにかかるのは、エンジニアリングの時間だ。自社のエンジニアか、あなたのチームの中で働く外部のエンジニアの時間である。新しいサブスクリプションは発生しない。修正の第2ラウンドも計画しておく。修正後に最初に来る混雑した時期に、次についていけなくなる部分が見つかることが多いからだ。

マネージドサービスは毎月請求され、その一部はイベントのギガバイト単位で料金が決まるので、請求額はトラフィックに連動する。プロバイダーのサーバーの外側にあるものは、引き続きすべて自社のエンジニアが運用する。Amazon MSK Serverless は、AWS の Kafka 向けマネージドサービスの提供形態の一つだ。Kafka は、収集からデータベースまでのあいだイベントを保持するキューである。2026年10月14日に閲覧した料金ページには、クラスター（サービスの個々の導入単位）ごとの時間料金と、パーティション（キューを分割した一つひとつ）ごとの時間料金が載っている。さらに、キューに書き込まれる1ギガバイトごと、キューから読み出される1ギガバイトごとの料金と、ストレージの料金がかかる。そのため、ビッダーのログとの毎日の再集計のように、同じイベントを読むプログラムが一つ増えるたびに請求額も増える。

マネージドの選択肢は、来年で最も混雑する月に見込まれるトラフィックで値段を出し、そのトラフィックをプロバイダーの上限と照らし合わせる。たとえば、2026年10月14日に閲覧したクォータのページによれば、MSK Serverless のクラスターは、毎秒200メガバイトを超える書き込みの速度を落とす。

作り直しの費用の大半は、プロジェクトそのものにかかる。これに、古いパイプラインと新しいパイプラインを並行して動かす月数と、成果物をレビューして検収する自社の人員の時間を加える。引き渡しのあとは誰かが新しいパイプラインを運用しなければならず、それが誰なのかを契約で名指ししておくべきだ。並行稼働を含めた同じ範囲の作業について、すべての会社に書面で見積もりを出してもらう。そうすれば、見積もりを項目ごとに並べて比べられる。

それぞれの選択肢で、どれだけのコントロールが手元に残るのか

マネージドサービスでは、コントロールの一部を手放すことになる。最初に手放すのはスケジュールだ。MSK のバージョンサポートポリシーによれば、サポート終了日を過ぎても同じ Kafka バージョンのままのクラスターは「推奨される Kafka バージョンに自動でアップグレードされる」。ポリシーはさらに「アップグレードの前に通知を受け取ることはない」と付け加えている。その日付より前に自社でアップグレードを計画するか、プロバイダーのタイミングを受け入れるかだ。あとで離れるときは、それ自体が一つの移行になる。データを、自社がほかの場所で運用するシステムへコピーし、そのデータを書き込む、あるいは読むすべてのプログラムを切り替える。

今のパイプラインを直すなら、パイプラインのコントロールはすべて手元に残る。修正の仕組みを知っているのは修正した本人なので、その中に外部の契約エンジニアがいるなら、去る前に修正ごとに書面のメモを残してもらう。

作り直しの場合、手元に残るコントロールは契約が与えるものがすべてだ。契約には、コードが自社に帰属し、作業の開始時から自社のアカウントに保管されることを明記する。設計ドキュメントはコードと一緒に受け取り、あわせてランブック、つまりアラートごとの対応手順を書いた文書も受け取る。外部の会社がまだプロジェクトにいるうちから、自社のエンジニアが新しいパイプラインのアラートに対応し始めるべきだ。

請求のもとになる数字を最も早く正しくできるのは、どの選択肢か

今のパイプラインの修正は、次のピークで確かめられる。パイプラインの各段階の1時間ごとの件数を、修正の前後で比べればよい。マネージドサービスへの移行はもっと時間がかかる。データをコピーし、イベントを書き込む、あるいは読むすべてのプログラムを切り替え、両方のシステムを件数が一致するまで並行して動かすからだ。プロバイダーのサーバーの外側にある漏れは、それでも直す必要がある。たとえば、ブラウザやアプリからイベントを受け取るプログラムであるコレクタでの漏れだ。作り直しは最も時間がかかる。ビッダーのログと合わないレポートについての記事で説明しているとおり、請求のもとになるレポートを切り替える前に、少なくとも請求期間まるごと一つのあいだ、両方のパイプラインを同じイベントで動かす。

自社のデータから、どう選択肢を選ぶのか

選択の大部分は、四つの答えで決まる。最初の三つはすでに手元にある記録から得られ、四つ目にはテストが必要になることがある。

• 差のうち、どれだけが失われたイベントで、どれだけが集計ルールによるものか。再集計で内訳がわかる
• ピーク時に、どの段階でイベントが消えているのか。コレクタからデータベースまで、各段階の1時間ごとの件数を見れば、どこで件数が落ちるかがわかる
• 前の四半期、エンジニアがパイプラインに費やした時間はどこに消えたのか。チケットとアラートを、サーバーを動かし続けるのに使った時間と、集計やデータの問題を直すのに使った時間に分ける
• 12か月後、パイプラインはどれだけのトラフィックを運ばなければならないのか。記録しておいた自社のトラフィック1日分をその速度で送り直し、パイプラインが持ちこたえるかを見る

三つの選択肢を並べると、こうなる。

• 今のパイプラインを直す。エンジニアリングの時間、完全なコントロール、そして次のピークで確かめられる結果
• マネージドサービス。トラフィックに連動する毎月の請求、プロバイダーの日程で行われるアップグレード、そして移行を終えてから出る結果
• 外部の会社と作り直す。プロジェクトに加えて数か月の並行稼働、契約を通じたコントロール、そして少なくとも請求期間まるごと一つを経てから出る結果

選択肢を比べるには、それぞれについて、今後12か月の費用と、差の月額コストにその選択肢で差が埋まるまでの月数を掛けたものを足し合わせる。合計を比べるのは、実際に見つかった損失を取り除ける選択肢どうしだけにする。イベントがデータベースに届く前に失われているなら、マネージドのデータベースは役に立たない。差が、双方で1日を締める時刻が違うことから来ているなら、作り直しは役に立たない。

選択肢を組み合わせることはできるのか

最も安い計画は、三つの選択肢を決まった順番で組み合わせたものであることが多い。まず集計ルールに合意する。下で何が動いていても、ルールは同じように適用されるからだ。次に、場所を特定できる漏れを直す。サーバーと設計については最後に決める。数週間分のきれいな1時間ごとの件数で、何が残っているかが見えてからだ。

作り直しは、自前のサーバーを運用することを意味するとは限らない。新しいパイプラインは、マネージドのキューとマネージドの分析用データベースの上に置くことができ、ローダ、つまりキューからデータベースへイベントを書き込む段階まで運用するプロバイダーもある。ClickHouse データベースのホスティング版である ClickHouse Cloud は、そのために ClickPipes を提供している。そのドキュメントは ClickPipes を「マネージドな統合プラットフォーム」と呼び、データソースとして Kafka と AWS MSK を挙げている。そのうえで外部の会社は、集計ルールやビッダーのログとの毎日の再集計のように、あなたのプラットフォームに固有の部分を作り、合うマネージドサービスがないところではコレクタとローダも作る。

外部の会社の提案には、何が示されているべきか

会社がどの選択肢を提案するにせよ、その提案は自社のデータで検証できるものであるべきだ。選択肢に合った確認材料を求める。

• 最も混雑した1時間における各段階の件数。その会社が提案する修正ごとに、修正の前と後
• 来年のトラフィックで最も混雑する月の請求額、引き続き自社で運用する部分、そしてプロバイダーから離れる方法
• ビッダーのログとの毎日の再集計が合意した差の範囲に収まることに連動した支払い。あわせて、並行稼働の期間と、自社のエンジニアがアラートを引き継ぐ日付

amBrain は広告イベントパイプラインを構築しているのか

amBrain はアドテク向けのイベント分析パイプラインを構築する。インプレッションとクリックのイベントの収集、処理、レポーティングである。AdTech の分野では、DSP 開発、リアルタイムビディングのプラットフォーム、アドエクスチェンジのエンジニアリングにも取り組んでおり、RTBBidder は amBrain がある顧客のために構築したデマンドサイドプラットフォームである。

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

amBrain は2019年からソフトウェアを作っている。働き方には三つの形態がある:フルデリバリー、専任チーム、あるいはあなたのチームに入るエンジニア。所有権についての一文はこうだ:「顧客は、プロダクトとコードの完全な所有権を保持する。ただし、私たちの再利用可能なコンポーネントは除く。」

ここに書いたことは、どの顧客のパイプラインについての記述でもない。Amazon MSK、Kafka、ClickHouse、ClickPipes はよくある例として挙げたものであり、amBrain がそれらを使ったことがある、あるいはパイプラインをマネージドサービスに移したことがあると主張するものではない。この記事は amBrain の価格や期間を示しておらず、上のドルの数字は架空の例である。

amBrain と話すなら、差の年間コストと、最も混雑した日の1時間ごとの件数から始める。

広告イベントパイプラインの修正と作り直しについてよくある質問

• 作り直しを決めるまで、どれだけのあいだ修正を試すべきか。修正後の最初のピークまでは試し、件数の落ち込みが次の段階に移っただけなら、第2ラウンドまで続ける。すでに直した段階で件数が再び落ちる、あるいは第2ラウンドのあとも次のピークで新たな落ち込みが残るなら、修正がトラフィックに追いついていない。作り直しを検討のテーブルに載せるのは、そのときだ
• パイプラインを作り直した会社に、その後の運用まで任せられるか。誰がどれだけ早くアラートに対応するかを契約に定めれば、そう取り決めることはできる。それでも、自社のエンジニアをアラート対応の当番表に入れておく。契約を終えたときに、パイプラインを知る人が誰もいない状態にならないようにするためだ