AIOps on AWS

Intelligent Cloud Operations for AnyCompany

Junseok Oh

Sr. Solutions Architect

AWS

오늘의 아젠다

총 90min 세션

AIOps Foundations & AWS Observability 30분

ML-Powered Operations & Anomaly Detection 30분

☕

Break 5분

Implementation Strategies & Best Practices 25분

300 레벨 — 개념보다 실전 중심 | 실시간 Q&A 환영 | 각 블록 후 브레이크

AIOps란 무엇인가?

정의

AI for IT Operations — ML과 빅데이터 분석을 활용하여 IT 운영을 자동화하고 향상시키는 접근법

핵심 요소

Observe — 전체 스택 가시성 확보
Detect — 이상 징후 자동 탐지
Diagnose — 근본 원인 분석 (RCA)
Respond — 자동화된 대응 및 복구

Gartner 정의 (2024)

"AIOps platforms combine big data and ML to automate IT operations processes, including event correlation, anomaly detection, and causality determination."

왜 지금 AIOps인가?

마이크로서비스 → 복잡성 기하급수적 증가
분당 수백만 이벤트 → 사람이 처리 불가
MTTR 단축 압박 → 수동 분석의 한계
Gen AI 발전 → 자연어 기반 운영 가능

Observability vs Monitoring

Known-unknowns — 미리 정의한 임계값 기반 알람
대시보드 중심, 사후 분석
"CPU > 80% 이면 알람" → 증상만 탐지

Unknown-unknowns — 예상치 못한 문제를 발견하는 능력
세 가지 신호(Three Pillars): Metrics, Logs, Traces
"왜 이 API가 느려졌는지" 역추적 가능

ML 기반 이상 탐지 — 시즌별/시간대별 패턴 학습 후 편차 감지
이벤트 상관 분석 — 수천 개 알람을 소수의 인시던트로 그룹핑
예측 — 리소스 고갈, 장애 전조 사전 경고

AWS Observability Stack — 전체 구성도

CloudWatch — AIOps의 데이터 허브

Metrics

고해상도 메트릭 — 1초 간격 수집 가능
Embedded Metric Format (EMF) — 구조화된 로그에서 메트릭 자동 추출
Metric Math — 실시간 연산 (에러율 = Errors / Invocations × 100)
Contributor Insights — Top-N 기여자 실시간 분석

Logs Insights

fields @timestamp, @message
| filter @message like /ERROR/
| stats count(*) as errorCount by bin(5m)
| sort errorCount desc

Anomaly Detection

2주간 메트릭 패턴 학습 (시간대, 요일, 계절)
Band 모델 — 정상 범위를 밴드로 표현
밴드 이탈 시 알람 → 정적 임계값 없이 동적 탐지
ANOMALY_DETECTION_BAND(metric, stddev) 함수

Cross-Account Observability

Monitoring Account 하나에서 모든 계정 관측
Organization 전체 로그/메트릭/트레이스 통합
AnyCompany 멀티 계정 환경에 필수

ADOT — 통합 텔레메트리 수집

AWS Distro for OpenTelemetry

벤더 중립 — CNCF 표준 기반
하나의 에이전트로 Metrics + Traces + Logs 수집
EKS DaemonSet 또는 Sidecar 배포
Kubernetes 메타데이터 자동 태깅 (pod, namespace, node)

수집 파이프라인

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
  prometheus:
    config:
      scrape_configs:
        - job_name: 'k8s-pods'
          kubernetes_sd_configs:
            - role: pod

Exporters 구성

exporters:
  awsxray:
    region: ap-northeast-2
  awsemf:
    namespace: AnyCompany/App
    region: ap-northeast-2
  prometheusremotewrite:
    endpoint: https://aps-workspaces...
    auth:
      authenticator: sigv4auth

service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [awsxray]
    metrics:
      receivers: [otlp, prometheus]
      exporters: [awsemf, prometheusremotewrite]

핵심 이점

X-Ray + CloudWatch + AMP에 동시 전송
애플리케이션 코드 변경 최소화

AMP & AMG — 시각화와 분석

AMP 핵심 기능

완전 관리형 — PromQL 호환, 스케일링/패치 자동
150일 보존 — 장기 트렌드 분석 가능
Cross-region replication — DR 지원
IAM 인증 — Prometheus 네이티브 인증 대비 보안 강화

비용 고려

항목	가격
샘플 수집	$0.003/1K samples
쿼리 처리	$0.10/10억 samples
스토리지	$0.03/GB/month

팁: cardinality 관리가 비용의 핵심. label 조합이 100만 개 넘으면 비용 급증

AMG로 AIOps 대시보드 구축

다중 데이터소스: CloudWatch, AMP, X-Ray, Athena
Alerting: Grafana Alerting → SNS → PagerDuty/Slack
ML Plugin: Prophet 기반 메트릭 예측 시각화

권장 대시보드 구성

Overview — 서비스 헬스맵, 핵심 SLI/SLO
Deep Dive — 서비스별 상세 메트릭 (p99, error rate)
AIOps — Anomaly Detection 밴드, DevOps Guru 인사이트
Cost — 리소스 사용량 vs 비용 트렌드

이상 탐지 PromQL 예시

# SLO burn rate (1시간 윈도우)
(
  sum(rate(http_requests_total{code=~"5.."}[1h]))
  / sum(rate(http_requests_total[1h]))
) / 0.001 > 1

# P99 latency 이동 편차
histogram_quantile(0.99,
  sum(rate(http_request_duration_seconds_bucket[5m]))
  by (le, service)
) > 2 * histogram_quantile(0.99,
  sum(rate(http_request_duration_seconds_bucket[1h]))
  by (le, service)
)

# CPU throttling 비율
sum(rate(container_cpu_cfs_throttled_periods_total[5m]))
by (pod) /
sum(rate(container_cpu_cfs_periods_total[5m]))
by (pod) > 0.25

AIOps 데이터 파이프라인 — 실시간 흐름

Block 1 — Key Takeaways

핵심 포인트

AIOps = Observe + Detect + Diagnose + Respond 4단계 자동화
Three Pillars — Metrics, Logs, Traces 통합 수집이 전제 조건
ADOT — 벤더 중립 통합 수집기, EKS 환경의 표준
CloudWatch Anomaly Detection — 정적 임계값의 대안, ML 기반 밴드 모델
AMP + AMG — 오픈소스 호환 관리형 분석/시각화 스택

AnyCompany 체크포인트

[ ] CloudWatch Agent 전체 워크로드 배포 여부
[ ] ADOT 또는 기존 Prometheus 수집 파이프라인 존재
[ ] Cross-Account Observability 설정 유무
[ ] SLI/SLO 정량적 정의 및 대시보드 운영
[ ] 로그 보존 정책 및 아카이빙 전략

다음 블록 예고

Block 2에서는 이 데이터를 활용하는 ML 서비스들 — DevOps Guru, CodeGuru, Lookout for Metrics, 그리고 Gen AI 기반 운영을 다룹니다.

Thank You

수고하셨습니다!

← 목차로 돌아가기

AIOps on AWS

Intelligent Cloud Operations for AnyCompany

Junseok Oh

Sr. Solutions Architect

AWS

ML-Powered Operations

Block 2 — Anomaly Detection & Intelligent Diagnostics (30분)

Amazon DevOps Guru — ML 기반 운영 인사이트

작동 원리

AWS 리소스의 운영 메트릭을 ML로 분석
서비스별 사전 학습 모델 (Lambda, RDS, ECS, DynamoDB 등)
비정상 패턴 감지 시 Insight 생성
관련 이벤트를 자동 그룹핑 (노이즈 감소)

Insight 유형

유형	설명
Reactive	이미 발생한 문제에 대한 분석
Proactive	곧 발생할 문제 사전 경고

지원 리소스

Lambda, API Gateway, DynamoDB, RDS, ECS, EKS, SQS, SNS, Step Functions, CloudFormation stacks

Insight 구성 요소

Anomalous Metrics — 어떤 메트릭이 비정상인지
Related Events — CloudTrail 이벤트 상관 분석
Recommendations — 구체적 조치 방안

실제 사례

Lambda Duration이 평소 200ms → 2s로 증가 → DevOps Guru가 동시에 발생한 DynamoDB ProvisionedThroughputExceeded 이벤트와 상관 분석 → "DynamoDB 테이블 용량 부족이 Lambda 지연의 원인" 진단 → "Auto Scaling 활성화 또는 On-Demand 전환" 권고

비용

$0.0028 / AWS 리소스 / 시간
100개 리소스 기준 ~$200/월

DevOps Guru — 설정과 운영

CloudFormation Stack 기반 활성화

AWSTemplateFormatVersion: '2010-09-09'
Resources:
  DevOpsGuruConfig:
    Type: AWS::DevOpsGuru::ResourceCollection
    Properties:
      ResourceCollectionFilter:
        CloudFormation:
          StackNames:
            - "AnyCompany-Production-*"

  DevOpsGuruNotification:
    Type: AWS::DevOpsGuru::NotificationChannel
    Properties:
      Config:
        Sns:
          TopicArn: !Ref OpsAlertTopic
        Filters:
          Severities:
            - HIGH
            - MEDIUM
          MessageTypes:
            - NEW_INSIGHT
            - SEVERITY_UPGRADED

권장 설정

Production 스택만 활성화 (비용 최적화)
HIGH + MEDIUM severity만 알림 (노이즈 최소화)
SNS → Lambda → Slack/PagerDuty 연동

DevOps Guru for EKS

# EKS 클러스터에 DevOps Guru 활성화
aws devops-guru update-resource-collection \
  --action ADD \
  --resource-collection '{
    "Tags": [{
      "AppBoundaryKey": "devops-guru-eks",
      "TagValues": ["anycompany-prod"]
    }]
  }'

탐지 가능한 EKS 이슈

Pod CPU/Memory 이상 사용 패턴
Container restart loop 감지
Node 리소스 고갈 예측
API Server latency 이상

제한 사항

Container Insights 활성화 필수
EKS 1.23+ 지원
Fargate Pod은 일부 메트릭 제한

EventBridge 연동

{
  "source": ["aws.devops-guru"],
  "detail-type": ["DevOps Guru New Insight Open"],
  "detail": {
    "insightSeverity": ["HIGH"]
  }
}

Lambda 자동 대응 예시

def handler(event, context):
    insight = event['detail']
    severity = insight['insightSeverity']
    anomalies = insight.get('anomalies', [])

    for anomaly in anomalies:
        source = anomaly['sourceDetails']
        if 'DynamoDB' in str(source):
            enable_auto_scaling(source)
        elif 'Lambda' in str(source):
            adjust_concurrency(source)

    send_slack_notification(insight)

CloudWatch Anomaly Detection — ML 모델 동작 원리

Amazon CodeGuru & Lookout for Metrics

CodeGuru Profiler

프로덕션 환경 프로파일링 (overhead < 1%)
CPU, Latency hotspot 자동 탐지
ML 기반 비용 절감 권고 (비효율 코드 식별)
Java, Python 지원

프로파일링 결과 예시

Top CPU Consumers:
1. OrderService.processPayment()
   → 37% CPU, 12ms avg latency
   → Recommendation: Connection pool 재사용
      예상 절감: $340/month

2. InventoryService.checkStock()
   → 22% CPU, 8ms avg latency
   → Recommendation: BatchGetItem 사용
      예상 절감: $120/month

Amazon Lookout for Metrics

비즈니스 메트릭 이상 탐지 특화
Revenue, Order count, User engagement 모니터링
다차원 근본 원인 기여도 자동 분석

Lookout vs CloudWatch AD

기준	Lookout	CW AD
대상	비즈니스 메트릭	인프라 메트릭
차원 분석	다차원 기여도	단일 메트릭
데이터소스	RDS, S3, Redshift	CloudWatch only
알림 지연	5~15분	1~5분
비용	메트릭당 과금	무료 (CW 포함)

사용 시나리오

"주문량이 평소 대비 30% 감소" → Lookout이 region=ap-northeast-2 + category=electronics에서 주로 감소했다고 차원 분석

Generative AI for Operations

Amazon Q in CloudWatch

자연어로 CloudWatch 데이터 분석
"왜 이 Lambda가 느려졌어?"에 대한 설명 생성
로그 패턴 요약 및 근본 원인 제안
자연어 → Logs Insights 쿼리 자동 변환

Amazon Q Developer

IDE에서 운영 코드 자동 생성
IaC (CloudFormation/CDK) 자동 생성
코드 리뷰에서 운영 이슈 사전 탐지

Amazon Bedrock Agent

커스텀 AIOps 챗봇 구축
사내 운영 문서 + AWS 데이터 통합
RAG 기반 인시던트 자동 대응 가이드

Bedrock Agent 아키텍처

사용자 질문
    ↓
Bedrock Agent (Claude)
    ↓
┌─────────────────────────────┐
│ Knowledge Base               │
│ ├─ 운영 Runbook (S3)        │
│ ├─ 장애 이력 DB (OpenSearch) │
│ └─ AWS 공식 문서            │
├─────────────────────────────┤
│ Action Groups               │
│ ├─ CloudWatch 쿼리 실행     │
│ ├─ Lambda 호출 (복구 액션)   │
│ └─ Jira 티켓 생성           │
└─────────────────────────────┘
    ↓
"DynamoDB 테이블 X의 RCU가
 포화 상태입니다. 과거 유사 사례에서는
 Auto Scaling을 활성화하여 해결했습니다.
 지금 바로 적용할까요?"

도입 단계

Q in CloudWatch — 즉시 사용 (설정 불필요)
Q Developer — IDE 플러그인 설치
Bedrock Agent — 커스텀 구축 (2-4주)

AIOps 이벤트 상관 분석 — 노이즈에서 인사이트로

CloudWatch Composite Alarms — 알람 전략

문제: 알람 폭풍

하나의 장애 → 수십 개 알람 동시 발생
온콜 엔지니어 알람 피로 (Alert Fatigue)
"어떤 알람이 진짜 중요한지" 판단 불가

해결: Composite Alarm

여러 개별 알람을 논리 조합 (AND/OR/NOT)
조건 조합이 충족될 때만 알림
suppress-on-recovery: 곧 복구되면 불필요한 알림 억제

3계층 알람 아키텍처

L3 Business Impact → PagerDuty 호출
  └─ L2 Service Health → Slack 알림
       └─ L1 Individual Metrics → 대시보드만

CloudFormation 설정

CompositeServiceAlarm:
  Type: AWS::CloudWatch::CompositeAlarm
  Properties:
    AlarmName: AnyCompany-ServiceHealth
    AlarmRule: >-
      ALARM("ELB-5xx-Rate")
      AND
      ALARM("Backend-P99-Latency")
      AND
      NOT ALARM("Maintenance-Window")
    AlarmActions:
      - !Ref PagerDutyTopic
    ActionsSuppressor: MaintenanceWindow
    ActionsSuppressorWaitPeriod: 120
    ActionsSuppressorExtensionPeriod: 60

베스트 프랙티스

L1 알람 (개별 메트릭) → 대시보드 전용
L2 Composite (서비스 단위) → Slack 알림
L3 Composite (비즈니스 영향) → PagerDuty 호출
유지보수 윈도우 Suppressor 필수 설정

Block 2 — Key Takeaways

핵심 포인트

DevOps Guru — 이벤트 상관 분석 + 사전 예측으로 MTTR 대폭 단축
CloudWatch AD — Random Cut Forest 기반 동적 밴드, stddev 2~3 권장
Composite Alarms — 3계층(L1/L2/L3) 전략으로 알람 피로 80% 감소
CodeGuru + Lookout — 코드 레벨 + 비즈니스 레벨 이상 탐지 보완
Gen AI (Q + Bedrock) — 자연어 분석 + 커스텀 AIOps Agent 구축

AnyCompany 체크포인트

[ ] DevOps Guru Production 스택 활성화
[ ] CloudWatch AD 핵심 SLI에 적용
[ ] Composite Alarm 3계층 구조 설계
[ ] Amazon Q in CloudWatch 팀 내 시범 사용
[ ] Bedrock Agent 기반 AIOps 챗봇 PoC 계획

다음 블록 예고

Block 3에서는 이 서비스들을 AnyCompany 환경에 맞게 조합하는 구현 전략과 단계별 로드맵을 다룹니다.

Thank You

수고하셨습니다!

← 목차로 돌아가기

AIOps on AWS

Intelligent Cloud Operations for AnyCompany

Junseok Oh

Sr. Solutions Architect

AWS

Implementation Strategies

Block 3 — AnyCompany를 위한 AIOps 구현 (25분)

AnyCompany AIOps 레퍼런스 아키텍처

단계별 도입 로드맵

AIOps 비용 최적화 전략

서비스별 월간 비용 (100 리소스 기준)

서비스	항목	월 비용
CloudWatch Metrics	커스텀 메트릭 200개	~$60
CloudWatch Logs	50GB 수집, 30일 보존	~$75
CloudWatch AD	메트릭 50개	무료 (CW 포함)
DevOps Guru	100 리소스	~$200
AMP	50M samples/month	~$150
AMG	1 workspace, 5 editors	~$45
X-Ray	10M traces	~$50
Lookout	50 메트릭	~$300
합계		~$880/month

Production만 적용 시 기준. Dev/Staging은 ~$380/month로 축소 가능

즉시 적용 가능

로그 보존 정책: hot 30일 → warm 90일 → S3 아카이브
메트릭 필터링: 불필요한 high-cardinality 메트릭 drop
AMP relabeling: label 조합 100만 이하로 관리
X-Ray 샘플링: reservoir 1/s + fixed_rate 5%

아키텍처 레벨

Monitoring Account 통합으로 중복 수집 제거
ADOT Processor: batch + filter로 불필요 데이터 제거
Tiered Alerting: L1은 CloudWatch만, L2부터 DevOps Guru

ROI 측정 공식

AIOps ROI = (MTTR_before - MTTR_after) × incidents/month
            × cost_per_minute_downtime
            - AIOps_monthly_cost

AnyCompany 시나리오

Before AIOps

월 평균 장애: 8건
평균 MTTR: 2시간
분당 비즈니스 영향: $500
월 손실: 8 × 120분 × $500 = $480,000

After AIOps (Phase 3)

월 평균 장애: 5건 (3건 사전 예방)
평균 MTTR: 15분
월 손실: 5 × 15분 × $500 = $37,500

결과

항목	금액
월 손실 감소	$442,500
AIOps 월 비용	$880
월 순이익	$441,620
ROI	50,000%+

장애 비용이 있는 환경이라면 AIOps는 거의 항상 positive ROI

AIOps 운영 성숙도 모델

장애 발생 후 수동 확인, 개인 경험에 의존
알람 = 정적 임계값, 대시보드 수동 확인
MTTR: 2-4시간

ML 기반 이상 탐지, 관측성 3 Pillars 구축
DevOps Guru + CloudWatch AD 활성화
MTTR: 15-30분

EventBridge + SSM 자동 복구, Composite Alarm
Runbook 기반 셀프 힐링
MTTR: 1-5분

Gen AI 기반 자연어 분석, Predictive scaling
자동 RCA → 자동 수정 → 자동 검증
MTTR: 자동 복구 (사람 개입 최소)

AIOps 도입 시 흔한 도전과 해결책

Challenge

데이터 사일로 — 팀마다 다른 모니터링 도구 사용
알람 피로 — 수백 개 알람이 울려도 무시
스킬 갭 — ML/데이터 분석 역량 부족
신뢰 부족 — "ML 판단을 믿을 수 있나?"
비용 우려 — 관측성 비용이 인프라 비용의 10%+

Solution

Monitoring Account 통합 + ADOT 표준화 → 사일로 해소
Composite Alarm 3계층 + DevOps Guru 상관 분석 → 노이즈 80% 감소
Amazon Q — ML 전문성 없이 자연어로 분석 → 스킬 갭 해소
점진적 자동화 — 알림부터 시작, 신뢰 구축 후 자동 대응
Tiered 수집 — 핵심 SLI만 ML 적용 → 비용 최적화

AnyCompany — 내일부터 시작할 수 있는 Quick Wins

Week 1 — 즉시 적용

Amazon Q in CloudWatch 활성화 (무료)
- 팀 전원에게 접근 권한 부여
- "가장 에러가 많은 Lambda는?" 테스트
CloudWatch Anomaly Detection 핵심 SLI 5개 적용
- API latency P99, Error rate, Lambda Duration
- Stddev = 2로 시작
Composite Alarm 1개 시범 구성
- 가장 중요한 서비스의 L3 알람

Week 2-4 — 기반 구축

SLI/SLO 워크숍 개최
- 서비스 소유자와 함께 핵심 SLI 정의
- 99.9% availability = 월 43분 다운타임
DevOps Guru Production 스택 활성화
- HIGH severity만 SNS → Slack 알림
ADOT 파일럿 EKS 1개 클러스터 적용
- DaemonSet 배포 + AMP 연동

성공 기준

2주 내: "ML이 잡아낸 이상" 최초 사례 1건
4주 내: MTTR 30% 감소 (측정 시작)

전체 세션 요약

Block 1 — Foundations

AIOps = Observe + Detect + Diagnose + Respond
ADOT 통합 수집 → CloudWatch + AMP + X-Ray
Cross-Account Observability로 통합 모니터링

Block 2 — ML Operations

DevOps Guru — 이벤트 상관 분석, 사전 예측
CloudWatch AD — RCF 기반 동적 이상 탐지
Gen AI (Q, Bedrock) — 자연어 운영 인터페이스
Composite Alarm — 3계층 알람 전략

Block 3 — Implementation

4-Phase 로드맵: Foundation → Detection → Automation → Intelligence
MTTR: 4시간 → 30분 → 5분 → 자동 복구
ROI: AIOps 비용 대비 50,000%+ 절감 가능

핵심 메시지

"AIOps는 목적지가 아니라 여정입니다." 작게 시작하고(Quick Wins), 신뢰를 구축하고(점진적 자동화), 지속적으로 발전시키세요.

Next Steps

SLI/SLO 워크숍 스케줄링
Amazon Q + CloudWatch AD 시범 적용
DevOps Guru PoC 범위 합의

Q&A

추가 리소스

AWS Well-Architected — Operational Excellence Pillar
Amazon DevOps Guru Documentation
AWS Observability Best Practices Guide
AWS AIOps Workshop (workshops.aws)

Contact

Junseok Oh

Sr. Solutions Architect, AWS

세션 후에도 언제든 연락 주세요.

Thank You

수고하셨습니다!

← 목차로 돌아가기