Signal：リアルタイム・テレメトリ基盤

課題

100 以上の国と地域で数百万人が本人確認を進めるなか、一部のユーザーは誰にも気づかれずに離脱していました。ベンダー連携が壊れても誰も気づけず、断片化したサーバーログを手作業で読み、診断には 1〜3 日かかっていました。その 1 日ごとに、オンボーディングを完了できない実際のユーザーがいたのです。

アプローチ

• 小さく型付けされた SDK。 1 つの TypeScript トラッカーが、Web、モバイル、Mini Program のすべての画面で同じユーザー行動データを収集し、どこでもイベントの意味がそろうようにしました。
• 安全弁つきのスロットリング。 SDK はイベントをキューにため、3 秒ごとか 10 件たまった時点の早いほうで送信します。クリックごとに 1 リクエスト送るとブラウザのネットワークスレッドを圧迫し、長くためすぎるとタブを閉じたときに失われます。ページを離れるときは navigator.sendBeacon を使います。
• 検証する BFF。 バッチは Backend for Frontend に届き、TypeScript の定義に照らしてスキーマを検証し、タイムスタンプの妥当性を確認し、想定外のフィールドや個人情報（PII）を取り除き、セッションのメタデータとバックエンドの判定（通過、却下、審査待ち）を付与します。この判定と UI の表示を比べることで、UI とバックエンドの状態の食い違いが見えるようになりました。
• Kafka、Flink、ClickHouse、Grafana。 Kafka が世界中のトラフィックの急増を吸収し、Flink がイベントをリアルタイムに処理し、ClickHouse が保存し（列指向ストレージなら高カーディナリティの数十億件のイベントの集計にもミリ秒で応答できますが、行指向では遅すぎます）、Grafana がファネルを表示します。
• 静かな障害対応。 パイプラインが落ちている間、SDK は最大 100 件のイベントを localStorage に保持し、受動的なサーキットブレーカーが送信を止めます。ヘルスチェックのためにサーバーへ問い合わせることはせず、次の成功レスポンスを待ちます。

結果

障害を検知するまでの時間は 24〜72 時間から 5 分未満になりました。ベンダーの 1 ステップが壊れるだけで何千件ものオンボーディングが失敗するファネルにとって、これはポストモーテムの一行で終わるか、その日の朝のうちに直せるかの違いです。