フェルミ推定と数字感覚 ─ 1台のサーバーは何RPS捌けるか

システム設計の議論でいちばん効くのは、正確な数値ではなく桁を外さない概算です。「日次1億リクエストなら平均は約1,200 QPS、ピークで6,000 QPS、サーバーは4台に冗長で8台」までを10秒で言えると、そこから先の議論が「その台数を前提にしたときキャッシュは要るのか」という具体的な設計判断に進みます。逆に桁を1つ外すと、必要ないキャッシュ層を足したり、逆に単一インスタンスで足りる規模に分散システムを持ち込んだりと、設計そのものが歪みます。

この記事は個別のシステム設計ではなく、その手前にある見積もりの技術そのものを扱います。覚えるべき基準値、4ステップの手順、3つの完全な例題、そして桁を落とす典型的な罠の順に進みます。

概算は「基準値 × 割り算」でできている

フェルミ推定と呼ばれるやり方の中身は驚くほど単純で、次の2つしかありません。

1. 問題を、値を知っている量の積や商に分解する
2. 知らない量には、覚えている基準値を代入する

たとえば「1億リクエスト/日は何QPSか」は 1e8 ÷ 86400 という単なる割り算です。難しいのは割り算ではなく、「1日は86,400秒」という基準値を身体で覚えていること、そして「日次総数 ÷ 1日の秒数 = 平均QPS」という分解を即座に思いつくことのほうです。

分解と基準値さえ揃えば、誤差は驚くほど小さく収まります。個々の仮定が2倍ずれても、複数の仮定の誤差は互いに打ち消し合う方向に働くことが多く、最終値は真値の2〜3倍以内、つまり桁としては当たるのが普通です。設計判断に必要なのはたいてい桁だけなので、これで十分に用が足ります。

暗記すべき基準値

覚える対象は少数です。以下の3つの表がほぼすべてで、この範囲を押さえておけば大半の見積もりが組み立てられます。

まず時間です。ここが最も使用頻度が高く、かつ間違えやすい場所です。

次にレイテンシと帯域です。ここはメモリ階層の実測値と揃えてあります。桁が9つにわたって並ぶので、隣り合う階層の比で覚えるのが実用的です。

最後にサイズと帯域です。

手順は4ステップ

見積もりは次の順で進めると、途中で迷子になりません。

1. 分解    : 求めたい量を、知っている量の積・商に書き下す
2. 代入    : 各項に基準値、または明示した仮定を入れる
3. 桁合わせ: 指数だけを先に計算し、係数は後から掛ける
4. 検算    : 独立した別経路で出し直し、桁が合うか見る

ステップ3が実務上のコツです。1e8 × 400 を筆算するのではなく、まず 10^8 × 4×10^2 = 4×10^10 と指数だけを合わせ、そこからバイト・GB・TBへ単位を降ろします。桁を先に確定させると、係数の計算ミスが最終的な桁に波及しません。

例題1 ─ 1台のサーバーは何RPS捌けるか

最も出番が多い見積もりです。答えの骨格はリトルの法則 L = λW を変形した λ = L ÷ W で、ここでLは同時処理数、Wは1件あたりの滞在時間、λがスループットです。

ケースA：I/Oバウンド（DB・外部API待ちが支配的）

スレッドプール200本、平均応答時間50msのアプリケーションを考えます。

λ = L ÷ W = 200 ÷ 0.05秒 = 4,000 RPS

ただしこれは理論上限です。使用率を上限まで上げると待ち行列が伸びて応答時間Wそのものが悪化するので、実務では使用率7割程度で見ます。

実用上の目安 = 4,000 × 0.7 = 2,800 RPS

ケースB：CPUバウンド（計算・シリアライズが支配的）

同時実行数をいくら増やしてもコア数以上には並列で走れないので、Lにはコア数が入ります。8 vCPUで1リクエストあたりのCPU時間が5msなら、

λ = 8コア ÷ 0.005秒 = 1,600 RPS

この場合、スレッドプールを1,000本に増やしても意味はありません。増えるのは待ち行列の長さだけで、スループットは変わらず応答時間だけが伸びます。

台数へ落とす

ピーク6,000 RPSを捌く必要があり、1台1,600 RPS（CPUバウンド側の厳しいほう）を採るなら、

6,000 ÷ 1,600 = 3.75 → 4台
可用性のため1台落ちても耐える + 成長ヘッドルーム → 8台

例題2 ─ アクセスログを1年保管すると何TBか

ストレージ見積もりの型です。分解は「1件のサイズ × 件数 × 保持期間 × 実効係数」になります。

日次1億リクエスト、構造化ログ1行400バイトと置きます。

日次   : 1e8件 × 400B = 4×10^10 B = 40 GB/日
年間   : 40 GB × 365 = 14,600 GB = 14.6 TB

ここで止めると必ず外します。生データ量から実効容量へ降ろす係数が残っているからです。

圧縮   : テキストログはgzipで5〜10倍縮む。1/8として 14.6 ÷ 8 = 1.8 TB
複製   : 3レプリカで  1.8 × 3 = 5.5 TB
索引   : 全文検索の索引は元データと同等以上。×2 として 11 TB

生データ14.6TBが、圧縮で1.8TBまで下がったあと、複製と索引で11TBに戻ります。圧縮と複製・索引はほぼ相殺するというのが実用的な経験則で、「生データ量とだいたい同じ桁の実効容量が要る」と覚えておくと外しません。

この11TBという数字から設計判断が出ます。オブジェクトストレージに置くなら月数百ドル規模で誤差の範囲ですが、これを全部検索エンジンのホットノード（メモリとNVMeが高価な層）に載せると桁違いのコストになります。だから「直近7日だけホット、それ以降はコールドストレージへ」という階層化が正当化されます。7日ぶんなら 40GB × 7 ÷ 8 × 3 × 2 = 210GB で、ホットノード1台に載る現実的な量です。

例題3 ─ 1億件のバッチは夜間4時間で終わるか

同じ1億件でも、ボトルネックがどこにあるかで所要時間が6桁以上変わります。この例題はそれを見るためのものです。前提は1億レコード、1件200バイト、合計20GBです。

(a) ファイルをシーケンシャルに読むだけの場合

20 GB ÷ 3 GB/s = 約6.7秒

I/Oは一切ボトルネックになりません。20GBという数字を見て身構える必要はないと分かります。

(b) 1件ごとに外部APIを1回叩く場合（直列）

1e8件 × 50ms = 5×10^6秒 = 約58日

完全に破綻します。ここで並列度を求め直します。4時間（14,400秒）で終えるには、

必要スループット λ = 1e8 ÷ 14,400 = 約6,900 RPS
必要同時実行数   L = λW = 6,900 × 0.05秒 = 約350

つまり350並列で回せば計算上は間に合いますが、真の制約は自分側ではなく相手のAPIが6,900 RPSを受け付けるかです。多くの場合ここでレートリミッタに阻まれ、バッチ設計は「並列度を上げる」ではなく「そもそも1件ずつ叩かずバルクAPIを使う」方向へ変わります。見積もりが設計を書き換えた瞬間です。

(c) 1件ごとにDBへランダムな1行更新をかける場合

1e8件 ÷ 10万IOPS = 1,000秒 = 約17分

理論上は17分ですが、実際にはトランザクションログのfsyncと索引更新が乗るので、実効は数分の1に落ちると見ます。それでも「数十分〜1時間」の桁に収まり、夜間バッチとしては成立します。

同じ件数で6桁の差が出ます。だからバッチの見積もりで最初にやるべきは総件数の確認ではなく、1件あたりの処理がどのボトルネックに属するかの判定です。ストレージ側の桁を自分の構成で確かめたい場合はIOPS計算機が使えます。

桁を落とす4つの罠

概算が外れるとき、原因はほぼこの4つに集約されます。

罠1：平均とピークの混同

日次総数から出るのは平均QPSです。実サービスのトラフィックは昼夜で偏り、ピークは平均の2〜10倍になります。国内向けサービスなら3〜5倍、イベント連動なら10倍以上を見ます。キャパシティはピークに対して確保するものなので、平均で設計すると必ず落ちます。

罠2：KBとKiBの取り違え

1 KB = 10^3 バイトに対し 1 KiB = 2^10 = 1,024 バイトです。この差はTB規模で約10%まで開きます。ディスクの「1TB」がOS上で931GiBと表示されるのはこれで、10^12 ÷ 2^30 = 931.3 という計算です。見積もりの段階では10%の差は無視してよいのですが、「容量がぴったり足りるはず」という結論を出したときだけは確認が要ります。

罠3：実効容量を忘れる

例題2で見たとおり、生データ量はそのまま必要容量にはなりません。レプリカ本数、索引、ファイルシステムのオーバーヘッド、そして空き率（使用率90%を超えたストレージは性能が落ち、運用上も危険）を掛けます。逆方向に圧縮が効きます。この4つを掛け合わせると、生データの0.5倍から5倍まで幅が出ます。

罠4：使用率を上げれば効率が上がるという誤解

待ち行列のある系では、使用率ρが1に近づくと待ち時間が 1 ÷ (1-ρ) で発散します。

ρ = 0.5  →  待ち時間は空いているときの 2倍
ρ = 0.8  →  5倍
ρ = 0.9  →  10倍
ρ = 0.95 →  20倍

使用率50%から80%に上げてもコストは4割しか下がりませんが、レイテンシは2.5倍に伸びます。「サーバーを遊ばせるのはもったいない」という直感がここで裏切られます。詳しくは待ち行列理論とテールレイテンシで扱っています。

検算 ─ 独立な2経路で出す

横にスクロール

概算の信頼性は、検算の有無でほとんど決まります。有効なのはトップダウンとボトムアップの2経路で出して桁を突き合わせる方法です。

たとえば「あるSNSの1日の投稿数」を出すとき、

トップダウン : 月間アクティブ1億人 × 1割が投稿 × 1日2件 = 2,000万件/日
ボトムアップ : ストレージ増分が日次20GB、1投稿1KBなら = 2,000万件/日

2つが同じ桁に着地したら、その見積もりは信用してよい水準です。桁が違ったら、どちらかの仮定に誤りがあるので、そこを詰めます。

もう1つ有効なのが次元解析、つまり単位を必ず書きながら計算することです。件/日 ÷ 秒/日 = 件/秒 のように単位が正しく消えるかを見れば、掛けるべきところで割るといった事故は起きません。ビットとバイトの8倍、msと秒の1000倍の取り違えも、単位を書いていれば計算の途中で気づけます。

最後に極端値でのサニティチェックです。出てきた答えを、常識と照らして「速すぎないか・大きすぎないか」を見ます。「1台で50万RPS捌ける」という結果が出たら、1リクエストあたり2µs、つまりDRAM参照20回ぶんしか使えない計算になり、HTTPパースだけで足が出ます。どこかで仮定を間違えたと分かります。

まとめ

• 概算は基準値と割り算だけでできている。覚えるべきは「1日=8.6万秒」「1年=π×10^7秒」「DC内往復0.5ms」「NVMe 3GB/s・10万IOPS」「1Gbps=125MB/s」といった10個ほどの値で、あとは分解の型を知っているかどうかにかかる。
• 1台のRPSはリトルの法則から出る。I/Oバウンドならスレッド数÷応答時間、CPUバウンドならコア数÷CPU時間。使用率7割を実用上限と見て台数に落とし、可用性ぶんを積む。
• ストレージは生データ量から実効容量へ降ろす。圧縮で下げ、レプリカと索引で戻す。両者はおおむね相殺し、結果として生データと同じ桁に落ち着くことが多い。
• 同じ件数でもボトルネック次第で6桁変わる。総件数より先に、1件あたりの処理がシーケンシャルI/O・ランダムI/O・ネットワーク往復のどれに属するかを判定する。
• 検算はトップダウンとボトムアップの2経路で。単位を書きながら計算し、最後に極端値で常識と照らす。

この手順は個々のシステム設計記事の冒頭にある「規模の見積もり」節でそのまま使えます。レートリミッタやシステム設計の各記事がどう数字を組み立てているかを、この記事の型に照らして読み直すと、見積もりのパターンが定着します。