Traffic / Performance System Designの入口

なぜ学ぶか

大量アクセスへの対応は台数だけで決まらない。何を同期で返すか、どこで待たせるか、どの負荷を減らすかを決め、下流と利用者への影響を確認する。Nintendo Systems求人の大規模トラフィック・高可用性・負荷試験・DB/KVS・LB/CDN・長期運用につながる。実際の同社の構成や面接問題はunknown。

入口を読んでから一つのテーマで会話learnへ進む。Databaseと既存System Designを継続し、その判断をOS・Networkの観測までつなぐ。

基本概念とレイヤーのつながり

RPSは単位時間のrequest数、throughputは処理量、latencyは一件にかかる時間。到着数と完了数を分け、平均だけでなくp95/p99など遅い側を見る。Concurrencyは同時に処理中・待ち中の数で、RPSとは別物。Burstは短時間の集中。平均負荷に余裕があっても、待ち行列や接続上限にぶつかりうる。

SLIは成功率や所要時間などの指標、SLOはその目標。どの操作・期間・計測地点を対象にするかを先に定める。「受付が速い」と「仕事が完了するまでが速い」は別の契約になる。

利用者 → CDN/LB → アプリ → DB/KVS・外部サービスという経路に、connection pool・queue・cacheが関わる。各区間にはCPU、socket、network、I/O、lockの待ちがある。設計上の箱を増やすときは、下流の接続・帯域・処理量がどう変わるかも考える。

設計手段・観測・代償

以下は一般的な設計候補。AWS欄は対応例で、同社の実装や本人の利用経験ではない。

手段と目的	主要メトリクス・疑うこと	代償・低レイヤーとの接続	AWSでの対応例
LB：健全な処理先へ分散	target別RPS・遅延・接続エラー・偏り	下流DBが共有なら台数増だけでは解消しない。TCP接続やaccept待ちも確認	ALB
CDN / Cache：originへの仕事を減らす	hit率、miss時遅延、origin負荷	鮮度・失効・認可・cache stampede。帯域節約と更新負荷を比較	CloudFront、ElastiCache / Redis
Connection Pool：接続再利用と同時数の制御	借用待ち・使用数・保持時間	大きすぎるpoolはDBを圧迫。Keep-AliveとFD・socket・DB接続を結ぶ	ECS上のアプリ、Auroraへの接続
Timeout / Retry / Backoff：待ちを打ち切り一時失敗を扱う	timeout率、retry回数、下流RPS	冪等性と期限が必要。backoff・jitter・回数制限を使い、多層retryの増幅を避ける	SDK、アプリの制御
Queue：burstを時間に分散	到着／完了rate、最古の待ち時間、再送	即時完了を諦める。継続的に到着が処理を上回るなら溜まり続ける	SQS、worker
Rate Limit：受付負荷を制御	拒否率、利用者別負荷、成功率	公平性・再試行案内・拒否してよい操作を決める	gateway／アプリでの制御
Auto Scaling：処理能力を追従させる	replica数、起動時間、待ち、CPU制限	立上り遅延・コスト。CPU平均だけでI/Oやpool待ちを検出できるとは限らない	ECS/Fargate、Lambdaの同時実行制御
DB / KVS：読み書き負荷を分担	query時間、lock、接続、hot key、throttling	index・read replica・分割・cacheを比較。整合性と運用複雑性が変わる	Aurora、DynamoDB、Redis
Multi-AZ / Multi-region：障害範囲を分離	切替時間、replication lag、復旧状況	書込整合性・RTO/RPO・network遅延・コスト。冗長化だけで無停止とはしない	サービスごとの冗長化・DR構成

Retryの設計はAWS Reliability Pillarを参照。失敗なら何でも再送するのでなく、再試行可能性、操作の冪等性、残り時間を確認する。

同じ問題を二方向から読む

演習上の追加条件：10,000 RPSでlatencyが急増した。 実測ではなく、原因と構成はまだunknown。

高レイヤーではrequest内訳、cache、pod/task数、queue、rate limit、DB設計を確認する。低レイヤーではCPU saturation、socket backlog、TCP再送、FD、pool待ち、I/Oを見る。最初から増設を正解にせず、各区間の時間を比較する。

例えばcache失効後のorigin負荷増なら、hit率とDB負荷の同時変化を調べる。Pool待ちなら、接続保持時間とquery/lockの時間を分ける。Network再送なら、アプリCPU増設で改善すると決めつけない。これらは仮説例であり、追加観測なしに原因を確定しない。

容量計画と負荷試験

まず対象操作、到着パターン、payload、read/write比、SLO、下流の上限を決める。通常負荷・段階増加・burst・長時間継続・障害時を分け、負荷生成側が限界になっていないかも確認する。成功率・tail latency・queue待ち・資源とコストを同時に見る。

平均だけでなく最も狭い箇所と余力を探す。対策後は同じ条件で比較し、ボトルネックが下流へ移っただけでないかを確かめる。負荷試験の実施はこの入口の読了条件ではなく、今回も未実施。

容量計画の振り返り、queue、DB connection pool、caching、replicationで必要なテーマだけ深める。

現職と接続して考える

Linux/AWSのケースで見えたtimeoutや接続エラーを、「どの段階の待ちか」「設計で流入・同時数・保持時間を変えられるか」と考える。ALBのtarget応答時間、アプリのend-to-end時間、DBの実行時間は測定範囲が異なる。EC2で見られるkernel情報をFargate/Lambdaでも取れると仮定せず、サービスとアプリの計測を組み合わせる。

顧客の構成や非公開ログは教材に転記しない。一般化した問いと、本人が説明した設計判断だけを後続セッションに残す。

最低限の理解とセッション開始

RPS・同時数・latencyを区別し、queueは容量不足を消すのでなく待ちへ変えること、アプリ増設は下流負荷も変えることを理解してから始める。分からなければ会話learnでその用語から扱う。

AGENTS.md、CHATGPT.md、careerの最新方針とtraffic-designの入口を読んでください。
今回はlearnです。入口で不明な基本概念を確認・説明した後、題材を一つに絞ってください。
最初の問い → 条件追加 → 観察すべきメトリクス → 原因仮説 → 設計上の対策 → トレードオフの順に、私の回答を一つずつ待ってください。
高レイヤーの設計とOS/Networkの観測を接続してください。未提示条件はunknown、追加設定は「演習上の追加条件」です。
約40分で区切り、実際の回答・ヒント・次回の問いを既存Session Syncへ残してください。

一次資料・対象

確認日：2026-09-11。AWSのサービス文書は固定版なし。実験環境・SDK版・構成は未指定。後続の実装・実験時に対象版と設定を記録する。

AWS Reliability Pillar：Retryの制御
AWS ALB：CloudWatch metrics
Linux kernel：Networking StackのScaling — rolling文書。低レイヤーとの接続用、環境のkernel版は未指定。
既存の容量・queue・DB教材には、各テーマの一次資料と保存済み実測の条件を記載。今回の概念例と混同しない。