大手ITシステム設計面接ガイド：フラッシュセールからメッセージキューまで8つの実際の問題を詳細解説

大手ITシステム設計面接ガイド：フラッシュセールからメッセージキューまで8つの実際の問題を詳細解説

背景紹介

2024年の春採用シーズンからシステム設計面接の準備を本格的に始めました。それまでは中規模インターネット企業で3年間バックエンド開発をしていて、高同時アクセスのシーンも経験しましたが、システム設計の回答フレームワークを体系的に整理したことはありませんでした。正直に言うと、初めて「フラッシュセールシステムを設計してください」と聞かれた時、頭が真っ白になり、要点を全く突けませんでした。その後2ヶ月かけて、市場に出回っているシステム設計問題をすべて洗い出し、最も頻出する8問をまとめました。各問題は要件分析→アーキテクチャ設計→コアコンポーネント→スケーリング方案の4ステップで分解しています。この記事が皆さんの参考になれば幸いです。

面接プロセスの振り返り

大手IT企業4社のシステム設計面接を受けました。全体的な感想として、面接官は完璧なシステムを求めているのではなく、問題分析の思考プロセスとトレードオフを処理する能力を見ています。典型的な流れは以下の通りです：

ステップ1：要件の明確化（5分）——面接官が問題を出した後、すぐに設計を始めないでください。ユーザースケール、QPS、一貫性要件、可用性要件を必ず確認しましょう。最初の面接で確認せず、100万QPSで設計したら、面接官が「我々のシナリオは1万QPSです」と言い、過剰設計だと即座に指摘されました。

ステップ2：高レベル設計（10分）——コアアーキテクチャ図を描き、主要モジュールとデータフローを説明します。クライアント→ゲートウェイ→サービス層→ストレージ層の4層モデルで整理することをお勧めします。ほとんどのシナリオをカバーできます。

ステップ3：詳細設計（20分）——面接官は1〜2つのポイントを深掘りします。「在庫のダブルブッキングをどう防ぐか？」「キャッシュとDBの一貫性をどうするか？」具体的な実装方案を説明できる必要があります。

ステップ4：スケーリング議論（5分）——システムが10倍にスケールしたらどうするか？単一障害点はどこか？災害復旧はどうするか？ここで良い回答ができれば大きく評価されます。

問題1：フラッシュセールシステムの設計

要件分析：フラッシュセールシステムの核心的な課題は瞬間的な高同時アクセスです。典型的なシーン：10万人が100個の商品を争う。主要指標：QPSは10万以上に達する可能性、在庫は絶対にオーバーセルしてはならない、ユーザー体験で大規模なタイムアウトが発生してはならない。

アーキテクチャ設計：全体はフロントエンド流量制限→CDN→ゲートウェイ→フラッシュセールサービス→在庫サービス→注文サービスのチェーン。核心的な考え方は段階的フィルタリングで、大部分のリクエストを上流で遮断し、在庫サービスに到達するリクエストを極小割合に抑えます。

コアコンポーネント：

1. Redis事前在庫削減：フラッシュセール開始前に在庫をRedisにロード。リクエストはまずRedisで在庫を削減し、成功後に非同期で注文を作成。Luaスクリプトで原子性を保証。

2. メッセージキューによるピークカット：在庫削減成功後、MQメッセージを送信。注文サービスが非同期消費して注文を作成し、DBが直接ピークを負担するのを防ぐ。

3. フロントエンド流量制限：ボタン無効化+CAPTCHA+ランダムドロップで、QPSを元の1/10に削減。

スケーリング方案：マルチデータセンターデプロイ時、分散Redisクラスタで在庫をシャード保存し、各シャードが一部の商品を担当。ローカルキャッシュをセカンダリフィルターとして導入し、Redisアクセス圧を削減。

問題2：短縮URLサービスの設計

要件分析：長いURLを短いURLに変換。核心要件：短縮コードはできるだけ短く、リダイレクトは高速、重複不可。DAU1億、毎秒1000件の短縮URL生成を想定。

アーキテクチャ設計：書き込みパス：長URL→ハッシュ/IDジェネレータ→短縮コード→マッピング保存。読み取りパス：短縮コード→ストレージ検索→302リダイレクト。

コアコンポーネント：

1. IDジェネレータ：MD5ハッシュよりもオートインクリメントID+Base62エンコーディングをお勧めします。短縮コードが制御可能で重複なし。分散シナリオではSnowflakeやRedis INCRを使用。

2. キャッシュ層：ホットな短縮URLをRedisにキャッシュ。ヒット率95%以上で、読み取りレイテンシを10msから1msに削減。

3. ブルームフィルタ：書き込み前にブルームフィルタで短縮コードの既存確認を行い、重複生成を防止。

スケーリング方案：グローバルデプロイ時、GeoDNSでユーザーを最寄りのデータセンターにルーティング。データセンター間は非同期レプリケーションで短縮URLマッピングを同期。

問題3：メッセージキューの設計

要件分析：メッセージキューのコア機能：プロデューサーがメッセージを送信、コンシューマーがメッセージを受信、メッセージの損失・重複なし。主要指標：スループット、レイテンシ、メッセージ信頼性。

アーキテクチャ設計：コアモデルはTopic→Partition→Consumer Group。メッセージはPartitionに順次追記され、消費時はOffsetでプル。

コアコンポーネント：

1. Brokerクラスタ：各Brokerが複数のPartitionを担当。レプリケーション機構で高可用性を保証。Leaderが読み書きを処理し、Followerがデータを同期。

2. コンシューマーオフセット管理：Offsetは内部Topicに保存。コンシューマーが定期的にコミット。Exactly-Onceにはトランザクション+冪等性が必要。

3. パーティション戦略：Keyベースのハッシュで同じKeyのメッセージの順序を保証。Keyなしの場合はラウンドロビンで負荷分散。

スケーリング方案：単一Partitionのスループットが不足する場合、Partition数を増やす。クロスデータセンターシナリオではMirrorMakerで非同期レプリケーション。

問題4：ソーシャルフィード（タイムライン）の設計

要件分析：コア機能：投稿投稿、フィード閲覧、いいね・コメント。主要な課題：プッシュ型vsプル型の選択。1億ユーザー、平均200友達を想定。

アーキテクチャ設計：プッシュ型メイン+プル型サブのハイブリッド方案をお勧めします。一般ユーザーの投稿は全友達の受信箱にプッシュ（プッシュ型）、インフルエンサーの投稿はフォロワーが能動的にプル（プル型）。

コアコンポーネント：

1. フィードストレージ：各ユーザーがTimelineテーブルを維持し、時系列降順で並べる。RedisのSorted Setで実装し、Scoreをタイムスタンプにする。

2. ファンアウトサービス：投稿後、メッセージキューで非同期に全友達のTimelineにファンアウト書き込み。

3. インタラクションサービス：いいね・コメントは別途保存し、投稿詳細ページでリアルタイム集約。

スケーリング方案：友達数5000以上のインフルエンサーはプル型。フォロワーはキャッシュ→DBの順で取得。コールドデータはHBaseに降格保存してコストを削減。

問題5：検索エンジンの設計

要件分析：コア機能：ウェブクロール→インデックス構築→クエリ→結果返却。主要指標：クエリレイテンシ<100ms、インデックス規模数百億件。

アーキテクチャ設計：4層アーキテクチャ：クローラー→ドキュメントストア→転置インデックス構築→クエリサービス。

コアコンポーネント：

1. 転置インデックス：Term→DocIDリストのマッピング。検索エンジンのコアデータ構造。スキップリストで複数キーワードのAND演算を高速化。

2. シャーディングと分散：インデックスをDocIDで複数ノードにシャーディング。クエリは全シャードを並列検索し、TopK結果をマージ。

3. ランキングモデル：基本はTF-IDF+PageRank、高度なものは機械学習モデル（LambdaMARTなど）でLearning to Rank。

スケーリング方案：リアルタイムインデックスはNRT（Near Real-Time）機構で、毎秒Segmentをリフレッシュ。ホット/コールド分離で、ホットクエリ結果をRedisにキャッシュ。

問題6：レコメンドシステムの設計

要件分析：コア機能：ユーザー行動に基づいて興味のあるコンテンツを推薦。主要な課題：リコール率、多様性、リアルタイム性。

アーキテクチャ設計：古典的な3層アーキテクチャ：リコール層→ランキング層→再ランキング層。リコール層は膨大な候補から千件程度に絞り込み、ランキング層で百件程度に精緻化、再ランキング層で多様性とビジネスルールを調整。

コアコンポーネント：

1. マルチパスリコール：協調フィルタリングリコール、コンテンツリコール、人気リコール、ベクトルリコール（ANN）を並列実行し、結果をマージ・重複排除。

2. 特徴量プラットフォーム：ユーザー特徴、アイテム特徴、コンテキスト特徴を統合管理。リアルタイム特徴はKafka+Flinkのストリーミング処理で計算。

3. ランキングモデル：粗いランキングはツインタワーモデル（低レイテンシ）、精密ランキングはDIN/DIENなどのディープモデル（高精度）。

スケーリング方案：A/B実験プラットフォームで複数実験を並行実施。階層型実験でトラフィックの排他を回避。コールドスタートはExplore-Exploit戦略で探索と利用のバランスを取る。

問題7：レートリミッターの設計

要件分析：レートリミッターのコア機能：指定した時間ウィンドウ内のリクエスト数を制限。主要要件：分散、低レイテンシ、概ね正確。

アーキテクチャ設計：レート制限アルゴリズムがコア。一般的な4つのアプローチ：固定ウィンドウ、スライディングウィンドウ、トークンバケット、リーキーバケット。

コアコンポーネント：

1. トークンバケットアルゴリズム：固定レートでバケットにトークンを追加。リクエストはトークンを消費し、バケットが空なら拒否。利点はバーストトラフィックを許容できることで、最も一般的に使用される。

2. スライディングウィンドウログ：各リクエストのタイムスタンプを記録し、ウィンドウ内のリクエスト数をカウント。正確だがメモリ消費が大きく、低QPSシナリオに適している。

3. 分散レート制限：Redis+Luaスクリプトで集中カウントを実現、またはトークンシャーディング方式で各ノードにトークンの一部を割り当て。

スケーリング方案：マルチティアレート制限：ゲートウェイ層グローバル制限→サービス層制限→インスタンス単位制限。制限時はHTTP 429+Retry-Afterヘッダーを返し、クライアント側でグレースフルデグラデーション。

問題8：分散キャッシュの設計

要件分析：分散キャッシュのコア機能：KVストレージ、高スループット、低レイテンシ。主要な課題：キャッシュ貫通、キャッシュアベーランチ、キャッシュブレイクダウン。

アーキテクチャ設計：Client→一致性ハッシュ→Cache Node→データベース。一致性ハッシュでスケーリング時のデータ移行問題を解決。

コアコンポーネント：

1. 一致性ハッシュ：仮想ノードでデータ偏り問題を解決。各物理ノードに100〜200の仮想ノードをマッピング。スケールアウト時は隣接ノードのデータにのみ影響。

2. キャッシュ戦略：LRU/LFU退去ポリシー。書き込み戦略はCache-Asideパターン（先にDBを更新してからキャッシュを削除）、遅延ダブルデリートで一貫性を保証。

3. 防護メカニズム：キャッシュ貫通にはブルームフィルタで不正クエリを遮断。キャッシュブレイクダウンにはミューテックスロックで同時キャッシュミスを防止。キャッシュアベーランチにはランダム有効期限で負荷を分散。

スケーリング方案：マルチレプリカで高可用性を保証。プライマリ-レプリカ同期は非同期レプリケーション（性能優先）またはRaft合意（一貫性優先）。ホットキーはローカルキャッシュ+リモートキャッシュの2層アーキテクチャで対応。

心得・アドバイス

1. 必ず先に要件を確認する。いきなりアーキテクチャ図を描かない。面接官が最も重視するのは、答えを暗記する能力ではなく、問題を分析する能力です。

2. 汎用フレームワークを身につける：要件明確化→高レベル設計→詳細設計→スケーリング議論。このフレームワークは全システム設計問題に適用できます。

3. 汎用コンポーネントを準備する：ロードバランサー、キャッシュ、メッセージキュー、シャーディング戦略。これらはほとんどのシステム設計で使用されます。

4. 積極的にトレードオフを議論する：「ここで強一貫性を選ぶと可用性が犠牲になるため、結果整合性+補償機構を推奨します」といった表現は非常に評価されます。

5. 図を描く：システム設計面接では必ず図を描くこと。図なしでは説明が不十分とみなされます。シンプルな四角+矢印でアーキテクチャを表現する練習をしましょう。

FAQ

Q：システム設計面接はどの程度の深さで準備すべきですか？

A：論文レベルの深さは必要ありませんが、コアコンポーネントの選定理由とトレードオフは説明できる必要があります。例えば、RedisではなくMemcachedを選ぶ理由、メッセージキューではなく同期呼び出しを選ぶ理由など。

Q：大規模システムの経験がない場合はどうすればいいですか？

A：システム設計面接がテストするのは設計思考であり、実務経験ではありません。論文（Dynamo、Kafka論文など）や技術ブログで補完できます。面接で「直接的な経験はありませんが、設計アプローチは…」と正直に述べても問題ありません。

Q：時間が足りない場合の配分は？

A：要件明確化5分、高レベル設計10分、詳細設計15〜20分、スケーリング5分。時間が足りない場合は、高レベル設計の完全性を優先し、詳細設計は1点に絞って深く説明しましょう。