TL;DR
- システム設計は「要件・制約 → 規模見積もり → ボトルネック仮説 → 対策/検証」の反復。言語化した前提を常に更新するのが肝。
- 規模感は“目分量”ではなく、概算（QPS Queries Per Second。1 秒あたりに処理するリクエスト数。システム規模を見積もる基本指標。 / スループット 単位時間あたりに処理できる量（件数・データ量）。処理能力の指標。 / ストレージ容量 / 帯域 1 秒あたりに送受信できるデータ量。ネットワークの太さの指標。 ）で会話する。数字があると優先順位とトレードオフが立つ。
- スケール戦略は段階的に（垂直 1 台あたりの CPU/メモリ/IO を増やす拡張。シンプルだが上限がある。 → 水平 台数を増やして負荷を分散。運用は複雑になるが上限が高い。 → 分割 機能やデータを小さな単位に分ける（サービス分割/パーティショニング）。 ）。キャッシュ 繰り返し使う結果を一時保存し、読み出しを速くする仕組み。 、非同期化 応答を待たずに裏で処理する設計（ピーク平準化）。 、キュー 要求を一時的に貯めて順次処理するバッファ。スパイク吸収に有効。 、シャーディング データを複数分割（シャード）に分けて並列処理/分散。 、冪等性 同じ操作を何度実行しても最終結果が変わらない性質。 で詰まりを逃がす。
- 可用性 システムが利用可能な時間の割合（例: 99.9%）。 ・一貫性 複数の副本やサービス間で“同じ事実”を同時に見られる度合い。 ・コスト・複雑性はトレードオフ。SLO Service Level Objective。ユーザー体験の“目標品質”。 を置き、過不足を検証で詰める。
参加イベント
2025 年 11 月 29 日（土）に開催された Recursion 主催の『大規模システム設計の基礎』を視聴しました。
# イベント概要 本イベントは、1.5時間で「大規模なアプリケーションを設計するための基礎概念」を学ぶことを目的としたオンラインワークショップです。メガベンチャーや外資系テック企業では、技術面接・実務の両面でシステム設計の理解が強く求められます。 本講義では、大量のデータやア …
備考: 当日 Zoom のチャットで登壇者様より参加者向け URL として資料共有がありましたが、connpass には一般公開されていないため、本記事では資料 URL/内容の直接掲載や図版の転載は行いません（要旨のみ記載）。
印象に残ったこと
1. 前提をそろえる（要件/制約/成功条件）
機能要件（誰が何をいつまでに）と非機能要件（可用性/レイテンシ
リクエスト往復の遅延時間。p95 など分位で評価。
/スループット/保存期間/費用上限）を先に言語化。
「SLO と完了定義」があると、後段のトレードオフや優先順位の会話が速くなると実感しました。
2. 概算でスケールを掴む（Back-of-the-envelope）
Back-of-the-envelope とは、封筒の裏計算。厳密さよりも“桁”を素早く掴む概算のこと。
リクエスト/秒、平均レスポンス、書き込み/読み出し比
Write/Read Ratio。書込と読取の比率。キャッシュや DB 設計の判断材料。
、データ増分、帯域、ストレージ費をざっくりで良いので置く。
数字が置けると、キャッシュの利き所、DB/ネットワークの詰まり、ボトルネック
全体性能を支配する最も遅い箇所。
候補が自然と見えてきます。
3. ボトルネックに対する基本手筋
- キャッシュ（ブラウザ/エッジ CDN などユーザー近くの層で応答する仕組み。 /アプリ/DB 前）でホットパス 最も頻繁に通る主要経路。最適化の優先度が高い。 を軽くする。
- 非同期化（キュー/ワーカー キューから取り出して処理するバックグラウンド実行体。 、リトライ 一時失敗時に再実行する制御。回数/間隔/上限を設計。 とバックオフ 再試行間隔を段階的に伸ばす戦略（指数バックオフなど）。 ）でピークを平準化。
- シャーディング/レプリケーション 同一データの複製を複数ノードに配置し可用性/読み取り性能を高める手法。 で水平分割。ハッシュ キーをハッシュ関数で数値化して均等に分散する方式。 or レンジ 値の範囲（例: A〜F）ごとに分ける方式。ホットレンジに注意。 の選択とスキュー アクセスやデータが特定シャードに偏ること。検知と再分割が必要。 対策。
- 冪等性キー 重複実行を識別する一意キー。処理済み検知で二重適用を防ぐ。 と順序保証 イベント/メッセージの処理順を維持する仕組み（例: パーティション内順序）。 、バックプレッシャー 下流能力に合わせて上流の受け付けを抑制する制御。輻輳防止。 で故障時の増幅を抑える。
4. 一貫性と可用性の折り合い
ユーザー体験の SLO を軸に、強い整合性
書き込み直後でも全読取りで同じ値が見える性質。直感的だがスケールは難しい。
/最終的整合性
時間経過で整合することを許容。可用性とスケールを取りやすい。
、厳密なトランザクション
ACID を満たす不可分な操作単位。分散では難度/コスト増。
/アウトボックス＋イベント駆動
DB のアウトボックスにイベントを書き、別プロセスで配信するパターン。二相問題を回避しやすい。
などの選択肢を評価。
“理想”ではなく“必要十分”を合意して進めるのが現実的だと再確認しました。
5. 運用と検証まで含めて設計
観測可能性
内側の状態を外から推測できる性質。メトリクス/ログ/トレースの組み合わせ。
（メトリクス
数値で継続計測する指標（RPS、p95、エラー率など）。
/ログ/トレース
分散処理の経路を関連付けて可視化する仕組み（OpenTelemetry 等）。
）とローリング
少数ずつ順に置き換えるデプロイ方式。影響を限定。
/カナリア
一部トラフィックのみに新バージョンを適用する実験的リリース。
/段階リリース、容量監視、スロットリング
受け付け量を動的に絞る制御。過負荷や連鎖障害を防ぐ。
/レート制限
クライアント単位で一定時間あたりの呼び出し回数を制限。濫用防止。
を最初から設計に入れる。
設計レビューは “図と言葉と数字” の 3 点セットで回すと意思疎通が早い。
後に試してみたいこと （自分向け）
- 設計ワンペーパーを定着: 前提/概算/リスク/実験計画の 1 枚を作ってから実装に入る。
- 概算テンプレの自動化: QPS・保存量・帯域を計算する簡易シートを用意して、レビューで使い回す。
- 失敗前提の設計チェック: タイムアウト 上限時間を超えた処理を打ち切る制御。 /リトライ/冪等性/バックオフ/サーキットブレーカ 下流の失敗率が高いとき回路を開いて呼び出しを止め、回復後に半開で試行するパターン。 の有無を点検。
- 観測の最小セット: 成功率、p95 全リクエストの 95% がこの値以下で終わるという分位（パーセンタイル）。 レイテンシ、エラー率、キュー滞留、リソース使用率を最初からダッシュボード化。
System Design ワンペーパー（雛形・コピペ可）
## 背景/目的
- 目的: <例: 注文 API を 300 RPS で p95 300ms 以内に>
- ユーザー価値: <例: カート離脱を抑える>
## 前提/制約
- SLO: 可用性 99.9% / p95 300ms / 28 日
- 制約: <リージョン/既存 DB/予算上限/発売日 など>
## 概算（Back-of-the-envelope）
- トラフィック: ピーク <RPS> / 日次 <リクエスト数>
- データ: 書込/読取比、1 リクエストあたりのペイロード、日次増分
- 帯域/費用: 出入口 <MB/s>、ストレージ/月 <GB>
## アーキテクチャ（初期案）
- パス: <同期> API Gateway → App → Cache → DB
- バックグラウンド: <非同期> Queue → Worker → 外部連携
- 信頼性: Retry(指数)/Timeout/Idempotency/CircuitBreaker/RateLimit
## リスク/対策
- ホットキー/スキュー → キャッシュ分散、キー設計
- キュー滞留 → 可視化、スケールポリシー、DLQ
- DB ボトルネック → 読取レプリカ、セカンダリインデックス
## 実験計画/検証
- 負荷試験: 100→300→500 RPS ステップ、p95/エラー率監視
- カナリア: 5% → 25% → 50% ロールアウト、指標は SLO 直結のみ Pager
まとめ（現時点の所感）
数字で前提を固定し、小さく検証して学びを反映する ── この当たり前を“儀式化”すると組織の設計力が底上げされると感じました。
まずはワンペーパー
設計の要点を 1 枚にまとめた資料。前提/概算/リスク/検証を簡潔に記す。
と概算テンプレをチームで共有し、レビューの共通フォーマットにしていきます。
SRE は “定義 → 運用 → 学習” のリズムを組織で回す営みだと再確認しました。
まずは自チームの SLO を 3 件に絞り、アラートの棚卸しと PIR
Post-Incident Review。事後レビュー。非難なく、タイムライン/影響/恒久対策を言語化する振り返り。
のテンプレ整備から着手したいと思います。なお Pager
“人を起こす”レベルの緊急通知（例: PagerDuty）。SLO 直結のみを対象にするのが原則。
方針を徹底することも心がけたいと思います。