system-design

システム設計フレームワーク

大規模な分散システムを設計するための体系的なアプローチです。新しいサービスのアーキテクチャ設計、設計レビュー、キャパシティの見積もり、システム設計に関する議論の準備に、これらの原則を適用してください。

基本原則

解決策ではなく、要件から始めてください。 制約を理解する前にアーキテクチャに飛びつくと、過剰設計または設計不足のシステムになります。スケーラブルなシステムは、よく理解された構成要素（ロードバランサー、キャッシュ、キュー、データベース、CDN）から組み立てられます。重要なのは、適切な構成要素を選び、見積もりに基づいてサイズを決め、それぞれの選択がもたらすトレードオフを把握することです。

スコアリング

目標：10/10。 8つのクイック診断項目のうち、設計が満たす項目数に基づいて採点します — score = round(passed / 8 × 10)：9〜10 = すべて、またはほぼすべての項目を満たす — 要件が明示され、実際の見積もり、冗長性、明示されたDBスケーリング戦略とキャッシュ戦略、キューを介した非同期処理、モニタリング、デプロイ計画があり、トレードオフが示されている。5〜6 = 設計は機能するものの、見積もり、冗長性、または運用が省かれている。<=3 = 要件や見積もりがないままアーキテクチャを提案している。現在のスコアを必ず示し、不合格の診断項目を挙げ、それぞれに具体的な修正方法を示してください。

システム設計フレームワーク

信頼性とスケーラビリティに優れた分散システムを構築するための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段階の観点から障害をたどる	どの要件を見落としたか？ どの構成要素が故障したか？ どのトレードオフが問題を招いたか？

設計を最初から最後まで進める際は、references/four-step-process.md を参照してください。各段階の時間配分、明確化のための質問例、4つの各ステップのヒントが記載されています。

2. 概算見積もり

基本概念： 2の累乗、レイテンシの数値、簡単な計算を使って、アーキテクチャを決定する前に QPS、ストレージ、帯域幅、サーバー台数を見積もります。

効果がある理由： 見積もりにより、過剰なプロビジョニング（無駄なコスト）やプロビジョニング不足（負荷時の停止）を防げます。2分の計算で、何週間もの手戻りを防げることがあります。

主なポイント：

• 2の累乗：2^10 ≈ 1千、2^20 ≈ 100万、2^30 ≈ 10億、2^40 ≈ 1兆
• レイテンシ：メモリ読み取り ~100 ns、SSD 読み取り ~100 us、ディスクシーク ~10 ms、同一データセンター内の往復 ~0.5 ms、大陸間 ~150 ms
• 可用性のナイン：99.9% = 年間 8.77 時間のダウンタイム、99.99% = 年間 52.6 分のダウンタイム
• QPS：DAU x 1日あたりのアクション数 / 86,400 秒。ピークは通常、平均の2～5倍です
• ストレージ：1日あたりのレコード数 x レコードサイズ x 保持期間
• 大まかに丸めます。目的は桁の把握であり、精度ではありません

コードでの適用例：

コンテキスト	パターン	例
キャパシティプランニング	QPS を見積もり、成長係数を掛ける	100M DAU x 5 アクション / 86400 = 平均 ~5,800 QPS、ピーク ~30K
ストレージ予算の策定	レコードあたりのサイズ x 件数 x 保持期間	1日あたり 500M 件のツイート x 300 bytes x 365 days = 年間 ~55 TB
SLA の定義	ナインを許容ダウンタイムに換算する	フォーナイン = 年間 ~52 分のダウンタイム

システムの規模を見積もる際は、references/estimation-numbers.md を参照してください。レイテンシの全一覧、可用性のナインの一覧、QPS／ストレージ／帯域幅の計算例が記載されています。

3. 基本コンポーネント

基本概念： スケーラブルなシステムは、DNS、CDN、ロードバランサー、リバースプロキシ、アプリケーションサーバー、キャッシュ、メッセージキュー、一貫性ハッシュという標準的なツールキットを組み合わせて構築します。

効果がある理由： 各コンポーネントは、あるコストを別のコストと引き換えにします（キャッシュは読み取り速度のために鮮度を犠牲にし、キューは疎結合のためにレイテンシを犠牲にします）。そのため、特定のボトルネックが現れてから導入します。最初からすべてを追加すると、障害の可能性が増えるだけです。

主なポイント：

• ロードバランサー：L4（トランスポート層 — 高速でシンプル）と L7（アプリケーション層 — コンテンツを認識したルーティング）
• キャッシュ層：クライアント、CDN、ウェブサーバー、アプリケーション（Redis/Memcached）、データベースのクエリーキャッシュ
• キャッシュ戦略：キャッシュアサイド（アプリが管理）、リードスルー、ライトスルー（同期）、ライトビハインド（非同期）
• メッセージキュー（Kafka、RabbitMQ、SQS）：プロデューサーとコンシューマーを分離し、急増する負荷を吸収して、非同期処理を可能にします
• 一貫性ハッシュ：ノードが変わったときの再分配を最小限に抑えながら、キーをノード間に分散します

コードでの適用例：

コンテキスト	パターン	例
読み取り中心のワークロード	データベースの前段に Redis を配置するキャッシュアサイド	ユーザープロフィールを TTL 付きでキャッシュし、書き込み時に無効化する
トラフィックの急増	API とワーカーの間にメッセージキューを配置する	画像リサイズのジョブをキューに登録し、ワーカーがそれぞれのペースで取得する
グローバルユーザー	静的アセットに CDN を使用する	JS/CSS/画像をエッジから配信し、オリジンは API のみを提供する
負荷の偏り	シャード割り当てに一貫性ハッシュを使用する	ノードを追加すると、移動するキーは ~1/n のみ

コンポーネントを選ぶ際は、references/building-blocks.md を参照してください。DNS、CDN、ロードバランサー、キャッシュ戦略、メッセージキュー、一貫性ハッシュのそれぞれの仕組みと、導入するタイミングについて説明しています。

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

中核となる考え方： データの形状とアクセスパターンに基づいて SQL と NoSQL のどちらを使うかを選びます。まずは垂直スケーリングを行い、垂直スケーリングの限界に達したら、レプリケーションやシャーディングによって水平スケーリングします。

効果がある理由： 通常、最初のボトルネックになるのはデータベースです。レプリケーション、シャーディング、非正規化のトレードオフを理解しておくことで、コストのかかる再設計を先延ばしにし、計画的に成長できるようになります。

主なポイント：

• 垂直スケーリングは簡単ですが上限があります。水平スケーリングは難しいものの、ほぼ無制限に拡張できます
• レプリケーション：読み取りが多い場合はリーダー・フォロワー（書き込みは1台、読み取りは複数台）、複数リージョンで書き込みを行う場合はマルチリーダーを使います
• シャーディング：ハッシュベース（均等に分散できますが、範囲クエリは困難です）、範囲ベース（範囲指定は簡単ですが、ホットスポットのリスクがあります）、ディレクトリベース（柔軟ですが、追加のルックアップが必要です）
• ACID トランザクション、結合、定義済みスキーマには SQL を、柔軟なスキーマ、水平スケーリング、非常に高い書き込みスループットには NoSQL を使います
• 非正規化は、読み取り速度のためにストレージ容量と書き込みの複雑さを犠牲にします。読み取りが多く、データの変更がまれな場合に使います
• セレブリティ／ホットスポット問題：特定のシャードに負荷が集中した場合は、二次パーティショニングまたはキャッシュレイヤーが必要です

コードの適用例：

コンテキスト	パターン	例
読み取りが多い API	リードレプリカを使ったリーダー・フォロワー	読み取りはレプリカに、書き込みはリーダーに送ります。わずかな遅延を許容します
大規模なユーザーデータ	user_id に基づくハッシュベースのシャーディング	hash(user_id) % num_shards。均等で独立したシャードになります
分析ダッシュボード	非正規化したマテリアライズドビュー	毎晩、結合と集計を事前に行い、マテリアライズドテーブルから提供します

データベースがボトルネックになっている場合は、references/database-scaling.md を参照してください。レプリケーションのトポロジー、3つのシャーディング戦略の比較、非正規化のトレードオフ、SQL と NoSQL の選択ガイドを紹介しています。

5. よく使われるシステム設計

中核となる考え方： ほとんどのシステムは、URL 短縮サービス、レートリミッター、通知システム、ニュースフィード、チャット、検索オートコンプリート、Web クローラー、一意 ID 生成器といった、よく知られた少数の設計パターンを組み合わせたものです。

効果がある理由： よく知られた設計パターンを蓄えておくことで、新しい問題がどのパターンに似ているかを把握し、ゼロから考案するのではなく、既存のパターンを応用できます。

主なポイント：

• URL 短縮サービス：Base62 エンコーディング、キー・バリューストア、301 と 302 リダイレクトのトレードオフ（キャッシュと分析）
• レートリミッター：ゲートウェイでのトークンバケットまたはスライディングウィンドウ。429 と Retry-After を返します
• ニュースフィード：ファンアウト・オン・ライト（投稿時にプッシュ）とファンアウト・オン・リード（読み取り時に取得）。セレブリティにはハイブリッド方式を使います
• チャット：リアルタイムの双方向メッセージには WebSocket、配信保証にはキュー、接続状況の管理にはハートビートサービスを使います
• オートコンプリート：頻出クエリ上位 k 件のトライ木。人気のあるプレフィックスを事前計算してキャッシュします
• Web クローラー：URL フロンティアを使った BFS、礼儀正しいクロール（robots.txt、ドメインごとのレート制限）、コンテンツハッシュによる重複排除
• 一意 ID：UUID（シンプルで調整不要）と Snowflake（64ビット、時刻順に並べ替え可能、データセンターを考慮）

コードの適用例：

コンテキスト	パターン	例
短縮リンクサービス	自動インクリメント ID またはハッシュを Base62 でエンコード	https://short.ly/a1B2c3 がキー・バリューの行に対応します
API 保護	ゲートウェイでのトークンバケット	キーごとに毎分100トークン。一定の速度で補充し、超過時は429で拒否します
ソーシャルフィード	ハイブリッドファンアウト	フォロワー数が10K未満のアカウントはフィードを事前計算し、セレブリティの投稿は読み取り時に結合します

問題がよく知られた設計パターンに似ている場合は、references/common-designs.md を参照してください。URL 短縮サービス、レートリミッター、ニュースフィード、チャット、オートコンプリート、Web クローラー、一意 ID 生成器を詳しく解説しています。

6. 信頼性と運用

基本概念： システムの品質は、稼働を維持し、障害から復旧し、状態を把握できる能力によって決まります。ヘルスチェック、モニタリング、ロギング、デプロイ戦略は、後付けではなく、設計の最重要事項です。

有効な理由： 本番システムでは、図からは決して予測できない形で障害が発生します。運用準備状況――メトリクス、アラート、ロールバック計画、冗長化――によって、障害が一時的なものになるか、サービス停止につながるかが決まります。

主なポイント：

• ヘルスチェック：ライブネス（プロセスは稼働しているか？）とレディネス（トラフィックを処理できるか？）の2種類があり、Kubernetes は両方を使用します
• オブザーバビリティの3本柱：メトリクス（Prometheus、Datadog）、ロギング（ELK、CloudWatch）、トレーシング（Jaeger、Zipkin）
• デプロイ：ローリング（段階的）、ブルーグリーン（同一環境間で即時に切り替え）、カナリア（まず一部の割合で展開）
• 災害復旧：RPO（許容されるデータ損失）と RTO（許容される復旧時間）が、バックアップとフェイルオーバーの戦略を決定します
• マルチデータセンター：アクティブ・パッシブ（フェイルオーバー）またはアクティブ・アクティブ（データ同期と競合解決が必要）
• オートスケーリング：CPU、メモリ、キューの深さ、またはカスタムメトリクスに応じてスケールします。最小数と最大数は必ず設定してください

コードへの適用例：

コンテキスト	パターン	例
ダウンタイムなしのデプロイ	ヘルスチェックゲートを使ったブルーグリーン	チェックに合格したらグリーンに切り替え、即時ロールバックに備えてブルーを維持します
段階的な展開	メトリクスを比較するカナリア	新バージョンにトラフィックの5%を流し、エラーとレイテンシを比較してから昇格またはロールバックします
データの安全性	RPO/RTO を定義し、それに応じて実装	RPO 1時間＝毎時バックアップ、RTO 5分＝自動フェイルオーバー

本番環境向けに強化する際は、references/reliability-operations.md を参照してください。ヘルスチェックのパターン、オブザーバビリティの3本柱、デプロイ戦略、災害復旧（RPO/RTO）、オートスケーリングについて説明しています。

よくある間違い

間違い	失敗する理由	対策
要件より先にアーキテクチャを決める	間違った問題を解決し、制約を見落とします	最初の5～10分で、機能、規模、SLA の範囲を確認します
見積もりをしない	プロビジョニングの規模が大幅にずれます	コンポーネントを選ぶ前に、QPS、ストレージ、帯域幅を見積もります
単一障害点	1つのコンポーネントがシステム全体を停止させます	マルチサーバー、マルチ AZ、マルチリージョンなど、すべての層で冗長化します
早すぎるシャーディング	必要になる前に運用が非常に複雑になります	まず垂直スケーリングを行い、読み取りレプリカを追加して積極的にキャッシュし、最後にシャーディングします
無効化の仕組みがないキャッシュ	古いデータがバグや混乱の原因になります	TTL を定義し、書き込み時に明示的に無効化するキャッシュ・アサイド方式を使用します
あらゆる場面で同期呼び出しを行う	1つのサービスの遅延が、すべての呼び出し元に波及します	レイテンシが重要でない経路にはキューを使い、同期呼び出しにはタイムアウトを設定します
ホットスポットを無視する	1つのシャードやキーに負荷が集中し、ほかがアイドル状態になります	ホットキーを検出し、二次パーティショニングまたはローカルキャッシュを追加します
モニタリングやアラートがない	ユーザーが先に障害に気づきます	初日からメトリクス、ログ、トレースを計測できるようにします

クイック診断

質問	いいえの場合	対応
機能要件と非機能要件を列挙していますか？	設計が推測に頼ることになります	機能、DAU、QPS、ストレージ、レイテンシ、可用性のSLAを書き出します
QPSとストレージを見積もっていますか？	容量が当てずっぽうになります	QPSはDAU x アクション数 / 86400、ストレージはレコード数 x サイズ x 保持期間で算出します
すべてのコンポーネントに冗長性を持たせていますか？	単一障害点が発生します	コンポーネントごとにレプリカ、フェイルオーバー、またはマルチAZを追加します
データベースのスケーリング戦略を定義していますか？	成長時に限界に達します	まず垂直スケーリングを行い、次に読み取りレプリカを追加し、その後、明確なシャードキーを使ってシャーディングします
読み取り負荷の高い処理にキャッシュを設けていますか？	データベースに不要な負荷がかかります	TTLを定義し、Redis/Memcachedによるキャッシュ・アサイドを実装します
非同期処理でキューを使用していますか？	密結合や連鎖的な障害が発生します	ジョブ、通知、分析処理をKafka/SQSで疎結合にします
モニタリングとアラートの計画を立てていますか？	本番環境の障害を把握できません	メトリクス、ログの集約、トレーシング、アラートのしきい値を定義します
デプロイ戦略を定義していますか？	一度にすべてをリリースするリスクがあります	自動ロールバックに対応したローリング、ブルーグリーン、またはカナリア方式を採用します

参考資料

詳細な図解と手順を含む完全版ガイド：

• "System Design Interview -- An Insider's Guide" Alex Xu 著（第1巻）
• "System Design Interview -- An Insider's Guide: Volume 2" Alex Xu 著（第2巻）
• "Designing Data-Intensive Applications" Martin Kleppmann 著（データシステムの基礎）
• ByteByteGo -- Alex Xu による、視覚的なシステム設計の解説を提供するプラットフォーム

著者について

Alex Xu は、Twitter、Apple、Oracleでの勤務経験があるソフトウェアエンジニアで、ByteByteGoの創設者です。50万部以上を売り上げた2巻構成の著書 System Design Interview シリーズは、構造的な思考、見積もり、明確なコミュニケーションを通じて、システム設計を学習・反復可能なスキルにしました。