システムデザインフレームワーク

大規模分散システムを設計するための体系的なアプローチです。新しいサービスを構築する際、システムデザインを見直す際、容量計画を立てる際、またはシステムデザインの議論に備える際に、これらの原則を適用してください。

コア原則

要件から始め、ソリューションから始めるな。 すべてのシステムデザインは、何を、誰のために、どのスケールで構築しているのかを明確にすることから始まります。制約条件を理解する前にアーキテクチャに飛び込むと、過度に複雑化されたまたは過度に単純化されたシステムになります。

基礎： スケーラブルなシステムは一から発明されるのではなく、よく理解されたビルディングブロック(ロードバランサー、キャッシュ、キュー、データベース、CDN)が明確なデータフローでつながった形で組み立てられます。スキルは正しいブロックを選択し、適切に規模を設定し、各選択がもたらすトレードオフを理解することにあります。4段階のプロセス(スコープ、高レベル設計、詳細分析、まとめ)により、設計は焦点が定まり、伝わりやすくなります。

スコアリング

目標: 10/10。 システムデザインをレビューまたは作成する際、以下の原則への適合性に基づいて0～10の評価をしてください。10/10は、要件を明確に述べ、バックオブザエンベロープ推定を含み、適切なビルディングブロックを使用し、スケーリングと信頼性に対応し、トレードオフを認識していることを意味します。低いスコアは対処すべきギャップを示しています。常に現在のスコアを提供し、10/10に到達するために必要な具体的な改善を示してください。

システムデザインフレームワーク

信頼性があり、スケーラブルな分散システムを構築するための6つの領域:

1. 4段階プロセス

コア概念： すべてのシステムデザインは4つの段階に従います: (1)問題を理解し設計の範囲を確立する、(2)高レベル設計を提案し合意を得る、(3)重要なコンポーネントを詳しく分析する、(4)トレードオフと今後の改善でまとめる。

なぜ機能するのか： 体系的なプロセスがなければ、設計は抽象的なままか、時期尚早な詳細に埋もれるかのいずれかになります。4段階アプローチにより、時間を比例的に投資できます——まず大まかに、重要な部分だけ詳しく。

主要インサイト:

• ステップ1は約5～10分: 澄み切った質問を行い、機能要件と非機能要件をリストアップし、スケール(DAU、QPS、ストレージ)に合意する
• ステップ2は約15～20分: API、サービス、データストア、データフロー矢印を含む高レベル図を描く
• ステップ3は約15～20分: 最も難しいまたは最も重要な2～3個のコンポーネントを選び、詳しく設計する
• ステップ4は約5分: トレードオフをまとめ、ボトルネックを特定し、今後の改善を提案する
• ステップ1をスキップしない——スコープの曖昧さは設計努力の無駄につながる
• 進める前に仮定について明示的な合意を得る

コード適用例:

コンテキスト	パターン	例
新しいサービスのキックオフ	コーディングの前に、4段階すべてを含む1ページの設計ドキュメントを作成する	要件、APIコントラクト、データモデル、容量推定、その後実装
アーキテクチャレビュー	レビュアーを4段階を通じて順序立てて説明する	スコープ、高レベル図、最もリスクの高いコンポーネントの詳細分析、未解決の質問
インシデント事後分析	失敗を4段階レンズを通して遡る	どの要件が見落とされたか? どのビルディングブロックが失敗したか? どのトレードオフが引っかかったか?

参照: references/four-step-process.md

2. バックオブザエンベロープ推定

コア概念： 2乗数、レイテンシ数値、単純な算術を使用して、アーキテクチャに確定する前にQPS、ストレージ、帯域幅、サーバー数を推定します。

なぜ機能するのか： 推定は2つの失敗モードを防ぎます: 過度にプロビジョニング(お金の無駄)と不十分なプロビジョニング(負荷下での停止)。2分の計算は数週間の手直しを救うことができます。

主要インサイト:

• 2の累乗を知る: 2^10 = 1千、2^20 = 1百万、2^30 = 10億、2^40 = 1兆
• メモリ読み取り ~100 ns、SSD読み取り ~100 us、ディークシーク ~10 ms、同じデータセンター往復 ~0.5 ms、大陸間 ~150 ms
• 可用性の9: 99.9% = 年間8.77時間ダウンタイム、99.99% = 年間52.6分
• QPS推定: DAU × 1日あたりの平均アクション数 / 86,400秒; ピークQPSは通常平均の2～5倍
• ストレージ推定: 1日あたりのレコード数 × レコードサイズ × 保持期間
• 常に積極的に丸める——目標は精密性ではなく、大きさの桁

コード適用例:

コンテキスト	パターン	例
容量計画	QPSを推定し、成長係数を掛ける	1億DAU × 5アクション / 86400 = 約5,800 QPS平均、約30K QPS ピーク
ストレージ予算	レコードごとのサイズと量と保持期間を掛ける	5億ツイート/日 × 300バイト × 365日 = 年間約55 TB
SLA定義	可用性の9を許容ダウンタイムに変換する	4つの9 (99.99%) = 年間約52分ダウンタイム

参照: references/estimation-numbers.md

3. ビルディングブロック

コア概念： スケーラブルなシステムは標準的なツールキットから組み立てられます: DNS、CDN、ロードバランサー、リバースプロキシ、アプリケーションサーバー、キャッシュ、メッセージキュー、一貫性ハッシング。

なぜ機能するのか： 各ブロックは特定のスケーリングまたは信頼性の問題を解決します。各ブロックをいつどのように導入するかを知ることで、時期尚早な複雑さと回避可能なボトルネックの両方を防ぎます。

主要インサイト:

• DNSはドメイン名を解決します; CDNは静的資産をユーザーの近くのエッジロケーションでキャッシュします
• ロードバランサーはトラフィックを分散させます——L4(トランスポート層、高速、シンプル) 対 L7(アプリケーション層、コンテンツ対応ルーティング)
• キャッシング層: クライアント側、CDN、ウェブサーバー、アプリケーション(例: Redis/Memcached)、データベースクエリキャッシュ
• キャッシュ戦略: キャッシュアサイド(アプリが管理)、リードスルー(キャッシュが読み取りを管理)、ライトスルー(キャッシュが同期的に書き込みを管理)、ライトビハインド(キャッシュが非同期に書き込みを管理)
• メッセージキュー(Kafka、RabbitMQ、SQS)はプロデューサーとコンシューマーを分離し、トラフィックスパイクを吸収し、非同期処理を有効にします
• 一貫性ハッシングは、ノードが追加または削除されるときに最小限の再分配でキーをノード全体に分散させます

コード適用例:

コンテキスト	パターン	例
読み取り集約的なワークロード	データベースの前にキャッシュアサイドとRedisを追加する	TTL付きのユーザープロフィールをキャッシュし、書き込み時に無効化
トラフィックスパイク	APIとワーカー間にメッセージキューを挿入する	画像リサイズジョブをエンキューし、ワーカーは自分のペースでプル
グローバルユーザー	静的資産の前にCDNを配置する	エッジからJS/CSS/イメージを提供; オリジンはAPIのみ提供
不均等な負荷	一貫性ハッシングをシャード割り当てに使用する	ノードを追加し、約1/nのキーだけ移動する必要がある

参照: references/building-blocks.md

4. データベース設計とスケーリング

コア概念： データベース形状とアクセスパターンに基づいてSQLとNoSQLを選択し、まず垂直スケーリング、水平スケーリング(レプリケーションとシャーディング)が必要になったら適用します。

なぜ機能するのか： データベースは通常、最初のボトルネックです。レプリケーション、シャーディング戦略、非正規化トレードオフを理解すれば、高価な再アーキテクチャを遅延させ、成長を意図的に計画できます。

主要インサイト:

• 垂直スケーリング(より大きいマシン)はシンプルですが上限があります; 水平スケーリング(より多くのマシン)はより難しいですがほぼ無制限です
• レプリケーション: リーダー・フォロワー(1つのライター、多くのリーダー)は読み取り集約的; マルチリーダーは複数リージョンの書き込み
• シャーディング戦略: ハッシュベース(均等分布、難しい範囲クエリ)、範囲ベース(効率的な範囲クエリ、ホットスポットのリスク)、ディレクトリベース(柔軟、追加ルックアップ)
• SQLは ACID トランザクション、複雑なジョイン、定義されたスキーマが必要な場合; NoSQL は柔軟なスキーマ、水平スケール、または非常に高い書き込みスループットが必要な場合
• 非正規化は、ストレージと書き込み複雑さをより高速な読み取りと引き換えにします——読み取りパフォーマンスが重要でデータが頻繁に変わらない場合に使用します
• 有名人/ホットスポット問題: 1つのシャードが不釣り合いなトラフィックを受け取る場合、セカンダリパーティショニングまたはキャッシング層を追加します

コード適用例:

コンテキスト	パターン	例
読み取り集約的なAPI	リーダー・フォロワーレプリケーション(読み取りレプリカ)	読み取りをレプリカにルーティング、書き込みをリーダーにルーティング; レプリケーションラグを許容
スケール時のユーザーデータ	user_idに基づくハッシュシャーディング	シャードキー = hash(user_id) % num_shards; 均等分布、各シャード独立
分析ダッシュボード	読み取り最適化された物理化ビューに非正規化	毎晩事前ジョイン・集約; 物理化テーブルからダッシュボード提供
複数リージョンアプリ	競合解決を伴うマルチリーダーレプリケーション	各リージョンにリーダー; ラストライトウインズまたはアプリケーションレベルのマージ

参照: references/database-scaling.md

5. 一般的なシステムデザイン

コア概念： ほとんどのシステムは、よく知られた少数の設計の変形です: URL短縮機、レート制限機、通知システム、ニュースフィード、チャットシステム、検索オートコンプリート、ウェブクローラー、一意ID生成器。

なぜ機能するのか： 一般的なデザインを研究することで、パターンとトレードオフの精神的ライブラリを構築できます。新しい問題が到来したとき、どの既知のデザインが最も類似しているかを認識し、一から発明するのではなく適応させることができます。

主要インサイト:

• URL短縮機: base62エンコーディング、キー・バリューストア、301対302リダイレクトトレードオフ、リダイレクトログイングによる分析
• レート制限機: トークンバケットまたはスライディングウィンドウアルゴリズム、APIゲートウェイまたはミドルウェアに配置、429をRetry-Afterヘッダーで返す
• ニュースフィード: ファンアウト・オン・ライト(投稿時にフォロワーキャッシュにプッシュ)対ファンアウト・オン・リード(読み取り時にプルしてマージ); 有名人アカウント向けハイブリッド
• チャットシステム: リアルタイム双方向通信用WebSocket、配信保証用メッセージキュー、ハートビート経由のプレゼンスサービス
• 検索オートコンプリート: トライデータ構造、トップkの頻繁なクエリ、人気プレフィックスの結果を事前計算・キャッシュ
• ウェブクローラー: URL境界でBFS、礼儀(robots.txt、ドメインごとのレート制限)、コンテンツハッシュを使った重複排除
• 一意ID生成器: UUID(シンプル、協調不要)対Snowflake(タイム・ソート可能、64ビット、データセンター対応)

コード適用例:

コンテキスト	パターン	例
短いリンクサービス	オートインクリメントIDまたはハッシュをbase62エンコード	https://short.ly/a1B2c3 はキー・バリューストアの行にマップ
API保護	ゲートウェイのトークンバケットレート制限機	API キーごと100トークン/分; 定期的にリフィル; 429で拒否
ソーシャルフィード	ハイブリッドファンアウト: 通常ユーザーはプッシュ、有名人はプル	1万人未満のフォロワー数のアカウント向けフィードを事前計算; 有名人投稿は読み取り時にマージ
分散ID	Snowflake: タイムスタンプ + データセンター + マシン + シーケンス	64ビット、タイム・ソート可能、ジェネレータ間の協調不要

参照: references/common-designs.md

6. 信頼性と運用

コア概念： システムは、稼働し続け、失敗から回復し、観察される能力と同じくらい良いです。ヘルスチェック、モニタリング、ロギング、デプロイメント戦略は事後的な考慮ではなく、第一級の設計上の関心事です。

なぜ機能するのか： 本番システムは、設計図が決して予測しない方法で失敗します。運用上の準備——メトリクス、アラート、ロールバック計画、冗長性——は、失敗が軽微な問題になるか大きな障害になるかを決定します。

主要インサイト:

• ヘルスチェック: ライブネス(プロセスは生きているか?)と読み込み準備状態(トラフィックを提供できるか?) ——Kubernetes は両方を使用
• モニタリングスタック: メトリクス(Prometheus、Datadog)、ログ(ELK、CloudWatch)、トレーシング(Jaeger、Zipkin)——観測可能性の3本柱
• デプロイメント戦略: ローリング(段階的交換)、ブルーグリーン(2つの同一環境、即座の切り替え)、カナリア(最初に小さいパーセンテージ、その後拡張)
• ディザスターリカバリー: RPO(どれくらい多くのデータを失うことができるか)とRTO(回復までのどのくらい長いか)がバックアップとフェイルオーバー戦略を定義
• 複数データセンター: アクティブ・パッシブ(フェイルオーバー)またはアクティブ・アクティブ(両方が提供); アクティブ・アクティブはデータ同期と競合解決が必要
• オートスケーリング: CPU、メモリ、キューの深さ、またはカスタムメトリクスでスケール; 常に最小と最大インスタンス数の両方を設定

コード適用例:

コンテキスト	パターン	例
ダウンタイムなしデプロイ	ヘルスチェックゲート付きブルーグリーン	ヘルスチェックが通った後、グリーンにトラフィックをルーティング; ブルーは即座のロールバックとして保持
段階的ロールアウト	メトリクス比較付きカナリアデプロイ	新バージョンに5%のトラフィック送信; エラー率とレイテンシを比較; 昇進またはロールバック
失敗検出	ライブネスと読み込み準備プローブ	/healthz は生きていれば200を返す; /ready はデータベースが接続され、キャッシュがウォーム状態であれば200を返す
データ安全性	RPO/RTO を定義し、それに応じて実装	RPO = 1時間は1時間ごとのバックアップを意味する; RTO = 5分は自動フェイルオーバーを意味する

参照: references/reliability-operations.md

一般的な間違い

間違い	失敗する理由	修正
要件を明確にせずにアーキテクチャに飛び込む	間違った問題を解決するか、重要な制約を見落とす	最初の5～10分をスコープに費やす: 機能、スケール、SLA
バックオブザエンベロープ推定がない	1桁以上多い/少ないでプロビジョニング	QPS、ストレージ、帯域幅を推定してからコンポーネントを選択
単一障害点	1つのコンポーネントが失敗するとシステム全体が機能しなくなる	すべての層で冗長性を追加: マルチサーバー、マルチAZ、マルチリージョン
時期尚早なシャーディング	必要になる前に巨大な運用複雑さを追加	垂直スケール、読み取りレプリカを追加、積極的にキャッシュ、最後にシャード
無効化戦略なしのキャッシング	古いデータはバグと混乱を引き起こす	TTL を定義し、キャッシュアサイド with 書き込み時の明示的無効化
どこでも同期呼び出し	1つの遅いダウンストリームサービスがすべての呼び出し元のレイテンシをカスケード	非レイテンシクリティカルパスにメッセージキューを使用; 同期呼び出しにタイムアウトを設定
有名人/ホットスポット問題を無視	1つのシャードまたはキャッシュキーがハンマーされ、その他はアイドル	ホットキーを検出、セカンダリパーティショニングを追加、またはローカルキャッシュを使用
モニタリングまたはアラート機能なし	ユーザーからではなくダッシュボードから障害を知る	メトリクス、ログ、トレースを最初から実装

クイック診断

質問	いいえの場合	アクション
機能要件と非機能要件は明示的にリストアップされていますか?	設計は仮定に基づいている	機能、DAU、QPS、ストレージ、レイテンシ SLA、可用性 SLA を書き出す
QPS とストレージのバックオブザエンベロープ推定がありますか?	容量は推測	計算: DAU × アクション / 86400 for QPS; レコード × サイズ × 保持期間 for ストレージ
図内のすべてのコンポーネントは冗長ですか?	単一障害点が存在	各コンポーネントにレプリカ、フェイルオーバー、またはマルチAZを追加
データベーススケーリング戦略は定義されていますか?	成長下で壁に当たる	計画: 垂直スケール、その後読み取りレプリカ、その後クリアなシャードキーでシャーディング
読み取り集約的なパスのキャッシング層があります?	データベースは不要な負荷を取る	Redis/Memcached をキャッシュアサイドで追加し、定義済みのTTL
非同期パスはメッセージキューを使用していますか?	密結合、カスケード失敗	バックグラウンドジョブ、通知、分析用 Kafka/SQS で分離
モニタリングとアラート計画があります?	本番環境での失敗に盲目	メトリクス、ログ集約、トレーシング、アラート閾値を定義
デプロイメント戦略は定義されていますか?	リスク高いオールアットワンスリリース	ローリング、ブルーグリーン、または自動ロールバック付きカナリアを選択

参照ファイル

• four-step-process.md: 各段階の時間配分、質問例、ヒントを含む完全な4段階プロセス
• estimation-numbers.md: 2の累乗、レイテンシ数値、可用性9、解き方例付きQPS/ストレージ/帯域幅推定
• building-blocks.md: DNS、CDN、ロードバランサー、キャッシング戦略、メッセージキュー、一貫性ハッシング
• database-scaling.md: SQL対NoSQL、レプリケーション、シャーディング戦略、非正規化、データベース選択ガイド
• common-designs.md: URL短縮機、レート制限機、ニュースフィード、チャットシステム、検索オートコンプリート、ウェブクローラー、一意ID生成器
• reliability-operations.md: ヘルスチェック、モニタリング、ログ、デプロイメント戦略、ディザスターリカバリー、オートスケーリング

さらなる学習

このスキルは Alex Xu の実践的なシステムデザイン方法論に基づいています。詳細な図とウォークスルーを含む完全なガイドについては:

• "System Design Interview -- An Insider's Guide" by Alex Xu (Volume 1)
• "System Design Interview -- An Insider's Guide: Volume 2" by Alex Xu (Volume 2)
• "Designing Data-Intensive Applications" by Martin Kleppmann (データシステム基礎への深い掘り下げ)
• ByteByteGo -- Alex Xuの視覚的システムデザイン説明プラットフォーム

著者について

Alex Xu はソフトウェアエンジニアであり、システムデザインを学ぶための最も人気のあるプラットフォームの1つである ByteByteGo の創作者です。彼の2巻の System Design Interview シリーズは、あらゆるレベルのエンジニアのための事実上の準備リソースになり、50万部以上が売られています。Xuのアプローチは、構造的思考、バックオブザエンベロープ推定、設計決定のクリアな伝達を強調しています。ByteByteGo 以前は、Twitter、Apple、Oracleで働いていました。彼のビジュアル説明と段階的なフレームワークは、システムデザインを従来の不透明なトピックから学習可能で繰り返し可能なスキルに変えて、幅広いエンジニアリング聴衆にアクセス可能にしました。