難
AWS で数百万ユーザーへスケールするシステムを設計せよ
課題
1人のユーザーしかいない状態(1台のサーバーに全部入っている)から、数千万ユーザーが使う規模まで、システムを段階的に進化させる。各段階で『何が最初に詰まるか(ボトルネック)』を見つけ、それを1つずつ解消していく。この演習は他の7問の集大成で、『スケールの考え方そのもの』を学ぶのが目的です。一気に最終形を描くのではなく、必要になってから足すのが鉄則。
制約・前提
- 1人のユーザー → 数千万ユーザーへ段階的に成長
- 最終的にユーザーは10M(1000万)人
- 書き込みは1B(10億)/月、読み取りは100B(1000億)/月
- 1書き込みあたり1 KB
- read:write は約100:1 (read-heavy、多くのサービスがそうである)
- 各段階でボトルネックを特定し対処、常にBenchmark/Load Test → Profile → 対処 → 反復
主要数値
概算（back-of-the-envelope）の出発点。
| 成長 | 1 user → 数千万 users |
|---|---|
| 最終 read req/s | 40,000 req/s |
| 最終 write req/s | 400 write/s |
| read:write比 | 約100:1 (read-heavy) |
| 1書き込みサイズ | 1 KB |
| スケールの鉄則 | Benchmark → Profile → 対処 → 反復 |
主要数値の可視化
read : write 比
read : write = 100:1
最終形の操作別 req/s（対数軸）
readwrite
read-heavy (100:1) 1ユーザーから数千万へ。最終的に read 40,000/s vs write 400/s。Benchmark→Profile→対処→反復でread側を水平スケール。
まず自分で設計を考えてから、1ステップずつ答え合わせをしましょう。
Step 1: 要件・ユースケース（まだ伏せられています）
考えてみよう（面接官の追加質問）
- 『single box』のまま粘れるのはおおよそ何ユーザー/何req/sまでか? いつ分離に踏み切ると判断する?
- Webサーバーをstatelessにするためにsessionを外出しした。もしsessionストア(Cache)が落ちたら全ユーザーがログアウトする。これをどう緩和する?
- Master-Slave構成でmasterが落ちた瞬間、未レプリケーションのwriteは失われうる。どこまで許容し、どう減らす?
- write 400/sが単一masterに厳しくなったとき、Sharding と NoSQL移行のどちらを先に選ぶ? その判断基準は?
- 各スケール段階を『いつ実行するか』をAutoscalingのように自動化できるか? できない判断(=人が決めるべき判断)はどれか?