リアルタイム分析基盤の構築方法

意思決定から逆算するレイテンシ予算とKPI設計

リアルタイムの「速さ」は用途で決まります。たとえば不正検知は10秒以内、在庫反映は1分以内、レコメンドはページ表示中の200ms以内など、誰がどのアクションを起こすかから逆算し、エンド・ツー・エンドのレイテンシ予算を数値で持ちます（例：取り込み5秒、集計10秒、配信5秒）。同時に「どの精度を諦めるか」も合意します。最新性を優先して最終整合性で許容するのか、遅延を増やしてでも完全整合性を目指すのかを明文化すると、後の摩擦が減ります。

イベント設計は最初の落とし穴です。各イベントに一意ID、発生時刻（event_time）と受信時刻（ingest_time）を分けて保持し、パーティションキー（例：tenant_id、user_idのハッシュ）を決めます。粒度は「意思決定単位」に合わせ、過剰なネストは避け、ペイロードは圧縮を前提に100KB未満を目安にします。KPIはビジネスKPI（CVR、LTV）に加え、技術KPI（P95レイテンシ、コンシューマLag、重複率、遅延到着率）をダッシュボードで常時可視化します。

アーキテクチャの定石と選び方

取り込み（Ingest）

アプリSDKやログフォワーダからメッセージブローカーに送ります。スループットが読めない初期はマネージドのKafka互換やクラウドのPub/Sub系が無難です。スキーマはAvro/Protobufで必須化し、Schema Registryで後方互換（nullable追加、フィールド追加のみ許可）を強制します。バッチのCDCも必要なら、データベースからの変更データキャプチャをイベントに変換し、同じストリームに流します。

ストリーム処理（Process）

FlinkやSpark Structured Streamingでウィンドウ集計・結合・フィルタを実装します。時間はイベント時刻ベース、ウォーターマークで遅延到着を2分まで許容、重複はevent_idで除外、集計はスライディングウィンドウ（例：5分幅・1分スライド）が扱いやすいです。出力先はトランザクション対応のシンクを選び、少なくとも「実質的に一度だけ」（at-least-once＋冪等キー）を守ります。ジョブの並列度はパーティション数に合わせ、バックプレッシャが出たら最初にシリアライザとネットワーク帯域を疑います。

保存・配信（Serve）

サブ秒のOLAPが必要ならClickHouse/Pinot/Druidが候補、分単位でよければBigQuery/Snowflakeのストリーミング挿入で十分です。メトリクスはメトリクステーブル（ワイドテーブル）にまとめ、よく使うクエリはマテリアライズドビューとロールアップ（1秒→1分→1時間）でレイヤを分けます。推論系や機械学習の特徴量はフィーチャーストアでバージョン管理し、オンライン用KV（Redis等）にホットデータをキャッシュします。可視化はBIに加え、Webhooksやメッセージングでオペレーションに直接つなげると価値が出ます。

スキーマ・品質・コスト最適化の具体策

データコントラクトは「型・単位・null可否・例外時の代替値」を最低限。PR時に自動検証し、互換性チェックをCIに組み込みます。品質は次を監視します。

• Null率・カテゴリ増加率・配布のドリフト（しきい値超えで自動アラート）
• ジョインの爆発防止にキー選択とブルームフィルタ
• P95レイテンシとLagを同時に見る（P99だけで判断しない）

コストはイベントサイズ・保持期間・クエリパターンで決まります。施策例：

• 圧縮はzstd、画像や大きなJSONはオブジェクトストレージに外出ししURI参照
• ホットを7日、ウォームを90日、コールドをアーカイブに分層
• 近似集計（HyperLogLog、TopK）でカードinality計算を高速化
• サンプリングは意思決定に影響しない粒度で。広告クリックなら1%、不正検知は0%

運用はSLOを数値で持つと回ります。例：可用性99.9%、エンド・ツー・エンドP95≦30秒、遅延到着率≦3%。アラートは「行動可能」なものに絞り、Lag、エラー率、スループットの急変に限定。個人情報は最初からトークナイズし、アクセスは属性ベース制御でBIも行単位マスキングを適用します。実装や運用ドキュメントはCopilotで雛形を作り、Flink SQLのテストケースやRoot Causeの仮説整理はChatGPTやGeminiを併用すると速度が出ます。

身近な企業活用例：中堅ECの失敗と改善

セール時に広告入札が過剰になり、在庫切れ商品にも入札が続く問題が発生。日次バッチの在庫集計と3時間遅延のコンバージョン計測が原因でした。最初はBigQueryに1分間隔でストリーミング挿入しダッシュボード更新を高速化しましたが、ピーク時にクエリが詰まり、在庫反映が間に合わない失敗を経験。

改善では、取り込みをKafkaに切り替え、パーティションキーをtimestampにしてしまいホットスポットが発生。すぐにproduct_idのハッシュに変更し並列度を16→64へ。Flinkで在庫とクリックを5分スライディングで結合、ウォーターマークは2分、重複はevent_idで除外。配信は在庫・価格系をClickHouse、長期分析はBigQueryへ二重書き。広告入札用のオンライン指標はRedisにキャッシュし、在庫0の商品は500ms以内に入札停止へ反映。

結果、セールピーク時でもP95が22秒、過剰入札を18%削減、在庫切れ広告の表示は90%減。コストはzstd圧縮と1分ロールアップでストレージを40%削減。運用面では、Lagとウォーターマーク差分にのみアラートを絞り、ノイズアラートは3分の1に。コードレビューはCopilotでテスト雛形を用意し、アラート時の初動手順はChatGPTで下書きして整備、ダッシュボードの説明文はGeminiで文言改善しました。

運用の現実解：スモールスタートと段階的な厳格化

最初から完璧を狙うより、1系統のイベント・1画面の意思決定から始め、SLOとデータ契約、アラート基準を段階的に厳格化する方が失敗しづらいです。実務では「スキーマ違反で拒否」より「受け入れて隔離（DLQ）」が現実的で、後続影響を抑えつつ改善サイクルを回せます。ベンダ選定はレイテンシ要求と運用体制で決めましょう。サブ秒が主戦場なら列指向OLAP＋ストリームSQL、分単位ならマネージドDWHで十分。どちらにせよ、契約・品質・コスト・運用の仕組みが基盤の寿命を決めます。これらを事業の土台として整えることが、データ解析プラットフォーム事業の価値を最大化し、現場の意思決定を継続的に速く・正確にしていきます。