Notice
Recent Posts
Recent Comments
Link
«   2026/06   »
일 월 화 수 목 금 토
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30
Tags more
Archives
Today
Total
관리 메뉴

근묵자흑

AIOps 스터디 4주차 — Correlation 본문

AIOps

AIOps 스터디 4주차 — Correlation

Luuuuu 2026. 4. 25. 20:28

1. 들어가며 — 새벽 알람 폭풍

새벽 3시, payment-db-1의 디스크가 한순간 100% 찼다고 합시다. 5분 안에 운영자의 화면에는 이런 알람들이 뜹니다.

  • MySQL replication lag > 30s (DB 모니터링)
  • payment-api 5xx rate > 5% (APM)
  • checkout p99 latency > 2s (RUM)
  • order-worker queue depth > 10k (Kafka 모니터링)
  • Pod CrashLoopBackOff × 3개 (K8s)
  • SSL cert expiring in 14 days (보안 — 무관함)

이 상황을 그림으로 옮기면 다음과 같습니다. 단 하나의 원인 사건 이 의존 그래프를 따라 번지면서 50개의 알람을 만들어 내고, 그와 무관한 알람 한두 개가 같은 시간대에 우연히 함께 도착합니다.

graph TD
    ROOT[" payment-db-1<br/>디스크 100%"]

    ROOT -->|직접 영향| A1["MySQL<br/>replication lag"]
    ROOT -->|직접 영향| A2["payment-api<br/>5xx rate"]
    A2 -->|전파| A3["checkout<br/>p99 latency"]
    A2 -->|전파| A4["order-worker<br/>queue depth"]
    ROOT -->|직접 영향| A5["Pod<br/>CrashLoopBackOff"]

    NOISE["SSL cert<br/>expiring<br/>(무관)"]

    A1 --> CONSOLE[("운영자 콘솔<br/>알람 50개")]
    A2 --> CONSOLE
    A3 --> CONSOLE
    A4 --> CONSOLE
    A5 --> CONSOLE
    NOISE -.우연히 동시 발생.-> CONSOLE

    style ROOT fill:#ffcccc,stroke:#c00,stroke-width:2px
    style CONSOLE fill:#ffe6cc,stroke:#e68a00,stroke-width:2px
    style NOISE fill:#e6e6e6,stroke:#999,stroke-dasharray: 3 3

관측된 알람: 50개. 실제 incident: 1개. 운영자가 가장 먼저 마주하는 질문은 이것입니다 — *"이 50개 중 어느 것이 원인이고, 어느 것이 결과인가?"*

3주차에서 다룬 Detection이 *"무엇이 잘못됐는가"* 의 신호를 만들어 냈다면, Correlation은 *"그 신호들이 어떻게 묶이는가"* 를 복원하는 단계입니다. 그리고 여기서 가장 자주 오해받는 명제 한 가지가 있습니다.

"AIOps의 본질은 알람을 줄이는 것이 아니다. 알람의 관계를 복원하는 것이다."

이 글은 그 관계 복원 이라는 단 하나의 작업을, Service Dependency Graph (SDG) 라는 자료구조 위에서 어떻게 실현하는지에 대한 4주차 정리입니다.

2. Correlation의 정의와 파이프라인 위치

Sabharwal & Bhardwaj 의 Hands-on AIOps (Apress, 2022) Ch.2는 AIOps의 신호 처리 단계를 Suppression → Deduplication → Rule-based Correlation → ML-based Correlation → Anomaly Detection → Event Correlation → Root-Cause Analysis 의 흐름으로 정리합니다. 이 중 4주차의 작업 영역은 가운데 세 단계, 즉 알람을 묶고 그 묶음 안에서 원인을 가르는 부분입니다.

flowchart LR
    RAW["Raw 신호<br/>(메트릭/로그/이벤트)"] --> SUP["Suppression<br/>점검 중 알람 제거"]
    SUP --> DEDUP["Deduplication<br/>중복을 1건으로"]
    DEDUP --> RC["Rule-based<br/>Correlation"]
    RC --> TC["Topology-based<br/>Correlation<br/>(그래프 위 묶기)"]
    TC --> ML["ML-based<br/>Correlation<br/>(패턴 학습)"]
    ML --> RCA["Root-Cause<br/>Analysis"]

    SUP -.전처리.- DEDUP

    style RC fill:#fff5cc,stroke:#cc9900,stroke-width:2px
    style TC fill:#ffe6cc,stroke:#e68a00,stroke-width:3px
    style ML fill:#fff5cc,stroke:#cc9900,stroke-width:2px

표로 정리하면 이렇게 보입니다.

단계 무엇을 하는가 4주차에서의 위치
Suppression 정기 점검·알려진 이슈 알람을 끔 전처리
Deduplication 동일 신호의 반복을 1건으로 합침 전처리
Rule-based Correlation 룰 매칭으로 알람을 묶음 본 작업
└ Topology-based Correlation 토폴로지 그래프로 묶고 causal/impacted를 가름 본 작업의 핵심
ML-based Correlation 패턴/인과를 학습으로 추출 본 작업

 

 Hands-on AIOps Ch.2 의 correlation의 표준 정의입니다.

*"For example, if a switch is down, then all servers or infrastructure beyond the switch is unreachable from the monitoring systems. The topology-based correlation will flag these events, correlate all infrastructure events with the switch-down event, and flag the switch as a probable root cause for all these events."* — Hands-on AIOps Ch.2

핵심은 두 가지입니다. (1) 토폴로지가 알람을 묶는 기준이 된다. (2) 그 묶음 안에서 probable root cause 가 한 알람으로 지목된다. Correlation은 dedup의 확장이 아니라, 그래프 구조 위에서의 묶기입니다.

3. Alert Noise는 왜 생기는가

세 가지 메커니즘이 동시에 작동합니다.

(a) Cascading: 분산 시스템에서는 하나의 장애가 호출 그래프를 따라 번집니다. Observability Engineering Ch.1의 한 문장이 이를 가장 정확하게 표현합니다.

*"In modern cloud native systems, the hardest thing about debugging is no longer understanding how the code runs but finding where in your system the code with the problem even lives. Good luck looking at a dashboard or a service map to see which node or service is slow, because distributed requests in these systems often loop back on themselves. When something gets slow, everything gets slow."*

(b) Threshold 기반 알람의 누적: 모니터링 도구마다 자체 임계값으로 알람을 발사합니다. DB·APM·RUM·K8s가 같은 사건을 각자의 언어로 신고합니다. Observability Engineering Ch.3은 이를 *"meaningless noise"* 로 부릅니다.

(c) Edge case의 폭증: 사용자가 다양해질수록 *"모든 사용자에게 같은 경험"* 이라는 가정이 깨집니다. Threshold-based 알람은 그 변동을 false positive로 쏟아냅니다.

이 셋이 합쳐져 50:1, 100:1의 알람-인시던트 비율이 나옵니다. 그래서 Hands-on AIOps Ch.2는 *"All this data needs correlation so that the noise can be eliminated, and the causal event ... is flagged and identified automatically."* 라고 명시합니다. 노이즈를 끄는 게 아니라 묶어서 원인 알람을 골라내는 것 — 이 차이가 4주차의 출발점입니다.

4. Event Correlation의 4가지 축

학술적으로 알람 상관관계 기법을 처음 체계적으로 분류한 것은 Salah, Maciá-Fernández, Díaz-Verdejo 의 *"A model-based survey of alert correlation techniques"* (Computer Networks, 2013)입니다. 이 서베이는 similarity / sequence / case 기반의 3축으로 분류했습니다. 본 글은 이를 그대로 옮기지 않고, 2024-2026 산업 환경에 맞게 4축으로 재정리합니다 — Salah의 분류를 토대로, Topology-aware correlation 흐름과 LLM 기반 의미 매칭이 부상한 현재 상황을 반영한 것입니다.

flowchart TB
    INPUT["같은 시간대<br/>여러 알람"] --> AXES{"어떤 기준으로<br/>묶을 것인가?"}

    AXES --> T["Temporal<br/>같은 시간 윈도우<br/>(BigPanda)"]
    AXES --> L["Label<br/>같은 라벨 셋<br/>(Alertmanager)"]
    AXES --> TOP["Topological<br/>호출/의존 그래프 인접<br/>(MicroRCA, Groot)"]
    AXES --> S["Semantic<br/>메시지 의미 유사<br/>(PagerDuty IG, COLA)"]

    T --> COMBINE["실무에서는<br/>4축을 결합"]
    L --> COMBINE
    TOP --> COMBINE
    S --> COMBINE

    style TOP fill:#ffe6cc,stroke:#e68a00,stroke-width:2px
    style COMBINE fill:#cce5ff,stroke:#0066cc,stroke-width:2px
축 무엇을 보는가 대표 도구 한계
Temporal 같은 시간 윈도우 안에 발생한 알람 BigPanda time-window correlation 같은 시각의 무관한 알람도 묶음
Label 같은 라벨 셋 (alertname, cluster, service) Prometheus Alertmanager group_by 라벨이 다르면 묶이지 않음
Topological 호출/의존 그래프상 인접 Topology-aware correlation, Groot 토폴로지 정확도에 의존
Semantic 알람 메시지의 의미 유사성 PagerDuty Intelligent Grouping, COLA 어휘 차이에 취약

실제 production-grade correlation 엔진은 이 4축을 결합해 사용합니다. PagerDuty의 Unified Alert Grouping은 Content(=Semantic) + Intelligent(=Temporal) 결합이고, BigPanda는 source / time window / tags / filter — 4가지 correlation property를 룰로 조합합니다.

5. Topology-aware Correlation 심화 — Network vs Application

Hands-on AIOps Ch.8은 토폴로지를 두 종류로 분리합니다.

5.1 Network Topology Correlation

*"This correlation uses the network connectivity diagram as the topology to perform correlation. For example, if a core switch connecting hundreds of servers and devices to its interfaces is down, then alerts from this switch are causal, and all other alerts from the underlying network devices and servers as well as applications running over them are considered impacted."* — Hands-on AIOps Ch.8

JSON 표현은 단순한 부모-자식 관계입니다.

{"network_topology": [
  {"child-ci": "dummy-app-1", "parent-ci": "ntwrk-switch-1"},
  {"child-ci": "dummy-db-1",  "parent-ci": "ntwrk-switch-1"},
  {"child-ci": "ntwrk-lb-1",  "parent-ci": "ntwrk-switch-1"}
]}

이 한 쌍 — child-ci ↔ parent-ci — 이 곧 SDG의 한 edge입니다. 그림으로 옮기면, 책의 예제는 core switch 한 대 아래에 모든 서버가 매달린 단순한 별 형태입니다. 스위치가 죽으면 이 별 전체가 한 incident로 묶이고, causal CI는 스위치 단 하나입니다.

graph TD
    SW["🔴 ntwrk-switch-1<br/>(parent CI · 죽으면 causal)"]
    SW --> APP1["dummy-app-1"]
    SW --> APP2["dummy-app-2"]
    SW --> WEB1["dummy-web-1"]
    SW --> WEB2["dummy-web-2"]
    SW --> DB1["dummy-db-1"]
    SW --> DB2["dummy-db-2"]
    SW --> SRV1["dummy-srv-1"]
    SW --> SRV2["dummy-srv-2"]
    SW --> SRV3["dummy-srv-3"]
    SW --> LB["ntwrk-lb-1"]

    style SW fill:#ffcccc,stroke:#c00,stroke-width:3px

5.2 Application Topology Correlation

마이크로서비스 환경에서 더 중요한 것은 애플리케이션 토폴로지입니다. KPI(metric type/name)까지 포함된 더 풍부한 메타데이터가 함께 갑니다.

{"application_topology": [
  {"child-ci": "dummy-db-1",  "parent-ci": "",
   "kpi": {"type": "process", "name": "dummy-process"}},
  {"child-ci": "dummy-app-1", "parent-ci": "dummy-db-1",
   "kpi": {"type": "service", "name": "app_service"}},
  {"child-ci": "dummy-web-1", "parent-ci": "dummy-app-1",
   "kpi": {"type": "url",     "name": "dummy-url.com"}}
]}

이 구조를 그림으로 옮긴 다음, DB 프로세스가 떨어진 시나리오를 같은 그림 위에 겹쳐 보면 causal/impacted 판정이 한눈에 보입니다.

graph TD
    DB1["dummy-db-1<br/>process: dummy-process<br/>━━━━━━━━━━<br/>🔴 DB 프로세스 down<br/>= causal alert"]
    APP1["⚠️ dummy-app-1<br/>service: app_service<br/>━━━━━━━━━━<br/>🟡 큐 적체 알람<br/>= impacted"]
    WEB1["⚠️ dummy-web-1<br/>url: dummy-url.com<br/>━━━━━━━━━━<br/>🟡 응답시간 알람<br/>= impacted"]

    DB1 -->|상위 호출| APP1
    APP1 -->|상위 호출| WEB1

    style DB1 fill:#ffcccc,stroke:#c00,stroke-width:3px
    style APP1 fill:#fff5cc,stroke:#cc9900,stroke-width:2px
    style WEB1 fill:#fff5cc,stroke:#cc9900,stroke-width:2px

세 알람은 한 incident로 묶이고, causal CI는 dummy-db-1 으로, 나머지 둘은 impacted 로 표시됩니다. 이것이 4주차에서 가장 자주 쓰일 causal vs impacted 판정의 가장 단순한 예입니다.

5.3 한계 — 100% 정확한 CMDB는 없다

같은 챕터의 다음 문장은 4주차에서 반드시 짚어야 할 현실입니다.

*"To improve the accuracy of clustering and the determination of the root cause, you need to provide some topology context. But the CMDB and discovery are challenges in themselves, and having a 100 percent accurate CMDB with 100 percent discovery and modeling of infrastructure is a tough task."*

100% 정확한 토폴로지는 없습니다. 그래서 Ch.8은 hostname/IP 유사도, 알람 시간 패턴, 메시지 텍스트, 이벤트 클래스/소스 — 4가지 feature로 토폴로지를 학습하는 보조 기법을 제시합니다. CMDB가 stale일 때의 안전장치입니다.

6. Service Dependency Graph 구축 4가지 경로

SDG는 어디서 오는가? 네 가지 출처가 있고, 어느 출처를 쓰든 결국 *"누가 누구를 호출하는가"* 의 동일한 그래프로 수렴합니다. 다른 점은 정확도·커버리지·코드 변경 필요 여부입니다.

flowchart LR
    CMDB["(a) CMDB 수작업<br/>ServiceNow / BMC<br/>━━━━━━━━<br/>광역 · stale 위험"]
    OTEL["(b) 분산 트레이싱<br/>OpenTelemetry / Jaeger<br/>━━━━━━━━<br/>실측 · 계측 필요"]
    MESH["(c) 서비스 메시<br/>Istio / Kiali<br/>━━━━━━━━<br/>코드 무수정 · 메시 안만"]
    EBPF["(d) eBPF<br/>Pixie / Cilium Hubble<br/>━━━━━━━━<br/>클러스터 전체 · 커널 권한"]

    CMDB -->|수렴| SDG[("Service<br/>Dependency<br/>Graph")]
    OTEL -->|수렴| SDG
    MESH -->|수렴| SDG
    EBPF -->|수렴| SDG

    SDG --> CORR["Topology-aware<br/>Correlation<br/>(causal / impacted 판정)"]

    style SDG fill:#cce5ff,stroke:#0066cc,stroke-width:3px
    style CORR fill:#ffe6cc,stroke:#e68a00,stroke-width:2px
경로 정확도 커버리지 운영 부담 핵심 한계
(a) CMDB 수작업 낮~중 인프라까지 광역 매우 높음 Stale 문제
(b) 분산 트레이싱 (OTel) 높음 (실측) 계측된 서비스만 중 (계측 노력) 외부·미계측 컴포넌트 누락
(c) 서비스 메시 (Istio/Kiali) 높음 메시 안의 서비스만 중~상 메시 외부 트래픽 보이지 않음
(d) eBPF (Pixie/Hubble) 높음 클러스터 전체 (코드 무수정) 중 (커널 권한) 암호화 트래픽·앱 의미론 일부 손실

6.1 (a) CMDB — ServiceNow / BMC

ServiceNow 자체가 Stale CI 처리 플레이북(KB0829106)을 별도 운영합니다. 정의 그대로 *"a stale CI is a configuration item that is no longer accurate, not updated, or no longer exists in the environment, but still exists in the CMDB."* CMDB는 단독으로는 충분하지 않습니다.

6.2 (b) 분산 트레이싱 — OpenTelemetry Service Graph Connector

OTel Collector Contrib의 servicegraphconnector는 가장 표준적인 SDG 자동 생성기입니다. README의 핵심 한 줄.

*"Service graphs work by inspecting traces and looking for spans with parent-children relationship that represent a request."*

Span의 5가지 필수 필드 중 Parent ID 가 곧 SDG의 edge 정보입니다. Trace 자체가 *"a series of interconnected events"* (Observability Engineering Ch.6)이므로, 충분한 trace를 누적하면 SDG는 자연스럽게 그려집니다. 한 요청이 들어올 때 어떻게 Parent ID가 SDG의 edge가 되는지 시퀀스로 보면 더 직관적입니다.

sequenceDiagram
    participant A as Service A
    participant B as Service B
    participant C as Service C
    participant SG as servicegraph<br/>connector

    A->>B: span(parent=root)
    B->>C: span(parent=A의 span)
    C-->>B: response
    B-->>A: response

    Note over SG: trace 검사 →<br/>parent-children 추출
    SG->>SG: edge 추가: A → B
    SG->>SG: edge 추가: B → C

    Note over SG: ⇒ Service Dependency<br/>Graph 자동 구축

권장 구성 예:

connectors:
  servicegraph:
    latency_histogram_buckets: [2ms, 4ms, 8ms, 50ms, 200ms, 1s, 2s, 5s, 10s]
    dimensions: [service.namespace, deployment.environment, k8s.cluster.name]
    store:
      ttl: 2s
      max_items: 10000
service:
  pipelines:
    traces:  { receivers: [otlp], exporters: [servicegraph, otlp/traces] }
    metrics: { receivers: [servicegraph], exporters: [otlp/metrics] }

미계측 클라이언트(브라우저, 외부 DB)는 virtual_node_peer_attributes로 peer.service / db.name을 가상 노드로 만듭니다. 이게 없으면 *"Unknown"* 노드로만 표시됩니다.

6.3 (c) 서비스 메시 — Istio + Kiali

Envoy proxy가 자동으로 노출하는 istio_requests_total, source_workload, destination_service 라벨을 Kiali가 Prometheus로 쿼리해 그래프를 그립니다. 코드 변경 0줄. 다만 Kiali FAQ가 직접 인정하듯 *"Istio can't recognize HTTPS request that go directly to the service... these requests are encrypted and are recognized as TCP traffic"* — 메시 외부 호출은 Unknown 노드로 들어옵니다.

6.4 (d) eBPF — Cilium Hubble · Pixie

가장 새로운 경로입니다. 커널 레벨에서 syscall을 관찰하므로 애플리케이션 무수정.

  • Cilium Hubble — *"zero-effort automatic discovery of the service dependency graph for Kubernetes Clusters at L3/L4 and even L7"*. Cilium은 2023-10-11 CNCF Graduated.
  • Pixie — Auto-telemetry, In-Cluster Edge Compute (CPU < 5%, 통상 < 2%), Scriptability(PxL). 자동 추적 프로토콜 10종+. 현재 CNCF Sandbox 단계.

7. Stale Topology의 함정 — 토폴로지가 틀리면 어떤 일이 벌어지는가

SDG-aware correlation은 그래프가 옳다는 가정 위에 서 있습니다. 그래프가 틀리면 운영자가 가장 먼저 마주하는 것은 잘못된 causal 지목입니다 — 이미 사라진 노드가 root cause로 표시되고, 운영자는 존재하지 않는 서버를 디버깅합니다. 두 번째는 고립 노드 누락으로, 새로 추가된 서비스가 그래프 밖에 있어 그 서비스의 알람이 아무 incident에도 묶이지 않습니다. 세 번째는 잘못된 inhibition입니다. 부모-자식 관계가 틀려서 살아있는 알람이 mute 되거나, 반대로 이미 묶여야 할 알람이 별도 incident로 분리됩니다. 네 번째 위험은 토폴로지 drift 미감지로, auto-scaling이나 배포로 호출 패턴이 바뀌어도 그래프가 그것을 따라가지 못하는 경우입니다. 마지막은 multi-tenant leakage — 토폴로지 상의 경계가 모호하면 한 tenant의 알람이 다른 tenant의 incident로 흘러 들어갑니다.

이 다섯 가지 위험을 그림으로 보면 다음과 같습니다.

flowchart LR
    REAL["실제 시스템<br/>(현재)"] -.시간 경과.-> DRIFT["배포·스케일링·<br/>새 서비스 추가"]

    SDG["저장된 SDG<br/>(과거 시점)"]

    DRIFT --> RISKS{"SDG와 어긋남"}

    RISKS --> R1["1️⃣ 잘못된 causal<br/>(없는 노드 지목)"]
    RISKS --> R2["2️⃣ 고립 노드<br/>(새 서비스 누락)"]
    RISKS --> R3["3️⃣ 잘못된 inhibition<br/>(살아있는 알람 mute)"]
    RISKS --> R4["4️⃣ Drift 미감지<br/>(호출 패턴 변화)"]
    RISKS --> R5["5️⃣ Multi-tenant<br/>leakage"]

    style REAL fill:#ccffcc
    style SDG fill:#e6e6e6,stroke-dasharray: 3 3
    style RISKS fill:#ffcccc,stroke:#c00

완화 패턴은 세 가지가 있습니다. 첫째, 다중 출처 결합입니다. CMDB만 믿지 말고 OTel/eBPF로 보강합니다 — Hands-on AIOps Ch.8의 4가지 feature 학습이 정확히 이 자리에 들어갑니다. 둘째, 짧은 TTL과 자동 expiry. OTel servicegraph connector의 store.ttl을 2~10초로 짧게 잡으면 drift는 자동 반영됩니다. 단 짧은 burst를 놓치는 trade-off가 있습니다. 셋째, dynamic SDG 인식 알고리즘입니다. DynaCausal (arXiv:2510.22613, 2025)은 *"auto-scaling이 transient fault를 cascading failure로 증폭하고, continuous deployment가 'ghost' failure를 만든다"* 는 문제를 명시적으로 다룹니다.

8. Alert Grouping 실전 — 50개 알람을 1개 incident로

도입의 새벽 3시 시나리오로 돌아갑시다. 50개 알람을 어떻게 1개 incident로 묶을까요?

세 가지 단계의 묶기 방법이 같은 알람 셋에 적용되었을 때 결과가 어떻게 달라지는지 비교해 보면, 토폴로지 인지가 왜 중요한지가 한눈에 들어옵니다.

flowchart TB
    INPUT["입력: 6개 알람<br/>━━━━━━━━━━<br/>DB latency · API 5xx<br/>checkout slow · queue depth<br/>Pod crash · SSL cert(무관)"]

    INPUT --> M1["① 라벨 기반<br/>group_by: alertname"]
    INPUT --> M2["② 시간 윈도우<br/>5분 이내 묶기"]
    INPUT --> M3["③ 토폴로지 인지<br/>SDG ancestor 묶기"]

    M1 --> O1["결과: 6개 그룹<br/>(라벨이 다 다름)<br/>운영자가 직접<br/>관계 추론 필요"]
    M2 --> O2["결과: 1 incident(5개)<br/>+ SSL 별도<br/>causal 모름"]
    M3 --> O3["결과: 1 incident<br/>━━━━━━━━━<br/>🔴 causal: DB<br/>🟡 impacted: 4개<br/>+ SSL 별도"]

    style M3 fill:#ffe6cc,stroke:#e68a00,stroke-width:2px
    style O3 fill:#ffcccc,stroke:#c00,stroke-width:2px

8.1 라벨 기반 — Prometheus Alertmanager

가장 낮은 단계입니다.

route:
  receiver: sre-team
  group_by: ['alertname', 'cluster', 'service']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
inhibit_rules:
  - source_matchers: [severity="critical", alertname="ClusterUnreachable"]
    target_matchers: [severity=~"warning|info"]
    equal: [cluster]

한계는 공식 문서 와 운영 가이드가 직접 명시합니다 — Prometheus가 룰 그룹을 동시 평가하므로 한 그룹의 알람이 다른 그룹을 inhibit하기 어렵고, inhibition은 정적 룰이며, 라벨 외의 그래프 구조는 모릅니다. 즉 도입 시나리오의 50개 알람 중 라벨이 다른 알람들은 묶이지 않습니다.

8.2 시간 윈도우 — BigPanda

라벨이 달라도 같은 시간 윈도우 안에 발생한 알람을 묶습니다. BigPanda 공식 문서 기준 한 incident에 묶을 수 있는 알람 최대치(max correlation limit)는 300개, correlation 처리 시간은 < 100ms 입니다.

⚠️ "한 incident 평균 300 alerts"로 옮기면 과장입니다. 상한 한계 입니다.

8.3 토폴로지 인지 — SDG ancestor 묶기

가장 윗 단계입니다. SDG 위에서 알람을 단 노드들의 공통 조상*을 찾고, 그 조상 서브트리에 속한 모든 알람을 한 incident로 묶습니다. 도입 시나리오라면 payment-db-1이 조상이고, 그 아래의 API/체크아웃/큐 알람은 모두 *impacted, DB 알람만 causal 로 표시됩니다.

11번 절에서 다룰 Groot*가 한 단계 더 나아가, 노드를 *서비스 가 아니라 event 로 두어 "Service B의 deploy event가 원인"처럼 더 fine-grained한 식별을 합니다.

9. SLO 기반 Alerting과 Correlation의 두 층

알람의 질 자체를 어떻게 설계해야 correlation이 잘 동작할까요? Honeycomb의 Observability Engineering Ch.12가 가장 명확한 답을 줍니다.

*"SLOs narrow the scope of your alerts to consider only symptoms that impact what the users of our service experience. ... In contrast, traditional monitoring relies on a cause-based approach: a previously known cause is detected ... That approach fuses the 'what' and 'why' of a situation. ... Decoupling 'what' from 'why' is one of the most important distinctions in writing good monitoring with maximum signal and minimum noise."*

여기서 *"causal vs symptom"* 이 두 층으로 갈라집니다. 그림으로 보면, 두 층은 충돌하지 않고 순차적으로 작동합니다.

flowchart TB
    USER["👤 사용자가 느끼는<br/>지연 / 오류 / 실패"]

    subgraph layer1 ["Layer 1 — 알람 설계 (SLO 기반)"]
        USER --> SLO_CHECK{"SLO 위반?"}
        SLO_CHECK -->|Yes| SYM["✅ 알람 발사<br/>(모든 알람은 symptom)"]
        SLO_CHECK -->|No| DROP["❌ 알람 발사 안 함<br/>(cause-based 알람 제거)"]
    end

    subgraph layer2 ["Layer 2 — Correlation (Topology 기반)"]
        SYM --> GROUP["SDG ancestor 묶기"]
        GROUP --> CAUSAL["🔴 causal alert<br/>(원인에 가장 가까운 노드)"]
        GROUP --> IMPACTED["🟡 impacted alerts<br/>(영향 받은 다른 노드들)"]
    end

    style SYM fill:#fff5cc,stroke:#cc9900
    style CAUSAL fill:#ffcccc,stroke:#c00,stroke-width:2px
    style IMPACTED fill:#ffe6cc,stroke:#e68a00
    style DROP fill:#e6e6e6,stroke-dasharray: 3 3
층 무엇이 causal/symptom인가
알람 설계 알람 자체를 symptom-based로 (= SLO 위반만 알람)
Correlation 묶인 incident 안에서 알람들 사이의 causal/impacted 를 가름

도입 시나리오의 50개 중 알람 자체는 모두 symptom (사용자가 느끼는 결제 지연)일 수 있고, 그 안에서 토폴로지로 보면 DB 알람이 causal 입니다. 두 층은 충돌하지 않고 보완합니다.

10. Public Cloud 기능 비교

클라우드 서비스 Correlation 방식 SDG 출처
AWS DevOps Guru ML 기반 anomaly + 관련 이벤트 묶음 X-Ray trace + CloudWatch
Azure Monitor + Application Insights Smart Detection, Application Map Application Insights 자동 의존성 매핑
GCP Cloud Operations (Stackdriver) Alerting Policy + Incident 자동 그룹화 Cloud Trace + Service Mesh 메트릭

세 클라우드 모두 자동 SDG 생성 → ML correlation → incident 묶기의 동일 구조입니다. 클라우드 외 워크로드까지 묶으려면 순수 벤더 솔루션 또는 오픈 표준(OTel) 으로 빠지게 됩니다.

11. Correlation 알고리즘의 진화 — 5단계

학술적으로 보면 4축이 진화 의 형태로 누적된 것이 잘 보입니다. 각 단계가 이전 단계를 대체 한 게 아니라, 새 축을 추가 한 것이 핵심입니다.

graph LR
    L["라벨 기반<br/>━━━━━━<br/>Alertmanager<br/>(2015~)"] 
    T["+ 시간 윈도우<br/>━━━━━━<br/>BigPanda"]
    G["+ 그래프 인접성<br/>━━━━━━<br/>MicroRCA<br/>(NOMS 2020)<br/>Personalized PageRank"]
    C["+ 인과 관계<br/>━━━━━━<br/>Microscope (PC algo)<br/>Sieve (Granger)<br/>(2017~2018)"]
    E["+ event 노드<br/>━━━━━━<br/>Groot<br/>(ASE 2021)<br/>Top-1: 78%"]

    L --> T --> G --> C --> E

    style L fill:#f0f0f0
    style T fill:#fff5cc
    style G fill:#ffe6cc
    style C fill:#ffcccc
    style E fill:#ff9999,stroke:#c00,stroke-width:3px

11.1 라벨 기반 — Alertmanager (2015~)

8.1에서 본 형태. 가장 널리 쓰이지만 그래프 인지 능력이 없음.

11.2 시간 윈도우 + 룰 — BigPanda

8.2의 형태. 라벨 외에도 source / time window / tags / filter 4가지 룰 조합.

11.3 그래프 인접성 + PageRank — MicroRCA (NOMS 2020)

Wu, Tordsson, Elmroth, Kao, *"MicroRCA: Root Cause Localization of Performance Issues in Microservices"*, NOMS 2020. (Inria HAL PDF)

  • Istio 서비스 메시 메트릭에서 service call graph 자동 추출 (애플리케이션 무수정)
  • Anomaly subgraph 추출 → Personalized PageRank 로 root cause 후보 랭킹
  • Sock-shop on Kubernetes 평가: precision 89%, MAP 97%

11.4 인과 그래프 — Microscope (PC algorithm) / Sieve (Granger Causality)

같은 시기에 두 가지 접근이 나란히 등장합니다. 둘 다 사전 토폴로지 없이 메트릭이나 syscall만으로 인과 관계를 추출하지만, 사용하는 통계 도구가 다릅니다.

  • Microscope (Lin, Chen, Zheng, ICSOC 2018): system call 파싱으로 통신/비통신 의존성 모두 추출. PC algorithm 으로 causality DAG 구축. precision 88%, recall 80% (Sock-shop).
  • Sieve (Thalheim et al., Middleware 2017, arXiv:1709.06686, Nokia GitHub): 메트릭 시계열만으로 Granger Causality 로 component 의존 그래프 자동 추출. 사전 토폴로지 불필요. 저장소 측에서 CPU 80% / storage 90% / network 50% 절감 보고. (※ arXiv 버전 제목은 *"...in Microservices", Middleware 컨퍼런스 발표본은 *"...in Distributed Systems" 로 부제가 약간 다릅니다.)

11.5 이벤트 그래프 — Groot (ASE 2021)

Wang et al. (eBay + UIUC + Peking U), *"Groot: An Event-graph-based Approach for Root Cause Analysis in Industrial Settings"*, IEEE/ACM ASE 2021. (arXiv:2108.00344, eBay TechBlog)

핵심 차별점은 노드를 서비스 가 아니라 event 로 둔다는 것입니다. "Service B가 원인"이 아니라 *"Service B의 deploy event가 원인"* 으로 더 fine-grained하게 식별됩니다. 그림으로 비교하면, 일반적인 SDG와 Groot의 event graph는 노드의 의미 자체가 다릅니다.

graph LR
    subgraph normal ["일반 SDG (서비스가 노드)"]
        SA["Service A"]
        SB["Service B"]
        SC["Service C"]
        SA --> SB --> SC
    end

    subgraph groot ["Groot Event Graph (event가 노드)"]
        E1["B의 배포<br/>이벤트<br/>(13:45)"]
        E2["B의 latency<br/>알람<br/>(13:47)"]
        E3["A의 5xx<br/>알람<br/>(13:48)"]
        E4["C의 timeout<br/>알람<br/>(13:49)"]
        E1 -->|"인과<br/>(도메인 룰)"| E2
        E2 --> E3
        E2 --> E4
    end

    style E1 fill:#ffcccc,stroke:#c00,stroke-width:2px
  • 입력: performance metrics + status logs + developer activities (배포, 설정 변경)
  • 토폴로지: eBay distributed tracing의 service dependency snapshot, 운영 환경 5,000+ services, 일 147B traces 규모
  • 결과: 952개 실제 incident 라벨 데이터셋에서 Top-1 정확도 78%, Top-3 정확도 95%

12. 2025–2026 산업 동향

세 가지 메타 트렌드가 동시에 진행 중입니다.

12.1 Gartner의 시장명 재정의 — AIOps에서 EIS로

2025년 3월 10일, Gartner는 Market Guide for Event Intelligence Solutions (doc ID G00802859, 발행일 2025-03-10, 이후 2025-05-20 revision)을 발간했습니다. 본문 한 줄 — *"EISs (formerly AIOps platforms)..."* — 이 모든 것을 요약합니다.

정확하게 표현하면 : Gartner가 AIOps Platforms 카테고리를 공식 폐기 했다고 단정하기보다, 시장명을 Event Intelligence Solutions로 rebrand 했다고 보는 편이 정확합니다. Gartner의 후속 자료들도 여전히 "AIOps" 표현을 병기하며, Peer Insights는 시장명을 EIS로 운영합니다.

같은 보고서의 5가지 mandatory feature 중 두 가지가 정확히 4주차 주제입니다.

  • Topology ingestion and/or assembly — 토폴로지 인지가 없는 도구는 더 이상 EIS로 분류되지 않음
  • Event correlation and enrichment — correlation은 이제 mandatory

그리고 한 인용이 추가로 흥미롭습니다 — *"in extreme cases this can result in a 95%+ reduction in events that require human intervention."* Gartner가 *"extreme cases"* 라는 단서를 직접 부기했다는 점이 중요합니다.

12.2 OSS 생태계의 재편

  • Keep: 2025년 5월 7일, Elastic이 Keep Alerting 인수에 합의했다고 발표했고 (Elastic 공식 발표), 같은 해 5월 21일 인수가 완료됐습니다 (Elastic IR). Y Combinator(Winter 2023) 출신, GitHub ★ 약 11.7k. 인수 이후에도 Keep 자체는 오픈소스로 유지되며 — *"Excited to announce that Keep is joining forces with Elastic"* — Elastic Observability에 통합 중입니다.
  • Robusta: K8s 알람 enrichment + HolmesGPT(AI assistant)로 RCA 보조. MIT.
  • Grafana OnCall (OSS): 2026년 3월 24일 archived. Grafana Cloud IRM으로 이관. 알람 그룹핑은 Alertmanager에서 하고 OnCall은 escalation·routing만 담당하라는 권장 패턴이 그대로 유지됩니다.

12.3 새로운 기술 축

  • eBPF 무계측 가시성의 주류화 — Pixie, Cilium Hubble.
  • LLM 기반 correlation — COLA (Kuang et al., ICSE-SEIP 2024, arXiv:2403.06485)는 SOP를 in-context로 주입해 알람 간 인과를 추론. *"on-call engineers prefer interpretable reasoning over yes/no answers"* 라는 정성적 결과가 인상적.
  • Open Standard 우세 — OTel servicegraph connector가 사실상 표준 SDG 생성기. ServiceNow조차 OTel용 Service Graph Connector for OpenTelemetry 를 제공.

토론 논의

T1. 토폴로지 정확도와 correlation 정확도는 선형 관계인가?
직관적으로는 그렇지만, Hands-on AIOps Ch.8의 학습 기반 보강 기법은 *"100% 정확한 CMDB가 없어도 충분히 좋은 correlation이 가능하다"* 는 가설을 시사합니다. 운영 환경에서 어디까지 trade-off 가능한가?

T2. LLM은 SDG를 대체할 수 있는가?
COLA는 SOP + LLM 만으로 SDG 없이도 의미 있는 correlation을 보여줍니다. 그러나 incident.io 의 production 사례(hybrid: deterministic + LLM rerank)처럼 순수 LLM 만으론 부족 하다는 결론이 우세합니다. 두 접근의 결합점은 어디인가?

참고자료

책 

  • Hands-on AIOps (Sabharwal & Bhardwaj, Apress 2022) — Ch.2, Ch.8: Springer Link
  • Observability Engineering (Majors, Fong-Jones, Miranda, O'Reilly 2022) — Ch.1, Ch.6, Ch.8, Ch.12: O'Reilly
  • Wang et al., *"Groot"*, ASE 2021: arXiv:2108.00344

논문

벤더·도구 공식 문서

Gartner

기술 블로그

'AIOps' 카테고리의 다른 글

AIOps 스터디 6주차 — coroot의 데이터 흐름과 RCA 책임 분담  (0) 2026.05.16
AIOps 스터디 5주차 - RCA 평가지표 정리  (1) 2026.05.10
AIOps 스터디 5주차 - RCA  (0) 2026.05.09
AIOps 스터디 3주차 — 전통 Anomaly Detection의 기본기와 Forecasting Foundation Model의 등장  (0) 2026.04.18
AIOps 스터디 2주차 - What is AIOps  (1) 2026.04.11
'AIOps' Related Articles more