第6部 面接の実践・第15章
正解の構成を当てる試験ではない。要件を確認し、規模を見積もり、トレードオフを説明しながら面接官と対話で設計を深めることが評価される。
要件の確認（5分）：機能要件、非機能要件（可用性、レイテンシ、一貫性）、ユーザー数、読み書きの比率を質問する
規模の見積もり（5分）：QPS、ストレージ量、帯域を概算する
全体構成（10分）：主要コンポーネントとデータの流れを描く
深掘り（15分）：ボトルネック、DB設計、キャッシュ、スケーリング
障害と運用（10分）：故障時の挙動、監視、デプロイ、SLO。SRE面接ではここが最も重視される
時間が足りなくなりやすいのは深掘り。障害と運用の時間を必ず残す。
| 分類 | 質問の例 |
|---|---|
| 機能 | 必須の機能は何か、後回しでよい機能は何か |
| 規模 | 1日のアクティブユーザー数、ピーク時のリクエスト数、データ量の増え方 |
| 読み書き | 読み取りと書き込みの比率、書き込み直後に読む必要があるか |
| 一貫性 | 多少古いデータでもよいか、厳密な一貫性が必要か（お金・在庫） |
| 可用性 | どれくらい止まってよいか、どの機能が最も重要か |
| レイテンシ | 何ミリ秒以内に返す必要があるか |
| 地理 | ユーザーは国内だけか、世界中か |
| 制約 | 予算、既存システム、チームの規模 |
| 項目 | 目安 |
|---|---|
| 1日の秒数 | 約 86,400 秒（概算では 10万秒） |
| 1日 100万リクエスト | 平均 約12 QPS、ピークは平均の 2〜5 倍で見積もる |
| メモリ参照 | 約 100 ナノ秒 |
| SSD のランダム読み込み | 約 100 マイクロ秒 |
| 同一データセンター内の往復 | 約 0.5 ミリ秒 |
| 日本と米国の往復 | 約 100〜150 ミリ秒 |
| 項目 | 前提 | 計算 | 結果 |
|---|---|---|---|
| 書き込み | 1日1億件の短縮URL作成 | 1億 ÷ 10万秒 | 約 1,000 QPS（ピーク 3,000） |
| 読み取り | 書き込みの100倍 | 1,000 × 100 | 約 10万 QPS（ピーク 30万） |
| 1件のサイズ | URL＋メタデータ | － | 約 500バイト |
| 5年分のストレージ | 1億件 × 365日 × 5年 | 1,825億件 × 500B | 約 90TB |
| キャッシュ | 読み取りの上位20%を保持 | 1日分の20% | 約 10GB / 日 |
見積もりは桁が合っていれば十分。計算の前提を口に出すことが大事。
読み取りと書き込みの比率が設計を決める。見積もりから構成を導く。
| 観点 | 問われること |
|---|---|
| アーキテクチャ選択 | 冗長化、キュー、リトライ、分離の境界をどう置くか |
| 障害時の挙動 | 一部障害時の動作、縮退運転、リトライストーム、重複イベント |
| 運用の現実性 | ダッシュボード、オーナーシップ、デプロイ方法、ロールバック手段 |
| トレードオフ | なぜこの設計か、何を犠牲にし、何を守るのか |
| お題 | 主な論点 |
|---|---|
| URL短縮サービス | ID生成、読み取り中心のキャッシュ、リダイレクトのレイテンシ |
| 通知システム（メール / プッシュ） | キュー、冪等な送信、チャネルごとの隔離、外部APIのレート制限 |
| ログ収集・監視基盤 | 大量書き込み、バッファリング、保持期間とコスト、取りこぼし |
| レート制限器 | アルゴリズム選択、分散環境でのカウンタ共有（Redis） |
| チャットシステム | WebSocket、メッセージの順序と配信保証、既読管理 |
| フィード / タイムライン | 書き込み時配信と読み取り時集約の使い分け |
| ファイルアップロード・画像配信 | 署名付きURL、オブジェクトストレージ、CDN、非同期変換 |
| チケット販売（アクセス集中） | 在庫の整合性、待合室（キュー）、事前スケール |
要件：メール・プッシュ・SMS で通知を送る。1日1,000万通、重要な通知（パスワードリセット等）は確実に届ける。
| コンポーネント | 役割 | 設計のポイント |
|---|---|---|
| 通知API | 送信リクエストを受け付ける | ステートレス、冪等キーで二重送信を防ぐ、受付後すぐ返す |
| ユーザー設定DB | 通知の受信設定、連絡先 | キャッシュして読み取りを高速化 |
| メッセージキュー | APIと送信処理を分離 | チャネルごと、優先度ごとにキューを分ける |
| 送信ワーカー | 各チャネルの外部サービスへ送る | 外部サービスのレート制限に合わせて流量制御、リトライ |
| デッドレターキュー | 失敗し続けた通知を退避 | 監視して手動・自動で再送 |
| 送信ログ | 送信状況の記録 | 重複送信の防止、問い合わせ対応 |
キューが受付と送信の間に入ることで、外部サービスが落ちても受付は止まらず、回復後にまとめて送れる。
| 面接官からの追加質問 | 答え方 |
|---|---|
| メール配信サービスが落ちたら？ | サーキットブレーカーで遮断し、キューに溜めて回復後に送る。重要通知は別の配信サービスへフェイルオーバー |
| 同じ通知が2回届いたら？ | at-least-once 前提なので、通知IDで送信済みを記録して重複を排除 |
| キャンペーンで一斉送信すると？ | 一斉送信用のキューを分け、重要通知が遅れないようにする（バルクヘッド） |
| どう監視する？ | キューの滞留時間、送信成功率、チャネルごとのレイテンシをSLIにする |
要件：数百台のサーバーとコンテナから1日数TBのログを集め、検索と長期保存をしたい。
| 段階 | 選択肢 | 判断の観点 |
|---|---|---|
| 収集 | Fluent Bit、Vector、OpenTelemetry Collector | 軽量さ、バッファリング、再送 |
| 転送・バッファ | Kinesis Firehose、Kafka | 取りこぼし防止、スパイクの吸収 |
| 検索用ストア | OpenSearch、Loki、Datadog | 検索速度とコスト。全文検索が必要か |
| 長期保存 | S3（Glacier へ自動移行） | 監査要件の保持期間、Athena で検索 |
| 可視化・アラート | Grafana、Kibana、Datadog | ログからのメトリクス化 |
論点：大量のログをすべて高価な検索ストアに入れるとコストが膨らむ。重要度でサンプリングや保持期間を分ける設計を提案できるとよい。
| 課題 | 対策 |
|---|---|
| 販売開始直後に数十万アクセス | 待合室（仮想キュー）で入場を制御、静的ページはCDNから配信 |
| 在庫の二重販売 | 在庫の減算をDBの条件付き更新や Redis のアトミック操作で行う |
| 座席の一時確保 | TTL付きで仮押さえし、期限切れで解放 |
| 決済の失敗 | 決済と在庫確定を Saga で管理し、失敗時は在庫を戻す |
| 事前準備 | 負荷試験、事前スケール、関係チームとの当日の体制 |
GoogleのSRE面接にある NALSD（Non-Abstract Large System Design）は、抽象的な設計にとどまらず「サーバーが何台必要か」「ディスクやネットワーク帯域は足りるか」を具体的な数字で詰める形式。既存システムを理解し、ボトルネックと故障モードを見つけ、現実的に段階的な改善案を出せるかが見られる。
| 失敗 | なぜ評価が下がるか |
|---|---|
| 要件を聞かずに描き始める | 問題の理解が浅いと判断される |
| 最初から過剰な構成にする | 規模に合わない設計はコスト感覚がないと見られる |
| 流行の技術名を並べる | 選んだ理由とトレードオフを説明できないと逆効果 |
| 障害時の話をしない | SRE面接で最も見られる部分を落としている |
| 一人で話し続ける | 面接官のヒントや関心を拾えない |
まず答えを見ずに声に出して答え、そのあと開いて比べる。
模範回答
まず規模と要件を確認します。仮に1日1億件の作成とすると書き込みは約1,000 QPS、読み取りはその100倍の約10万 QPSと見積もり、読み取り中心の設計にします。短いIDは連番をBase62で変換するか、衝突しない生成器を使います。読み取りはCDNとキャッシュで受け、DBはキーで引けるKVSやシャーディングで拡張します。最後に、キャッシュやDBが落ちたときの挙動、監視するSLI、悪用対策まで話します。
深掘りされたら
見られているポイント見積もりから設計判断を導けるか
模範回答
誰に（ユーザー、IP、APIキー）、どの粒度で制限するかを確認します。アルゴリズムはバーストを許容できるトークンバケットが一般的です。複数台のサーバーで共有するためカウンタはRedisに置き、アトミックな操作で更新します。超過時は429とRetry-Afterを返します。Redisが落ちたときに全リクエストを通すか止めるかも決めておきます。
深掘りされたら
見られているポイント障害時の振る舞いまで決めているか
模範回答
見積もった数字をもとに、各コンポーネントの処理能力と比べて答えます。多くの場合、書き込みが集中するDB、特定のキーに集中するキャッシュ、外部APIのレート制限が先に詰まります。そのうえで、計測すべき指標と、限界に近づいたときの対策（シャーディング、キュー、事前スケール）を述べます。
深掘りされたら
見られているポイント数字にもとづく判断