リアルタイム・フロントエンド・テレメトリ基盤

課題

長い複数ステップのフローで、静かに離脱するユーザーがいました。サードパーティとの連携が壊れても誰も気づけず、原因の調査は断片的なサーバーログを手で読むことになり、数日かかりました。その1日1日が、完了できなかった実際のユーザーです。

アプローチ

• 小さな型付き SDK。 1つの TypeScript トラッカーがすべての画面とプラットフォームで同じユーザー操作データを集めるので、イベントはどこでも同じ意味を持ちます。
• 安全弁つきのスロットリング。 SDK はイベントをまとめ、短いタイマーかサイズ上限のどちらか早い方で送信します。クリックごとに1リクエストではブラウザのネットワークスレッドが枯渇し、長く溜めるとタブを閉じたときに失うおそれがあるため、ページを離れるときは navigator.sendBeacon を使います。
• 検証する BFF。 バッチは Backend for Frontend に届き、TypeScript の定義に照らしたスキーマ確認、タイムスタンプの妥当性チェック、想定外のフィールドや個人データの除去、セッションメタデータの付与を行います。バックエンドの判定と UI の表示を突き合わせることで、両者の状態のずれが見えるようになりました。
• 列指向ストレージへのストリーミングパイプライン。 ストリーミングがトラフィックの急増を吸収し、列指向ストレージは、行指向では遅くなる非常に大きくカーディナリティの高いイベント集合の集計をミリ秒で返します。
• 静かな障害対応。 パイプラインが止まっても、SDK はローカルに小さなバッファを保持し、受動的なサーキットブレーカーが送信を止めます。サーバーに死活確認を送らず、次に成功したレスポンスを待ちます。

結果

障害の検知にかかる時間は、数日から5分未満になりました。壊れたステップが多数の失敗につながる場面では、ポストモーテムの一行で終わるか、その朝のうちに直せるかの違いになります。