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 쿼리 라이브러리 구축