Scalability design

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：キャッシュ戦略を選ぶ

条件	戦略	備考
読み取りが多く実装の単純さを優先	Cache-Aside	最も一般的。キャッシュミス時にDBを読みキャッシュへ書く
強い一貫性が必要	Write-Through	書き込み時に必ずキャッシュも同期更新
書き込みスループット優先	Write-Behind	非同期書き込み。プロセス障害時のデータロストリスクを許容できるか要確認
アクセスパターンが予測可能	Refresh-Ahead	期限切れ前に先回りして更新

チェックリスト：

• キャッシュ無効化ロジック（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）を洗い出したか

アンチパターン集

アンチパターン	現実
「将来スケールするから」と最初からマイクロサービス・シャーディングを導入する	需要が確定していない段階での複雑化は運用コストだけが先に発生する。レプリケーションで足りるうちはそれで十分
キャッシュを「とりあえず入れておく」	無効化ロジックを決めずに導入すると、古いデータを返し続けるバグの温床になる。導入前に無効化戦略を決める
CAPの選択を明文化しない	分断発生時に「一貫性を優先すべきか可用性を優先すべきか」でチームの意見が割れ、対応が遅れる
キューに上限を設けない	詰まった処理が無限にキューへ積み上がり、メモリ枯渇やレイテンシ悪化に気づくのが遅れる
数値要件なしに「スケーラブルな設計」を作る	QPSも整合性要件もない状態でのアーキテクチャ選定は当てずっぽうになる。先にヒアリングする

出典

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