プログラマティックオーディオの世界では、101ミリ秒は収益ゼロを意味します。これはパフォーマンスの問題ではなく、存在そのものの問題です。 当社は音声広告DSPを運用しており すべてのリクエストは この時間を逃すと入札は取り消されます。101ミリ秒では、事実上、私たちのサービスは存在しないようなものです。 、1日あたり約3億5000万件、週あたり約20億件のリクエストを処理しています。 100ミリ秒以内に受信、評価、そして応答しなければなりません。 私たちは3人のエンジニアリングチームと月額1万ドル未満のクラウド料金でこれを実現しています。入札インフラ、アプリケーション層、データベース、運用まで、すべてを同じチームが管理しています。   RTBエコシステム アドテクノロジーにあまり詳しくない方のために、簡単に説明します。プログラマティック広告はリアルタイム入札（RTB）で実行されます。 供給側には があります。AdsWizzやTritonのようなプラットフォームは、ポッドキャストプレーヤー、ストリーミングアプリ、その他のオーディオサーフェスなど、数千ものアプリやパブリッシャーの広告在庫を集約します。 SSP（サプライサイドプラットフォーム） 需要側には があります。これは、広告主を代表して、特定のインプレッションに入札するかどうかをリアルタイムで決定する、当社のシステムのようなシステムです。 DSP (Demand-Side Platforms) リスナーがポッドキャストアプリを開き、広告枠が利用可能になると、アプリはSSPと通信します。SSPは複数のDSPに入札リクエストを送信します。私たちのシステムはそのリクエストを受け取り、ユーザーとアクティブなキャンペーンを評価し、入札価格を計算し、レスポンスを返します。これらすべてがエンドツーエンドで100ミリ秒以内に完了する必要があります。 ここではレイテンシーは単なる指標ではありません。それは製品そのものなのです。 それを受け入れた途端、標準的なウェブアプリのパターンではうまくいかないことは明らかでした。マイクロサービス間のネットワークホップは許容できず、Kubernetesの大規模な導入に伴うクラウド費用も到底賄えませんでした。生き残るためには、まず制約を考慮した設計をする必要がありました。 その制約は理論上のものではありませんでした。クラウドクレジットがまだあった当初は、効率性についてはあまり気にしていませんでした。しかし、クレジットがなくなると、あらゆるアーキテクチャ上の決定に突如として現実的なコストがかかるようになりました。そこで、レイテンシ、コスト、そして運用のシンプルさを念頭に置き、システムを再構築する必要に迫られました。 以下は、3 人のメンバーからなるチームが、費用をかけたり、睡眠時間を削ったりすることなく、大規模なグローバル RTB システムを実行できるようにするアーキテクチャです。  1. 地理を第一のフィルターとして：ネットワーク物理を考慮した設計 当社が連携する主要なオーディオSSP（   ）は、米国、ヨーロッパ、東南アジアでホストされています。インドを拠点とする広告主向けのキャンペーンロジックを保持するアプリケーションレイヤーは、インドで運用されています。 Triton、AdsWizz、Magnite（旧Rubicon）、MCTV これらのリージョン間のネットワークラウンドトリップだけでも、アプリケーションロジックを実行する前でも約 かかります。これはすでに許容予算の2倍以上を超過しています。 240ミリ秒 修正は簡単でしたが、妥協の余地はありませんでした。入札クラスターは、米国西部（オレゴン）、欧州中部（フランクフルト）、アジア太平洋（シンガポールおよび香港）の に展開されました。 4つの戦略的なAWSリージョン これにより、SSP が入札リクエストを送信するときに、物理層までの距離が無視できるほど小さくなり (通常は 1 桁のミリ秒)、100 ミリ秒の予算のほとんどが実際のコンピューティングに充てられるようになります。  2. モノリスとマイクロサービスのハイブリッド 私たちは、従来のモノリスとマイクロサービスの中間に位置するアーキテクチャに到達しました。サービスをネットワーク全体に分散させるのではなく、 共存させ、グローバルロードバランサーの背後でそれらのVMを水平方向にスケーリングします。 密結合されたサービスの小規模なクラスターを単一の仮想マシン上に 各 VM の内部は単一ノードとして扱われ、ミニチュア分散システムのように見えます。    : 内部のトラフィック監視役として機能する単一のイングレス コンテナ。 Nginx : CPU を最大限に活用するために、同じマシン上で Node.js 入札サービスのレプリカを 3 ～ 5 個実行します。 入札者    : コードと並行して実行されるローカル Redis インスタンス。 Redis メリットは、デフォルトでデータの局所性が得られることです。ビッダーはデータを取得するためにネットワークを経由せず、ローカルホストから読み取ります。これにより、 大幅に高めることも可能になります。より大きなVM（例えばc6i.xlarge）を使用し、単一のインメモリデータセットを複数のワーカーで共有することで、RAMとCPUの比率を大幅に向上させ、無駄を最小限に抑えながらスループットを最大化できます。 リソース密度を  3. 論理：早く失敗すること 100ミリ秒の期限を守るには、コードが高速なだけでは不十分です。システムは、いつ作業をしないかを迅速に判断する必要があります。 入札リクエストのほとんどは、決して落札に至りません。これらのリクエストが状態、データベース、または書き込みパスにアクセスすると、レイテンシバジェットを最も早く超過することになります。私たちは入札者を「失敗の可能性」順に並べた決定木として構成し、最もコストのかからないチェックを最初に実行します。 チェックはおおよそ次の順序で実行されます。 ：入札の大部分はここで失敗します。これは単純な比較であり、ほぼ即座に結果が返されます。 地理チェック   : 地理的条件が満たされた場合、プラットフォームとデバイスの制約を検証します。 OS とデバイスのチェック : アプリが許可された在庫と一致しているかどうかを確認します。 パブリッシャー/アプリのターゲティング : リクエストがこれらのフィルターを通過した場合にのみ、より重いパス (ユーザー レベルのデータ、予算とペースのロジック、または調整が必要なもの) にアクセスします。 ステートフル ロジック 迅速に失敗することで、マイクロ秒単位でトラフィックの 90% を拒否し、実際に変換される入札のために CPU サイクルを予約します。  4. データアーキテクチャ: ルールにはRedis、プロファイルにはAerospike アクセス パターンと「古さ」のコストに基づいて、データ アーキテクチャを 2 つの層に分割します。 ルール: ローカルRedis 各ノードは、ローカルRedisに「ホット」なメタデータ（アクティブなキャンペーンや予算上限など）を保持しています。cronワーカーは を使用し、60秒ごとに中央APIにアクセスして最新の「真実」をダウンロードします。 プルモデル 私たちの規模では、この60秒の古さは というリスクを生み出します。複数のノードが同じ古い予算データに同時にアクセスした場合、クライアントが割り当てた金額を超える支出が発生する可能性があります。 「過剰支出」 これを で処理します。フリートサイズを予算管理の入力として扱います。アクティブな入札ノードの数が増えると、各ノードは使用できる予算の「スライス」を動的に削減します。ノードが古いデータで作業している場合でも、そのノードのローカル制限は現在のフリートサイズに基づいて既に調整されています。支出は急上昇するのではなく、スムーズに減速し、システムは次の更新サイクルに収束します。 ブレーキングメカニズム プロファイル: Aerospike (SSD の利点) ユーザーレベルのデータ（プロファイル検索、フリークエンシーキャップ、リターゲティングなど）には、膨大で変更可能なデータセットへのミリ秒未満のアクセスが必要です。従来のRDBMSでは、当社の価格帯ではこの負荷を処理できません。 このレイヤーには 使用しています。これは、ワーキングセット全体をRAMに保持するのではなく、SSDをプライマリストレージとして扱うように最適化されているためです。これにより、ElastiCacheのような純粋なRAMソリューションに比べてハードウェアコストを大幅に抑えながら、レイテンシを予測することが可能になります。 Aerospikeを このレイヤーを手頃な価格に保つために、私たちはデータの衛生管理に徹底しています。  10 日ルール: 過去 10 日間にアクティブだったユーザーのデータのみを保持します。  1,000 万キャップ: 最もアクティブな上位数百万人のユーザーにデータセットを積極的に絞り込みます。 ユーザーが利用を停止した場合、そのユーザーのデータは削除されます。この規律により、入札者は重要なユーザーのみに集中しながら、ストレージコストを一定に保つことができます。  5. 「非同期」の秘密：負担の分離 最初のバージョンでは、技術的には非同期処理を目指していました。入札レスポンスは即座に送信し、Node.js関数はバックグラウンドで実行を継続してMongoDBにログを書き込むようにしていました。 ：トラフィックは平坦ではなく、バーストします。ピーク時には、入札レスポンスがなくなったにもかかわらず、Node.jsコンテナは「フローティング」状態のままになり、オープンな接続を保持したまま、データベースへの書き込みを完了しようとCPUサイクルを消費していました。そのため、オートスケーラーは 処理するためだけにVMを追加起動し、接続数の増加によってデータベースがクラッシュしました。 罠 書き込みのバックログを ：「非同期コード」から「 」に移行しました。ビッダーと書き込みパスの間にショックアブソーバーとして 導入しました。これで、ビッダーはKafkaにメッセージをプッシュし、即座にリソースを解放します。「書き込み」は、制御されたペースで別のコンシューマーフリートによって処理されます。 修正 非同期アーキテクチャ Kafkaを  6. ベンチマーキング：推測ではなく測定する この規模では、インスタンスタイプを推測するのはコストがかかります。そこで、理論に頼るのではなく、ベンチマークを実施しました。 入札サービスがコンピューティング能力に依存しているのかメモリに依存しているのか、ノードあたりに適切なワーカープロセス数はいくつなのか、インスタンスサイズがレイテンシにどのような影響を与えるのかといった仮説を立てました。複数のAWSインスタンスファミリーとインスタンスサイズでテストを行い、単一ノードで実行される入札サービスの数を変化させました。 データ レイヤーでも同じアプローチを採用し、さまざまなマシン タイプを試して、実際の負荷下で MongoDB に最適なものを見つけ、ピーク時のスループットよりも安定したレイテンシを優先しました。 これらすべては、実稼働環境並みのQPSをシステムに投入し、応答時間とテールレイテンシを測定する負荷テストによって検証されました。いくつかの仮定は成立しましたが、多くの仮定は成立しませんでした。 結論はシンプルでした。100 。 ミリ秒の予算で、ベンチマークは常に理論を上回ります  7. FinOps: 請求額を1万ドルに抑える方法 スタートアップはトラフィックの急増で潰れるわけではありません。クラウドクレジットが枯渇すれば潰れるのです。私たちにとって、コスト管理は後付けではなく、システム設計の一部です。 コスト削減の一部は交渉によるものです。課金を再販業者経由で行うことで、定額のボリュームディスカウントを実現しました。帯域幅については、 とすることで、オンデマンド料金と比較してCDN料金を60%以上引き下げることができました。当社のトラフィックレベルでは、このたった一つのコミットメントが大きな効果を発揮しました。 月間転送量を約1PB また、私たちは懸念事項を分離しています。ステートレス入札サーバーは大幅に割引されたスポット容量で実行されますが、ステートフルデータベースは予測可能で長寿命のインスタンスを使用します。 当社の規模では、1日に数億件ものレコードを保存することは時限爆弾と同義です。詳細な入札ログの保存期間は短く、数か月ではなく数日程度です。保存したいデータは、イベントごとではなく時間ごとに集約され、より安価でクエリしやすいストレージに移動されます。コンプライアンスや履歴監査にのみ必要なデータはコールドストレージに移行し、標準プランと比較してコストを80～90%削減します。 しかし、最大の節約は割引ではありません。それは です。 利用率 ほとんどのシステムは「安全のため」CPUを20～30%で稼働させますが、私たちのシステムではそうする必要はありません。アーキテクチャはフォールトトレラントであり、負荷を適切に軽減するように設計されているため、CPUを で稼働させても問題ありません。アイドルサイクルには料金がかかりません。コアに料金を支払っている場合、そのコアは入札していることになります。 80%の使用率 効率性を第一の制約として扱うという考え方により、トラフィックが増加しても請求額は一定に保たれます。  8. 3人で運営する：「授業料」の哲学 3人チームでグローバル規模の運用を行うには、人ではなくシステムが負荷を担う必要があります。私たちは、クリティカルパスから人間の介入を排除し、可能な限り単一障害点を排除するように運用を設計しています。また、役割のサイロ化も避け、各エンジニアがフルスタックを操作できるようにすることで、運用に関する知識が単一障害点となることを防ぎます。 インフラストラクチャはデフォルトで使い捨てです。ノードに不具合が発生した場合、その場でデバッグするのではなく、ノードを終了し、オートスケーラーに置き換えさせます。復旧は調査よりも迅速で、すべてのインスタンスは既知のクリーンな状態から起動されます。 可観測性は重要ですが、ダッシュボードだけでは小規模なチームには役に立ちません。私たちは、人間の対応が必要な場合にのみトリガーされる、実用的なアラート（Datadog経由）を活用しています。リージョンクラスターの速度が低下したり、コンシューマーが遅延したりした場合は、呼び出し音が鳴ります。それ以外のすべては自動化されています。 しかし、自動化は魔法ではありません。私たちは依然として、時折授業料を支払っています。 初期のインシデントでは、予算状態の更新を担うバックグラウンドジョブがサイレントに失敗しました。入札者は古いデータで処理を続け、終了するはずだったキャンペーンに資金を費やしました。これは典型的な「ゾンビ入札者」のシナリオです。クライアントに返金し、ギャップを修復し、Datadog によるハートビートチェックでシステムを強化しました。予算の最新状態は明示的になり、サイレント状態になっただけでアラートがトリガーされます。入札者が有効な更新を受信しなかった場合は、フェイルクローズされます。 小規模なチームでは、ミスは避けられません。 ミスを繰り返すのは任意です。 終わりに このシステムにおける決定は、どれもそれ自体では特異なものではありません。それがどのように複合的に作用するかによって、このシステムは機能します。 ネットワーク物理が境界を設定します。局所性とフェイルファストロジックが100msのパスを保護します。非同期境界がトラフィックバーストを吸収します。測定が直感に取って代わります。コスト管理と高い稼働率が経済性を担保します。運用は、システムが自力で回復できない場合にのみ人間が介入するように設計されています。 これはアドテクや特定のスタックに関する話ではありません。大規模なシステムにおいては、 改めて認識させてくれるものです。レイテンシー、コスト、そして人員数を最優先の要件として扱うと、結果として生まれるアーキテクチャは複雑になるのではなく、よりシンプルなものになる傾向があります。 制約は障害ではなく、設計上のインプットとなることを 目標は何か印象的なものを作ることではなく、生き残るものを作ることでした。

This story contains new, firsthand information uncovered by the writer.

This story contains AI-generated text. The author has used AI either for research, to generate outlines, or write the text itself. 

Read My Stories

このオーディオは、ストーリーの元の言語で制作されています。

20億件のリクエスト、100ミリ秒の期限、月1万ドル：無駄のないグローバルRTBシステムの設計

About Author

コメント

ラベル

この記事は

Related Stories

ユニークなエコシステムを支えるビットコインUTXOのモデル

Telegram: クリプト島と本土を結ぶ橋

ユーザー中心の暗号通貨製品の作成: 顧客からのフィードバックの重要性

18 種類の開発者ツールで生産性を向上しましょう 🚀🔥

ユニークなエコシステムを支えるビットコインUTXOのモデル

Telegram: クリプト島と本土を結ぶ橋

ユーザー中心の暗号通貨製品の作成: 顧客からのフィードバックの重要性

18 種類の開発者ツールで生産性を向上しましょう 🚀🔥

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps