出題の入口に先に回答し、必要な節から復習する。以下はAIによる一般化した解説。数値・障害は演習上の追加条件で、実環境の観測や本人の経験ではない。資料確認日：2026-09-09。対象：PostgreSQL 18、node-postgres公開資料（版未固定）、AWSの更新型資料、Grafana k6 latest（試験ツール未導入）、Google SRE Book。
https://github.com/MFQWKMR4/tech2026 の CHATGPT.md、AGENTS.md、src/content/docs/career/index.md と次のファイルを読み、architecture-scaling の振り返りを一緒に読むlearnセッションを始めてください。- src/content/docs/architecture/scaling.mdx- public/diagrams/architecture-scaling/backlog-composition.svg- reviews/architecture-scaling.yaml- sessions/2026-09-08-architecture-scaling-01.yaml- diagrams/architecture-scaling/connection.json- diagrams/architecture-scaling/backlog.json- diagrams/architecture-scaling/capacity.json- src/content/docs/practice/scaling-capacity.md- sessions/2026-09-10-int-burst-01-01.yamlreviewに新しいsessionがあればそちらも確認してください。参照できたファイルとcommitを示し、不明はunknownとしてください。図JSONの読解と描画の確認を区別してください。まず希望する節を一つだけ聞き、回答を待ってください。指定がなければneeds_revisitから、一節ずつ説明→追加疑問→理解確認へ進めてください。演習は問題だけを一問ずつ提示し、模範解答を先に出さないでください。終了時は実際の回答を根拠に、CHATGPT.mdと既存テンプレートに従ってYAML＋Session narrativeを含む [Session Sync] GitHub IssueをMFQWKMR4/tech2026に作成し、URLを返してください。作成できない場合は未作成と明示し、コピー可能なタイトルと本文を返してください。最終レビュー：2026-09-10 · 説明した（Explained）。ヒント後の理解と自力の説明を区別して記録しています。
INT-BURST-01 v1（2026-09-09）の口頭interview。開始問題「イベント開始時に受付が集中し、受付後に外部サービスを使って処理するシステム」で、初回独力回答ではAPI serverのhorizontal scaling、queueによるproducer/consumer分離、外部APIの処理能力に合わせたconsumer側rate調整、queue容量設計、受付完了と処理中/完了の状態表示を提案した。進捗表示では当初「受付APIではDB書込みを発生させたくない」とし、queue投入時に受付成功を返し、consumer開始後にDBへprocessing、完了後にcompletedを記録して状態取得APIで見せる案を出した。
Q1初回独力でAPI水平分散、queue、下流能力に合わせたconsumer rateを提案。Q2容量、DB占有、Q4は未出題。新しい容量不足の観察は登録しない。
architecture-scaling の初回 interview。API traffic 10倍を起点に、水平スケールと共有ボトルネック、DB connection pool、外部副作用とidempotency、noisy neighbor、rate limit / quota、scheduled scaling、queueによる平準化、consumerのbackpressure、429 / retry / DLQ、arrival rate・processing rate・backlog・deadlineによるcapacity計算、負荷試験でのcapacity limit判定まで条件を一つずつ変えて確認した。開始時刻は会話上確認できた最早タイムスタンプ基準で22:15頃、終了時刻は23:51頃（America/Toronto）、所要時間は約1時間36分。厳密なストップウォッチ計測ではなく概算。
共有制約・tenant制限・backlog増加量・CPUだけでは判断しない点を自力で説明。pool保持時間・通信境界・drain・capacity固定は説明後。replica/shardingとdrainの初回誤答はsessionに保持し、修正後の独力再確認は未実施。quotaの質問を欠落の証拠にせず、AI説明の単純化は教材で訂正。statusはExplained、実装適用・独力再確認の実績はない。
記録された項目はありません。
statelessなappは処理を分散しやすいが、DB・外部API・共有lockが同じならそこは増えない。最大app数×プロセス当たりpool上限×各appのプロセス数に、worker、管理、migration、入替中の旧新app分を加えて接続予算を置く。pool上限は常時接続数とは限らない。たとえば1プロセスのappが10台で各20接続なら最大200、30台なら600となる。各poolを小さくしても台数が無制限なら総数を固定できない。
poolは接続確立コストを再利用し、同時DB利用を制限する。小さすぎるとpool待ち、大きすぎるとDB側の競合が増える。read replicaはreadの分散先を作り、shardingはデータを分ける設計であり、接続枯渇の原因確認前に追加すると運用・整合性の負担が増える。
時系列図は、逐次awaitする一般的なclientの例。poolから借りるのはapp内の操作であり、空き接続を再利用できれば新しいTCP接続を張らない。同じDB sessionへBEGIN、query A、query B、COMMITを順に送り、それぞれの応答を待つ。COMMIT後も返却までconnectionを保持し、poolへの返却でTCPが必ず切れるわけではない。
transactionを一回のnetwork requestと同一視しない。一方で「SQL一文＝必ず一往復」でもない。複数文を一つのQueryメッセージに含める方法やpipelineがある。図は全driver共通のpacket数を表さない。PostgreSQL 18 protocol flow
node-postgresならtransactionの全statementに同じclientを使い、成功時COMMIT、失敗時ROLLBACKを試み、finallyで返却する。壊れた接続はpoolへ正常接続として戻さない。各statementを別々のpool.queryに任せると同じtransactionを維持できない。node-postgres Transactions
| 設計例 | Connectionの保持と障害時の意味 |
|---|---|
| 悪例：借用→BEGIN→注文更新→決済APIを500ms待つ→COMMIT→返却 | 外部待ち中も接続と取得済みlockを保持。DB rollbackで決済は取り消せない |
| 改善例：短いtransactionでpendingをcommit→返却→決済→短いtransactionで結果更新→返却 | 決済待ちにDB接続は不要。ただし途中停止を回収するworkerと照合が必要 |
前段で永続的な仕事IDと状態を残し、同じ業務操作には同じprovider idempotency keyを使う。決済成功直後の停止は「失敗」と断定せず照会・再試行で確認する。詳細は外部副作用・Outboxの解説、決済APIの再試行契約を再利用する。単にtransactionを二分しただけで処理完了は保証されない。
pool待ちが増えたら、借用から返却までのhold timeを計測し、その内訳をquery実行、lock待ち、外部I/O、アプリ内処理、返却漏れへ分解する。DBのquery開始時刻、transaction開始時刻、state、wait eventを照合する。DBのCPUが低くても、idle in transactionやlock待ちは残り得る。app側pool待ちはDB統計だけでは見えない。PostgreSQL 18 monitoring
| 手段 | 制御する対象 | 利点と限界 |
|---|---|---|
| tenant rate limit | 単位時間の受付・送信量 | 一顧客の急増を抑える。burst allowanceがなければ正当な短期需要も拒否 |
| quota | 割当上限。件数・容量・同時数・速度など、定義による | queue未完了件数の上限なら占有を抑える。期間と単位とscopeの明記が必要 |
| priority / weighted scheduling | 仕事を処理する順序・配分 | strict priorityは低優先度を飢餓にし得る。最低配分を設けても総capacityは増えない |
| tenant isolation | queue・worker・接続等の境界 | 障害影響を限定。専用資源はコスト・低稼働時の無駄・管理数が増える |
「rate limit＝速度、quota＝総量」は一つのAPIの説明としては便利でも、AWS全体の定義ではない。AWSのquotaにはresource数のほか操作上限もあり、API GatewayにはRPSのthrottle quotaがある。何を・誰に・どの期間・どの強制方式で制限するかを確認する。AWS Service Quotas、API Gateway quotas
演習上の追加条件として、tenantごと100/s補充・bucket容量200件のtoken bucketと、queued＋in-flightの未完了最大1,000件を併用する。満杯bucketなら一時200件を受けられるが、未完了が1,000件なら新規受付を拒否または合意済みの別契約へ送る。受付と占有数更新は並行requestでも上限を守る必要がある。件数だけでは巨大payloadを抑えられず、byte数・実処理コストの制限も検討する。これは独自サービスの設計例で、SQSの標準機能としてtenant quotaが提供されるという意味ではない。
予測可能なburstはwarm-upを見込んだscheduled scalingが候補だが、時刻ずれと下流上限は残る。数分以内の完了でよければ常設queueで平準化できる。ただし受付成功と処理完了は別であり、通常時にbacklogが小さくても同期の完了保証にはならない。状態照会や完了通知を含むAPI契約を決める。
429でconsumerを増やすと下流をさらに圧迫する。全consumer合計の送信rate・concurrencyを制限し、backoffとjitter、retry budgetで再試行の増幅を抑える。DLQは調査・再投入のためであり、容量不足の恒常的な逃がし先にしない。best effortを受けるなら受付時から契約・資源配分を分け、保証対象と同じFIFOの前方へ大量投入してSLOを壊さない。Google SRE overload
以下は空queue、一定処理能力、1件につき外部APIを1回、retry・障害なし、FIFOの流体近似。外部上限1,000 req/sを実効1,000 msg/sとして使えるという演習上の追加条件である。本番では他consumer、retry、API応答時間を考慮した余裕が必要。
burstの到着率をλ、処理率をμ、継続をT秒とすると、λがμを上回る間の終了時backlogは B = (λ − μ) × T。後続到着率をλ₀とすると、queue全体が空になる追加時間は B / (μ − λ₀)（λ₀がμ未満）。λ₀がμ以上ならそのままでは解消しない。
時系列図と次の区別を確認する。
| 演習条件 | 結果 |
|---|---|
| 5,000/sが10秒、処理1,000/s | t=10で40,000件 |
| t=10以降、到着ゼロ | 追加40秒、t=50でqueueが空 |
| t=10以降、通常500/sへ戻る | 純減500/s、追加80秒、t=90でqueueが空 |
| 同じ500/s継続でもFIFOのburst分だけを見る | 後続は後ろに並ぶためburst分はt=50で完了。queue全体の解消とは違う |
既存の時系列図は到着率が変わる時刻を追う。次の図は、同じ10秒burstの例で待っている仕事の内訳を追う。橙はburst中に来た仕事、青はt=10以降に500/sで到着する仕事。棒の長さは待機件数に比例し、空白は容量上限を意味しない。
t=10から50の40秒で、処理能力1,000/sは先に来たburstの残り40,000件を処理する。その間に通常の仕事が 500 × 40 = 20,000件 到着して後ろに並ぶ。そのためburstを処理し終えても、queueは空にならない。以後は純減500/sなので、さらに40秒かかる。
図は上の演習条件からの計算で、処理時間・障害・再配送を省いた流体近似である。実システムのSQS Standardに厳密なFIFO順序を仮定する意味ではない。「どの集団を、いつまでに終えるか」を決めてから、次のSLOの式を選ぶ。
「60秒SLO」は起点・対象・達成割合が必要。λ=5,000/s、T=30秒、μ=1,000/sなら15万件を受け、t=30で12万件残り、burst末尾はt=150頃完了する。
λT ≤ μ×60 より、許容λは最大2,000/s。(λ−μ)T/μ ≤ 60、許容λは約3,000/s。t=30の末尾をt=90までに処理する計算。個別処理時間・ばらつきの余裕を別途引く。(λ−1,000)×30 ≤ (1,000−500)×60 より最大2,000/s。元セッションの6万件という総量と約3,000/sという説明は、同じdeadlineを使った式ではない。SLO起点は元記録でunknownのため、これらを単一の正解として覚えない。上式は仮定からの算出で、実測の保証値ではない。percentile SLOなら全件保証とも区別し、業務の許容遅延・失敗率からadmission controlとpage条件を決める。
負荷とcapacityの図は曲線の屈曲前後を段階点で示す概念図で、実測曲線ではない。
固定するのはapp台数・instance種類、pool/worker設定、コード・DB schema/index、データ量・分布、request mix・payload、cacheの条件、外部依存先の上限。まず通常負荷の安定を確認し、投入RPSを段階的に増やして各段階で滞留の成長も見る。その後、一つの資源だけ変えて同じ試験を比較する。autoscalingを含む追従試験は別の目的としてwarm-up・overshoot・復旧を測る。Grafana k6 stress testing
| 投入RPS（演習値） | 成功完了RPS（追加の仮定） | p99（演習値） | 解釈 |
|---|---|---|---|
| 1,000 | 1,000 | 200ms | 安定段階の例 |
| 2,000 | 2,000 | 300ms | ここまでは追従する例 |
| 2,500 | 2,200 | 1,500ms | throughputの伸びが鈍り待ちが増える例 |
元セッションでthroughputの実測はない。上表の完了RPSは曲線説明用に追加した値。投入が完了を上回る差は未完了・拒否等へ行くので、error 0%でも短時間観測ならbacklogが成長し得る。CPU70%だけで余裕と断定しない。p99急増はknee候補で、2点だけで正確な限界を確定せず、その間を細かく測る。許容capacityはSLOを満たす持続可能な点に運用余裕を残して決める。
2026-09-08-architecture-scaling-01（Issue #10）の追加質問4件：connectionの通信境界、quotaと公平性、backlogとdeadline、負荷試験の固定条件。一次資料は各節に記載。図JSONは diagrams/architecture-scaling/ が正本。SQLや負荷試験は今回実行しておらず、教材の整備を本人の実績へ加えていない。
図表改善（2026-09-09）：説明用SVGはSVG自体が正本。前提と判断は本文、状態・比較は図、通信順序・依存関係は既存図、実測は元の記録を参照する。教材編集を新しい学習実績にはしない。