Atlassian은 Apache Kafka, Kubernetes상의 Apache Flink, OpenTelemetry를 기반으로 인시던트 자동 생성 시스템에 데이터를 공급하는 인시던트 탐지 플랫폼을 재구축했다. 18개월간 작업한 뒤 발표된 측정 결과에 따르면, 이벤트가 메트릭에 도달하는 시간은 40초 이상에서 10초 미만으로 줄었으며, 50% 샘플링을 사용할 때 지속 처리 용량은 하루 약 5억 건에서 하루 10억 건 이상으로 증가했다.
이 프로젝트는 완성된 성공 사례로 제시되지는 않는다. 관측 범위에 포함된 인시던트의 재현율은 약 60%에서 2026년 6월 86%까지 상승했다가 8월에는 64%로 하락했다. 정확도 역시 목표 수준에 미치지 못했으며, 이에 따라 팀은 탐지기 자체의 품질과 계측이 구성된 제품 및 경험의 범위를 분리하게 됐다.
이벤트 흐름을 중심으로 구축된 플랫폼
Atlassian은 수백만 테넌트를 대상으로 10개가 넘는 클라우드 제품을 운영하며, 이 제품들은 사용자 상호작용에서 매일 수십억 건의 이벤트를 생성한다. 이벤트에는 작업의 시작과 결과, 테넌트·사용자·경험에 관한 데이터, HTTP 코드가 포함된다. 플랫폼은 이 데이터를 사용해 세 가지 질문에 신속하게 답한다. 문제가 있는가? 영향의 규모는 어느 정도인가? 어느 팀에 어떤 심각도로 알려야 하는가?
새로운 설계에서는 애플리케이션 내부에서 전체 흐름을 소비하는 대신 Apache Kafka 버스에서 이벤트를 필터링한다. 약 770줄에 달하는 구독 필터는 코드 설정의 일부로 보관된다. 그런 다음 단일 Apache Flink 1.20 애플리케이션이 Kubernetes에서 이벤트를 처리하고, 테넌트 데이터로 이벤트를 보강하며, OpenTelemetry를 통해 메트릭을 전송하고, 60초 윈도우에서 인시던트 영향을 집계한다.
팀은 집계된 데이터를 저장하기 위해 Apache Parquet을 사용하고, 주요 값에는 멀티리전 저장소를 사용했다. Impact API는 영향을 받은 사용자와 테넌트 수에 대한 답변을 제공한다. AutoHOT 엔진은 알림을 인시던트로 변환하고, 심각도 매트릭스를 적용하며, 일시적인 알림을 억제한 뒤 매분 영향을 다시 평가한다.
성능 및 비용 개선
- 대기열 및 캐시 계층을 포함해 약 90대였던 가상 머신 수가 Kubernetes 컨테이너 4개로 줄었다.
- 월 운영 비용은 약 2만 달러에서 약 650달러로 감소했으며, 이는 약 97%의 감소에 해당한다.
- 데이터 손실 없이 약 20분 안에 Kafka 이벤트를 재생해 처리 중단에서 복구할 수 있게 됐다.
- 영향 대시보드의 조회 시간은 약 10초에서 약 1초로 줄었다.
- 2주간의 병렬 운영 동안 기존 경로와의 일치율은 99.9%에 도달했다.
이 설계는 사용자 ID를 저장하는 대신 영향을 받은 고유 사용자를 계산하기 위해 HyperLogLog를 사용했으며, 오차는 약 1.5%였다. 또한 Kafka 재생을 행 중복 없이 복구할 수 있도록 멱등성 저장 키를 사용했다. 팀은 StatsD 경로를 통해 기존 메트릭 이름을 유지했으며, 이에 따라 전환 시 기존 SLO 대시보드와 탐지기를 변경 없이 계속 사용할 수 있었다.
성능 수치만으로는 충분하지 않은 이유
인시던트 결과는 데이터 파이프라인을 가속한다고 해서 반드시 더 나은 커버리지가 확보되는 것은 아님을 보여준다. 9개월 동안 대형 인시던트는 263건 발생했지만, 그중 117건, 즉 44.5%만 계측이 구성된 경험에 영향을 미쳤다. 이 인시던트 중 80건이 탐지됐으며, 이는 해당 기간 전체 대형 인시던트의 30.4%만 시스템이 포착했다는 의미다.
정확도 역시 알림 유형에 따라 달랐다. 시스템이 자동으로 생성한 Sev2 인시던트의 정확도는 회계연도 동안 약 85%였고, 심각도가 낮은 조기 경보의 정확도는 70%에서 79% 사이였다. 변동 억제 기능은 무시된 일시적 알림 티켓을 약 80% 줄이는 데 기여했다. 반면 메트릭 시스템의 지연으로 인해 데이터 감소가 0으로 간주되면서 오탐이 급증했으며, 이를 해결하기 위해 데이터량 감소 탐지기에 최소 120초의 지연을 추가했다.
남아 있는 제약
가장 큰 논리적 문제는 침묵이 정상 상태처럼 보일 수 있다는 점이다. 데이터베이스 전체가 중단되면 페이지 로딩이 차단될 수 있고, 그 결과 실패 이벤트 자체가 생성되지 않는다. 이벤트 파이프라인 자체가 중단돼도 탐지기가 보지 못할 수 있다. 따라서 팀은 데이터량 감소 탐지기와 메트릭 최신성 검사를 추가했으며, 에지 5xx 오류와 합성 프로브 같은 독립적인 신호를 포함할 계획이다.
팀은 인시던트 탐지와 영향 측정이 서로 다른 두 문제라는 점도 확인했다. 한 인시던트에서는 티켓이 조기에 생성됐지만 시스템은 영향을 받은 사용자를 약 2천 명으로 추정했고, 실제 수는 8만 명을 넘었다. 또한 Impact API는 사전 집계나 캐시 없이 읽기 시점에 HyperLogLog 스키마를 병합했기 때문에 동시 사용자 약 100명의 부하에서 중단됐다.
가장 중요한 취약점은 의사결정 엔진이 두 리전에서 액티브-액티브 방식으로 작동하는 것과 달리, 이벤트 게이트웨이와 Kafka 구독, Flink 작업이 한 리전에서 작동한다는 점이다. 이는 리전 장애가 발생하면 컴퓨팅은 정상적으로 유지되더라도 탐지 소스 자체가 중단될 수 있음을 의미한다.
certi.news의 편집적 해석
Atlassian의 경험에서 핵심적인 가치는 Flink나 Kafka 중 하나를 선택한 데 있지 않다. 버스에서의 필터링, 멱등성 키, OpenTelemetry 자체를 사용한 플랫폼 모니터링, recall과 coverage의 구분처럼 검토 가능한 운영 지표에 아키텍처 결정을 연결한 데 있다. 결과는 효율성을 개선하면 비용과 시간을 뚜렷하게 줄일 수 있지만, 측정 공백이나 사용자 신호를 생성하지 않는 인시던트까지 자동으로 해결하지는 못한다는 점을 보여준다.
Atlassian은 OpenTelemetry를 통해 공급되는 시계열 저장소로 탐지기를 이전하고, Flink 파이프라인을 리전 간 액티브-액티브 방식으로 확장하며, Impact API 앞에 일일 집계와 캐시를 추가할 계획이다. 또한 계측 범위 내에서 recall과 정확도를 각각 90% 이상으로 높이고, Sev3 인시던트 탐지 P90 시간을 90분 미만으로 단축하는 것을 목표로 하고 있다. 이러한 목표는 향후 계획이며, 발표된 자료에 따르면 달성된 결과는 아니다.