Atlassian은 마이크로서비스 환경에서 인시던트의 근본 원인을 분석하는 작업이 더 이상 수작업 검토만으로는 신뢰하기 어려운 수준에 이르렀다고 봅니다. 수백 개의 상호 연결된 서비스가 여러 리전에서 작동할 때 하나의 장애는 방대한 양의 메트릭, 로그, 트레이스 데이터를 생성합니다. 반면 당직 엔지니어는 보통 서로 분리된 대시보드 사이를 오가며 문제의 원천과 확산 경로에 관한 가설을 머릿속으로 구성해야 합니다.
CNCF 블로그 게시물에서 Atlassian의 Santosh Balaranganathan, Michael Yoo, James Moessis, James Kieltyka, Jason Lee, Lavender Neesham은 근본 원인 분석을 자동화하는 시스템을 설명합니다. 이 시스템은 가설 생성을 자동화하여 대응팀이 증거를 수작업으로 다시 모으는 대신 더 빠르게 검증 및 완화 단계로 이동할 수 있도록 하는 것을 목표로 합니다.
근본 원인 분석을 다중 신호 연결 문제로 전환하기
이 설계는 신호 유형, 시간, 서비스 토폴로지라는 세 가지 증거 계층을 연결하는 데 기반을 둡니다. 신호에는 메트릭, 로그, 트레이스가 포함됩니다. 시간적 동시성은 서로 연관되었을 가능성이 있는 이벤트를 식별하고, 서비스 종속성 그래프는 장애를 시작한 서비스와 이후 영향을 받은 서비스를 구분하는 데 도움을 줍니다.
프로세스는 OpenTelemetry에서 도출한 서비스 맵을 통해 검색 범위를 좁히는 것에서 시작합니다. 플랫폼의 모든 서비스를 분석하는 대신 시스템은 성능이 저하된 사용자 경험 경로에 있는 서비스를 식별하여 일반적으로 수백 개가 아닌 수십 개의 서비스로 구성된 범위를 만듭니다. 이 맵은 문서에 가정된 구조가 아니라 프로덕션 트래픽에서 시간 구간 간 부모-자식 관계로 추출한 실제 통신을 반영합니다.
모니터링 데이터에서 우선순위가 매겨진 가설로
범위가 정해지면 독립적인 모듈이 각 신호 유형에서 이상을 탐지합니다. 메트릭의 경우 Atlassian은 요청률, 오류율, 응답 시간인 RED 지표를 중앙절대편차와 백분위수 범위 같은 통계적 방법으로 모니터링합니다. 각 이상 상태는 강도 값, 관측값, 그리고 관측값이 이탈한 기준선을 생성합니다.
분산 트레이스는 예상치 못한 예외, 새로운 오류 전파 패턴, 특정 구간의 응답 시간 급증을 찾도록 검사합니다. 로그에는 임베딩 기반 클러스터링 기법을 사용해 의미적으로 유사한 항목을 묶은 뒤, 서비스의 일반적인 분포와 비교하여 새롭거나 드문 오류 그룹을 부각합니다.
모든 탐지기는 결과를 타임스탬프, 서비스 이름, 신호 유형, 강도 점수, 세부 정보를 포함하는 통합 스키마의 이벤트로 변환합니다. 이 계층을 통해 연결 엔진은 각 탐지기가 상태를 발견한 방식에 의존하지 않고 이벤트를 분석할 수 있습니다. 또한 전체 시스템을 다시 구축하지 않고도 새로운 탐지기를 추가하거나 하나의 통계 모델을 머신러닝 기반 모델로 교체할 수 있습니다.
장애의 방향을 파악하기 위한 시간과 종속성 그래프
엔진은 조정 가능한 시간 창 안에서 서로 가까운 이벤트를 묶으며, 일반적으로 ±5분을 사용합니다. 각 그룹에는 시간적 응집도 점수가 부여됩니다. 이벤트가 서로 가까울수록 연관되었을 가능성이 높아집니다. 동일한 가설이 수십 번 반복되는 것을 방지하기 위해 시스템은 서비스 시퀀스에 지문을 사용하고, 반복되는 장애 시퀀스를 하나의 그룹으로 통합하면서 재시작 횟수를 셉니다. 따라서 5분 동안 47번 반복된 장애 패턴을 동일한 가설 47개가 아니라 하나의 패턴으로 설명할 수 있습니다.
그런 다음 시스템은 가장 큰 영향을 받은 노드, 즉 다운스트림 노드라고 부르는 대상을 식별하고 종속성 그래프를 거슬러 올라가 시간상 먼저 이상을 보인 서비스를 찾습니다. 서비스 A가 서비스 B를 호출하고 B의 문제가 A의 문제보다 먼저 나타났다면 B는 장애 원천의 더 강력한 후보가 되며, A의 문제는 이후에 발생한 영향으로 취급됩니다. 최종 평가는 시간적 응집도와 전파 경로 점수를 결합해 가설의 우선순위를 정합니다.
결과는 서비스와 신뢰도 점수의 목록에 그치지 않습니다. 각 가설에는 의심되는 서비스, 전파 경로, 각 노드의 증거가 포함됩니다. 증거에는 한계를 초과한 메트릭이나 장애와 연관된 트레이스 ID가 포함되며, 사건의 순서와 특정 원천이 우선시된 이유를 설명하는 자연어 서술도 제공됩니다.
이 방법론이 운영팀에 중요한 이유
여기서 실질적인 가치는 대응 엔지니어를 대체하는 것이 아니라 검토 가능한 가설에 도달하는 데 필요한 시간을 줄이는 데 있습니다. Atlassian은 근본 원인 분석 엔진을 더 광범위한 인시던트 대응 플랫폼과 연결합니다. 이 플랫폼에는 장애가 사용자에게 미친 영향을 탐지하고, 담당 팀을 식별하며, 이용 가능한 증거를 바탕으로 릴리스를 롤백하거나 기능 플래그를 비활성화하는 등의 조치를 제안할 수 있는 인시던트 어시스턴트가 포함됩니다. 또한 플랫폼은 엔지니어가 가설을 수용했는지, 거부했는지, 수정했는지를 기록하여 시간이 지남에 따라 가중치를 개선합니다.
이 경험은 각 신호에 복잡한 머신러닝 모델을 구축하는 것보다 설명 가능한 단순한 방법으로 시작하는 편이 더 적합할 수 있음을 보여줍니다. 중앙절대편차와 백분위수 범위 같은 방법만으로도 많은 메트릭 이상을 탐지하기에 충분했으며, 통계적 방법이 덜 적합한 로그 클러스터링과 트레이스 구조 분석에는 머신러닝 기법이 사용되었습니다.
그러나 이 방법론이 제약을 없애는 것은 아닙니다. 가설의 품질은 모니터링 데이터의 일관성, 서비스 종속성 그래프의 정확성, 실제 장애와 노이즈를 구분하는 탐지기의 능력에 좌우됩니다. 또한 신뢰도 점수는 인과관계에 대한 최종 증거가 아닙니다. 따라서 Atlassian은 각 증거의 출처와 그것을 결과에 연결하는 서술을 보여주는 것이 중요하다고 강조합니다. 회사는 이후 추가 데이터를 요청하고 가설을 수정할 수 있는 언어 모델 기반 오케스트레이션의 활용을 검토하고 있으며, 속도 제한, 격리된 실행, 증거 출처에 대한 명확한 기록을 요구하고 있습니다.
certi.news의 편집자 견해: 이 접근법의 실제 변화는 인시던트 분석을 서로 분리된 도구 간의 수작업 비교에서 신호, 시간, 토폴로지를 통합하는 통합 프로세스로 전환하는 것입니다. 운영상의 성공 여부는 순위 지정 알고리즘 하나가 아니라 설명 가능성, 데이터 품질, 피드백 루프에 달려 있습니다. 따라서 완전한 근본 원인 분석 자동화에 대한 약속보다 모듈화, 중복 제거, 증거 문서화가 즉시 적용하기 더 쉬운 원칙으로 보입니다.