EXERCISE 90分

ストーリー

田
田中VPoE
ストリーム処理、イベント駆動、CDC、リアルタイム分析。一通り学んだところで実践だ。DataFlow社にリアルタイムデータパイプラインを設計してもらう
あなた
DataFlow社はマーケティングオートメーションSaaSでしたね。どんなリアルタイム要件がありますか？
あ
田
田中VPoE
3つある。第一に、メール配信のリアルタイムモニタリング — 大量配信中にバウンス率が急上昇したら即座に配信を停止する必要がある。第二に、ユーザー行動のリアルタイムトラッキング — 「今この瞬間にサイトを見ているユーザー」を可視化する。第三に、CDCによるDWHのニアリアルタイム更新だ
あなた
レイテンシ要件がそれぞれ異なりますね。適切なアーキテクチャを選定します
あ
田
田中VPoE
そうだ。「すべてをリアルタイムにする」のではなく、要件に応じたアーキテクチャを設計してくれ

ミッション概要

項目内容
演習タイトルストリーム処理パイプラインの設計
想定時間90分
成果物リアルタイムパイプライン設計書（3つのユースケース）

前提条件

DataFlow社のリアルタイム要件:

1. メール配信モニタリング（レイテンシ: 秒）
   - 1日あたり約500万通のメール配信
   - バウンス率、開封率、クリック率をリアルタイムに集計
   - バウンス率が5%を超えたら自動アラート＋配信停止

2. ユーザー行動トラッキング（レイテンシ: 分）
   - ピーク時の同時接続: 約10,000ユーザー
   - ページビュー、クリック、フォーム送信をトラッキング
   - 「現在アクティブなユーザー数」をダッシュボードに表示

3. DWHニアリアルタイム更新（レイテンシ: 5分以内）
   - PostgreSQLの主要テーブル（users, subscriptions, campaigns）の変更をBigQueryに同期
   - 日次バッチの代替として、ニアリアルタイムのデータ鮮度を実現

技術スタック:
  - 既存: PostgreSQL, MongoDB, BigQuery, Looker
  - 利用可能: AWS (Kafka/MSK, Kinesis), GCP (Pub/Sub, Dataflow)

Mission 1: メール配信モニタリングの設計

要件

バウンス率のリアルタイム監視と自動停止の仕組みを設計してください。

  1. イベントスキーマを定義する
  2. ストリーム処理のアーキテクチャを設計する
  3. ウィンドウ集計とアラート条件を定義する
  4. 障害時のフォールバックを設計する
解答例

イベントスキーマ

{
  "event_id": "evt_email_001",
  "event_type": "email.delivered | email.bounced | email.opened | email.clicked",
  "timestamp": "2025-06-15T14:30:00Z",
  "data": {
    "campaign_id": "camp_123",
    "recipient_email_hash": "sha256_abc",
    "message_id": "msg_456",
    "bounce_type": "hard | soft",
    "bounce_reason": "invalid_address"
  }
}

アーキテクチャ

メール配信サーバー → Kafka Topic: email-events
  → Flink (5分タンブリングウィンドウ)
    → campaign_idごとにバウンス率を計算
    → バウンス率 > 5% → アラート + 配信停止API呼び出し
    → 集計結果 → ClickHouse → Grafanaダッシュボード

ウィンドウ集計

メトリクスウィンドウ集計アラート条件
バウンス率5分タンブリングbounced / (delivered + bounced)> 5%
開封率1時間スライディング（5分スライド）opened / delivered参考値
配信速度1分タンブリングdelivered件数 / 分< 期待値の50%

Mission 2: ユーザー行動トラッキングの設計

要件

ユーザー行動をリアルタイムに集計し、ダッシュボードに表示する仕組みを設計してください。

  1. イベント収集のアーキテクチャを設計する
  2. セッションウィンドウの定義を決定する
  3. リアルタイムダッシュボードの更新方式を選択する
解答例

アーキテクチャ

ブラウザ（JS SDK）→ イベント収集API → Kafka Topic: user-events
  → Flink (セッションウィンドウ: ギャップ30分)
    → セッション単位の集計
    → ClickHouse / BigQuery Streaming Insert
    → Lookerダッシュボード (30秒ごとにリフレッシュ)

セッションウィンドウ定義

項目設定値
セッションギャップ30分
セッション最大長24時間
ウォーターマーク遅延2分

リアルタイムメトリクス

メトリクス計算方法
現在のアクティブユーザー数過去5分間にイベントを発生させたユニークユーザー数
現在のページビュー/分1分タンブリングウィンドウでのPVカウント
平均セッション時間セッションウィンドウの開始〜終了の平均

Mission 3: CDCによるDWHニアリアルタイム更新

要件

PostgreSQLからBigQueryへのCDCパイプラインを設計してください。

  1. CDC方式とツールを選定する
  2. データフローを設計する（初期ロード + 増分同期）
  3. Bronze層への取り込みとSilver層への変換を設計する
  4. データ整合性の検証方法を定義する
解答例

ツール選定

コンポーネントツール理由
CDCDebezium (Kafka Connect)OSSで実績豊富、PostgreSQL WAL読み取り
メッセージングAmazon MSK (Managed Kafka)マネージドでKafka互換
SinkBigQuery Kafka ConnectorKafka → BigQuery直接書き込み

データフロー

Phase 1: 初期ロード
  PostgreSQL → Debezium Snapshot → Kafka → S3 (Bronze)
  → dbt (Silver/Gold) → BigQuery

Phase 2: 増分同期
  PostgreSQL WAL → Debezium → Kafka → BigQuery Sink Connector
  → Bronze テーブル (Streaming Insert)
  → dbt (5分ごとにincremental run) → Silver/Gold テーブル

整合性検証

チェック方法頻度
レコード数PostgreSQL COUNT() vs BigQuery COUNT()1時間ごと
チェックサム主要カラムのハッシュ値比較日次
遅延監視Debeziumのラグモニタリングリアルタイム

達成度チェック

観点達成基準
メール監視ウィンドウ集計とアラート条件が定義されている
ユーザートラッキングセッションウィンドウとリアルタイムメトリクスが設計されている
CDC初期ロード＋増分同期のフローと整合性検証が設計されている
レイテンシ選定各ユースケースに適切なレイテンシとアーキテクチャが選択されている

推定所要時間: 90分