Scalability Design

システムアーキテクチャの意思決定を、勘ではなく確立された判断フレームワークで行うためのスキル。新規設計・既存設計のレビュー・スケール要件のヒアリング時に使う。

使うタイミング

• 新しいシステム／サービスのアーキテクチャを設計するとき
• 「スケールしない」「大量アクセスに耐えられるか」を検討するとき
• キャッシュ・DB分割・非同期処理・ロードバランサーの導入可否を判断するとき
• 既存アーキテクチャのボトルネック候補をレビューするとき

このスキルは「アーキテクチャの意思決定」用。単一コードのチューニングは performance-optimization、API・モジュールのインターフェース設計は deep-module-design を使う。

手順

ステップ0：要件を数値化する

判断の前に必ず以下を明文化する（数値がなければ判断できない）。

• 想定同時ユーザー数・リクエスト数（QPS）
• 読み取り:書き込み比率
• 許容レイテンシ（p50/p95/p99）
• データ整合性要件（強整合が必須か、最終的整合性で許容できるか）
• 想定データ量・増加率

数値なしで「スケーラブルな設計にして」と言われた場合は、上記をヒアリングしてから設計に進む。

ステップ1：CAP定理でデータストアの方針を決める

分散データストアを選ぶ／既存構成のトレードオフを説明するときの判断手順。

1. そのデータに「原子的な読み書き整合性」が必須か確認する。
   • 必須 → CP（一貫性・分断耐性優先、可用性を犠牲にする側）
   • 最終的整合性で許容できる → AP（可用性・分断耐性優先）
2. ネットワーク分断は必ず起こる前提で設計する。CとAのどちらを犠牲にするかを設計ドキュメントに明記する（後から「なぜこの構成にしたか」を誰も説明できなくなるのを防ぐ）。
3. 1つのシステムの中でも、データの種類ごとにCP/APを使い分けてよい（例：決済台帳はCP、いいね数カウンタはAP）。

ステップ2：キャッシュ戦略を選ぶ

チェックリスト：

• キャッシュ無効化ロジック（TTL・イベント駆動どちらか）を設計段階で決めている（後付けは事故のもと）
• キャッシュ層がダウンした場合のフォールバック（DB直読み）を用意している
• キャッシュキーの設計（バージョン・namespace）を決め、デプロイ時の不整合を防いでいる

ステップ3：負荷分散レイヤーを選ぶ

• 単純なTCP/IPレベルの分散で足りる → Layer 4（軽量・低コスト）
• パス・ヘッダー・Cookieなどコンテンツに基づくルーティングが必要 → Layer 7（柔軟だがオーバーヘッド増）

判断基準：ルーティングにHTTPの中身（パス、ヘッダー）を見る必要があるかどうかで即断できる。

ステップ4：DB分割戦略をコストの低い順に検討する

いきなりシャーディングに飛びつかない。以下の順で検討する。

1. マスタースレーブレプリケーションで読み負荷を分散できないか
2. 高可用性が要件ならマスターマスターレプリケーション
3. 機能別（ユーザー/商品/注文など）に分けられるならフェデレーション（分割）
4. それでも足りない場合のみシャーディング（実装コスト・運用複雑性が大幅に増す。クロスシャードクエリ・リバランス戦略まで設計してから着手する）

ステップ5：非同期処理の導入可否を判断する

以下がすべてYesならメッセージキュー（例：RabbitMQ、Redis Queue、SQS）導入を検討する。

• 処理時間が長い（数秒以上）か
• ユーザーが即時結果を必要としないか
• 失敗時にリトライ可能な設計にできるか

導入する場合はキューサイズの上限（バックプレッシャー）を必ず設定し、無制限にキューが積み上がる設計にしない。

チェックリスト（設計レビュー時）

• 要件（QPS・整合性・レイテンシ）を数値で明文化したか
• CP/APのどちらを選んだか、理由込みで文書化したか
• キャッシュ導入時、無効化ロジックとフォールバックを決めたか
• DB分割はレプリケーション→フェデレーション→シャーディングの順で検討し、いきなり複雑な手段に飛びついていないか
• 非同期化する処理にバックプレッシャーの上限を設定したか
• 単一障害点（SPOF）を洗い出したか

アンチパターン集

出典

• donnemartin/system-design-primer（MIT License）— CAP定理、キャッシュ戦略、負荷分散、DB分割、非同期処理の各パターンを要約・手順化した。原文の図表・コードの丸写しは行っていない。