AWS RTB FabricにAZ単位のルーティング設定が追加
AWS RTB Fabricで、レスポンダーゲートウェイへの接続先Availability Zone（AZ）を制御できるようになりました。新たに、リクエスター側のAZを基準にしたクライアントルーティング方針を設定できます。
選択肢は大きく2つです。
- リクエスターと同じAZにあるゲートウェイを優先する
- レスポンダーゲートウェイがまたがるすべてのAZを利用する
従来は、リクエストを送信する側のAZにあるゲートウェイ容量が優先的に利用されていました。そのため、別AZに余裕があっても、特定AZの容量だけが逼迫する、あるいは他AZの容量が十分に活用されない可能性がありました。
今回の変更は、単なる接続先の追加ではありません。DSPやSSPのように、複数AZへ入札・広告配信基盤を展開している事業者にとって、レイテンシー、ゲートウェイ容量、障害時の余力をどのように配分するかを設計できるようになった点が重要です。
2つのルーティング方針を比較する
同一AZを優先する構成
同一AZのゲートウェイを優先する方式では、AZ境界をまたぐ通信を抑えられます。リアルタイム入札では、リクエストの受信から入札レスポンスの返却までの時間が収益や配信機会に影響するため、余計なネットワーク遅延を避けたいケースに適しています。
特に次のような構成では、同一AZ優先が有力です。
- 入札レスポンスのレイテンシー目標が厳しい
- 各AZに十分なゲートウェイ容量を確保している
- AZ間の通信をできるだけ避けたい
- 通常時の遅延を最小化することを重視している
ただし、同一AZに接続先を限定するほど、そのAZに配置されたゲートウェイ容量への依存度は高まります。トラフィックの偏りや一時的な処理量の増加があると、別AZに空き容量があっても有効活用できない可能性があります。
全AZを利用する構成
レスポンダーゲートウェイがまたがるすべてのAZを利用する方式では、複数AZのゲートウェイ容量をリクエスターから利用できます。AZごとのトラフィック差が大きい環境や、特定AZの容量を超えないようにしたい環境で効果を発揮します。
次のような場合に検討しやすい方式です。
- AZごとのリクエスト量に大きな偏りがある
- 一部AZのゲートウェイ容量がボトルネックになっている
- 複数AZの余剰容量をプールして使いたい
- 容量逼迫時にも処理を継続できる余力を重視している
一方で、リクエスターとゲートウェイが別AZになる可能性があるため、同一AZ優先と比べて追加のネットワーク遅延が発生し得ます。リアルタイム入札では数ミリ秒単位の差が無視できない場合もあるため、単純に「全AZ利用が常に優れている」とは判断できません。
| 観点 | 同一AZ優先 | 全AZ利用 |
|---|---|---|
| レイテンシー | AZ境界をまたぐ通信を抑えやすい | 別AZ接続による遅延の可能性がある |
| 容量効率 | AZごとの余剰容量を活用しにくい場合がある | 複数AZの容量を活用しやすい |
| 障害時の余力 | 特定AZへの依存が大きくなりやすい | 他AZの容量を利用できる余地がある |
| 適した環境 | 低遅延を最優先する入札基盤 | 負荷分散と容量効率を重視する基盤 |
DSP・SSPの実運用で考える選択基準
ケース1：DSPの入札レスポンスを最優先する
DSPでは、広告リクエストを受けてから入札レスポンスを返すまでの時間が短いほど、オークションに参加できる可能性を高めやすくなります。各AZに十分なゲートウェイ容量があり、トラフィックも均等に分散されているなら、同一AZ優先によって通常時の経路を短く保つ設計が考えられます。
この場合は、次の指標をAZ別に観測することが重要です。
- リクエスト数と入札レスポンス数
- レスポンスタイムのパーセンタイル
- タイムアウト率
- ゲートウェイ容量の使用状況
- AZごとのエラー率
同一AZ優先を採用した後も、特定AZだけでレイテンシーやタイムアウトが悪化していないかを確認します。平均値だけでなく、p95やp99などの高位パーセンタイルを見ることで、混雑時の影響を把握しやすくなります。
ケース2：SSPのトラフィック変動に対応する
SSPでは、媒体やユーザー、時間帯によってリクエスト量が大きく変動することがあります。あるAZにリクエストが集中し、別AZのゲートウェイが空いているなら、全AZ利用によってインフラ全体の容量を効率よく使える可能性があります。
特に、イベントやキャンペーンによる急激なトラフィック増加がある場合は、ピーク時に単一AZの容量が先に不足しないかを確認する必要があります。全AZ利用を選ぶ場合でも、レイテンシーの増加が入札タイムアウトや落札率に与える影響を、段階的な切り替えや負荷試験で評価するのが現実的です。
ケース3：AZ障害時の継続性を重視する
マルチAZ構成では、障害時に別AZへ処理を逃がせることが可用性向上につながります。ただし、AZアフィニティの設定だけでアプリケーション全体の障害対策が完了するわけではありません。
次の要素を分けて設計する必要があります。
- DSP・SSPアプリケーションのAZ分散
- ゲートウェイの配置と容量
- 入札処理のステートレス性
- タイムアウトとリトライの方針
- 障害発生時のトラフィック切り替え
- 監視、通知、復旧手順
全AZ利用は、ゲートウェイ容量の選択肢を増やす設計要素ですが、アプリケーション側が特定AZのリソースに依存していれば、期待した可用性は得られません。
導入前に確認すべきフリート要件
AWSは、AZアフィニティ設定を有効にする前に、AWS RTB Fabric User Guideに記載されたフリート要件を確認するよう案内しています。既存環境へ設定を適用する際は、ゲートウェイの構成やAZのまたがり方が要件を満たしているかを確認することが前提になります。
実務では、次の観点で導入計画を整理するとよいでしょう。
- レスポンダーゲートウェイがどのAZに展開されているか
- 各AZのゲートウェイ容量と現在の使用率
- リクエスター側のワークロードがどのAZに分散しているか
- AZ間通信によるレイテンシーを許容できるか
- 障害時に別AZの容量を利用できる構成か
- 変更前後を比較できる監視指標があるか
- 本番トラフィックへ適用する前に検証できるか
設定変更の効果は、ネットワークレイテンシーだけでなく、入札タイムアウト率や広告オークションへの参加率にも現れます。そのため、ネットワークメトリクスとビジネス指標を分離せずに評価することが重要です。
コストと容量設計への影響
AWS RTB Fabricは、AdTechパートナーとの接続を、プライベートで高性能なネットワーク環境を通じて提供するサービスです。AWSの案内では、標準的なクラウドネットワークコストを最大80%削減でき、初期コミットメントも不要とされています。また、今回のAZアフィニティ機能の利用に追加料金はありません。
ただし、追加料金がないことと、設計上のコストがないことは同じではありません。全AZ利用によって容量効率が改善しても、AZ間通信に伴う遅延や、アプリケーション側の処理設計が変わる可能性があります。逆に、同一AZ優先によって遅延を抑えられても、AZごとに余分なゲートウェイ容量を保持する必要が生じる場合があります。
判断の軸は、次のように整理できます。
- まず入札レスポンスや広告配信に必要なレイテンシー目標を定義する
- AZごとのピークトラフィックとゲートウェイ使用率を把握する
- 同一AZ優先と全AZ利用で、タイムアウト率やp99レイテンシーを比較する
- 容量不足時とAZ障害時の振る舞いを確認する
- ネットワークコストだけでなく、機会損失や過剰プロビジョニングも評価する
まとめ：最適解はワークロードの性質で変わる
AWS RTB FabricのAZアフィニティ設定によって、AdTech事業者は「低遅延を優先するか」「複数AZの容量を広く使うか」を、ワークロードに合わせて選択できるようになりました。
低遅延が最重要で、各AZの容量に余裕があるDSPでは、同一AZ優先が適しています。一方、トラフィック変動が大きく、AZごとの容量を柔軟に活用したいSSPや大規模DSPでは、全AZ利用が有力な選択肢になります。
重要なのは、設定を変更すること自体ではなく、AZ別の容量、レイテンシー、タイムアウト、可用性を継続的に測定し、実際の入札成果と結び付けて評価することです。導入時にはフリート要件を確認したうえで、まず検証環境や限定的なトラフィックで比較し、自社のSLOに合うルーティング方針を決めるのが堅実です。
AWS RTB Fabricは、米国東部（バージニア北部）、米国西部（オレゴン）、アジアパシフィック（シンガポール、東京）、欧州（フランクフルト、アイルランド）など、サービスが提供されているリージョンでこの機能を利用できます。
出典： AWS What’s New