AWS CloudWatch
터클라우드 운영에서 관측 가능성(Observability)은 핵심 요소입니다. 클라우드 엔지니어, DevOps 전문가, SRE는 모니터링을 통해 시스템과 애플리케이션의 운영 상태에 대한 가시성을 확보합니다. AWS 환경에서는 클라우드 네이티브 서비스인 Amazon CloudWatch(이하 CloudWatch)를 많이 사용합니다. 이 글에서는 올해 초 모든 리전에 적용된 CloudWatch의 경보 메트릭 데이터 한도 증가 소식을 다루겠습니다. 먼저 한도 증가 배경과 엔지니어가 체감할 효과를 짚어보고, 안랩클라우드메이트가 수행한 테스트 결과와 주요 권장 사항을 소개하겠습니다.
2025년 1월 23일, AWS는 모든 리전의 CloudWatch에서 경보 설정 시 최대 7일(168시간) 전의 메트릭 데이터까지 평가하도록 기능을 확장했다고 공식 발표했습니다. 이는 기존 24시간 제한에서 7배 증가한 수치로, 장기 추세와 패턴 모니터링에 큰 도움이 될 것으로 보입니다.
이 기능은 AWS GovCloud를 포함한 모든 상용 리전에서 사용할 수 있어, 여러 리전을 사용하는 환경에서도 일관된 장기 모니터링 정책 적용이 가능합니다. 사용자는 CloudWatch 콘솔, AWS CLI, SDK(PutMetricAlarm API)로 이 기능을 구성할 수 있습니다.
하지만 이 강력한 기능을 활용하려면 한 가지 전제 조건이 있습니다. 바로 경보를 설정하려는 지표의 기간(Period)을 최소 3,600초(1시간) 이상으로 설정해야 한다는 점입니다. 여기에는 중요한 배경이 숨어 있습니다. 7일이라는 긴 시간 동안 1분 단위의 데이터를 매번 쿼리하고 평가하는 것은 상당한 컴퓨팅 자원을 소모합니다. 실제로 1분 주기로 7일간 데이터를 평가하면 10,080개의 데이터 포인트를 처리해야 하지만, 1시간 주기일 경우 168개만 처리하면 됩니다. AWS는 최소 기간을 1시간으로 지정함으로써, 사용자가 이 기능을 단기 변동이 아닌 장기 추세 분석 용도로 활용하도록 유도하는 것으로 보입니다.
이 기능의 효용성을 이해하려면 먼저 기존 24시간 제한의 한계를 알아볼 필요가 있습니다. 많은 중요 비즈니스 프로세스와 시스템 동작은 24시간 주기를 넘어섭니다. 예를 들어 매일 밤 실행되는 대용량 데이터 로딩, 주말에 수행하는 ETL(Extract, Transform, Load) 프로세스, 주간 보고서 생성 배치 작업 등은 24시간이라는 짧은 시간만으로는 성공 여부나 성능 추이를 온전히 파악하기 어렵습니다.
이전에는 이런 제약 때문에 AWS Lambda 함수를 주기적으로 실행해 메트릭을 조회하고, 그 결과를 별도로 분석해 커스텀 메트릭을 생성하거나 알림을 보내는 복잡한 방법을 사용해야 했습니다. 이번 업데이트 덕분에 이런 번거로운 과정 없이 CloudWatch 네이티브 기능만으로 장기 모니터링이 가능해졌습니다.
이번 CloudWatch 기능 강화로 더욱 다양한 목적의 경보 설정이 가능해졌습니다.
• 주간 성능 동향 파악 & 점진적인 성능 저하 분석: 시스템 문제는 급작스럽게 발생하기도 하지만, 미세한 메모리 사용량 증가처럼 서서히 진행되기도 합니다. 7일간의 데이터를 보면 일일 임계값을 넘지 않는 미세한 변화도 명확히 파악하여 심각한 장애를 예방할 수 있습니다. 또한 주중과 주말의 트래픽 패턴이 다른 전자상거래 사이트나 요일별 부하를 분석해 용량 계획을 최적화해야 하는 B2B SaaS 애플리케이션에도 장기 모니터링이 유용합니다.
• 비즈니스 KPI와 애플리케이션 상태 모니터링 폭 확장: 기존의 인프라 지표를 넘어 '주간 신규 가입자 수', '주간 활성 사용자(WAU) 추이' 같은 비즈니스 지표를 직접 모니터링할 수 있습니다. 가령 "지난 7일간 장바구니 포기율이 이전 7일보다 10% 이상 증가 시" 경보를 설정하는 등 비즈니스 성과와 연계한 관리가 가능합니다.
• 비용 관리와 최적화 강화: EstimatedCharges 지표를 7일 단위로 모니터링하여 일일 비용 변동에 휘둘리지 않고 주간 지출이 예산을 초과하는 추세인지 감지할 수 있습니다. 이는 재무팀과 DevOps팀의 예산 예측 및 통제에 도움을 줍니다.
• 규정 준수 및 감사 작업을 간소화: 특정 산업에서는 주간, 월간 데이터 추적 및 보고가 필수적입니다. "주간 보안 스캔이 성공적으로 완료되었는지" 또는 "필수 백업이 지난 7일간 최소 1회 이상 실행되었는지"를 검증하는 경보를 설정하면 규정 준수 활동과 감사 데이터 확보가 한결 수월해집니다.
백문이 불여일견! 새로운 기능의 실제 동작 방식과 숨겨진 제약 사항을 파악하기 위해 안랩클라우드메이트는 공식 발표가 나자마자 테스트를 진행했습니다. AWS 내부 문서와 유사한 조건으로, 표준 EC2 인스턴스에서 수집한 AWS/EC2 네임스페이스의 CPUUtilization 지표를 대상으로 삼았습니다. 테스트 목표는 7일 데이터를 활용한 경보 생성 가능 여부와 그 제약 조건을 확인하는 것이었습니다.
테스트 시나리오 1: 기능 확인
먼저, 기능이 정상적으로 동작하는 테스트했습니다. CloudWatch 콘솔의 '모든 경보' 메뉴로 이동하여 '경보 생성'을 선택합니다. '지표 선택'에서 AWS/EC2, '인스턴스별 지표'를 차례로 선택하고, 테스트할 인스턴스의 CPUUtilization 지표를 선택합니다. 임계값은 '정적(Static)'으로, 조건은 '보다 큼(Greater)'으로 설정하고 적절한 값(예: 30)을 입력합니다. 그리고 기간(Period)은 1시간(1 hour)으로 설정합니다. '추가 구성'에서 경보를 울릴 데이터 포인트(Datapoints to alarm)를 168개 중 168개로 설정합니다. 이 설정의 의미는 "지난 168시간(7일) 동안의 모든 시간별 데이터 포인트가 임계값을 초과할 경우 경보를 발생시켜라"입니다.
위와 같은 설정으로 테스트한 결과 경보가 아무런 오류 없이 성공적으로 생성되었습니다. 이는 1시간 이상의 '기간'을 설정하는 핵심 조건을 만족할 경우, 7일 데이터 평가 기능이 정상적으로 작동함을 명확히 보여줍니다.
테스트 시나리오 2: 제약 조건 확인
다음으로 핵심 전제 조건인 '기간' 설정을 위반했을 때 어떤 일이 발생하는지 확인했습니다. 시나리오 1과 동일한 과정을 진행하되 기간(Period)을 1분(1 minute)으로 설정했습니다.
그리고 7일에 해당하는 10,080분(7일 * 24시간 * 60분)을 평가 기간으로 설정하려고 시도했습니다. 그 즉시 "지표는 최대 1일 동안의 값만 확인할 수 없습니다."라는 경고 메시지가 나타나며 설정이 불가능했습니다.
콘솔은 평가 기간을 최대 1,440개(1일)의 데이터 포인트로 제한했습니다. 이 테스트는 7일 데이터 평가 기능이 '기간' 설정에 얼마나 엄격하게 의존하는지를 잘 보여줍니다.
테스트 시나리오 3: 콘솔 별 동작 차이
테스트 과정에서 가장 중요하고 독특한 가치를 지닌 발견은 바로 경보를 생성하는 위치, 즉 AWS 콘솔의 어느 부분에서 작업을 수행하는지에 따라 동작이 달라진다는 점이었습니다. 먼저 EC2 콘솔에서 경보 생성을 테스트했습니다.
EC2 인스턴스 상세 화면의 '모니터링' 탭에서 'CloudWatch 경보 관리'를 통해 경보 생성을 시도했습니다. '기간'을 1시간으로 설정했음에도 불구하고 평가 기간을 설정하는 UI가 최대 24개의 연속 기간, 즉, 1일으로 암묵적으로 제한되어 7일 설정이 불가능했습니다.
위와 같은 현상이 EC2 콘솔에만 국한된 문제인지 확인하기 위해 RDS 콘솔에서도 동일한 테스트를 진행했습니다.
RDS 인스턴스의 CPUUtilization 지표에 대한 경보를 생성할 때, '평가 기간'을 168로 설정하는 것이 문제없이 가능했습니다.
일관성 없는 동작의 원인을 파악하기 위해 AWS에 기술 지원 케이스를 오픈한 결과 2025년 2월 18일 기준으로 "해당 문제(EC2 콘솔의 UI 제한)에 대해 내부 개발팀이 인지하였고, 근시일 내에 수정 배포를 진행할 예정"이라는 공식 답변을 받았습니다.
이번 CloudWatch 업데이트는 단순한 기능 추가를 넘어 클라우드 시스템을 관찰하고 관리하는 새로운 가능성을 제시합니다. 테스트와 분석을 종합한 결론과 권장 사항은 다음과 같습니다.
• 기존 경보 재검토 및 확장: 현재 현재 운영 중인 경보 목록에서 단기적인 임계값보다 주간 추세 분석이 더 의미 있는 지표를 식별하고, 7일 평가 기반의 새로운 경보로 보강하는 것을 권장합니다.
• Metric Math와 결합하여 가치 극대화: 이 기능의 진정한 힘을 발휘하려면 앞서 잠시 언급한 Metric Math과 결합해 활용해보세요.
• 누락된 데이터 처리(Treat Missing Data) 옵션 신중히 선택: 장기 경보에서는 데이터 포인트가 누락될 가능성이 높습니다. 예를 들어, 반드시 실행되어야 하는 주간 배치 작업의 데이터가 누락됐을 때, 이를 '위반(breaching)'으로 처리하도록 설정하면 실행 실패를 즉시 감지할 수 있습니다. 처리 방식을 신중하게 결정해야 합니다.
정리하자면, 이번 업데이트는 AWS가 관측성 기능을 지속적으로 강화하는 큰 그림의 일부로 볼 수 있습니다. 앞으로 메트릭, 로그, 트레이스 간의 통합이 더욱 긴밀해지면서 AWS 플랫폼 내에서 직접 더 정교한 장기 분석과 이상 탐지가 가능해질 것으로 기대됩니다. 새로운 업데이트가 발표되면 다시 테스트하여 그 내용을 공유하겠습니다.
