DevOps 도구 및 베스트 프랙티스 마스터 - DevOps 지식 허브 DevOps 도구 및 베스트 프랙티스 마스터 - DevOps 지식 허브

AWS CloudWatch 마스터하기: 사전 예방적 성능 모니터링 및 최적화

CloudWatch를 마스터하여 AWS에서 최고의 성능을 발휘하세요. 사용자 정의 지표 설정, 정확한 지연 시간 추적을 위한 백분위수 통계(P99/P95) 활용, Auto Scaling을 트리거하는 지능형 알람 구성 방법을 알아보세요. 이 가이드는 최적화된 모니터링 대시보드를 구축하고 최종 사용자에게 영향을 미치기 전에 성능 병목 현상을 사전에 해결하기 위한 실행 가능한 단계를 제공합니다.

AWS CloudWatch 마스터하기: 사전 예방적 성능 모니터링 및 최적화

AWS CloudWatch는 많은 AWS 인시던트가 이해되기 시작하는 곳입니다. 느린 체크아웃 흐름, 갑자기 제한되는 Lambda 함수, 연결이 부족한 RDS 데이터베이스, 계속 증가하는 SQS 대기열은 모두 지표와 로그에 단서를 남깁니다. 어려운 점은 CloudWatch를 켜는 것이 아닙니다. 어려운 점은 사용자가 무언가 고장 났다고 말하기 전에 조치를 취할 수 있는 신호를 선택하는 것입니다.

좋은 CloudWatch 모니터링은 플랫폼 증상을 애플리케이션 동작과 연결합니다. CPU, 메모리, I/O도 중요하지만 체크아웃 실패, 대기열 수명, 결제 지연 시간, 분당 성공한 작업 수 등도 중요합니다.

AWS CloudWatch의 핵심 구성 요소

CloudWatch는 지표로 알려진 시계열 데이터를 수집하고, 이를 알람을 사용하여 임계값과 비교 평가하는 시스템에서 작동합니다. 이 데이터는 대시보드를 통해 시각화되고 로그 및 이벤트로 보완됩니다.

1. 지표: 모니터링의 기초

지표는 시간에 따라 추적되는 숫자 측정값입니다. 모든 AWS 서비스는 표준 지표(예: EC2 CPU 사용률, S3 요청 수)를 자동으로 게시합니다. 그러나 진정한 성능 모니터링을 위해서는 기본값을 넘어서야 합니다.

표준 지표 vs. 사용자 정의 지표

  • 표준 지표: AWS 서비스에서 자동으로 수집합니다. 해상도는 서비스 및 구성에 따라 다릅니다. 많은 일반 서비스는 1분 지표를 게시하는 반면, 일부 기본 또는 이전 구성은 5분 기간을 사용합니다.
  • 사용자 정의 지표: 직접 게시하는 데이터로, 주로 애플리케이션별 성능 지표를 측정하는 데 사용됩니다.

AWS CLI를 사용하여 사용자 정의 지표 게시:

put-metric-data 명령을 사용하여 사용자 정의 지표를 게시할 수 있습니다. 이는 애플리케이션 응답 시간, 대기열 깊이 또는 비즈니스에 중요한 운영 상태를 모니터링하는 데 중요합니다.

aws cloudwatch put-metric-data \
    --metric-name "CheckoutLatency" \
    --namespace "MyApp/ECommerce" \
    --value 150 \
    --unit "Milliseconds" \
    --region us-east-1

지표 세분성

CloudWatch 사용자 정의 지표는 표준 해상도 또는 고해상도일 수 있습니다. 고해상도 사용자 정의 지표는 1초 해상도로 저장되고 더 짧은 기간에 대해 알람을 설정할 수 있어 빠르게 움직이는 시스템에 유용합니다. 더 많은 볼륨과 알람이 비용을 증가시킬 수 있으므로 선택적으로 사용하십시오.

2. 알람: 임계값에 따른 작업 트리거

알람은 OK, INSUFFICIENT_DATA, ALARM의 세 가지 상태 사이를 전환합니다. 알람은 지정된 임계값이 정의된 기간 수 동안 위반되면 작업을 트리거합니다.

성능 알람 설정

효과적인 성능 알람은 단순한 대응적 실패보다는 선행 지표에 초점을 맞춥니다. 예를 들어 EC2 CPU 사용률을 모니터링하는 것은 좋지만, T 계열 인스턴스의 BurstBalance 지표를 모니터링하면 사용률이 100%에 도달하기 전에 향후 제한을 예측할 수 있습니다.

예: 높은 지연 시간에 대한 알람 설정

사용자 정의 CheckoutLatency 지표가 3회 연속 1분 기간 동안 평균 500ms를 초과하면 알람을 트리거하고 SNS 주제에 알립니다.

aws cloudwatch put-metric-alarm \
    --alarm-name "HighCheckoutLatencyAlarm" \
    --alarm-description "Alert when P95 latency exceeds 500ms" \
    --metric-name "CheckoutLatency" \
    --namespace "MyApp/ECommerce" \
    --statistic Average \
    --period 60 \
    --threshold 500 \
    --evaluation-periods 3 \
    --datapoints-to-alarm 3 \
    --comparison-operator GreaterThanThreshold \
    --actions-enabled \
    --alarm-actions arn:aws:sns:us-east-1:123456789012:PerformanceAlertsTopic

모범 사례: 백분위수(p99, p95) 활용 지연 시간을 모니터링할 때는 Average에만 의존하지 마십시오. 느린 요청의 작지만 고통스러운 그룹이 건강해 보이는 평균 안에 사라질 수 있습니다. 꼬리 지연 시간이 중요할 때는 P99 또는 P95와 같은 통계를 사용하십시오.

3. 대시보드: 시스템 상태 시각화

대시보드는 관련 지표를 단일 창으로 통합합니다. 효과적인 대시보드는 대상(예: 운영, 개발, 경영진)에 맞게 조정됩니다.

성능 최적화 대시보드 구축

성능 최적화를 위한 잘 구조화된 대시보드는 관련 지표를 그룹화해야 합니다.

  • 시스템 상태 패널: CPU 사용률, 네트워크 입/출력, 디스크 읽기/쓰기 IOPS (EC2/EBS).
  • 애플리케이션 성능 패널: 사용자 정의 지연 시간 지표(P99), 오류율(HTTP 5xx 수), 요청 처리량.
  • 비용/효율성 패널: 실행 중인 인스턴스 수, 예약 인스턴스 사용률, EBS 볼륨 사용률(미달 사용 스토리지 식별).

CloudWatch 대시보드는 텍스트 주석, 지표 수학 표현식(예: 효율성 비율 계산), CloudWatch Logs Insights 쿼리 결과 포함과 같은 복잡한 위젯을 지원합니다.

자동화된 성능 최적화를 위한 CloudWatch

모니터링 데이터는 조치를 유도할 때만 가치가 있습니다. CloudWatch 알람은 자동화된 최적화 워크플로우를 시작하는 주요 메커니즘입니다.

알람과 Auto Scaling 통합

가장 강력한 최적화 기술 중 하나는 CloudWatch 알람을 사용하여 AWS Auto Scaling 그룹(ASG)을 구동하는 것입니다. 이는 용량이 수요와 정확히 일치하도록 하여 과잉 프로비저닝(비용 절감) 및 과소 프로비저닝(성능 저하)을 방지합니다.

예: 대기열 깊이 기반 스케일 아웃

CPU에만 의존하는 대신 처리 대기 중인 백로그를 기준으로 확장하십시오. SQS 대기열의 경우 ApproximateNumberOfMessagesVisible 지표에 대한 알람을 생성합니다. 알람이 ALARM 상태가 되면 Auto Scaling 작업을 트리거하여 ASG에 EC2 인스턴스를 추가합니다.

구성 팁: 확장 정책이 평균 사용률 지표(예: 평균 CPU를 60%로 유지)를 유지하도록 구성된 Target Tracking Scaling을 사용하는지 확인하십시오. 이렇게 하면 AWS가 동적으로 확장을 관리할 수 있으며, 일반적으로 정적 단계 확장보다 선호됩니다.

심층 분석을 위한 로그 활용

성능 문제가 발생하면 CloudWatch Logs는 근본 원인 분석에 필수적입니다.

  • 중앙 집중식 로깅: 모든 애플리케이션 및 서비스(VPC 흐름 로그, Lambda 로그, ECS/EKS 컨테이너 로그)가 CloudWatch Logs로 스트리밍되도록 구성합니다.
  • Log Insights: Log Insights의 강력한 쿼리 언어를 사용하여 방대한 로그 볼륨을 빠르게 검색합니다. 예를 들어, 2초 이상 걸린 모든 요청을 찾으려면:
fields @timestamp, @message
| filter @message like /duration: \d{4,}/ 
| parse @message "*duration: *ms*" as duration
| filter as_number(duration) > 2000
| sort @timestamp desc
| limit 50

CloudWatch 모니터링 모범 사례

CloudWatch에서 얻는 가치를 극대화하고 성능을 최적화하려면:

  1. 서비스 한도 모니터링: AWS 서비스 할당량(예: 최대 동시 Lambda 실행 수, 계정에서 사용 가능한 최대 EBS IOPS)에 대한 알람을 설정합니다. 할당량에 도달하면 명확한 애플리케이션 오류 없이 성능이 완전히 중단됩니다.
  2. 기준 성능 설정: 최적화하기 전에 피크 및 비피크 시간 동안 시스템을 모니터링하여 정상이 무엇인지 정의합니다. 이렇게 하면 관련 없는 노이즈를 기반으로 알람을 설정하는 것을 방지할 수 있습니다.
  3. 비율에 지표 수학 사용: CloudWatch에서 직접 효율성 비율을 계산합니다. 예를 들어, (총 오류 / 총 요청) * 100을 사용하여 여러 개별 지표를 저글링하는 대신 직접적인 실패율 백분율을 얻을 수 있습니다.
  4. 비용 관리: 사용자 정의 고해상도 지표는 비용이 더 많이 듭니다. 신중하게 사용하십시오. 중요한 빠르게 변화하는 시스템(예: 로드 밸런서)에만 1분 해상도를 사용하십시오. 대부분의 백엔드 서비스에는 기본 5분 해상도로 충분합니다.
  5. 태깅 전략: 모니터링되는 모든 리소스(EC2, RDS, Lambda)에 일관되게 태그가 지정되었는지 확인합니다. 이렇게 하면 특정 환경(예: Env: Prod, App: CheckoutService)에 대한 필터링된 대시보드 및 알람을 생성할 수 있습니다.

대시보드를 인시던트와 일치시키기

CloudWatch 대시보드는 압박 속에서 누군가가 결정을 내리는 데 도움이 되어야 합니다. 대시보드가 시스템에 많은 지표가 있다는 것만 증명한다면 장애 시 도움이 되지 않습니다.

웹 애플리케이션의 경우 첫 번째 화면을 간단한 경로 주위에 구축하는 것을 좋아합니다: 트래픽이 들어오고, 애플리케이션이 처리하고, 종속성이 응답하고, 사용자가 성공하거나 실패합니다. 이는 일반적으로 다음 위젯이 서로 가까이 있어야 함을 의미합니다:

  • 로드 밸런서 또는 API Gateway의 요청 수 및 오류 수.
  • 동일한 진입점에 대한 P95 또는 P99 지연 시간.
  • 애플리케이션 수준의 성공 및 실패 지표.
  • ECS, EKS, Lambda 또는 EC2의 CPU, 메모리 및 작업 수.
  • 느린 요청을 일반적으로 설명하는 RDS, DynamoDB, Redis, SQS 또는 외부 종속성 지표.

정확한 서비스는 변경되지만 형태는 동일하게 유지됩니다. 체크아웃 지연 시간이 급증하면 트래픽이 급증했는지, 오류가 증가했는지, 데이터베이스 지연 시간이 증가했는지, 작업자가 뒤쳐졌는지 확인하려고 합니다. 해당 단서를 한 곳에 두십시오.

명확한 레이블 없이 프로덕션, 스테이징 및 개발을 혼합하는 대시보드는 피하십시오. 인시던트 중에 누군가가 결국 잘못된 그래프를 읽을 것입니다. 환경을 명확하게 하는 차원, 태그 및 명명 규칙을 사용하십시오.

백분위수 신중하게 사용

백분위수는 평균이 고통스러운 사용자 경험을 숨기기 때문에 지연 시간에 유용합니다. 대부분의 요청이 100ms에 완료되지만 소규모 그룹이 8초가 걸리면 평균이 여전히 수용 가능해 보일 수 있습니다. 백분위수 그래프는 긴 꼬리를 보이게 합니다.

즉, 백분위수가 마법은 아닙니다. 의미 있으려면 충분한 트래픽이 필요하며, 트래픽이 적은 서비스에서는 노이즈가 많아 보일 수 있습니다. 시간당 몇 번 실행되는 소규모 내부 작업의 경우 P99보다 최대 기간 또는 명시적 실패 지표가 더 유용할 수 있습니다. 안정적인 트래픽이 있는 공개 API의 경우 P95 및 P99를 주시할 가치가 있습니다.

알람을 생성할 때 CLI 명령이 실제로 의도한 통계를 사용하는지 확인하십시오. 백분위수 알람의 경우 --statistic Average가 아닌 --extended-statistic p95 또는 p99를 사용하십시오:

aws cloudwatch put-metric-alarm \
  --alarm-name "HighCheckoutP95Latency" \
  --metric-name "CheckoutLatency" \
  --namespace "MyApp/ECommerce" \
  --extended-statistic p95 \
  --period 60 \
  --threshold 500 \
  --evaluation-periods 5 \
  --datapoints-to-alarm 3 \
  --comparison-operator GreaterThanThreshold \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:PerformanceAlertsTopic

datapoints-to-alarm 설정이 중요합니다. 5개 중 3개 기간을 요구하면 시끄러운 1분 동안 페이지를 보내지 않고 지속적인 문제를 포착할 수 있습니다. 중요한 시스템의 경우 추측 대신 실제 과거 트래픽으로 이를 조정하십시오.

애플리케이션 지표를 AWS 지표 옆에 배치

AWS 서비스 지표는 플랫폼이 보는 것을 알려줍니다. 애플리케이션 지표는 사용자가 하려는 것을 알려줍니다. 둘 다 필요합니다.

예를 들어, ECS 서비스는 결제 제공업체가 시간 초과되어 체크아웃이 중단된 동안 정상적인 CPU 및 메모리를 표시할 수 있습니다. CloudWatch는 애플리케이션이 PaymentAuthorizationFailure, CheckoutCompleted 또는 PaymentProviderLatency와 같은 지표를 게시하지 않는 한 이를 알지 못합니다.

좋은 사용자 정의 지표는 일반적으로 비즈니스 작업에 연결됩니다:

  • LoginSucceeded 및 LoginFailed
  • OrderCreated
  • PaymentAuthorizationLatency
  • QueueJobProcessed
  • ImportRowsFailed

차원을 유용하게 유지하되 폭발적이지 않게 유지하십시오. Service, Environment 및 Region은 일반적으로 괜찮습니다. 모든 사용자 ID, 요청 ID 또는 URL 경로에 대한 차원은 높은 카디널리티 비용을 생성하고 데이터를 사용하기 어렵게 만들 수 있습니다. 세부적인 요청별 조사의 경우 로그 및 추적이 더 좋은 장소입니다.

CloudWatch Embedded Metric Format은 이미 구조화된 JSON 로그를 작성할 때 유용합니다. 동일한 이벤트에서 로그와 지표를 내보낼 수 있어 애플리케이션 계측을 더 간단하게 유지합니다. 절충점은 비용과 볼륨입니다: 구조화된 로그는 강력하지만 시끄러운 로그는 빠르게 비용이 많이 듭니다.

증상과 원인 주변에 알람 구축

일반적인 모니터링 실수 중 하나는 원인에 대해서만 알람을 설정하는 것입니다: CPU 높음, 메모리 높음, 디스크 대기열 높음. 이는 유용하지만 항상 사용자가 영향을 받고 있음을 의미하지는 않습니다. 또 다른 실수는 증상에 대해서만 알람을 설정하는 것입니다: 오류율 높음, 지연 시간 높음, 주문 실패. 이는 사용자가 영향을 받고 있음을 알려주지만 이유를 설명하지는 않습니다.

실용적인 설정은 둘 다 사용합니다:

  • 증상 알람은 서비스 소유자에게 페이지를 보냅니다: 높은 오류율, 높은 지연 시간, 성공적인 주문 없음, 대기열 수명 증가.
  • 원인 알람은 진단을 지원합니다: 데이터베이스 CPU, 제한된 DynamoDB 요청, Lambda 동시성, 소진된 버스트 밸런스, 낮은 디스크 공간.
  • 용량 알람은 조기에 경고합니다: Auto Scaling이 최대치에 가까움, 서비스 할당량 접근, 작업자가 소진할 수 있는 것보다 빠르게 증가하는 백로그.

모든 알람이 동일한 채널에 동일한 긴급도로 페이지를 보내면 사람들은 채널을 신뢰하지 않게 됩니다. 경고 알람은 누군가를 깨우지 않고 볼 수 있게 하고, 사용자 영향 또는 거의 확실한 사용자 영향을 위해 페이지를 예약하십시오.

검색이 아닌 질문을 위해 Logs Insights 사용

CloudWatch Logs Insights는 팀이 반복적으로 묻는 질문에 대한 쿼리를 저장할 때 가장 유용합니다. 예:

fields @timestamp, status, path, durationMs
| filter status >= 500
| stats count() as errors by path
| sort errors desc
| limit 20

fields @timestamp, requestId, customerId, durationMs
| filter durationMs > 2000
| sort durationMs desc
| limit 50

fields @timestamp, @message
| filter @message like /ThrottlingException|Rate exceeded/
| sort @timestamp desc
| limit 100

이러한 쿼리는 추적을 대체하지는 않지만 첫 번째 응답에 충분히 빠릅니다. Runbook 또는 대시보드 텍스트 위젯에 저장하여 다음 사람이 시스템이 느린 동안 구문을 기억할 필요가 없도록 하십시오.

가시성을 개선하는 동안 비용 검토

팀이 고해상도 사용자 정의 지표를 켜고, 모든 로그를 영원히 보관하거나, 너무 많은 고유 지표 차원을 생성할 때 CloudWatch는 비용이 많이 들 수 있습니다. 성능 모니터링은 예상치 못한 청구서를 생성해서는 안 됩니다.

의도적으로 보존 기간을 설정하십시오. 프로덕션 애플리케이션 로그는 개발의 디버그 로그보다 더 긴 보존이 필요할 수 있습니다. 보안 및 감사 로그에는 자체 규칙이 있을 수 있습니다. 자세한 서비스의 경우 CloudWatch에 도달하기 전에 시끄러운 정보 로그를 필터링하거나 샘플링하는 것을 고려하십시오.

지표의 경우 취할 수 있는 조치와 일치하는 해상도로 시작하십시오. 서비스가 안전하게 확장하는 데 몇 분이 걸리는 경우 1초 지표가 응답을 개선하지 못할 수 있습니다. 지연 시간 급증을 즉시 포착해야 하는 경우 해당 좁은 신호에 대해 고해상도 지표가 가치가 있을 수 있습니다.

유용한 첫 번째 CloudWatch 설정

새로운 프로덕션 서비스의 경우 견고한 첫 번째 패스는 다음과 같습니다:

  1. 트래픽, 지연 시간, 오류, 포화 및 종속성 상태를 포함하는 대시보드.
  2. 높은 오류율, 높은 지연 시간, 트래픽이 예상될 때 성공적인 트래픽 없음, 대기열 수명 및 관련된 경우 낮은 디스크 공간에 대한 알람.
  3. 주요 사용자 작업에 대한 애플리케이션 지표.
  4. 요청 ID와 경로, 상태, 기간 및 종속성별로 필터링할 수 있는 충분한 필드가 있는 구조화된 로그.
  5. 느린 요청, 5xx 오류, 제한 및 실패한 백그라운드 작업에 대한 저장된 Logs Insights 쿼리.
  6. 시끄러운 알람, 누락된 알람 및 CloudWatch 비용에 대한 월별 검토.

CloudWatch는 사용자가 불평한 후에만 누군가가 여는 대시보드가 아니라 팀이 운영하는 방식의 일부가 될 때 가장 잘 작동합니다. 인시던트 중에 묻는 질문으로 시작한 다음 해당 질문 주변에 지표, 알람 및 로그를 구성하십시오.