Googleシステム設計面接体験記：YouTube推薦システムの設計思路

Googleシステム設計面接体験記：YouTube推薦システムの設計思路

背景紹介

2024年3月にGoogleのバックエンドソフトウェアエンジニア職で面接を受けました。経験は3年です。正直に言うと、Googleのシステム設計面接は想像していたものと全く違いました。「アーキテクチャ図を描いて終わり」という形式ではなく、面接官はあらゆる詳細を深掘りし、答えられなくなるまで追及してきました。私が面接したチームはYouTube推薦方向で、面接官はYouTubeの推薦システムをゼロから設計するよう求めました。手のひらが汗で濡れるほど緊張しましたが、推薦システムの一般的なフレームワークを準備していたので、何とか乗り切りました。以下はこの面接の完全な振り返りです。

面接プロセスの振り返り

面接官は30代前半のスタッフエンジニアで、YouTube推薦インフラチーム所属と自己紹介しました。面接は約50分で、非常にタイトなペースでした。

最初の5分：面接官が面接の流れを簡単に説明し、すぐに本題に入りました。「YouTube Shortsに似たショート動画推薦システムを設計してください。」準備していたフレームワークに従い、まず要件確認の質問をしました。

5〜15分：要件確認段階。いくつかの重要な質問をしました：

1. ユーザースケール？——「DAU3億と仮定してください。」

2. 推薦目標？——「視聴時間とエンゲージメント率の最大化。」

3. リアルタイム性の要件？——「ユーザーが動画を見た後、次の推薦はその行動を反映する必要がある。」

4. コールドスタート対応？——「新規ユーザーと新規動画の両方を考慮。」

5. コンテンツ安全性？——「コンテンツモデレーション機構が必要。」

面接官はこれらの質問に満足したようで、「続けて」と頷きました。

15〜35分：最も核心的なセグメント。リコール→ランキング→再ランキングの3層アーキテクチャで説明しました。面接官は各段階で深いフォローアップ質問を追加しました。「協調フィルタリングのコールドスタートはどう解決する？」「精細ランキングのモデルは？」「推薦の多様性をどう保証する？」一つずつ回答しましたが、流暢に答えられたものと、詰まりながら答えたものがありました。

35〜45分：面接官はエンジニアリング実装の詳細に移りました。「特徴量をどうリアルタイム更新するか？」「A/B実験はどうやるか？」「動画のembeddingをどう処理するか？」この部分の回答は平均的だと感じました。いくつかのポイントは本当に考えが及んでいませんでした。

最後の5分：面接官が質問タイムをくれました。チームの技術スタックと推薦システムのイテレーションペースについて聞きました。

実際の問題：YouTube推薦システムの設計

1. 全体アーキテクチャ設計

3層アーキテクチャ図を描きました：リコール層→ランキング層→再ランキング層。面接官は一目見て「基本フレームワークは問題ない。各層を展開して」と言いました。

2. リコール層設計

リコール層の目標は、数億の動画から数千の候補に絞り込むことです。4つの並列リコールパスを設計しました：

1. 協調フィルタリングリコール：ユーザー行動行列に基づき、ItemCFで類似動画を見つける。面接官が「コールドスタートはどうする？」と追及。新規動画はまずコンテンツリコールに回し、十分な行動データが蓄積されたら協調フィルタリングプールに追加すると回答。

2. コンテンツリコール：動画のタグ、カテゴリ、embeddingに基づく類似推薦。ツインタワーモデルでユーザー特徴と動画特徴を別々に抽出し、内積を計算すると説明。面接官が「ベクトル検索は何を使う？」と質問——FAISSまたはHNSWで、10億規模のベクトルのミリ秒レベル検索をサポートすると回答。

3. 人気リコール：地域と時間帯でトレンド動画を表示し、新規ユーザーも質の高いコンテンツを見られるようにする。面接官が「フィルターバブルをどう回避する？」と質問——人気リコールは候補セットの一部（約10%）のみを占め、ランダム探索メカニズムを追加すると回答。

4. ソーシャルリコール：フォローしているユーザーが見た動画、友達がいいねした動画。このパスは通常最もクリック率が高いが、カバレッジは限定的。

面接官はリコール層の設計に概ね満足しましたが、私が見落としていた点を指摘しました：リコール重複排除。ユーザーが既に見た動画、興味なしとマークした動画はリコール段階でフィルタリングすべきで、そうしないとランキング層の計算リソースを無駄に消費する。

3. ランキング層設計

ランキング層の目標は、数千の候補から数百を精選することです。粗いランキングと精細ランキングの2段階に分けました：

1. 粗いランキング：軽量モデル（ツインタワーモデルなど）で高速にスコアリングし、数千の候補を数百に絞り込む。核心要件は低レイテンシで、各動画のスコアリング時間を1ms以内に抑える。

2. 精細ランキング：深層学習モデル（DIN、DIEN、MMOEなど）で多目的最適化。精細ランキングのいくつかの重要な設計を詳しく説明しました：

- 多目的最適化：CTR、完了率、いいね率、コメント率、シェア率を同時に予測し、最終的に重み付き公式で融合。面接官が「重みはどう決める？」と追及——「オンラインA/B実験で調整する」と回答。

- 特徴エンジニアリング：ユーザー特徴（行動履歴シーケンス、プロファイルタグ）、動画特徴（再生時間、解像度、タグembedding）、コンテキスト特徴（時間、ネットワーク、デバイス）。中でもユーザー行動シーケンスが最も重要な特徴で、Attention機構で現在の候補動画に関連する行動を抽出。

- 学習データ：インプレッション但没有クリックを負例とするが、サンプル選択バイアスに注意。面接官が「どう解決する？」と質問——ランダム負サンプリングで非インプレッションサンプルを補完すると回答。

4. 再ランキング層設計

再ランキング層はランキング結果にビジネスルールの調整と多様性保証を適用します：

1. 多様性制御：MMR（Maximal Marginal Relevance）アルゴリズムで関連性と多様性のバランスを取り、同種の動画が連続推薦されるのを防ぐ。

2. ビジネスルール：広告挿入位置、プロモーション動画の保証量、センシティブコンテンツのフィルタリング。これらのルールはモデルランキング結果を上書きする。

3. コンテキスト調整：時間帯（深夜はリラックスコンテンツ）、ネットワーク状態（弱電界では短い動画）に応じた動的調整。

5. リアルタイム特徴量更新

これは面接官が重点的に深掘りした領域です。YouTube推薦システムの核心的な利点はリアルタイムフィードバック——ユーザーがコメディ動画を見た直後、次の推薦は類似動画であるべき。

私の設計：ユーザー行動→Kafka→Flinkストリーミング処理→特徴量更新→モデル推論。

具体的には、ユーザーの再生、いいね、スキップの各行動がリアルタイムでKafkaに書き込まれる。Flinkが消費してユーザーのリアルタイム特徴（直近10件の視聴履歴、現在のセッション興味タグなど）を更新。更新された特徴はRedisに書き込まれ、精細ランキングモデルが推論時にRedisから読み取る。

面接官が「リアルタイム特徴のレイテンシ要件」を質問。「エンドツーエンド500ms以内」と回答。さらに「どう保証する？」と追及され、いくつかの最適化を挙げた：Flinkはイベントタイムウィンドウではなくタンブリングウィンドウで待ち時間を削減、RedisはPipelineでバッチ読み書き、モデル推論はGPU推論サービスを使用。

6. A/B実験プラットフォーム

面接官が「推薦アルゴリズムの効果をどう検証する？」と質問。A/B実験の設計を説明：

1. 階層型実験：リコール層、ランキング層、再ランキング層それぞれに実験レイヤーがあり、異なるレイヤーの実験は直交して互いに影響しない。これによりリコール実験Aとランキング実験Bを同時実行できる。

2. トラフィック分割：ユーザーIDのハッシュでバケット分けし、同じユーザーが常に同じグループに属するよう保証。実験グループは通常5〜10%のトラフィックを占める。

3. 指標モニタリング：コア指標（ユーザーあたり視聴時間、エンゲージメント率）+ガードレール指標（ネガティブフィードバック率、通報率）。ガードレール指標が悪化した場合、実験は即座にロールバック。

7. コールドスタート戦略

新規ユーザーコールドスタート：登録時に興味タグを選択→人気リコール+興味タグリコールのミックス→行動データを迅速に蓄積→段階的にパーソナライズ推薦に移行。

新規動画コールドスタート：新規動画はまず探索トラフィックプール（約5%トラフィック）に入る。初期フィードバックに基づいて推薦拡大を判断。好成績の動画は段階的により大きなプールに進出——「競馬メカニズム」に似た仕組み。

心得・アドバイス

1. 推薦システムの面接は必ず「リコール→ランキング→再ランキング」の3層フレームワークで説明する。これは業界標準で、面接官はすぐに専門知識があると認識する。

2. アルゴリズムだけでなく、エンジニアリング実装も語る。面接官が関心があるのは、モデルをどう運用に落とし込むかであって、モデル自体の先進性ではない。リアルタイム特徴量更新、A/B実験、コールドスタートといったエンジニアリング問題こそが差別化要因。

3. 積極的にトレードオフを議論する。「粗いランキングは精度を犠牲にしてレイテンシを確保し、精細ランキングはレイテンシを犠牲にして精度を確保する」といった表現は非常に評価される。

4. 具体的な数字を準備する。「リコールは10億件から5000件に絞り込み、粗いランキングは5000件から500件に、精細ランキングは500件から100件に」というように。数字は純粋なテキストよりも説得力がある。

5. Googleの面接スタイルは「底まで掘り下げる」——面接官は答えられなくなるまで追及し続ける。これは正常なので、パニックにならず、できる限り答えればよい。

FAQ

Q：Googleのシステム設計面接は通常何ラウンドありますか？

A：通常2〜3ラウンド。第1ラウンドは一般的なアーキテクチャ、第2ラウンドは具体的なビジネスシナリオ、第3ラウンドはクロスドメインの総合問題の可能性があります。

Q：推薦システム面接でどの論文を勉強すべきですか？

A：Deep Interest Network（DIN）、Deep Interest Evolution Network（DIEN）、Deep & Cross Network、Wide & Deep Learning。全論文を精読する必要はありませんが、核心的なアイデアは説明できるようにしましょう。

Q：推薦システムの経験がない場合は？

A：一般的なシステム設計の観点からアプローチし、推薦システムを「データ収集→特徴エンジニアリング→モデル学習→オンラインサービス」の4モジュールに分解して説明しましょう。面接官が評価するのは推薦アルゴリズムの専門知識よりも、システム設計能力です。