Kafka、Flink、OpenTelemetryを用いたインシデント検知の再構築

小規模なエンジニアリングチームが、自動化されたインシデント検知プラットフォームを再構築し、イベントからメトリクスへの処理遅延を40秒超から10秒未満に削減しました。新しいアーキテクチャは、Apache Kafka、Kubernetes上で実行されるApache Flink、そしてOpenTelemetryを活用し、毎日数十億件規模のクライアント側運用イベントを処理します。このシステムにより速度と分離性は向上しましたが、チームによると再現率（recall rates）は64%から86%の間で変動しており、正確な異常検知における継続的な複雑さが浮き彫りになっています。

何が起きたか

この組織は、数百万のテナントにサービスを提供する10以上のクラウド製品を運営しています。以前は、監視スタックとしてNode.jsのアグリゲーターを使用しており、共有クラウドキューからデータを受け取り、約90台の仮想マシンで稼働させていました。このレガシーシステムは、高い遅延、他のテナントのトラフィックによる遅延を引き起こす「ノイジーネイバー」問題、およびオンボーディングされる各新製品に対して線形に増加するコストといった課題を抱えていました。年間運用コストは12万ドルから23万ドルに上昇し、通常の変更作業中にもキャッシュ層のCPU使用率が頻繁に100%に達していました。

これらの制限に対処するため、チームは5つの目標に焦点を当てた新しいパイプラインを設計しました。それは、10秒未満の遅延、分離のための専用コンシューマーパス、リプレイ時の正確性を保証するための冪等書き込み、機能数ではなくボリュームに応じたコストスケーリング、そして設定駆動型の運用可能性です。その結果、新しいエクスペリエンスのオンボーディングには、フルデプロイメントではなく、設定を更新するためのプルリクエストのみが必要となるシステムが実現しました。チームは18ヶ月間、月次でパフォーマンスを測定し、速度が劇的に改善した一方で、精度は依然として目標を下回っていることを確認しました。

仕組み

アップストリームレイヤーでは、イベントバスとしてApache Kafkaを使用しています。すべてのデータを消費するのではなく、コードで定義されたサーバーサイドのサブスクリプションフィルターを実装しました。このフィルターにより、特定の製品とエクスペリエンスのみを許可し、実験的および合成トラフィックを破棄します。フィルタリングされたデータは、7日間の保持期間を持つ専用のKafkaトピックに格納され、デバッグや復旧のためのリプレイウィンドウとして機能します。パイプラインには2つのサイドインプットが供給されます。シャードやリージョンなどのメタデータを提供するテナントコンテキストサービスと、設定リポジトリです。

コア部分には、Flink Kubernetes Operatorを通じてデプロイされた単一のApache Flink 1.20ジョブが存在します。このジョブは古いイベントやエラーを除外し、サーキットブレーカー付きの非同期サイドカーを使用してテナントコンテキストでデータをエンリッチし、メトリクスを集約します。HyperLogLogスケッチを用いて重複カウントなしに影響を受けるユニークユーザー数を推定し、誤差マージンを約1.5%に抑えています。状態管理はRocksDBで行われ、オブジェクトストレージへの30秒ごとのチェックポイントにより、Parquetファイルに対するexactly-onceセマンティクスと、キーバリューストアへの冪等書き込みを保証します。メトリクスはOpenTelemetry経由でエクスポートされ、Prometheus互いの時系列データベースに保存されます。

AutoHOTと呼ばれる意思決定プレーンは、2つのリージョンでGoサービスとして実行されています。これは検出器からのアラートを消費し、集約ストアへのクエリによって影響度を定量化し、深刻度マトリクスを適用します。誤検知を防ぐため、チケットを作成する前に15分間のユーザーアクティビティの一時的な変動（blips）を確認します。エンジンでは分散ロックを使用し、フェイルオーバー時に重複インシデントが発生しないよう、一度に1つのリージョンのみがアラートを処理するように制御しています。また、テレメトリの沈黙（silence）を監視し、データの欠如がハードダウンしたデータベースシャードを示している可能性があることを認識します。

主要な詳細

• イベントからメトリクスへの処理遅延が40秒超から10秒未満に低下しました。
• システムはKubernetes上の単一のApache Flink 1.20ジョブを使用し、毎日数十億件のイベントを処理します。
• HyperLogLogスケッチにより、テナントとリージョン間でマージ可能なユニークユーザーカウントが可能になり、誤差は約1.5%です。
• 設定は製品設定から生成されるYAMLファイルで管理され、再デプロイメントなしでのホットローディングが可能です。
• 対象範囲内の再現率はピーク時で86%に達しましたが、難しい月には64%程度まで低下し、改善の余地があることを示しています。
• アラートパイプライン全体（注入からクローズまで）を検証するために、15分ごとに合成ディープチェックが実行されます。

なぜ重要なのか

可観測性プラットフォームを構築するエンジニアにとって、このケーススタディはバッチ型集約とリアルタイムストリーム処理の間のトレードオフを示しています。Flinkへの移行により、チームはオンボーディングされる機能の数からコストを切り離すことができました。これは成長中のSaaS製品にとって重要な要素です。OpenTelemetryをエンドツーエンドの可視性のために使用することで、監視システム自体も監視可能となり、ダッシュボードへの信頼を損なうサイレント障害を防ぎます。しかし、変動する再現率は、データが速くなるだけでは必ずしも検知ロジックが良くなるわけではないことをビルダーに思い出させます。

冪等シンクと専用Kafkaトピックを使用するというアーキテクチャ上の選択は、分散システムにおける一般的な痛点であるデータの重複とリソース競合に対処します。オペレーターUIDを安定したAPIとして扱い、オーバスケーラーの境界を調整することで、チームは以前の状態を混乱させていた頻繁な再起動を排除しました。このアプローチは、共有キューとインメモリキャッシュに依存する、ノイズが多く、高価で、遅いレガシー監視スタックに苦しむチーム向けの青写真を提供します。

できること

• ピーク負荷時にノイジーネイバー問題を引き起こす可能性のある共有キュー依存について、現在のイベントパイプラインを評価してください。
• 分散システム間でユニークカウントが必要な場合、HyperLogLogや同様の確率的データ構造の使用を検討してください。
• メッセージバスレベルでサーバーサイドフィルタリングを実装し、下流の処理ボリュームとコストを削減してください。
• 共有キューとインメモリキャッシュに依存する、ノイズが多く、高価で、遅いレガシー監視スタックに苦しむチーム向けの青写真として、このアプローチを検討してください。