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