EXERCISE 60分

ストーリー

高橋アーキテクト
データを正しく処理できなければ、どんな分析も意味を持たない。ここでは、実際のビジネスシナリオに基づいてデータ処理システムを設計しよう

ミッション一覧

#ミッション難易度推定時間
1ECサイトの商品検索システムを設計せよ基本15分
2動画ストリーミングのレコメンデーションを設計せよ応用15分
3リアルタイムログ分析パイプラインを設計せよ応用15分
4不正検知システムのデータ基盤を設計せよ発展15分

Mission 1: ECサイトの商品検索システム

要件

  • 1000万商品を全文検索(日本語対応)
  • ファセット検索(カテゴリ、価格帯、評価、ブランド)
  • オートコンプリート(100ms以内に候補表示)
  • 検索結果の関連度ランキング

設計すべき項目

  1. 検索インフラの選定(Elasticsearch vs Algolia vs OpenSearch)
  2. インデックスの設計(フィールド、アナライザー)
  3. ランキングのカスタマイズ方法
  4. 検索のパフォーマンス最適化
回答例

技術選定: Elasticsearch(OpenSearch)。日本語形態素解析にkuromoji、1000万商品規模でのファセット検索に対応。

インデックス設計:

{
  "mappings": {
    "properties": {
      "name": { "type": "text", "analyzer": "kuromoji" },
      "description": { "type": "text", "analyzer": "kuromoji" },
      "category": { "type": "keyword" },
      "price": { "type": "integer" },
      "rating": { "type": "float" },
      "brand": { "type": "keyword" }
    }
  }
}

ランキング: BM25ベース + function_scoreで販売数・評価をブースト。新着商品にrecency boostを適用。

パフォーマンス: レプリカ3台で読み取り分散。人気クエリのキャッシュ。結果セットのページネーションにsearch_afterを使用。


Mission 2: 動画レコメンデーション

要件

  • DAU 5000万人、動画コンテンツ500万本
  • 「次に見る動画」の推薦精度を最大化
  • 新しいコンテンツが1時間以内に推薦候補に入る
  • 推薦APIのレイテンシ p99 < 100ms

設計すべき項目

  1. 候補生成の戦略(コンテンツベース vs 協調フィルタリング)
  2. 特徴量の設計(ユーザー特徴、動画特徴、コンテキスト特徴)
  3. オフライン学習とオンライン推論の分離
  4. A/Bテスト基盤
回答例

候補生成: 2ステージ構成。Stage 1で500万本から1000本に絞り込み(ANN: Approximate Nearest Neighbor検索)。Stage 2でMLモデルによるスコアリング。

特徴量:

  • ユーザー: 視聴履歴、ジャンル嗜好、視聴完了率、時間帯
  • 動画: ジャンル、タグ、長さ、投稿者、エンゲージメント率
  • コンテキスト: 時間帯、デバイス、直前に見た動画

アーキテクチャ: モデル学習はSpark + GPU (日次バッチ)。特徴量は Feature Store (Redis + DynamoDB)。推論はTensorFlow Serving (リアルタイム)。

A/Bテスト: トラフィックの10%を新モデルに割り当て、CTR・視聴完了率・セッション時間で比較。統計的有意差が確認されたら全体に展開。


Mission 3: リアルタイムログ分析パイプライン

要件

  • 1000台のサーバーからログを収集
  • 1日100億行のログ(ピーク時50万行/秒)
  • リアルタイムのエラー率ダッシュボード
  • 過去30日間のログ検索

設計すべき項目

  1. ログ収集と転送の仕組み
  2. リアルタイム集計の処理基盤
  3. ログの長期保存とコスト最適化
  4. アラートの仕組み
回答例

ログ収集: Fluentd/Fluent Bit (各サーバー) → Kafka (バッファ) → 並行して2系統に分岐。

リアルタイム系: Kafka → Flink (ウィンドウ集計: 1分/5分) → Redis (最新メトリクス) → Grafanaダッシュボード。エラー率が閾値超過時にSlack/PagerDutyアラート。

バッチ系: Kafka → S3 (パーティション: year/month/day/hour) → Athena/Prestoで30日間のアドホック検索。7日以降のデータはGlacierに自動移行。

コスト最適化: ログレベルで保持期間を変更(ERROR: 90日、INFO: 30日、DEBUG: 7日)。圧縮(Parquet形式)でストレージ80%削減。


Mission 4: 不正検知データ基盤

要件

  • ECサイトの取引から不正を検知
  • 1日1000万トランザクション
  • リアルタイム検知(取引から3秒以内に判定)
  • 誤検知率(False Positive)を5%以下に

設計すべき項目

  1. リアルタイムストリーム処理のアーキテクチャ
  2. 特徴量エンジニアリング(リアルタイム特徴量)
  3. ルールベース + MLモデルの組み合わせ
  4. フィードバックループ(誤検知の学習)
回答例

アーキテクチャ: トランザクション → Kafka → Flink (リアルタイムスコアリング) → 判定結果DB。スコアが閾値超過時はトランザクションをブロック。

特徴量:

  • リアルタイム: 直近1時間の取引回数、金額合計、新しいデバイスか、地理的距離
  • バッチ: ユーザーの平均購入金額、通常の購入時間帯、過去の不正フラグ

判定ロジック:

  1. ルールベース: 明確な不正パターン(盗難カードリスト、高額閾値)→ 即座にブロック
  2. MLモデル: ルールで判定できないケースをスコアリング → スコア > 0.8でブロック、0.5-0.8で追加認証

フィードバック: ブロックされた取引を人間がレビュー → ラベル付きデータとしてモデル再学習に利用。週次でモデル更新。


達成チェックリスト

  • Mission 1: 商品検索システムの設計を完了した
  • Mission 2: レコメンデーションシステムの設計を完了した
  • Mission 3: ログ分析パイプラインの設計を完了した
  • Mission 4: 不正検知データ基盤の設計を完了した
  • 各ミッションで技術選定の理由を明記した
  • データの流れを図で示した

次のステップへ

次はStep 3のチェックポイントです。大規模データ処理の知識を確認しましょう。


推定所要時間: 60分