Intelligent Root Cause Analysis and Incident Diagnostics for Microsoft Fabric and Power BI through Telemetry Correlation and Kusto Query Language

당신이 "The Analytics Enterprise"라고 불리는 거대하고 첨단 기술이 집약된 우주선의 선장이라고 상상해 보십시오. 이 우주선은 Microsoft Fabric과 Power BI라는 두 개의 초복잡한 엔진으로 움직입니다. 이 엔진들은 단순히 비행하는 것이 아니라, 승무원들이 중요한 결정을 내릴 수 있도록 산더미 같은 데이터를 처리합니다. 하지만 때때로 우주선이 덜컥거릴 때가 있습니다. 대시보드가 빈 화면으로 변하거나, 보고서 로딩이 한참 걸리거나, 데이터 파이프라인이 멈춰버리는 상황 말입니다.

이런 일이 발생했을 때, 기존의 방식은 정비사가 손전등과 메모장을 들고 엔진실을 돌아다니며 문제를 찾는 것과 같습니다. 그들은 연료 파이프, 배선, 냉각 시스템, 그리고 항법 컴퓨터를 하나씩 확인하며 어디가 문제인지 추측해야 합니다. 이는 느리고 지치며, 만약 정비사가 전문가가 아니라면 엉뚱한 곳을 고치게 될 수도 있습니다.

이것이 바로 Shujath Baig Mirza의 논문이 다루고 있는 내용입니다. 저자는 Microsoft Fabric과 Power BI 같은 거대한 플랫폼에 있어서, 손전등을 들고 돌아다니는 것(수동 조사)은 너무 느리고 실수가 잦다고 주장합니다. 대신, 이 논문은 우주선 엔진실을 위한 초강력 GPS 역할을 하는 스마트 탐정 시스템을 제안합니다.

스마트 탐정의 도구 상자

새로운 시스템은 미스터리를 해결하기 위해 두 가지 주요 도구를 사용합니다.

1. 텔레메트리 상관관계 (The "All-Seeing Eye" - 모든 것을 보는 눈):
   우주선 곳곳에 수백만 개의 작은 카메라와 마이크(로그, 메트릭, 트레이스)가 있다고 생각해 보십시오. 과거에는 엔지니어들이 각 카메라 피드를 개별적으로 확인해야 했습니다. 새로운 시스템은 이 모든 피드를 하나의 거대한, 동기화된 영화로 엮어냅니다. 이 시스템은 연료 파이프의 깜빡임이 항법 컴퓨터의 이상 소음과 정확히 동시에 발생했다는 것을 알아낼 수 있습니다. 인간이 너무 많은 화면을 동시에 보고 있어서 놓칠 수 있는 점들을 연결해 주는 것입니다.

2. Kusto 쿼리 언어 (The "Magic Spellbook" - 마법 주문서):
   이것은 탐정이 우주선에 질문을 던질 때 사용하는 언어입니다. 무언가 고장 날 때마다 매번 새롭고 복잡한 질문을 처음부터 작성하는 대신, 탐정은 일련의 미리 작성된 재사용 가능한 "주문(템플릿)"을 사용합니다. 이 주문들은 우주선의 부품들이 서로 어떻게 의존하고 있는지 알고 있습니다. 만약 엔진이 고장 나면, 주문은 자동으로 연료, 배선, 냉각 시스템을 올바른 순서대로 점검하여 즉시 용의자 목록을 좁혀줍니다.

큰 실험: 시뮬레이션된 충돌

이 스마트 탐정이 실제로 작동하는지 확인하기 위해, 저자는 단순히 추측만 한 것이 아니라 통제된 시뮬레이션을 실행했습니다. 그들은 Microsoft Fabric과 Power BI 환경의 가짜 버전을 만들고, 의도적으로 네 가지 방식으로 고장을 냈습니다.

• 데이터 새로 고침 실패 (Data Refresh Failures): 연료 탱크를 채우려는데 펌프가 막힌 것과 같습니다.
• 쿼리 성능 저하 (Query Performance Regressions): 항법 컴퓨터가 슬로우 모션처럼 느려진 것과 같습니다.
• 시맨틱 모델 불일치 (Semantic Model Inconsistencies): 지도의 좌표가 잘못된 것과 같습니다.
• 용량 스로틀링 이벤트 (Capacity Throttling Events): 너무 많은 사람이 엔진을 사용하려고 해서 엔진이 과열된 것과 같습니다.

각 "충돌"에 대해 저자는 두 팀을 비교했습니다.

• 팀 매뉴얼 (Team Manual): 기존의 손전등과 메모장 방식을 사용하는 엔지니어들.
• 팀 인텔리전트 (Team Intelligent): 마법 주문서를 갖춘 새로운 스마트 탐정 시스템을 사용하는 엔지니어들.

결과: 속도와 영리함

시뮬레이션 결과는 매우 명확한 차이를 보여주었습니다. 스마트 탐정 시스템은 단순히 조금 더 나은 수준이 아니라, 현저히 더 뛰어났습니다.

• 진짜 범인 찾기:
  우주선이 고장 났을 때, 팀 매뉴얼이 올바른 근본 원인을 맞춘 확률은 데이터 새로 고침 실패의 경우 71.2%, 느린 쿼리의 경우 68.9%, 지도 오류의 경우 73.5%, 과열의 경우 **65.7%**였습니다.
  반면, 팀 인텔리전트는 각각 92.5%, 90.3%, 94.1%, **91.8%**의 확률로 정확한 근본 원인을 찾아냈습니다. 그들은 엔진의 엉뚱한 부분을 탓할 가능성이 훨씬 낮았습니다.

• 수리 시간:
  우주 여행에서 시간은 곧 돈(그리고 신뢰)입니다. 팀 매뉴얼은 연료 펌프가 막힌 이유를 밝히는 데 평균 47.8분, 느린 항법 시스템에 52.1분, 지도 오류에 39.6분, 그리고 과열된 엔진에 무려 58.9분이 걸렸습니다.
  팀 인텔리전트는 연료 펌프 미스터리를 단 18.4분 만에, 느린 항법 시스템을 21.7분 만에, 지도 오류를 15.2분 만에, 과열 문제를 23.5분 만에 해결했습니다! 그들은 진단 시간을 절반 이상 단축했습니다!

• 추측의 감소:
  팀 매뉴얼은 연료 펌프 문제를 찾기 위해 평균 18.6회의 다양한 조사 체크(쿼리)를 수행해야 했습니다. 팀 인텔리전트는 단 6.2회의 체크만 필요했습니다. 그들은 엉뚱한 곳을 보며 시간을 낭비하지 않았습니다.

이것이 의미하는 바 (그리고 그렇지 않은 것)

이 논문은 이러한 스마트하고 연결된 접근 방식을 사용함으로써, 위기 상황에서 개별 전문가의 추측에 의존하는 것을 멈출 수 있다고 제안합니다. 대신, 점들을 자동으로 연결하고 문제 지점을 직접 가리키는 시스템을 사용할 수 있습니다. 이를 통해 전체 운영을 더 안정적이고 스트레스 적게 만들 수 있습니다.

하지만 몇 가지 유의해야 할 사항이 있습니다.

• 이것은 시뮬레이션입니다: 이 결과들은 세심하게 통제된 시뮬레이션 환경에서 나온 것입니다. 논문은 이 시스템이 아직 수백만 명의 실제 사용자가 있는 실제 라이브 우주선에서 테스트되었다고 주장하지 않습니다. 저자들은 결과가 매우 좋아 보이지만, 실제 세계에서의 테스트가 다음 단계라고 제안합니다.
• 탐정이지 수리공이 아닙니다: 이 시스템은 문제를 찾아내고 그것이 무엇인지 알려주는 데 매우 뛰어납니다. 하지만 아직 엔진을 자동으로 수리(치유) 하지는 못합니다. 아주 훌륭한 가이드이지만, 여전히 렌치를 돌릴 정비사가 필요합니다.
• 모든 것에 마법처럼 작동하지는 않습니다: 이 시스템은 패턴과 타이밍을 찾는 것에 의존합니다. 만약 문제가 매우 미묘하거나, 패턴에 맞지 않는 기이한 지연 방식으로 발생한다면 시스템이 완벽하지 않을 수도 있습니다.

요약하자면, 이 논문은 Microsoft Fabric 및 Power BI와 같은 복잡한 데이터 플랫폼의 경우, "손전등과 추측" 방식에서 "스마트하고 연결된 탐정" 방식으로 전환하는 것이 문제를 더 빠르고, 정확하며, 스트레스 없이 찾을 수 있음을 보여줍니다. 이는 우리의 데이터 우주선을 원활하게 계속 비행하게 만드는 유망한 단계입니다.