概算見積もり
Back-of-the-Envelope Calculation
封筒の裏でやれる程度のざっくり計算で、QPS・ストレージ・帯域の規模感を素早く出す技術。『1か月≒250万秒』『40req/s≒1億req/月』などの換算を覚えておくと、システム設計面接で要件から必要リソースを即座に見積もれる。
概算見積もりとは何か
Back-of-the-envelope calculation(封筒の裏の計算)とは、その名の通り封筒の裏に殴り書きできる程度のざっくり計算で、システムの規模感を素早く出す技術です。
システム設計面接では『1000万ユーザーのSNSを設計して』のようなお題が出ます。ここでいきなり詳細設計に入るのは悪手。まず『秒間どれくらいのリクエストが来る? 何TBのデータになる? 帯域はどれくらい?』を概算し、規模に見合った設計を選ぶのが定石です。小さい店に巨大な厨房はいらないし、大行列の店に屋台の設備では潰れる——まず規模を掴むのです。
大事なのは正確さより桁感。『100万req/月くらい』なのか『100億req/月くらい』なのかが分かれば、設計判断には十分です。
覚えておくべき換算
時間
| 期間 | 秒数 |
|---|---|
| 1日 | 86,400秒 ≒ 約10万秒 |
| 1か月 | ≒ 250万秒 |
| 1年 | ≒ 3,150万秒 ≒ 約3000万秒 |
『1か月 ≒ 250万秒』を覚えておくのが最重要。これを軸にQPSが暗算できます。
QPS(Queries Per Second / 秒間リクエスト数)
| 秒間 | 月間 |
|---|---|
| 1 req/s | 250万 req/月 |
| 40 req/s | ≒ 1億 req/月 |
| 400 req/s | ≒ 10億 req/月 |
この対応を覚えておくと、月間リクエスト数から秒間QPSが、またその逆が一瞬で出せます。
図を描画中...
見積もる3点セット
設計面接では、この3つを順に見積もります。
- QPS(秒間リクエスト): 月間アクセス数 ÷ 250万秒。読み(read)と書き(write)を分けるとなお良い。
- Storage(必要容量): 1件あたりサイズ × 件数 × 保存期間。ここで powers-of-two(1KB×10億=1TB)が効く。
- Bandwidth(帯域): QPS × 1件あたりサイズ。秒間に何バイト流れるか。
例題でやってみる
お題: 1000万ユーザー、1人あたり1日3回投稿、1投稿1KB、3年保存。
QPS(書き込み)
- 書き込み総数/日 = 1000万 × 3 = 3000万 writes/日
- ÷ 86,400秒(≒約10万秒)≒ 約350 writes/s(平均)
- ピークは平均の数倍 → ピーク約1000〜3000 writes/s を想定
Storage
- 1日のデータ = 3000万 × 1KB = 30 GB/日
- 3年 = 約1000日 → 30 GB × 1000 = 約30 TB
- (1KB × 投稿総数 で powers-of-two が活きる)
Bandwidth
- 書き込み帯域 = 350 writes/s × 1KB ≒ 約350 KB/s
- 読み込みは通常書き込みの数倍〜数百倍(read heavy)なので、読み比率を仮定して別途算出
この数字が出れば、『書き込みは1台のDBで捌けそうか? ストレージ30TBはシャーディングが要るか?』といった設計判断に直結します。
ピークを忘れない
つまずきやすいのが平均とピークの違い。上の350 writes/sは『1日を平らにならした平均』です。実際は昼や夜にアクセスが集中するので、ピークは平均の数倍〜10倍。設計はピークに耐える必要があるので、平均QPSを出したら**ピーク係数(2〜10倍)**を掛けて余裕を見ます。primerでも『Traffic is not evenly distributed(トラフィックは均一ではない)』が全演習共通の前提です。
面接での使い方
- 要件を聞いたら、まず概算。ユーザー数・頻度・1件サイズ・保存期間を確認し、QPS/Storage/Bandwidthをざっくり出す。
- 桁を声に出す。『月1億リクエスト、つまり平均40 req/s、ピークで数百 req/s ですね』と言えると、規模を理解していると伝わる。
- その規模に応じた設計を選ぶ。『この読み量ならキャッシュ必須』『このストレージならシャーディング』と、見積もりを設計判断に繋げる。
つまずきポイント
- きれいな数字に丸める。86,400秒は『約10万秒』、1か月は『250万秒』。厳密さより暗算しやすさを優先。
- read:write比を確認する。多くのサービスはread heavy(読みが圧倒的に多い)。読みと書きを分けて見積もると、キャッシュやリードレプリカの判断が付く。
- 平均で満足しない。ピークに耐えられないと本番で落ちる。必ずピーク係数を掛ける。
- latency-numbers と powers-of-two が土台: 『何バイトを(powers-of-two)、どの速度で(latency-numbers)、秒間何回(QPS)』——この3つが揃って初めて、見積もりが立体的になる。
📊 図解
図解: 見積もりの3点セットと設計判断への接続
要件(ユーザー数・頻度・1件サイズ・保存期間)から QPS / Storage / Bandwidth を出し、QPSにはピーク係数を掛ける。出た数字が「キャッシュが要るか」「シャーディングが要るか」という設計判断に直結する流れ。
図を描画中...