# Stopping Performance Regression via Changepoint Detection Navigation: [[sources/_index]] | [[変化点検知]] | [[異常検知]] **イベント**: SREcon25 Americas（2025-03-27） **登壇者**: [[Joseph Cirella]]（Software Engineer）、[[Shanthini Velan]]（Software Engineering Team Lead）、[[Bloomberg]] Ticker Plant SRE Capacity & Performance チーム **公式 URL**: https://www.usenix.org/conference/srecon25americas/presentation/cirella --- ## 概要 [[Bloomberg]] の Ticker Plant インフラ（Bloomberg Terminal・Data License・B-PIPE 向けに市場データを供給するコアパイプライン）において、統計的変化点検知を用いてパフォーマンスリグレッションを検出するプロダクトを構築した経験報告。確率的手法を選ぶべき状況の判断基準、想定される変化点（市場開場/閉場）の扱い、エンジニアへの効果的な情報伝達、フィードバックループの構築を軸に構成される。 --- ## 背景: Ticker Plant とレイテンシの難しさ ![[wiki/sources/_attachments/sre25amer_slides-cirella/page-005-ticker-plant-architecture.png]] Ticker Plant は Bloomberg の膨大な市場データを各システムへ供給する中核インフラで、Bloomberg Terminal・Data License・B-PIPE が依存する。技術的に高度な外部クライアントはレイテンシを強く意識しており、**Ticker Plant のレイテンシが変わると Bloomberg 全体のレイテンシが変わる**。 レイテンシ分析が難しい理由: - **制御外の要因に左右される**: 政治・報道・ブラックスワン・データフィードのバグ - **銘柄・イベントごとに期待値が異なる**: コードパスが稀にしか通らず突発的なバースト活動が起きる - **高ボラティリティ期に一時的なレイテンシ増加は不可避**: 1 日 4,000 億件のメッセージ受信ピークも存在 **設計目標**: アクションとアウトカムを対応づける。測定・対応可能な変化としてコードのロールアウト・バグ・フィーチャーフラグ・ハードウェア変更・OS 変更・下流システムからの背圧がある。 --- ## 動機: なぜ変化点検知か - **データの幅と深さが洞察抽出能力を超えている**: 複雑なホワイトボックス観測とシンプルなブラックボックス観測の両方が存在するが、多様なクライアントが独自の市場サブセットに依存するため事前に全パターンをカバーする現実的なパフォーマンステストは構築不可能 - 統計的手法は「想定外のシステム摂動の自由度が多い」「ノイジーな環境」「システム挙動が時間変化する」「責任が分散している」「大量データがある」場合に適している --- ## 最初の成果: 緩やかな劣化の発見 ![[wiki/sources/_attachments/sre25amer_slides-cirella/page-012-the-findings.png]] マシン群をまたいでパフォーマンス低下が広がったが、ステージやコードロールアウトの明確なパターンがなく、いつ始まったかも不明瞭だった。**ローリング信頼区間**による変化点フラグを用いて変化点を特定し、そのタイミングにビルド・マシン・タグ・フィーチャーフラグのメタデータを紐付けてプログラム的分析を実施できた。 --- ## アルゴリズム選択: Bayesian Online Change Point Detection ![[wiki/sources/_attachments/sre25amer_slides-cirella/page-017-selection-bocd.png]] 3 種類の異なるレイテンシ時系列（比較的一貫・一貫して高い・より曖昧）を示しながら、アルゴリズム選択の難しさを説明。最終的に **Bayesian Online Change Point Detection（BOCD）**を採用した。 選択理由: - 従来手法はモダンな手法と競争力がある場合も多い - データが指数分布族でないにもかかわらず、変化点に対する期待に合った結果が得られた - (参照論文: Adams & MacKay「Bayesian Online Change Point Detection」、Truong ほか「An Evaluation of Change Point Detection Algorithms」) --- ## 課題 ### 想定していた課題 **うまくいったこと**: - 可視化や分析の初期ツール整備 - 合成データ生成への投資 **うまくいかなかったこと（主に MDLC: Machine Learning Development Life Cycle）**: - アノテータ間合意の追跡 - データのバージョン管理の徹底 - 実験の文書化・整理 - 注目するデータのサブセットの絞り込み ### 想定外の課題 1: 想定される変化点 ![[wiki/sources/_attachments/sre25amer_slides-cirella/page-020-expected-changes.png]] 検知器は**想定される変化点**を一貫して検出し続けた: - **市場の開場・閉場** - マシンのメンテナンス - 週末 - 長期休日 これらをマスクするための設定ファイルの維持管理が、**予想外に複雑でトイルが大きい**という課題が判明した。JSON 形式で data_source・series_type・initial_date・start/end などを記述するが、取引所ごとの開場時間の違い・カレンダーの変更・メンテナンス予定の変動が重なり、設定ファイルの鮮度を保つことが継続的な工数を要した。 ### 想定外の課題 2: クラッターとノイズ 初期 UI はすべての変化点を生の数値テーブルとして表示していたが（1 万 2,000 件超の行）、信号対雑音比が低くエンジニアが実際の問題を見つけにくかった。更新後の UI では UTC 表示オン/オフ切替、精度マーク（MARK ACCURACY）機能、`e2e-test` タグフィルタ、Mean、Mean_ms、Confidence 列の追加・並び替えにより、エンジニアが関連変化点を効率的に把握できるよう改善した。 --- ## 学習のまとめ ### 統計的手法を選ぶべき条件 以下のいずれかに当てはまる場合に統計的手法を検討する: - システム摂動の自由度が多い - ノイジーな環境 - システムの挙動が時間とともに変わる - 責任が分散している - 大量のデータがある ### 注意点 **工数の大半は検知コアでなくユーザビリティに費やされる**。検知ロジックより UI・設定管理・フィードバックループの設計に多くのエンジニアリング工数が必要だった。 参照先として [[Ivan Shubin]] の SREcon24 EMEA「Anomaly Detection in Time Series from Scratch Using Statistical Analysis」が挙げられている。 --- ## 関連 - 概念: [[変化点検知]] / [[異常検知]] / [[パフォーマンスリグレッション検知]] - エンティティ: [[Bloomberg]] / [[Joseph Cirella]] / [[Shanthini Velan]] - 関連 MOC: [[異常検知 - MOC]] ## 出典 - スライド全 27 ページ画像（.raw/slides/sre25amer_slides-cirella/pages/） - テキスト抽出（.raw/slides/sre25amer_slides-cirella/sre25amer_slides-cirella.txt） - 公式ページ: https://www.usenix.org/conference/srecon25americas/presentation/cirella