システムデザイン完全ガイド ①｜導入と土台 — 数字・スケール・見積もり・性能

• ① 導入と土台
• ② ネットワークと通信
• ③ データを保存する
• ④ システムの部品箱
• ⑤ 壊れないシステム
• ⑥ アーキテクチャの型
• ⑦ 面接を突破する

READ MEこのガイドの使い方

誰のためのガイドか

• プログラミングは書けるが「大規模システム」と言われるとピンとこない人
• Web アプリを作ったことはあるが、ユーザーが 1 億人になったら何が壊れるのか説明できない人
• Google / Amazon / Meta などのシステムデザイン面接を突破したい人
• 業務で「この設計で大丈夫ですか？」と聞かれて、自信を持って答えたい人

前提知識は「何かしらのプログラミング言語で 100 行くらいのコードが書ける」だけです。ネットワークもデータベースも分散システムも、このシリーズの中で 1 から説明します。

そのために、次の 3 つを同時に満たすように書いています。

1. 易しい — 専門用語は必ず初出時に日常の言葉で言い換える
2. 本格的 — 現場と論文で実際に使われている知識だけを載せる。「面接用の暗記」で終わらせない
3. 使える — 面接でそのまま口に出せる言い回し、判断基準、数字を載せる

読み方（推奨は 3 周）

本文中の記号

本文には 6 種類のマーカーが出てきます。このシリーズでは、それぞれ色分けされた枠で表示されます。

数値・仕様・法令の扱い

MAPシリーズ全体の地図

全 7 部・51 章の構成です。各部がこのシリーズの 1 記事に対応します。

CHAPTER 00システムデザインとは何か

0.1一言で言うと

プログラミングには「正解のコード」がある程度存在します。テストが通れば正解です。しかしシステムデザインに唯一の正解はありません。あるのは「その状況では妥当な選択」と「その状況では明らかにまずい選択」の 2 つだけです。

0.2何と何がぶつかるのか（トレードオフの一覧）

システムデザインで登場する対立軸は、実はそれほど多くありません。以下がほぼ全部です。この表はシリーズを通じて何度も戻ってくることになります。

0.3面接官が見ている 5 つのシグナル

Google のシステムデザイン面接は「知識テスト」ではなく「一緒に働けるかのシミュレーション」です。評価者は次の 5 点を見ています。

1. 曖昧さを扱えるか（Dealing with ambiguity）
   問題は必ず曖昧に出されます。「Twitter を設計して」だけです。まず質問して要件を絞れる人が高評価。いきなり描き始める人は低評価。
2. 数字で語れるか（Quantitative reasoning）
   「たくさんのリクエスト」ではなく「1 日 5 億リクエスト、ピーク 2 万 QPS、だから 1 台では無理で 50 台必要」と言えるか。
3. トレードオフを言語化できるか（Trade-off articulation）
   「A を選びます」だけでは足りません。「A を選びます。理由は X。ただし Y という欠点があり、それは Z で緩和します。もし要件が W に変われば B を選びます」— このように前提とトレードオフを説明すると評価されやすくなります。
4. 深く掘れるか（Technical depth）
   面接官は必ず 1〜2 箇所を深掘りします。「そのキャッシュが落ちたら？」「そのインデックスはどう保存されている？」表面的な暗記だと即座に崩れます。
5. 協調できるか（Collaboration）
   面接官のヒントを無視する、指摘に反発する、逆に何でも「はいそうします」と迎合する。どれも減点です。根拠を持って議論し、良い指摘は取り入れるのが正解です。

「ありがとうございます。まず要件を確認させてください。
 機能要件として押さえたいのは A・B・C だと思っていますが、
 今回スコープに入れるべきものはどれでしょうか。
 また規模感として、想定ユーザー数と読み書きの比率を伺えますか。」

0.4良い設計に共通する性質

面接でも実務でも、良い設計には次の性質があります。設計に詰まったらこのリストに戻ってください。

• 単純である：部品が少なく、データの流れが一方向で、説明が短い
• 境界が明確：「このサービスは何に責任を持つか」が一文で言える
• 失敗を前提にしている：どの部品が落ちても、システム全体は degraded（機能低下）で済む
• 測定できる：何が起きているか外から観測できる
• 段階的に成長できる：10 倍の負荷に、作り直しではなく台数増加で対応できる
• 元に戻せる：変更をロールバックできる。データを壊す変更を一発でやらない

0.5学び方の心構え

システムデザインの学習でつまずく最大の原因は、部品の「中身」を知らないまま名前だけ覚えることです。たとえば「キャッシュには Redis を使います」と言えても、次に答えられなければ面接では 1 分で崩されます。

• Redis はなぜ速いのか（メモリ上の単一スレッドのイベントループ）
• 落ちたらどうなるのか（キャッシュスタンピードで DB が死ぬ）
• データが消えても良いのか（永続化は RDB / AOF の 2 方式、どちらも完全ではない）

本シリーズは常に「名前 → 中身 → 使いどころ → 落とし穴」の順で説明します。急がば回れです。第 1 部の基礎は退屈に見えますが、ここが全ての土台になります。

CHAPTER 01コンピュータの中では何が起きているのか

1.1なぜ「数字」から始めるのか

システムデザインの議論は、突き詰めると次の 3 つに帰着します。

1. データはどこにあるか（CPU キャッシュ / メモリ / SSD / 別のマシン / 別の大陸）
2. そこへ行くのに何秒かかるか
3. 1 秒あたり何回行けるか

つまり「距離」と「回数」の話です。この距離感を体に入れることが最初の一歩です。

1.2覚えるべきレイテンシの数字

1.3メモリ階層とキャッシュライン

CPU から見たデータの「近さ」は階層になっています。

        速い・小さい・高い
            ▲
   ┌──────────────────────────┐
   │ レジスタ        数百 B   │  < 1 ns
   ├──────────────────────────┤
   │ L1 キャッシュ   32-64 KB │  ~1 ns
   ├──────────────────────────┤
   │ L2 キャッシュ  256KB-1MB │  ~4 ns
   ├──────────────────────────┤
   │ L3 キャッシュ    8-64 MB │  ~15 ns  ← コア間で共有
   ├──────────────────────────┤
   │ メインメモリ   16GB-2TB  │  ~100 ns
   ├──────────────────────────┤
   │ NVMe SSD         TB 級   │  ~50 µs
   ├──────────────────────────┤
   │ HDD / オブジェクトストレージ │ ~10 ms
   └──────────────────────────┘
            ▼
        遅い・大きい・安い

CPU のロード命令は 1 バイトを扱えます。ただし、キャッシュやメモリ階層では通常キャッシュライン（例：64 バイト）単位でデータが移動します。配列が連結リストより速くなりやすい理由は、連続配置と予測可能なアクセスによる局所性です。

配列 [a][b][c][d][e]...    ← 1 回のキャッシュラインで 8〜16 要素まとめて来る
連結リスト a → (どこか) b → (どこか) c   ← 1 要素ごとにキャッシュミス（100 ns）

1.4シーケンシャル読み取り vs ランダム読み取り

1.51 台のマシンでどこまでできるのか

1 台でできることの目安

• 数万 QPSHTTP リクエスト処理（軽い処理なら 10 万 QPS 以上）
• 数万 TPSPostgreSQL の読み取り（適切なインデックスがあれば）
• 10 万 ops/sRedis 単一インスタンス（パイプラインで 100 万も可）
• ≒ 100 GB全世界のツイート 1 日分のテキスト（5 億件 × 200B）＝メモリに載る

「まず単一のリレーショナルデータベースで足りるかを見積もります。
 見積もりでは 1 日 2,000 万件、ピーク 500 QPS なので、
 リードレプリカ 2 台を足した構成で十分に収まります。
 分散データベースを入れるのは、データ量が単一ノードの容量を超えるか、
 書き込みが 1 台の限界に達してからで良いと考えます。」

CHAPTER 02「スケールする」とはどういうことか

2.1スケールアップとスケールアウト

2.2ステートレスであることの意味

ユーザー A → [サーバー1] メモリにログイン状態
             次のリクエストが [サーバー2] に行くと → ログアウト扱いになる！

ユーザー A → [サーバー1/2/3 どれでもOK] → 状態は外部（Redis/DB/トークン）に

ステートレス化の具体策

• セッションを Redis や DB に外出しする
• あるいはセッション自体をなくし、署名付きトークン（JWT）をクライアントに持たせる
• ファイルアップロードをローカルディスクではなくオブジェクトストレージ（S3 等）へ

2.3スケーリングの標準的な進化の順番

これは面接で「規模が 10 倍になったら？」と聞かれたときの回答の骨格になります。

【第0段階】1台に全部（Web + DB + ファイル）
       │  ユーザー数千人まで
       ▼
【第1段階】Web と DB を分離
       │  DB の I/O が Web の CPU を邪魔しなくなる
       ▼
【第2段階】Web を複数台 + ロードバランサ
       │  ステートレス化が前提。ここで可用性も上がる
       ▼
【第3段階】キャッシュ導入（Redis / Memcached）
       │  読み取りの 80〜95% を DB から剥がす
       ▼
【第4段階】CDN 導入（静的ファイル・画像・動画）
       │  帯域とレイテンシが劇的に改善
       ▼
【第5段階】DB のリードレプリカ（読み取りスケール）
       │  ここまでで大半のサービスは足りる
       ▼
【第6段階】非同期化（メッセージキュー + ワーカー）
       │  重い処理（メール送信・画像変換・集計）をリクエストから外す
       ▼
【第7段階】DB のシャーディング（書き込みスケール）
       │  ここから複雑さが跳ね上がる。本当に必要か毎回問う
       ▼
【第8段階】サービス分割（マイクロサービス）／マルチリージョン
          組織の規模が理由になることが多い

2.4ボトルネックはどこか（4 つの資源）

システムの限界は必ず次の 4 つのどれかに現れます。どれが先に枯渇するかを常に考えます。

さらに、見落とされがちな「論理的な」資源があります。

• コネクション数（DB の max_connections、ファイルディスクリプタ）
• ロック（同じ行への更新競合）
• スレッド／ワーカープール
• サードパーティ API のレート制限

2.5アムダールの法則とユニバーサルスケーラビリティ

Speedup(N) = 1 / (s + (1-s)/N)

    スループット
      ▲
      │        ／‾‾＼
      │      ／      ＼＿＿   ← 台数を増やすほど遅くなる領域
      │    ／
      │  ／
      └──────────────────► ノード数

「ノードを増やせば線形にスケールするとは限りません。共有リソース（この場合は
 同一シャードへの書き込み）が調整点になるので、シャードキーを見直して
 調整が起きないように分割するのが本質的な解決だと考えます。」

CHAPTER 03概算見積もりの技術

これは面接で最も差がつくスキルです。そして練習すれば必ずできるようになります。

3.1覚えるべき数字（これだけ）

1 日  = 86,400 秒 ≒ 10^5 秒   ← これだけ覚える
1 ヶ月 ≒ 2.6 × 10^6 秒
1 年  ≒ 3.15 × 10^7 秒 ≒ π × 10^7 秒（覚え方:「パイ かける 1000万秒」）

char / ASCII 1 文字 = 1 B      日本語 1 文字 (UTF-8) = 3 B
int = 4 B      long / timestamp / ID = 8 B     UUID = 16 B（文字列表現なら 36 B）
1 KB = 10^3 B    1 MB = 10^6 B    1 GB = 10^9 B    1 TB = 10^12 B    1 PB = 10^15 B

ツイート 1 件（メタ込み）        ≒ 300 B 〜 1 KB
チャットメッセージ 1 件          ≒ 200 B
ユーザーレコード                 ≒ 1 KB
Web ページ (HTML)                ≒ 50〜100 KB
写真（圧縮済み、スマホ）         ≒ 1〜5 MB
サムネイル                       ≒ 20 KB
動画 1 分（1080p, H.264）        ≒ 30〜60 MB（≒ 5 Mbps）
動画 1 分（4K）                  ≒ 200 MB（≒ 25 Mbps）
ログ 1 行                        ≒ 200〜500 B

1 日 100 万リクエスト  ≒ 12 QPS
1 日 1 億リクエスト    ≒ 1,160 QPS ≒ 1.2 K QPS
1 日 10 億リクエスト   ≒ 11.6 K QPS
ピーク QPS = 平均 QPS × 2〜5（サービス次第。SNS なら 2〜3、EC のセールなら 10〜100）

3.2見積もりの手順（5 ステップ）

ステップ 1：ユーザー数から DAU を出す

総登録ユーザー 5 億人 → DAU（1日のアクティブ）は 20〜30% が典型 → 1 億人

ステップ 2：1 人あたりの行動回数を仮定する

1 人 1 日あたり 投稿 0.1 回、閲覧 20 回（読み:書き = 200:1）

ステップ 3：QPS を出す（平均とピーク）

書き込み: 1 億 × 0.1 = 1,000 万/日 ÷ 10^5 = 100 QPS（平均）→ ピーク 300 QPS
読み取り: 1 億 × 20  = 20 億/日   ÷ 10^5 = 20,000 QPS（平均）→ ピーク 60,000 QPS

ステップ 4：ストレージを出す（1 日 → 1 年 → 5 年、レプリカ込み）

1 件 1 KB × 1,000 万/日 = 10 GB/日
→ 年 3.6 TB → 5 年 18 TB
→ レプリカ 3 本 = 54 TB
→ インデックス・オーバーヘッドで ×1.3 ≒ 70 TB

ステップ 5：帯域とマシン台数

読み取り帯域 = 20,000 QPS × 1 KB = 20 MB/s（テキストなら軽い）
※ 画像なら 20,000 × 200 KB = 4 GB/s = 32 Gbps → CDN 必須と即断できる

Web サーバー = ピーク 60,000 QPS ÷ 1 台 5,000 QPS = 12 台 → 冗長込みで 20 台
キャッシュ   = ホットデータ（全体の 20%）= 10 GB/日 × 20% × 7日 = 14 GB → 1 台で足りる

3.3実例：Twitter 風サービスの見積もり

「数字を置きます。ざっくりで良いので確認しながら進めます。

 DAU を 2 億人とします。1 人 1 日 2 回投稿、200 回タイムラインを見るとします。

 【書き込み】2 億 × 2 = 4 億ツイート/日。10^5 で割って 4,000 QPS。
       ピークは 3 倍で 12,000 QPS。

 【読み取り】2 億 × 200 = 400 億回/日 = 40 万 QPS。ピーク 120 万 QPS。
       読み:書き = 100:1 なので、読み取り最適化が設計の中心になります。

 【ストレージ】ツイート本文 300 B にメタデータを足して 1 KB とすると、
       4 億 × 1 KB = 400 GB/日、年 146 TB。5 年で 730 TB、レプリカ 3 本で 2.2 PB。
       これは単一 DB では無理なので、シャーディング前提です。

       ただし画像・動画が入ると桁が変わります。仮に 10% のツイートに
       1 MB の画像が付くとすると、4,000 万 × 1 MB = 40 TB/日、年 15 PB。
       これはオブジェクトストレージ + CDN で扱います。

 【メモリ】直近 3 日分のツイートをキャッシュすると 400 GB × 3 = 1.2 TB。
       1 台 128 GB のキャッシュノードなら 10〜20 台のクラスタになります。」

3.4見積もりの作法

CHAPTER 04性能を語るための言葉

4.1レイテンシとスループット

• レイテンシ (latency)：1 件の処理にかかる時間。単位は ms。
• スループット (throughput)：単位時間あたりに処理できる件数。単位は QPS / RPS / TPS。

4.2平均を信じてはいけない — パーセンタイル

100 件のリクエストのうち 99 件が 10 ms、1 件が 5,000 ms だったとします。

• 59.9 ms平均（実態を全く表していない）
• 10 msp50（中央値）
• 5,000 msp99 ← 一部のユーザーは 5 秒待たされている

なぜテール（p99 以上）が重要か

1. 遅いユーザーほど、たいていデータが多い（＝重要な顧客）
2. 1 ページが 100 個のサービス呼び出しをする場合、各サービスの p99 が 100 ms なら、そのページの 63% が 100 ms 超になる（1 – 0.99^100 = 63%）。これは、各呼び出しが独立で、同時並行に評価され、共通の予算・相関障害・短絡がないという単純化した計算です。実システムでは依存グラフと相関を測定します。これをテイルレイテンシ増幅 (tail latency amplification) と呼びます。

「SLO は平均ではなく p99 で定義します。1 リクエストが内部で 20 個のサービスを呼ぶので、
 個々の p99 がそのままページ全体の体感に増幅されるためです。
 対策としてはヘッジドリクエスト（一定時間で返らなければ別レプリカにも投げる）
 を検討します。」

4.3リトルの法則

L = λ × W

L : システム内に同時に存在するリクエスト数（並行数）
λ : 到着レート（QPS）
W : 1 件の平均滞在時間（レイテンシ）

使い方 1：スレッド数の決定

1,000 QPS で、1 件の処理に 50 ms かかる
→ L = 1000 × 0.05 = 50
→ 同時に 50 件が処理中 → 最低 50 スレッド（or 50 コネクション）が必要

使い方 2：限界の把握

DB のコネクションプールが 20 本、1 クエリ 10 ms
→ λ = L / W = 20 / 0.01 = 2,000 QPS が上限
これを超えたリクエストはプール待ちで、レイテンシが跳ね上がる

4.4使用率とレイテンシの非線形な関係

W = S / (1 - ρ)      S: 1 件のサービス時間、ρ: 使用率（0〜1）

 レイテンシ
   ▲                          ／
   │                        ／
   │                    ／
   │              ＿／
   │  ＿＿＿＿／
   └────────────────────────► 使用率
     0%   50%   70%  85%  95% 100%
                        ↑ ここから先は崖

4.5性能に関する用語の整理