26M5d
RAG 기반 AIOps 체계 — 이상 감지 → 상황 파악 → 대처 가이드
1. 전체 접근 철학
기존 알람 체계의 한계
Threshold 기반
"CPU > 80% 이면 알람"
↓
단순 단일 지표 감시
맥락 없는 알람 폭발 (Alert Fatigue)
사람이 직접 로그 뒤져서 연결해야 함
"왜 이런지" 설명 없음
목표 체계
이상 탐지 (Anomaly Detection)
"평소와 다른 패턴" 자동 감지
↓
맥락 연결 (Context Correlation)
메트릭 + 로그 + 변경이력 + 문서 연결
↓
가이드 생성 (RAG Guidance)
SOP/Runbook/PIR 기반 대처 방안 제시2. 전체 아키텍처
┌─────────────────────────────────────────────────────────────┐
│ DATA INGESTION LAYER │
│ Prometheus OpenSearch Kafka K8s Events ChangeLog │
└────────────────────────┬────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────┐
│ ANOMALY DETECTION LAYER │
│ ML 모델(Prophet/Isolation Forest) Rule Engine Correlator │
└────────────────────────┬────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────┐
│ RAG KNOWLEDGE LAYER │
│ Milvus ← 벤더 메뉴얼 + SOP + Runbook + PIR + 아키텍처 문서│
└────────────────────────┬────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────┐
│ REASONING & GUIDE LAYER │
│ LLM (Ollama) → 상황 요약 + 근본 원인 가설 + 대처 가이드 │
└────────────────────────┬────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────┐
│ NOTIFICATION LAYER │
│ Slack / PagerDuty → SRE Landing Page → 챗봇 인터랙션 │
└─────────────────────────────────────────────────────────────┘3. 단계별 구축 로드맵
Phase 1 (Q1~Q2): 기반 구축
① 지식 베이스 구축 (RAG)
② 메트릭/로그 파이프라인 정비
③ 이상 탐지 모델 1차 적용
Phase 2 (Q2~Q3): 연동 및 가이드
④ 이상 → RAG 연결 파이프라인
⑤ 상황 요약 + 대처 가이드 생성
⑥ Slack/Landing Page 통합
Phase 3 (Q3~Q4): 고도화 + PoC
⑦ 상관관계 분석 고도화
⑧ Auto-Healing PoC (제한적)
⑨ 피드백 루프 구축4. Phase 1: 기반 구축 상세
4-1. 지식 베이스 구축 (RAG)
문서를 단순히 넣는 것보다 구조화된 청킹이 핵심입니다.
문서 유형별 수집 전략
[벤더 메뉴얼]
MinIO AIStor, Cilium, StarRocks, CNPG 등
→ 에러코드/증상 섹션을 별도 메타데이터로 추출
→ 예: error_code: "ErasureReadQuorumError"
component: "minio"
severity: "critical"
[SOP / Runbook]
→ 섹션별 청킹 (증상, 원인, 절차, 검증)
→ sop_id, component, action_type 메타데이터 부여
[PIR]
→ 타임라인, RCA, 액션아이템 별도 청킹
→ incident_id, root_cause_category, component 메타데이터
[아키텍처 문서]
→ 컴포넌트 간 의존성 관계 별도 인덱싱
→ "A → B 의존" 관계를 그래프로도 저장 (선택)# 문서 청킹 시 메타데이터 구조 예시
Document(
page_content="MinIO ErasureReadQuorumError 발생 시...",
metadata={
"doc_type": "runbook",
"sop_id": "RB-MINIO-001",
"component": "minio-aistor",
"symptoms": ["read_failure", "quorum_error"],
"error_codes": ["ErasureReadQuorumError"],
"severity": "sev1",
"section": "diagnosis",
"version": "v1.3",
}
)4-2. 메트릭/로그 파이프라인 정비
이상 탐지를 하려면 정제된 데이터 스트림이 먼저입니다.
메트릭 (Prometheus → 이상 탐지용 가공)
수집 대상 우선순위:
① 가용성 지표: up, kube_pod_status_ready
② 포화도 지표: CPU/Memory 사용률, 큐 깊이
③ 오류율 지표: HTTP 5xx, DB 연결 실패
④ 레이턴시: P50/P95/P99
⑤ 비즈니스 지표: Spark Job 성공률, 쿼리 처리량
중요: 단순 수집이 아닌 계절성 분리 필요
→ 업무 시간대 / 야간 배치 시간대 / 주말을 구분
→ 같은 CPU 80%도 맥락이 다름
로그 (OpenSearch → 구조화)
수집 대상:
① K8s 이벤트 (Warning 이상)
② 애플리케이션 에러 로그
③ Cilium Drop 로그 (Hubble)
④ 변경 이력 (ArgoCD sync 이벤트)
⑤ 감사 로그 (Keycloak, MinIO)
중요: 에러 패턴 정규화
→ 같은 에러도 다양한 형태로 출력됨
→ 정규식으로 에러 코드 추출 + 구조화
→ OpenSearch ingest pipeline으로 처리5. Phase 2: 이상 탐지 → RAG 연결
5-1. 이상 탐지 모델 선택
단일 모델이 아닌 레이어 구조로 접근합니다.
Layer 1: 기존 Threshold Alert (유지)
→ 명확한 장애는 여전히 빠름
→ 기준: CPU > 90%, Pod CrashLoop 등
Layer 2: 통계적 이상 탐지 (NEW)
→ 단기 이상: Z-score, IQR
"지금 수치가 최근 1시간 패턴에서 3σ 벗어남"
→ 장기 패턴: Prophet (Facebook)
"매주 화요일 오전 이 시간에 이 수준이 정상인데 지금 다름"
Layer 3: 다변량 이상 탐지 (NEW)
→ Isolation Forest / Autoencoder
"여러 지표를 동시에 보면 이상하지만
개별로는 Threshold 미달인 경우"
→ 예: CPU 60% + Memory 75% + I/O 급증
→ 개별 알람은 없지만 조합이 비정상
Layer 4: 로그 이상 탐지 (NEW)
→ 로그 빈도 이상: 평소 분당 10개 → 갑자기 1000개
→ 신규 에러 패턴: 처음 보는 에러 코드 등장
→ LogCluster / Drain 알고리즘으로 패턴 분류5-2. 상관관계 분석 (Correlation)
가장 중요한 부분입니다. 개별 이상이 아닌 연관성을 찾아야 합니다.
상관관계 분석 예시
시나리오:
14:23 MinIO 읽기 레이턴시 급증 (Layer 2 감지)
14:24 Spark Job 실패율 증가 (Layer 1 감지)
14:24 StarRocks External Table 쿼리 실패 (Layer 1 감지)
14:25 K8s 이벤트: minio Pod Evicted
단순 알람 체계 → 알람 3개 각각 발송
상관관계 분석 → "MinIO 문제가 Spark, StarRocks에 전파"
단일 근본 원인 그룹으로 묶기
방법:
① 시간 기반 클러스터링: 5분 이내 동시 발생 이상 그룹핑
② 의존성 그래프 기반: 아키텍처 문서에서 추출한
컴포넌트 의존 관계로 전파 경로 추론
③ 변경 이력 연계: 이상 발생 직전 1시간 이내
ArgoCD 배포 / 설정 변경 이력 자동 조회5-3. RAG 쿼리 생성 파이프라인
# 이상 탐지 → RAG 쿼리 자동 생성 흐름
def anomaly_to_rag_query(anomaly_event):
"""
이상 탐지 이벤트를 RAG 검색 쿼리로 변환
"""
# 이상 이벤트 구조화
context = {
"component": anomaly_event["component"], # "minio-aistor"
"anomaly_type": anomaly_event["type"], # "latency_spike"
"metrics": {
"read_latency_p99": "450ms", # 현재값
"baseline": "87ms", # 정상값
"deviation": "5.2σ", # 편차
},
"correlated_events": [
"spark_job_failure_rate_increase",
"starrocks_query_timeout",
],
"recent_changes": [
"cilium-bgp-config-updated 45min ago"
],
"error_logs": [
"storage: read timeout after 30s",
"ErasureRead: drive /dev/sdb offline",
]
}
# 구조화된 RAG 검색
queries = [
# 증상 기반 검색
f"MinIO read latency spike ErasureRead drive offline",
# 에러코드 기반 검색
f"ErasureReadQuorumError resolution",
# 연관 증상 검색
f"MinIO 장애로 인한 Spark StarRocks 연쇄 장애 대응",
]
# 메타데이터 필터 (정밀도 향상)
filters = {
"component": ["minio-aistor", "minio"],
"doc_type": ["runbook", "pir", "sop"],
}
return queries, filters, context5-4. LLM 가이드 생성
# 최종 가이드 생성 프롬프트 구조
GUIDE_PROMPT = """
당신은 Cloud Native Data Lakehouse 플랫폼의 SRE 전문가입니다.
아래 정보를 바탕으로 현재 상황을 분석하고 대처 방안을 제시하세요.
## 현재 이상 감지 내용
컴포넌트: {component}
이상 유형: {anomaly_type}
감지 시각: {detected_at}
현재 수치: {current_metrics}
정상 기준: {baseline_metrics}
편차: {deviation}
## 연관 이상 징후 (동시 발생)
{correlated_anomalies}
## 최근 변경 이력 (1시간 이내)
{recent_changes}
## 관련 에러 로그
{error_logs}
## 참고 문서 (RAG 검색 결과)
{retrieved_docs}
---
다음 형식으로 답변하세요:
### 🔍 상황 요약 (2~3줄)
비기술직도 이해할 수 있는 현재 상황 설명
### 🎯 가장 유력한 근본 원인 (1~3개, 확률 포함)
1. [확률 높음] 원인 설명
2. [확률 중간] 원인 설명
### ⚡ 즉시 확인할 것 (5분 이내)
- 명령어 포함한 구체적 확인 절차
### 🛠 권장 대응 절차
단계별 복구 절차 (해당 Runbook 참조 포함)
### ⚠️ 주의사항
이 상황에서 하면 안 되는 것
### 📋 참조 문서
- {sop_references}
"""6. Phase 3: 알림 통합
6-1. Slack 알림 구조
기존 알람:
[FIRING] CPU > 80% on node-123
새로운 알람:
┌─────────────────────────────────────┐
│ 🔴 이상 감지: MinIO AIStor │
│ 심각도: SEV1 가능성 │
│ 감지: 14:23 KST (임계치 도달 전 감지) │
├─────────────────────────────────────┤
│ 📊 이상 지표 │
│ • 읽기 레이턴시 P99: 450ms (정상 87ms, 5.2σ) │
│ • 연관 영향: Spark Job 실패 +340% │
│ StarRocks 쿼리 타임아웃 │
├─────────────────────────────────────┤
│ 🔗 연관 가능성 │
│ • 45분 전: Cilium BGP 설정 변경 │
│ • 에러 로그: drive /dev/sdb offline │
├─────────────────────────────────────┤
│ 🤖 AI 초기 분석 │
│ MinIO Erasure Drive 오프라인으로 │
│ Read Quorum 불안정 가능성. │
│ Spark/StarRocks는 2차 영향. │
├─────────────────────────────────────┤
│ [📖 Runbook 보기] [💬 상세 분석] │
│ [✅ 인지] [🚨 Incident 선언] │
└─────────────────────────────────────┘6-2. 챗봇 인터랙션 (추가 분석 요청)
SRE: "이 MinIO 이상, 더 자세히 분석해줘"
챗봇: 지난 24시간 메트릭 패턴을 보면...
드라이브 /dev/sdb의 I/O 에러가
어제 밤부터 간헐적으로 있었고,
오늘 오후부터 본격화되었습니다.
PIR-2025-003과 유사한 패턴입니다.
당시 동일 원인은 Cilium NetworkPolicy
충돌이었으나, 이번엔 드라이브 물리 오류
가능성이 더 높습니다.
RB-MINIO-001의 섹션 A-3을 참조하세요.
SRE: "지금 배치 Job 멈춰도 돼?"
챗봇: 현재 실행 중인 Spark Job 42개 중
MinIO 의존 Job: 38개 (이미 실패 중)
MinIO 비의존 Job: 4개 (정상 실행 중)
배치 일시 중단 시 야간 SLA 영향:
- 익일 오전 8시 리포트 지연 가능
- 실시간 Kafka 스트림은 영향 없음
→ 중단 권고합니다.7. 기술 스택 선택
컴포넌트 선택 이유
─────────────────────────────────────────────────────
이상 탐지 (통계) Prophet 계절성 처리 강점
Isolation Forest 다변량 이상 탐지
이상 탐지 (로그) Drain/LogPai 로그 패턴 클러스터링
상관관계 분석 자체 구현 의존성 그래프 기반
벡터 DB Milvus 이미 도입 예정
임베딩 all-MiniLM-L6 경량, 로컬 실행
LLM Ollama/llama3 Airgap, 로컬
파이프라인 오케스트레이션 Argo Workflows 이미 도입
알림 Slack + PagerDuty 기존 체계 활용
메트릭 수집 Prometheus + Thanos 기존 체계
로그 수집 Fluent Bit → OpenSearch 기존 체계
이벤트 버스 Kafka 실시간 이상 이벤트 전달8. 구현 시 핵심 주의사항
① 거짓 양성(False Positive) 관리
초기에는 이상 탐지 감도를 낮게 시작
→ 알람 폭발로 인한 Alert Fatigue 방지
→ 2~4주 운영 후 감도 점진적 조정
→ SRE 피드백("이건 정상이야") 수집 체계 필수
② LLM 환각(Hallucination) 방지
RAG 문서에 없는 내용은 "문서에서 찾을 수 없음"
→ 확률 표현 사용 ("가능성 높음" "확인 필요")
→ 명령어는 반드시 RAG 문서 기반만 제시
→ 사람 최종 확인 원칙 (Auto-Healing 미적용)
③ 컨텍스트 윈도우 관리
메트릭 + 로그 + 문서를 동시에 넣으면 토큰 폭발
→ 관련성 높은 것만 선택적으로 주입
→ 요약 후 주입 (로그 1000줄 → 핵심 패턴 5개)
④ 피드백 루프 구축 (가장 중요)
SRE가 "이 가이드가 맞았나/틀렸나" 기록
→ 맞은 케이스: RAG 지식 베이스 강화
→ 틀린 케이스: 프롬프트/모델 개선
→ PIR 작성 후 해당 내용 자동으로 RAG에 추가9. 올해 목표 달성 기준
Q1~Q2 완료 기준
✅ RAG 지식 베이스 구축 완료
(벤더 문서 5종 + SOP 전체 + PIR 전체)
✅ 기본 이상 탐지 파이프라인 가동
(통계적 이상 탐지 Layer 2)
✅ Slack 통합 알림 (기존 알람 + AI 분석 포함)
Q3 완료 기준
✅ 다변량 이상 탐지 (Layer 3) 가동
✅ 상관관계 분석 → 단일 근본 원인 그룹핑
✅ 챗봇 인터랙션 (추가 분석 요청 가능)
✅ False Positive율 < 20%
Q4 완료 기준
✅ 피드백 루프 정착
✅ Auto-Healing PoC 1~2개 시나리오
(예: MinIO Pod 재시작, K8s 노드 Drain)
✅ 임계치 미달 이상 감지율 측정 및 보고
측정 지표
Before: TTD 평균 8분, Alert Fatigue 다수
After 목표:
TTD 평균 3분 이하 (임계치 미달 조기 감지 포함)
Alert 정확도 80% 이상 (False Positive < 20%)
상황 파악 시간 50% 단축 (Runbook 찾는 시간 제거)요약
핵심 접근 순서
1. 데이터 정제 먼저
→ 좋은 이상 탐지는 깨끗한 데이터에서 나옴
2. 지식 베이스 구조화
→ 단순 문서 저장이 아닌
컴포넌트/증상/에러코드 메타데이터 체계
3. 이상 탐지는 레이어 구조로
→ Threshold → 통계 → 다변량 순으로 점진적 추가
4. 상관관계 분석이 핵심 차별점
→ 개별 알람이 아닌 "하나의 이야기"로 묶기
5. LLM은 마지막 계층
→ 수집/탐지/상관관계가 잘 되어야
LLM이 의미 있는 가이드를 줄 수 있음
6. 피드백 루프가 시스템을 살아있게 함
→ PIR → RAG → 더 나은 가이드 → 더 나은 PIR
engineer