QCon London 2026: コアを守る：多層防御によるレジリエンスのアーキテクチャ
本文の状態
日本語全文を表示中
詳細モードで約7分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
InfoQ
SeatGeekのスタッフソフトウェアエンジニア、アンダーソン・パラが、QCon London 2026で「コアを守る：多層防御によるレジリエンスのアーキテクチャ」を発表した。パラは、設計の優れたインフラでも圧倒される可能性のあるシステムで、大きなトラフィックスパイクを処理する戦略について議論した。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
SeatGeek のスタッフソフトウェアエンジニアである Anderson Parra は、QCon London 2026 で「Shielding the Core: Architecting Resilience with Multi-Layer Defenses」と題したプレゼンテーションを行い、設計されたインフラさえも圧倒してしまう可能性のある大きなトラフィックの急増に対処するための戦略について議論しました。
Parra はプレゼンの冒頭で、SeatGeek が活動する環境について説明しました。これには Parra 自身が「トラフィックの群衆殺到」と表現した状況が含まれます。問題なのはトラフィックそのものではなく、システムが適応できる速度よりも速くトラフィックが到達することだと、彼は主張しました。
以下の画像に示されているように、システムが崩壊する可能性があることを示すいくつかのシグナルがあります。
「ノイジー・ネイバー問題 (Noisy Neighbor Problem)」とは、マルチテナントシステムにおいて、あるテナントが共有リソースを不均衡に消費し、他のテナントのパフォーマンスを低下させる現象を指します。
「スケーリングギャップ (Scaling Gap)」は、スケーリングが需要に追いつかない期間として定義されます。Parra は、システムはこのスケーリングギャップを生き延びる必要があると主張し、ここでコアの保護が始まると述べました。
コアを保護する戦略は三つの柱から成り立っています：突然のトラフィックの急増がコアシステムに到達する前に処理して「バースト (Burst) を吸収する」、公平性、レート制限、および入場制御を適用して「フロー (Flow) を制御する」、そして需要の急増中に重要なサービスを安定させるために「コア (Core) を保護する」です。
SeatGeek が展開する防御層は、マルチシールドアプローチを使用しています：
エッジシールド (Edge Shield)
ゲートウェイシールド (Gateway Shield)
プラットフォームシールド (Platform Shield)
エッジシールド (Edge Shield)
Edge Shield の責任範囲には、オリジンにアクセスせずにリクエストに応答するキャッシュ、急激なトラフィックのバーストを吸収するキュー、およびボットや無効なトラフィックを検出するフィルタが含まれます。
キャッシュをレジリエンスメカニズムとして使用することで、障害が増加した際にキャッシュ応答が減少し、キャッシュヒットが減るとオリジンへのトラフィックが増加し、トラフィックが増加すると障害も増加するという課題に対処します。
Parra 氏は、キャッシュとレート制限を組み合わせて使用することですべてが変わると主張しました。これによりサービスは安定し、キャッシュのウォーミングアップがより安全に行われ、オリジンの負荷が減少します。
SeatGeek はまた、トラフィックを吸収してフローを制御する仮想待機室も実装しています。
Gateway Shield の責任範囲には、リクエストの速度を制御するレート制限、正当なユーザーを保護する公平なアクセス、および無効なトラフィックを拒否する検証が含まれます。
レート制限は、プラットフォームが過負荷になるのを防ぐためにレート制限ゲートを使用します。これにより、通常のトラフィック時にはクライアントからのリクエストが可能になりますが、高トラフィックのスパイク時には HTTP 429 Too Many Requests の応答がトリガーされます。
トラフィックの発生源には、正当にチケットを購入したい人間やファン、そして洗練されたボットや分散型自動化を含む自動エージェントが含まれます。SeatGeek の公平なアクセスポリシーでは、ユーザーとそのアカウント、および消費者とその API キーに対してレート制限を適用します。IP アドレスによる制限はフォールバックとして使用されます。
Platform Shield
プラットフォームシールドの責任には、リソースの分離（CPU リミットの適用、優先順位のスケジューリング、ノイジーネイバー問題の防止）、クリティカルパスの保護を目的とした優先順位付け、およびキュー、CPU 飽和、スケーリング信号を利用した観測性シグナルの提供が含まれます。
Parra は、A|B|C とラベル付けされた 3 つのサービスに関するシナリオを説明し、分離ありとなしの場合、およびサービス A に影響が生じた際の連鎖的なイベント（ノイジーネイバー問題）を比較しました。分離がない場合、サービス A で CPU 使用時間が大幅に増加すると、サービス B のレイテンシが増加し、その後サービス C が崩壊します。一方、サービス A の CPU 使用時間を制限することで、サービス B と C の両方に安定性がもたらされます。
シグナルフローとスケーリングのマッピングには以下が含まれます：
トラフィックの急増 --> キューサイズの増加（シグナル） --> スケーリングメカニズムによる対応（Horizontal Pod Autoscaler (HPA) の呼び出し） --> キャパシティの増加（利用可能なポッド数の増加） --> キューサイズの減少。
シグナルは SeatGeek の防御システムの 3 つのすべてのレイヤーから発生します。Parra は、回復力のあるシステムは早期のシグナルに依存しており、あらゆるシステムがシグナルを必要とすると述べています。これにより、シグナルフローとスケーリングで示されるキューサイズのより迅速な排水が可能になります。
4 つの核心原則には、以下が含まれます：レジリエンスを層状に構築する「構成（Composition）」、重要なパスを維持するための「コア保護（Protect the Core）」、信号がストレスを示すため「圧力の監視（Observe Pressure）」、そして必要であれば優雅に障害を起こすための「制御された失敗（Controlled Failure）」です。
最も優れたシグナルは障害が発生する前に現れます。パラ氏は結論として、「インターネットでの群衆の押し合い（stampede）は避けられませんが、システムの崩壊は必ずしも避けられないわけではありません」と述べました。
このトピックに関する詳細は、本ホワイトペーパーでご確認いただけます。
著者について
マイケル・レドリッチ（Michael Redlich）
マイケル・レドリッチ氏は、過去 25 年間にわたり Java コミュニティで活動的なメンバーとして活躍しています。2001 年に「ガーデンステート Java ユーザーグループ（旧 ACGNJ Java Users Group）」を設立し、現在も継続して運営されています。
2016 年以来、マイク氏は InfoQ の Java コミュニティニュース編集者を務めており、月次ニュース記事、技術文書の執筆、技術レビューなどの貢献を行っています。Oracle Code One、エンタープライズ向け新興技術カンファレンス（Emerging Technologies for the Enterprise）、トレントン・コンピュータフェスティバル（TCF）、TCF IT プロフェッショナルカンファレンス、および多数の Java ユーザーグループなどで登壇しています。マイク氏は Jakarta NoSQL および Jakarta Data の仕様におけるコミッターを務め、Jakarta EE アンバサダーのリーダーシップカウンシルにも参加しています。2023 年 4 月には Java チャンピオンに選出されました。
33年半にわたる勤務の後、マイクはニュージャージー州クリントンにあるエクソンモービル・テクノロジー&エンジニアリングから最近定年退職しました。同社では、カスタム科学実験室用およびウェブアプリケーションの開発に従事していました。また、Ai-Logix, Inc.（現 AudioCodes）のテクニカルサポートエンジニアとしても経験を積んでおり、顧客向けに技術サポートを提供し、電話システム用アプリケーションを開発した実績があります。
Show moreShow less
原文を表示
Anderson Parra, staff software engineer at SeatGeek, presented Shielding the Core: Architecting Resilience with Multi-Layer Defenses at QCon London 2026, where he discussed strategies for handling significant traffic spikes that can overwhelm even well-designed infrastructure.
Parra kicked off his presentation by describing the environment in which SeatGeek operates. This included what Parra characterized as a "traffic stampede." The problem isn't the traffic, he maintained, it's when the traffic arrives faster than a system can adapt.
As shown in the picture below, several signals indicate when a system may collapse.
The Noisy Neighbor Problem refers to a multi-tenant system where one tenant disproportionately consumes shared resources, which degrades performance for other tenants.
The Scaling Gap is defined as the period when scaling lags behind demand. Systems must survive the scaling gap, Parra maintained, and this is where shielding the core begins.
The strategy to shield the core is threefold: Absorb the Burst by handling sudden traffic spikes before they reach core systems; Control the Flow that applies fairness, rate limits, and admission control; and Protect the Core to keep critical services stable during demand spikes.
The defense layer deployed by SeatGeek uses a multi-shield approach:
Edge Shied
Gateway Shield
Platform Shield
Edge Shield
The responsibilities of the Edge Shield include: a Cache that serves requests without hitting the origin; a Queue to absorb sudden traffic bursts; and a Filter to detect bots and invalid traffic.
Using the Cache as a resilience mechanism addresses the issues of fewer cache responses as failures increase, more origin traffic when there are fewer cache hits, and increased failures when traffic increases.
Parra maintained that everything changes with the combined use of the cache with rate limiting. The service remains stable, the cache warms up more safely, and there is a decrease in origin load.
SeatGeek also implements a Virtual Waiting Room that absorbs the traffic and controls the flow.
Gateway Shield
The responsibilities of the Gateway Shield include: a Rate Limit that controls the rate of requests; Fair Access that protects legitimate users; and Validation that rejects invalid traffic.
Rate limiting uses a Rate Limit Gate to protect the platform from overload. This allows client requests during normal traffic but triggers an HTTP 429 Too Many Requests response during high-traffic spikes.
Sources of traffic include humans, fans who legitimately want to purchase tickets, and automated agents, including sophisticated bots and distributed automation. The SeatGeek Fair Access Policy applies rate limits to users and their accounts, and to consumers and their API keys. Limits by IP address are used as a fallback.
Platform Shield
The responsibilities of the Platform Shield include: resource Isolation, which applies CPU limits, schedules priorities, and prevents noisy neighbors; prioritization, which protects critical paths; and providing observability signals that use a queue, CPU saturation, and scaling signals.
Parra described a scenario of three services (labeled A | B | C) and compared them with and without isolation and the subsequent cascading events (or Noisy Neighbor Problem) when service A is affected. Without isolation, when service A experiences a significant increase in CPU time, service B incurs increased latency, followed by a collapse in service C. Conversely, limiting CPU time in service A provides stability for both service B and service C.
Mapping the Flow of Signals and Scaling includes:
Spike in traffic --> Increase in queue size (a signal) --> Reaction by the scaling mechanism (invocation of the Horizontal Pod Autoscaler (HPA)) --> Increase in capacity (more available pods) --> a decrease in queue size.
Signals originate from all three layers of the SeatGeek defense system. Parra stated that a resilient system depends on early signals and that every system needs signals. This provides a faster drain of the queue size shown in the Flow of Signals and Scaling.
The Four Core Principles include: Composition, where resilience is layered; Protect the Core to preserve critical paths; Observe Pressure because signals reveal stress; and Controlled Failure to fail gracefully, if necessary.
The best signals appear before failure, and Parra concluded by stating, "Internet stampedes are inevitable; system collapse, however, is not."
More details on this topic may be found in this white paper.
About the Author
Michael Redlich
Michael Redlich has been an active member within the Java community for the past 25 years. He founded the Garden State Java User Group (formerly the ACGNJ Java Users Group) in 2001 that remains in continuous operation.
Since 2016, Mike has served as a Java community news editor for InfoQ where his contributions include monthly news items, technical writing and technical reviews. He has presented at venues such as Oracle Code One, Emerging Technologies for the Enterprise, Trenton Computer Festival (TCF), TCF IT Professional Conference, and numerous Java User Groups. Mike serves as a committer on the Jakarta NoSQL and Jakarta Data specifications and participates on the leadership council of the Jakarta EE Ambassadors. He was named a Java Champion in April 2023.
With 33-1/2 years service, Mike recently retired from ExxonMobil Technology & Engineering in Clinton, New Jersey with experience in developing custom scientific laboratory and web applications. He also has experience as a Technical Support Engineer at Ai-Logix, Inc. (now AudioCodes) where he provided technical support and developed telephony applications for customers.
Show moreShow less
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み