back-of-the-envelope

概算見積もり（BOTEC）

曖昧な規模感（「高トラフィック」「膨大なデータ」）を、設計を左右する具体的な数値に変換します。BOTEC は簡易的で概算の計算です。精密な見積もりではなく、実現可能性を確認するためのものです。大切なのはプロセスと方向性の正しさです。単一のデータベースでは対応できない場合、キャッシュが必須になる場合、書き込みの急増にキューが必要な場合を見極められます。

1k QPS 向けの設計と 1M QPS 向けの設計は、異なるシステムです。10 GB は RAM に収まりますが、10 TB には分散ストレージが必要です。まず見積もり、その後に選定しましょう。

いつ使うか

あらゆる設計のステップ 2（要件の直後）と、選択が規模に左右されるときに使います。読み取りパスと書き込みパスの容量の見積もり、シャーディングと単一ノードの選択、キャッシュ導入の根拠づけ、提案されたコンポーネントが負荷に対応できるかの妥当性確認などが該当します。

使わない場面

精度を追い求めたり、すべてのマイクロサービスをモデル化したりしないでください。それはこの手法の目的と正反対です。判断を変えない見積もりはしないでください（YAGNI）。大胆に丸めましょう。「99,987 / 9.1」は「100,000 / 10」です。必ず単位を明記し、前提を書き留めてください。

まず確認すること

見積もりの精度は入力の質に左右されます。次の点を明確にしてください。

• DAU/MAU と、毎日アクティブなユーザーの割合。
• ユーザーあたりの 1 日のアクション数（投稿、閲覧、メッセージなど）。
• 読み取りと書き込みの比率 — どちらのパスが支配的か。
• オブジェクトのサイズ — レコードごと、メディアの BLOB ごと。
• 保持期間 — データをどのくらい保持するか（総ストレージ容量を左右します）。
• ピーク係数 — ピークは通常、平均の約 2 倍です。一部のワークロードでは、さらに変動が大きくなります。

基本的な見積もり（計算式）

それぞれ、乗算・除算を連ねた 1 つの式として計算します。数値を使った詳しい例と CPU 時間の導出は、references/estimation-recipes.md にあります。

• QPS = DAU × actions_per_user_per_day ÷ 86,400。ピーク QPS ≈ 2 × QPS （ピーク係数を明記してください）。
• 1 日あたりのストレージ容量 = writes_per_day × avg_object_size。総容量 = storage/day × retention_days（10 進法と 2 進法の違いに注意してください。ストレージは 10 進法で販売されています）。
• 帯域幅 = QPS × payload_size（読み取りと書き込みを分けて計算します。通常、送信データ量のほうが大きく、費用もかかります）。
• サーバー数 = peak_QPS ÷ per_server_QPS。下記のサーバーあたりの処理速度を除数として使います。
• 同時接続数／メモリ = concurrent_users × per_connection_cost。 ワーキングセットが RAM に収まるか確認してください（収まらない場合は、IO バウンドでディスクを使う設計になります）。

重要な数値

調べずに見積もるために、次の基準値を覚えておきましょう。 レイテンシ、サーバーの仕様、リクエストの種類、2 の累乗、ナインに関する詳細な表は references/numbers-to-remember.md にあります。具体的な数値が必要な場合は参照してください。

多くの判断を左右する 2 つの基準値：

対象	目安
単一の SQL/RDBMS ノード	約 1,000 QPS
キー・バリューストアのノード	約 10,000 QPS
キャッシュサーバー（Redis/Memcached）	約 100,000～1M QPS
最新の CPU コア 1 基	単純なリクエストで毎秒約 1,000 件 → 64 コアのマシンで約 64k 件/秒
1 MB の読み取り：メモリと SSD、ディスクの比較	約 μs と数十～数百 μs と ms（メモリ ≫ SSD ≫ ディスク）

正確な値ではなく、桁で考えましょう。 CPU バウンドの処理には約 1 倍、メモリバウンドには約 10 倍、IO バウンドには約 100 倍の時間がかかります。アーキテクチャを変えるのは、小数点以下の数値ではなく、この比率です。

やるべきこと・避けるべきこと

レシピと、見積もりが誤解を招くパターンから要点をまとめています。

やるべきこと

• 有効数字1桁に丸め、桁数で考えます。 アーキテクチャを変えるのは、小数点以下の数値ではなく比率（1×／10×／100×）です。
• 平均ではなくピークに合わせてサイジングします。 容量を決める前に、ピーク倍率（一般的なデフォルトは約2×。バースト性の高いワークロードではさらに大きくなります）を明記します。
• 読み取りと書き込みを別々に見積もります。 読み取り比率が95％の場合と書き込みが急増する場合では、設計の方向性が正反対になります。
• 単位を明記し、前提を書き留めます。 そうすれば「GB」が曖昧にならず、入力が変わったときに計算過程を再確認できます。

避けるべきこと

• 誤った精度を持ち込まないでください。 小数点以下の数値は、入力が裏付けていない確信を与えます。「99,987」は「100,000」です。
• サーバーあたりの処理率を普遍的なものと見なさないでください。 「SQLで1k QPS」はポイントクエリの経験則です。範囲スキャン、結合、大きなペイロードでは10×悪化することもあります。桁数を見積もるために使ったうえで、実際のベンチマークで検証してください。
• 2進法と10進法を混同しないでください。 RAMは2進法、ストレージやネットワークのマーケティング表記は10進法です。見積もりでは近似値として問題ありませんが、単位を明記することが条件です。
• 意思決定に影響しない計算はしないでください。 ある数値によってアーキテクチャが変わらないなら、その計算は省略します（YAGNI）。

図

見積もりは通常、図ではなく表にまとめます。数値と前提はインラインに記載してください。導出した数値によって構造を変える必要が生じる場合（例：「300k QPS > 単一DB → シャード化／レプリカ追加」）は、その内容をアーキテクチャ図自体に反映します。数値が裏付ける設計を描く際は、architecture-diagram スキルを使用してください。

関連する構成要素

• requirements-scoping — このスキルが数値に変換する入力（DAU、アクション率、比率、SLA）を得るために依存します。
• data-storage — このスキルに情報を提供します。ここで算出するストレージ総量とシャード数が、SQL／NoSQLおよびパーティショニングの選択を左右します。
• caching — このスキルに情報を提供します。ここでサイジングした高い読み取り比率やホットワーキングセットが、キャッシュを導入する根拠になります。
• scaling-evolution — このスキルに情報を提供します。見積もりがノードあたりの上限を超えたとき、その上限が次に対処すべきボトルネックになります。
• system-design — 推論ループという概念の管轄はここです。ステップ2でこのスキルを呼び出すオーケストレーターです。

参考資料

• references/numbers-to-remember.md — チートシートです。レイテンシ表、一般的なサーバー仕様、サーバーあたりのQPS、CPU／メモリ／I/Oがボトルネックとなるリクエストの種類、2のべき乗、可用性のナインが記載されています。具体的な数値が必要なときに参照してください。
• references/estimation-recipes.md — 計算例です（Twitter規模のQPSとストレージ、64コアから64kリクエスト／秒を導くCPU時間の計算、帯域幅とサーバー台数のサイジング）。一連の計算過程を最初から最後まで確認できます。

スクリプト

サイジングの計算過程を決定論的に確認する場合（厳密な計算が役立つ唯一の場面）は、手計算ではなく計算ツールを実行してください。

• scripts/botec.py — python3 scripts/botec.py --dau 150e6 --actions 2 --peak 2 --obj-bytes 1e6 --media-frac 0.10 --retention-days 1825 --server-qps 1000 --json → QPS、ピーク、1日あたりおよび総ストレージ、帯域幅、サーバー台数を出力します。サーバーあたりのQPSのデフォルト値は上記の経験則に合わせてあります（--server-qps で変更できます）。
• scripts/test_botec.py — 計算ツールの出力が expected_outputs/twitter_scale.json（Twitterの計算例）と一致することを検証します。これにより、説明文のレシピと計算結果が食い違わないようにします。