Learned Execution Graphs for Anomaly Detection & Drift in APIs — Ritvik Pandya, JP Morgan Chase

한 줄 핵심

API 요청 처리 흐름을 일시적인 실행 그래프로 모델링해 정상 경로의 기준선을 만들고, 구조적 변화·성능 편차·드리프트를 빠르게 국소화하면 오탐을 줄이면서 장애 탐지와 대응을 자동화할 수 있다.

시간별 요약

1. 0:01
   실행 그래프는 요청이 어떤 순서로 어떤 컨텍스트를 거쳐 처리되는지 DAG로 표현해, 단순한 persistence graph와 달리 실제 요청 흐름의 정상 경로를 이해하는 데 초점을 둔다. 이렇게 보면 재시도와 루프까지 별도 엔티티로 추적할 수 있어, 문제 지점을 더 정확하게 찾을 수 있다.
2. 3:00
   핵심은 전체 흐름을 기준선과 비교해 Tier 1에서 이상이 없으면 넘어가고, 지연이나 편차가 보일 때만 더 깊게 조사하는 방식이다. 새 노드 추가·삭제 같은 구조적 변화나 client별로 다른 지연 특성까지 반영해야 불필요한 알람을 줄일 수 있다.
3. 7:01
   Anomaly는 단발성 이상, drift는 시간이 지나며 기준 자체가 바뀌는 현상으로 구분된다. 구조적 drift, 볼륨 drift, covariate drift처럼 유형을 나눠 봐야 하며, 사례에 따라 롤백·스케일업·비동기 전환처럼 대응 방식도 달라진다.
4. 12:00
   전체 파이프라인은 OpenTelemetry로 데이터 수집을 하고, root cause analysis로 drift 유형을 분류한 뒤, 자동 조치와 그 위험도를 판단해 점진적으로 배포하는 구조다. 운영 환경에서는 hot path로 빠르게 결정하고, recon 경로로 더 정확하게 검증하는 이중 구조가 유효하다.
5. 16:00
   실무에서 중요한 보정 포인트는 지연된 이벤트를 구조적 변화로 오인하지 않도록 윈도우와 기준을 정교하게 잡는 일이다. endpoint별·client별 baseline, cold start 처리, 설명가능성, 새 배포 인지까지 포함해야 오탐을 줄이고 실제 대응 속도를 높일 수 있다.

실무 인사이트

• 요청 처리 흐름을 서비스 목록이 아니라 실행 DAG로 먼저 정의하면, 이상 탐지보다 원인 국소화와 대응 자동화가 훨씬 쉬워진다.
• 모든 트래픽에 하나의 baseline을 적용하기보다 client, endpoint, 요청 유형별 기준선을 분리해야 false alarm이 줄고 운영 신뢰도가 높아진다.
• 감지 시스템은 탐지만으로 끝내지 말고, 구조적 변화 인지와 점진적 rollout/rollback 판단까지 포함해야 실전에서 쓸 수 있다.