AIOps Deep Dive

관측성에서 자동 복구까지

Junseok Oh | Sr. Solutions Architect, AWS

세션 아젠다

1
관측성 파이프라인 30min
2
AI 기반 이상 탐지와 RCA 30min
3
자동 복구와 AIOps 로드맵 30min

관측성 vs 모니터링

모니터링 (Monitoring)

  • Known-unknowns — 미리 정의한 메트릭/임계값 감시
  • CPU > 80%, 응답시간 > 3초 같은 정적 규칙
  • "무엇이 고장났는가?" 에 답함

관측성 (Observability)

  • Unknown-unknowns — 예측 못한 장애도 탐지
  • 시스템 내부 상태를 외부 출력으로 추론
  • " 고장났는가?" 에 답함

관측성 데이터 3대 축

📊
Metrics
수치형 시계열 데이터
CPU, Memory, 응답시간
CloudWatch Metrics
Amazon Managed Prometheus
📝
Logs
이벤트 기록 (텍스트)
에러 스택트레이스, 감사 로그
CloudWatch Logs
OpenSearch Service
🔗
Traces
요청 흐름 추적
서비스 간 호출 체인
AWS X-Ray
CloudWatch ServiceLens
Metrics이 "무엇이" 문제인지 알려주고, Logs가 "왜" 발생했는지 설명하고, Traces가 "어디서" 발생했는지 보여줍니다.

OpenTelemetry 기반 수집 아키텍처

ADOT (AWS Distro for OpenTelemetry)
벤더 중립: OTel 표준 기반 — 백엔드 교체 시 코드 변경 불필요
통합 에이전트: Metrics + Logs + Traces를 하나의 Collector로 수집
자동 계측: Java/Python/Node.js SDK로 코드 변경 최소화
EKS 네이티브: DaemonSet 또는 Sidecar 배포
AWS 최적화: X-Ray, CloudWatch, AMP 익스포터 내장
수집 아키텍처 패턴
📦
DaemonSet (권장)
노드당 1개 Collector → 리소스 효율적
🔄
Sidecar
Pod별 격리 필요 시 → 보안 민감 워크로드
🌐
Gateway
중앙 집중 처리 → 필터링/샘플링 로직 통합

ADOT Collector 파이프라인 설정

receivers: otlp: protocols: grpc: endpoint: 0.0.0.0:4317 http: endpoint: 0.0.0.0:4318 prometheus: config: scrape_configs: - job_name: 'kubernetes-pods' kubernetes_sd_configs: - role: pod
processors: batch: timeout: 10s send_batch_size: 1024 memory_limiter: check_interval: 5s limit_mib: 512 spike_limit_mib: 128 filter/severity: logs: include: severity_number: min: 9 # INFO 이상만 수집
exporters: awsxray: region: ap-northeast-2 awsemf: region: ap-northeast-2 namespace: AnyCompany/AIOps prometheusremotewrite: endpoint: https://aps-workspaces.ap-northeast-2 .amazonaws.com/workspaces/ws-xxx/api/v1/remote_write auth: authenticator: sigv4auth

CloudWatch Logs Insights 실전 쿼리

# Top 10 에러 패턴 (서비스별 그룹핑) fields @timestamp, @message, service_name | filter @message like /(?i)(error|exception|fatal)/ | stats count(*) as error_count by service_name, substr(@message, 0, 100) as error_pattern | sort error_count desc | limit 10

💡 : substr(@message, 0, 100)으로 에러 메시지를 자르면 유사 에러가 자동 그룹됩니다. parse 명령으로 정규식 추출도 가능합니다.

# P99 레이턴시 by API endpoint filter ispresent(duration_ms) | stats avg(duration_ms) as avg_ms, pct(duration_ms, 95) as p95, pct(duration_ms, 99) as p99, count(*) as req_count by endpoint | filter req_count > 100 | sort p99 desc

💡 : req_count > 100 필터로 노이즈를 제거합니다. 트래픽이 적은 엔드포인트의 P99는 의미 없는 경우가 많습니다.

# 로그 그룹별 일일 수집량 (비용 추정) stats sum(strlen(@message)) as total_bytes by @logStream | sort total_bytes desc | limit 20

💡 : strlen(@message) × $0.50/GB 로 일일 비용을 추정합니다. DEBUG 로그가 전체의 60-80%를 차지하는 경우가 흔합니다.

로그 비용 최적화 계산기

파라미터 조정
일일 로그 볼륨
200 GB
DEBUG 로그 비율
65%
Trace 샘플링 비율
100%
보관 기간
90일
비용 비교
현재 월 비용
$5,040
최적화 후
$2,739
절감: 45.7%
• 로그 레벨 최적화: —
• Trace 샘플링: —
• 월간 절감액: —
• 연간 절감: —

통합 관측성 대시보드 아키텍처

Amazon Managed Grafana (AMG)
Multi-source: CloudWatch + AMP + X-Ray + OpenSearch를 단일 대시보드에 통합
SSO 연동: IAM Identity Center로 팀별 접근 제어
알림 통합: SNS, Slack, PagerDuty 연동
관리형: Grafana 서버 운영 불필요, 자동 스케일링
플러그인: 150+ 데이터 소스 플러그인 지원
권장 대시보드 구성
L1 — Overview
SLO 상태 + 핵심 KPI
Golden Signals
L2 — Service
서비스별 상세 메트릭
에러율 + 레이턴시
L3 — Debug
트레이스 + 로그 상관
Pod/Node 레벨
L4 — Business
비즈니스 KPI
매출 영향도 + 사용자 경험

Block 1 핵심 정리

🔑 Key Takeaways
관측성 ≠ 모니터링 — "왜?"에 답하는 능력
3대 축 통합 — Metrics + Logs + Traces 상관분석
ADOT — 벤더 중립 통합 수집 에이전트
비용 최적화 — 로그 레벨 + 샘플링으로 40-60% 절감 가능
대시보드 계층화 — L1~L4 4단계 구성
💡 실무 적용 포인트
→ OTel 자동 계측부터 시작 (코드 변경 최소)
→ DEBUG 로그 비율 확인 → filter/severity 적용
→ tail_sampling으로 에러 100% + 정상 10% 수집
→ AMG L1 대시보드 먼저 구축 → 점진적 확장
→ CloudWatch Logs Insights 쿼리 라이브러리 구축

AI 기반 이상 탐지와 근본 원인 분석

이상 탐지 · 상관분석 · GenAI RCA

정적 임계값의 한계

정적 알림의 문제

  • False Positive 폭주 — 트래픽 패턴에 따라 정상 범위가 달라짐
  • 느린 변화 탐지 불가 — Memory Leak 같은 점진적 이상 놓침
  • 알림 피로 — 의미 없는 알림 반복 → 중요 알림도 무시

ML 기반 이상 탐지

  • 동적 밴드 — 시계열 패턴을 학습하여 적응형 임계값
  • 계절성 반영 — 주간/월간 트래픽 패턴을 자동 학습
  • 상관분석 — 여러 메트릭 간 연관 관계 감지

CloudWatch Anomaly Detection 개요

동작 원리
Random Cut Forest (RCF) 알고리즘 기반
• 최대 2주 학습 기간 후 이상 탐지 시작
계절성 자동 감지: 시간별, 요일별, 월별 패턴
밴드 폭 조절: 표준편차 배수(1x-5x)로 민감도 설정
알림 조건: ANOMALY_DETECTION_BAND 함수 사용
ANOMALY_DETECTION_BAND(
  m1, // target metric
  2 // band width (σ multiplier)
)
지원 메트릭
EC2/ECS/EKS
CPUUtilization, NetworkIn/Out, MemoryUtilization
ALB/NLB
RequestCount, TargetResponseTime, 5XXCount
RDS/DynamoDB
ReadLatency, WriteLatency, ThrottledRequests
Lambda
Duration, Errors, ConcurrentExecutions

Anomaly Detection 밴드 시뮬레이터

밴드 폭 (표준편차 배수)
2x
🔴 이상치 주입
🟢 감지된 이상: 0건
⚠️ False Positive: 0건
🔴 False Negative: 0건
밴드 폭을 조절해 보세요

Amazon DevOps Guru — 서비스 레벨 이상 탐지

핵심 기능
Proactive Insights: 장애 발생 전 예측 알림
Reactive Insights: 현재 이상 탐지 + 관련 리소스 그룹핑
자동 상관분석: 관련 메트릭/로그/이벤트를 하나의 Insight로 묶음
권장 조치: ML 기반 해결 방안 제안
통합 범위: CloudFormation Stack / Tag 기반 범위 설정
Insight 구조 예시
🔴 Reactive Insight #247
─────────────────────
Anomalies:
  • ALB 5XX ↑320% (p99: 4.2s → 18.7s)
  • ECS TaskCount ↓ (desired: 10, running: 4)
  • RDS ReadLatency ↑ (2ms → 89ms)
Related Events:
  • ECS Deployment 14:32 UTC
  • RDS Storage Full 14:28 UTC
Recommendation:
  → RDS storage 확장 + ECS rollback 검토

근본 원인 분석 보고서

DevOps Guru Insight
이상 탐지 + 상관분석
Amazon Bedrock
Claude + RAG 분석
RCA Report
근본 원인 + 복구 계획
Input: Anomaly 메트릭, 관련 로그, 배포 이력, 변경 이벤트
RAG: 과거 인시던트 DB, 런북, 아키텍처 문서, 변경 로그
Output: 근본 원인 분석, 영향 범위, 복구 단계, 재발 방지책
당신은 AWS 운영 전문가입니다. 다음 인시던트를 분석해 주세요. - 발생 시각: {timestamp} - 영향 서비스: {affected_services} - DevOps Guru Insight: {insight_summary} - 이상 메트릭: {anomaly_metrics} - 최근 변경 사항: {recent_changes} - 관련 로그 (최근 30분): {relevant_logs} 1. 근본 원인 (Root Cause) — 가장 가능성 높은 원인 3가지 2. 인과 관계 체인 — 어떤 순서로 장애가 전파되었는지 3. 영향 범위 — 어떤 서비스/사용자에 영향을 미치는지 4. 즉시 복구 단계 — 우선순위 순서로 5. 재발 방지 — 장기적 개선 방안

RDS Aurora 스토리지 Full (99.7%) → 쓰기 작업 실패

→ ECS 헬스체크 실패 → Task 재시작 반복

→ ALB 5XX 급증

14:28 RDS storage 99.7% → WriteIOPS 0으로 감소

14:30 App write 실패 → error log 급증

14:31 ECS healthcheck timeout → Task restart

14:32 Running task 10→4 → ALB 503 응답

  1. [긴급] RDS 스토리지 확장: 100GB → 200GB
  2. [긴급] ECS desired count 임시 증가: 10 → 15
  3. [확인] 데이터 정합성 확인 쿼리 실행
  4. [모니터] 30분간 메트릭 안정화 관찰

DevOps Guru + Bedrock 통합 구현

# DevOps Guru → EventBridge → Lambda → Bedrock Resources: DevOpsGuruRule: Type: AWS::Events::Rule Properties: EventPattern: source: - aws.devops-guru detail-type: - DevOps Guru New Insight Open Targets: - Arn: !GetAtt RCAFunction.Arn Id: trigger-rca
import boto3, json bedrock = boto3.client('bedrock-runtime') cw_logs = boto3.client('logs') def handler(event, context): insight = event['detail']['insightDescription'] anomalies = event['detail'].get('anomalies', []) # 관련 로그 수집 logs = collect_recent_logs(anomalies) # Bedrock Claude로 RCA 실행 response = bedrock.invoke_model( modelId='anthropic.claude-sonnet-4-6', body=json.dumps({ 'messages': [{ 'role': 'user', 'content': build_rca_prompt( insight, anomalies, logs) }], 'max_tokens': 2000 }) ) return parse_rca_response(response)
# RCA 결과 → Slack + OpsCenter def send_results(rca_report): # Slack 알림 slack.post_message( channel='#incident', blocks=format_rca_blocks(rca_report) ) # SSM OpsCenter OpsItem 생성 ssm.create_ops_item( Title=f"RCA: {rca_report['root_cause']}", Description=rca_report['full_report'], Severity='2', Source='DevOpsGuru-Bedrock-RCA' ) # 자동 복구 트리거 (Block 3에서 상세) if rca_report['confidence'] > 0.85: trigger_auto_remediation( rca_report['remediation_steps'])

Block 2 핵심 정리

🔑 Key Takeaways
정적 임계값 탈피 — ML 기반 동적 밴드로 전환
CloudWatch AD — RCF 알고리즘, 밴드 폭 2-3x 권장
DevOps Guru — 서비스 레벨 자동 상관분석
GenAI RCA — Bedrock + RAG로 근본 원인 30초 분석
자동화 파이프라인 — EventBridge → Lambda → Bedrock
💡 실무 적용 포인트
→ 핵심 메트릭 10개부터 Anomaly Detection 적용
→ 밴드 폭은 서비스 특성에 맞게 (결제: 좁게, 로그: 넓게)
→ DevOps Guru는 CloudFormation Stack 단위로 활성화
→ RCA 프롬프트에 과거 인시던트 DB를 RAG로 연결
→ confidence 85% 이상일 때만 자동 복구 트리거

자동 복구와 AIOps 로드맵

자동 복구 · Chaos Engineering · 성숙도 모델

SSM Automation 기반 자동 복구

CloudWatch
Alarm 발동
EventBridge
규칙 매칭
SSM Automation
Runbook 실행
검증 + 알림
Slack 보고
Safety Guards
• 영향 범위 제한 (blast radius)
• 롤백 조건 사전 정의
• 승인 게이트 (선택)
Runbook 유형
• ECS/EKS 스케일링
• RDS 스토리지 확장
• 배포 롤백
검증 패턴
• 메트릭 안정화 확인
• 헬스체크 통과
• 에러율 정상 복귀
# SSM Automation Runbook: ECS Auto-Scale schemaVersion: '0.3' description: 'ECS Task 자동 스케일링 복구' assumeRole: '{{AutomationAssumeRole}}' parameters: ClusterName: type: String ServiceName: type: String DesiredCount: type: Integer default: 10 mainSteps: - name: checkCurrentState action: aws:executeAwsApi inputs: Service: ecs Api: DescribeServices cluster: '{{ClusterName}}' services: ['{{ServiceName}}'] - name: scaleUp action: aws:executeAwsApi inputs: Service: ecs Api: UpdateService cluster: '{{ClusterName}}' service: '{{ServiceName}}' desiredCount: '{{DesiredCount}}' - name: waitForStable action: aws:waitForAwsResourceProperty inputs: Service: ecs Api: DescribeServices cluster: '{{ClusterName}}' services: ['{{ServiceName}}'] PropertySelector: '$.services[0].runningCount' DesiredValues: ['{{DesiredCount}}'] timeoutSeconds: 300 - name: validateMetrics action: aws:executeScript inputs: Runtime: python3.11 Script: | import boto3 cw = boto3.client('cloudwatch') # 5XX 에러율이 1% 미만인지 확인 # 확인 실패 시 롤백 트리거
# Safety Guard 구현 패턴 class RemediationGuard: def __init__(self, config): self.max_blast_radius = config['max_affected_pct'] self.require_approval = config['require_approval'] self.rollback_conditions = config['rollback_on'] def can_execute(self, action, context): # 1. 영향 범위 확인 affected = self.estimate_blast_radius(action) if affected > self.max_blast_radius: return False, f"Blast radius {affected}% > {self.max_blast_radius}%" # 2. 동시 실행 제한 if self.has_active_remediation(context): return False, "Another remediation in progress" # 3. 승인 필요 여부 if self.require_approval: return 'pending_approval', "Waiting for operator approval" return True, "Safe to execute" def should_rollback(self, metrics_after): for condition in self.rollback_conditions: if self.evaluate(condition, metrics_after): return True, condition['description'] return False, None

Chaos Engineering으로 복구 파이프라인 검증

AWS Fault Injection Service (FIS)
관리형 카오스: AWS 네이티브 장애 주입 서비스
정밀 타겟팅: 특정 AZ, 서비스, 리소스 지정
자동 롤백: Stop Condition 충족 시 즉시 중단
실험 템플릿: 재사용 가능한 장애 시나리오
통합 관측: CloudWatch 메트릭으로 영향 추적
검증 시나리오
1. Pod 장애
EKS Pod 50% Kill → Auto-scaling 복구 확인
2. AZ 장애
단일 AZ 차단 → Multi-AZ 페일오버 확인
3. 네트워크 지연
100ms 추가 지연 → Circuit Breaker 동작 확인
4. CPU 스트레스
CPU 90% 부하 → Anomaly Detection + Auto-scale 확인

MTTR 개선 계산기

장애 대응 단계별 시간 (분)
🔍 탐지 (Detection) 15분 → 3분
Before
After (AIOps)
🔬 분석 (RCA) 30분 → 5분
Before
After (AIOps)
🔧 복구 (Remediation) 45분 → 8분
Before
After (AIOps)
✅ 검증 (Verification) 15분 → 5분
Before
After (AIOps)
MTTR 비교
Before MTTR
105분
1시간 45분
After MTTR
21분
21분
개선율: 80% 단축

AIOps 성숙도 모델

Level 1
Reactive
• 수동 모니터링
• 정적 임계값 알림
• 수동 장애 대응
• MTTR: 2-4시간
Level 2
Proactive
• 통합 관측성
• ML 이상 탐지
• 반자동 복구 (승인 필요)
• MTTR: 30-60분
Level 3
Predictive
• GenAI RCA 자동화
• 예측 기반 선제 조치
• 자동 복구 (safety guard)
• MTTR: 10-20분
Level 4
Self-Healing
• 자가 치유 시스템
• 지속적 학습/개선
• Chaos 자동 검증
• MTTR: <5분
대부분의 조직 선도 조직 AWS 권장 목표 미래 비전

AIOps 도입 로드맵

Month 1-2
기반 구축
✅ ADOT DaemonSet 배포 + OTel 자동 계측 적용
✅ CloudWatch Logs 비용 최적화 (DEBUG 필터 + 샘플링)
✅ AMG L1 Overview 대시보드 구축
Month 3-4
AI 탐지
✅ CloudWatch Anomaly Detection 핵심 메트릭 10개 적용
✅ DevOps Guru 활성화 (CloudFormation Stack 단위)
✅ 알림 채널 통합 (Slack + PagerDuty)
Month 5-6
자동화
✅ GenAI RCA 파이프라인 구축 (EventBridge → Lambda → Bedrock)
✅ SSM Automation Runbook 작성 (ECS 스케일링, RDS 확장)
✅ FIS Chaos 실험으로 복구 파이프라인 검증
Month 7+
고도화
✅ RAG 인시던트 DB 구축 → RCA 정확도 향상
✅ 자동 복구 범위 확대 + Safety Guard 고도화
✅ 정기 Chaos Day 운영 → 복원력 지속 검증

전체 세션 정리

Block 1: 관측성
• 모니터링 → 관측성 전환
• Metrics + Logs + Traces 통합
• ADOT 기반 수집 파이프라인
• 비용 최적화 40-60% 절감
• AMG 4단계 대시보드
Block 2: AI 탐지 + RCA
• ML 기반 동적 이상 탐지
• DevOps Guru 자동 상관분석
• GenAI RCA 30초 분석
• EventBridge 자동화 파이프라인
• RAG 기반 정확도 향상
Block 3: 자동 복구
• SSM Automation Runbook
• Safety Guard 안전장치
• FIS Chaos 검증
• MTTR 80% 단축
• 6개월 도입 로드맵
관측성AI 탐지자동 복구 = AIOps 완성

Thank You

Junseok Oh | Sr. Solutions Architect, AWS

수고하셨습니다!

← 목차로 돌아가기