エピローグ ── システム設計の「思考法」を身につける

---

シリーズを振り返って

このシリーズで扱った7つのテーマを、背景の CS 概念と対応させて振り返ろう。

graph TD
    subgraph データ構造・アルゴリズム
        A1[ハッシュ関数 → 短縮URL]
        A2[転置インデックス → 検索エンジン]
        A3[Bloom Filter → S3]
        A4[LRU/LFU → Redis]
        A5[BM25/TF-IDF → 検索ランキング]
    end

    subgraph 分散システム
        B1[一貫性ハッシュ → S3・Redis Cluster]
        B2[CAP定理 → AlloyDB・Spanner]
        B3[Paxos/Raft → 分散合意]
        B4[パーティション → Kafka・検索シャード]
    end

    subgraph ストレージ設計
        C1[LSM-Tree → Kafka・Elasticsearch]
        C2[WAL → AlloyDB レプリケーション]
        C3[MVCC → トランザクション]
        C4[イレイジャーコーディング → S3]
    end

    subgraph 並行性制御
        D1[Lua スクリプト → Redis レートリミット]
        D2[分散ロック → Thundering Herd 対策]
        D3[ゼロコピー → Kafka スループット]
    end

---

各テーマで共通して現れた「設計の問い」

シリーズを通じて、同じ問いが何度も登場した。

問い1：「事前計算 vs. 逐次計算」

検索エンジン：クエリ時に全文書をスキャンしない → インデックスを事前構築
S3：データの位置を実行時に計算しない → ハッシュで事前にノードを決定
Redis：期限切れチェックを全キーに走らせない → TTL を設定して OS に委ねる

パフォーマンスの壁にぶつかったとき、「何を事前に計算しておけるか」を問うことが突破口になる。

問い2：「強整合性 vs. 結果整合性」

決済・在庫：強整合性が必要（Spanner, 2PC）
ユーザープロフィールキャッシュ：結果整合性で十分（Cache-Aside + TTL）
ログ・分析データ：最終的に集まればいい（Kafka + バッチ処理）

「整合性が崩れたとき、ビジネス上の被害は何か」から要件を決める。強整合性はレイテンシと可用性のコストを伴う。

問い3：「状態をどこに持つか」

ステートレス（APIサーバー）：水平スケールが容易・フェイルオーバーが速い
ステートフル（DB・キャッシュ）：スケールに工夫が必要・データ保全が責任範囲

水平スケールを妨げるのは「状態」だ。ステートレスにできる部分を最大化し、状態を専用コンポーネント（DB・キャッシュ・キュー）に集約する設計が、現代のクラウドアーキテクチャの基本だ。

問い4：「どこで失敗しうるか」

単一障害点（SPOF）の排除：
  DB: Read レプリカ + フェイルオーバー
  キャッシュ: Redis Sentinel / Cluster
  メッセージキュー: Kafka の ISR（In-Sync Replicas）
  ID 生成: 複数の ID サーバー

信頼性の設計は「どこが落ちても全体が止まらない」構成を積み上げることだ。

---

技術面接でのシステム設計問題に臨む思考フレーム

面接官の「〜を設計してください」には、以下の順序で答えると評価が高い。

Step 1：要件の明確化（5分）
  - 何のためのシステムか（ユースケース）
  - スケール感（ユーザー数・QPS・データ量）
  - 非機能要件（レイテンシ・可用性・整合性）
  - 何をスコープ外とするか

Step 2：概算（Back-of-the-Envelope）（5分）
  - QPS の計算
  - ストレージの見積もり
  - 帯域幅の見積もり
  → ここで「どんな技術的問題が生じるか」が見える

Step 3：高レベル設計（10分）
  - コンポーネントとデータフローの図解
  - 主要な設計判断（DB選択・キャッシュの有無・非同期化など）

Step 4：深掘り（15分）
  - ボトルネックの特定
  - スケールアウトの方法
  - 障害シナリオと対応
  - トレードオフの明示

Step 5：まとめ（5分）
  - 設計のトレードオフを整理
  - 実世界でこれに近いシステムがあれば言及

面接官が見ているのは正解を知っているかではなく、問題を構造化し、トレードオフを認識して、根拠を持って判断できるかだ。

---

「知識」から「設計力」への橋渡し

このシリーズで扱った知識は、読んだだけでは定着しない。以下を実践することを強く勧める。

実践1：ミニ実装

各章のコードサンプルを実際に動かしてみる。

# LRU キャッシュを自分で実装して動かす
# 一貫性ハッシュのリングを可視化する
# Kafka の Consumer Group を手元のローカルで試す

「動く」実感を持つことで、抽象的な概念が具体的な理解になる。

実践2：実際のシステムのアーキテクチャを読む

大手企業のエンジニアリングブログには、このシリーズで扱った概念が実際にどう使われているかが詳しく書かれている。

- AWS Architecture Blog（S3・DynamoDB の設計詳細）
- Google Research（Spanner・Bigtable の論文）
- Confluent Blog（Kafka の深掘り記事）
- Shopify Engineering（大規模 Rails の水平スケール事例）
- Netflix Tech Blog（Chaos Engineering・キャッシュ設計）

実践3：設計問題を声に出して解く

ひとりで問題を考えるのと、声に出して説明しながら考えるのでは、理解の深さが違う。

- 友人・同僚と模擬面接
- Slack/Discord のエンジニアコミュニティで設計を議論
- ブログに設計案を書いて公開（フィードバックをもらう）

---

参考文献・情報源

書籍

• Designing Data-Intensive Applications（DDIA） - Martin Kleppmann
  分散システムの教科書として最も定評がある。このシリーズの多くの概念はここに端を発している。

• System Design Interview Vol.1, Vol.2 - Alex Xu
  面接準備の入門書として最適。本シリーズの問題設定はここから多く引用している。

• Database Internals - Alex Petrov
  LSM-Tree・B-Tree・レプリケーションの詳細を扱う。

論文・技術資料

• Google Spanner 論文（2012） - TrueTime の原著
• Amazon Dynamo 論文（2007） - 一貫性ハッシュの実用事例
• Kafka 論文（2011） - Kafka の設計思想
• Elasticsearch リファレンス - Lucene/セグメントの詳細

ブログ

• High Scalability - 大規模システムの事例集
• Martin Fowler’s Blog - アーキテクチャパターンの解説
• The Morning Paper - 論文要約（停止中だが過去記事が充実）

---

最後に

システム設計に「完璧な答え」はない。あるのは「与えられた制約のもとでのベストなトレードオフ」だ。

10億ユーザーのシステムを設計した経験がなくても、その問題を分解し、適切なCS概念を当てはめ、トレードオフを説明できるエンジニアは、実務でも面接でも信頼される。

このシリーズがその思考の補助輪になれば幸いだ。

＋ － ⟳ ✕