このガイドでは、アプリケーションを開発する際に考慮すべきベスト プラクティスについて説明します。 自動的に決定されます
接続を管理する
接続を維持する
新しい接続を確立するとレイテンシが増加し、 両端でリソースを使用するよりも効率的です。終了する回数を減らす 必要な接続数を減らすことで、 もう一度クリックします。
第 1 に、新しい接続ごとに、追加のネットワーク ラウンドトリップが必要 確立します接続はオンデマンドで確立されるため、最初のリクエストは 有効期限が短いため、タイムアウトする可能性が高くなります。 必要があります。タイムアウトを増やすとエラー率が上昇し、 スロットリングされます
第 2 に、多くのウェブサーバーが接続ごとに専用のワーカー スレッドを生成する あります。つまり、接続を閉じて再作成するために、サーバーは スレッドをシャットダウンして破棄し、新しいスレッドを割り当て、実行可能にする必要があります。 接続状態を構築してから、最終的にリクエストを処理します。多い オーバーヘッドが増加します。
接続を終了しない
まず、接続の動作を調整します。ほとんどのサーバーのデフォルトは 多数のクライアントが存在する環境であり、 できます。一方、RTB では、少数のマシンがリクエストの送信を 比較的おおよそ言えば、多くのブラウザの代わりになるということです。これらの条件下で 接続を可能な限り何度も再利用する方が理にかなっています。水 次の設定をおすすめします。
- アイドル タイムアウトは 2.5 分です。
- 最大接続数に対する最大接続数 できます。
- RAM が接続できる最大値への接続の最大数 同時に、接続数を検証しながら、 そこまで近づけないこともあります
たとえば Apache では、この設定に
KeepAliveTimeout～ 150、MaxKeepAliveRequests～
ゼロ、MaxClients をサーバーの種類に応じた値に設定します。
接続の動作を調整したら、 ビッダーコードによって不必要に接続が閉じられることはありません。たとえば デフォルトの「入札なし」を返すフロントエンドのコードレスポンスを返すのが エラーやタイムアウトが発生した場合は、 接続しますそうすれば ビッダーが 接続が閉じ始め、タイムアウトの数が増えて ビッダーがスロットリングされます
接続のバランスを保つ
認定バイヤーがビッダーのサーバーに接続した場合 プロキシ サーバー経由では、時間が経つと接続の不均衡が 認定バイヤーはプロキシサーバーの IP アドレスしかわからないため 各コールアウトをどのビッダー サーバーが受信しているかを特定できません。 時間の経過とともに認定バイヤーが 入札者のサーバーの再起動、接続数 非常に変動する可能性があります。
一部の接続の使用率が高い場合、他のオープン接続が、 その時は不要なため、ほとんどがアイドル状態のままです。として 認定バイヤーのトラフィックが変更されると、アイドル状態の接続がアクティブになる アイドル状態になる可能性があります。これにより、ビッダーのサーバーで負荷が不均一になる可能性があります 接続のクラスタ化に問題がある場合ですGoogle はこのような事態を防ぐために、 リクエスト 10,000 回を超えたらすべての接続を閉じて、ホット 継続的にモニタリングされます。それでもトラフィックのバランスが 以下の追加の手順を実施できます。
- 接続ごとに 1 回ではなく、リクエストごとにバックエンドを選択する パフォーマンスが向上します
- 次の場合は接続あたりの最大リクエスト数を指定する
ハードウェア ロードバランサまたはファイアウォールを介して接続をプロキシし、
接続が確立されると、マッピングが固定されます。なお、Google
リクエストには接続あたりの上限がすでに 10,000 件と指定されているため、
より厳密な値を指定する必要があるのは、依然として
環境内で接続がクラスタ化されますたとえば Apache では
MaxKeepAliveRequestsを 5,000 に設定する - リクエスト率をモニタリングし、一部を閉じるようにビッダーのサーバーを設定する 自身の接続で大量のリクエストを一貫して処理している場合、 同業他社と比較しています
過負荷を適切に処理する
割り当ては、ビッダーがすべてのメッセージを 上限を超えることはできません。実際には、割り当てを 最適なレベルを設定するのは難しく 過負荷がよく発生します ピーク時のバックエンドの停止、トラフィックの急増 リクエストごとにより多くの処理が必要な場合、または割り当て値が設定されている場合は、 高すぎます。ですから、入札システムが特定の状況下でどのように行動するかを考慮し、 トラフィック量が多すぎるからです
一時的なトラフィックの変化（最大 1 週間）に対応するため リージョン間（特にアジアと米国西部と米国東部と米国西部の間） 7 日間のピークと取引あたりの QPS の間では、15% のクッションをおすすめします。 位置情報。
負荷の高い状況における入札者は、大きく 3 つに分類されます。 カテゴリ:
- 「何にでも反応する」ビッダー
このビッダーは実装は簡単ですが、 過負荷状態になります。受け取ったすべての入札リクエストに 1 対 1 で応答しようとしますが、 いずれにしてもすぐに対応できない サービスはキューに入れられますシナリオ 多くの場合、次のようになります。
- リクエスト率が高くなるとリクエストのレイテンシも増加し、すべてのリクエストが タイムアウトの開始
- コールアウト率がピークに近づくにつれてレイテンシが急激に上昇
- スロットリングが発生し、許可されるコールアウトの数が急激に減少する
- レイテンシが回復し始め、スロットリングが軽減される
- というサイクルがまた始まります。
このビッダーのレイテンシのグラフは、非常に急なのこぎり歯のような形になります。 パターンです。または、キューに格納されたリクエストによってサーバーがページングを開始する。 なんらかの動作によって長期的な速度が低下しても、 ピーク時が過ぎるまで回復が見られず、コールアウトが抑制される 自動的に調整されますいずれの場合もコールアウト回数は減り、 低い値に設定された場合よりも応答時間が長くなります。
- 「過負荷時のエラー」ビッダー
このビッダーは一定のレートまでコールアウトを受け入れてから、再び入札するようになります 一部のコールアウトでエラーが発生しますこの処理は、内部タイムアウト、 接続キューイング（Apache では
ListenBackLogによって制御） 使用率やレイテンシが高くなりすぎた場合の確率的ドロップ モードの実装 高、あるいはその他のメカニズムの場合もあります。エラー率が 15%を超えたら スロットリングが開始されます「何にでも返信」入札者、このビッダー 「損失を減らす」リクエスト率が低下してもすぐに復旧できます できます。このビッダーのレイテンシのグラフは、のこぎり歯のような浅い歯のような形になります。 許容される最大許容時間範囲に局所化し、 。
- 「オーバーロード時に入札なし」はビッダー
このビッダーは一定のレートまでコールアウトを受け入れてから、再び入札するようになります 「入札なし」過負荷に対するレスポンスです「過負荷時のエラー」に類似しています。ビッダー これにはいくつかの方法があります。異なるのは、 シグナルが Google に返されるため、コールアウトを抑制することはありません。「 フロントエンド マシンによって過負荷が吸収されるため、 処理を続行できるように 制限する必要があります
このビッダーのレイテンシのグラフでは、 リクエスト レートの同時処理がピーク時に停止し、それに応じて 入札したレスポンスの割合
「過負荷時のエラー」を組み合わせて「オーバーロード時は入札なし」は 次のようなアプローチがあります。
- フロントエンドを過剰にプロビジョニングし、過負荷になるとエラーに設定する。これにより、なんらかの形で応答できる接続数を最大化する。
- 過負荷時にエラーが発生すると、フロントエンド マシンで定型の「入札なし」を使用できます。リクエストの解析はまったく必要ありません。
- 十分な容量を確保できるバックエンドがない場合は「入札なし」を返すように、バックエンドのヘルスチェックを実装するレスポンスが返されます。
これにより、ある程度の過負荷を吸収して、バックエンドで できるようにすることです。これは 「オーバーロード時に入札なし」と表示されフロントエンドマシンが「エラーオン」に オーバーロード」リクエスト数が想定より著しく多い場合に 通知を受け取ることができます
[すべてに返信] ボタンがある場合使用する場合は、それを 「過負荷時のエラー」有効にするには接続の動作を調整し 過負荷が拒否されますより多くのエラーが返されますが サーバーがタイムアウトになるのを防いで、 リクエストには対応できません。
ping に応答する
ビッダーが接続ではなく ping リクエストに応答できるようにする デバッグには驚くほど重要です。Google は ping を使用して、 ビッダー ステータス、接続の終了のサニティ チェックとデバッグのリクエスト 動作、レイテンシなどですping リクエストの形式は次のとおりです。
id: "\3503cg\3023P\364\230\240\270\020\255\002\231\314\010\362\347\351\246\357("
is_test: true
is_ping: true
OpenRTB JSON
"id": "4YB27BCXimH5g7wB39nd3t"
OpenRTB プロトコル バッファ
id: "7xd2P2M7K32d7F7Y50p631"
予想とは異なり、ping リクエストには何も含まれません。 2 つありますまた、前述の詳細のように、ping リクエストへの応答後は接続を終了しないでください。
ピアリングを検討する
ネットワークのレイテンシや変動を低減するもう 1 つの方法は、Google とのピアリングです。 ピアリングは、トラフィックがビッダーに到達するまでの経路を最適化するのに役立ちます。「 接続エンドポイントは同じままですが、中間リンクは変更されます。詳しくは、 ピアリング ガイドをご覧ください。「 ピアリングをベスト プラクティスとみなす理由は、以下のようにまとめられます。
インターネットでは、交通機関のリンクは主に「ホットポテト」 ルーティングできますネットワーク外にある最も近いリンクを見つけて、 宛先にルーティングし、そのリンク経由でパケットをルーティングします。日時 プロバイダが所有するバックボーンのセクションを経由する 選択されるリンクは、アクセス元の接続に近い場所 開始されます。その時点以降では、パケットのルートは制御できません。 入札者に送られるため、他の自律システムにバウンスされる場合があります。 （ネットワーク）に直接接続します。
対照的に、ダイレクト ピアリングの契約が締結されている場合、 常にピアリングリンクを介して送信されますパケットの送信元に関係なく、 Google が所有するリンクまたはリースされているリンクを、共有 ビッダーのロケーションの近くに配置する必要があります。逆ルート Google ネットワークへの短いホップから始まり、Google Cloud あとはネットワークに接続しますほとんどのルートを Google が管理する パケットが低レイテンシのルートを通るようになり、パケットが 大きく変動する可能性があります
静的 DNS を送信する
購入者は、常に 1 つの静的 DNS の結果を Google に送信し、 トラフィック配信を処理します。
一般的にビッダーから提供される読み込もうとしたときに DNS サーバーがあった 残高または空き状況の管理:
- DNS サーバーが、レスポンスで 1 つのアドレスまたはアドレスのサブセットを配布する クエリに変換し、このレスポンスをなんらかの形で循環します。
- DNS サーバーは常に同じアドレスセットで応答するが、循環する 返すことができます。
1 つ目の手法は、ロード バランシングに適した手法ではありません。なぜなら、リージョンには大量のキャッシュ保存があるからです。 キャッシュをバイパスしようとしても、スタックの複数のレベルに 望ましい結果も得られます。これは、DNS の解決時間が 表示されます。
2 つ目の方法ではロード バランシングがまったく行われません。これは、Google が DNS レスポンス リストから IP アドレスをランダムに選択するため、 重要ではありません。
ビッダーが DNS を変更した場合、Google は、変更前の TTL（Time-to-Live）を 更新間隔は不確定のままです。