Conceptly
← 전체 목록
📊

Amazon CloudWatch

관리모니터링 및 관측성

CloudWatch는 AWS 리소스와 애플리케이션에서 나오는 메트릭, 로그, 알람을 한곳에 모아 보는 관측 계층입니다. 현재 상태를 수치와 이벤트로 드러내고, 임계치를 넘으면 통지나 자동 조치를 연결합니다.

아키텍처 다이어그램

📊 데이터 흐름 다이어그램

점선 애니메이션은 데이터 또는 요청의 흐름 방향을 나타냅니다

왜 필요한가요?

배포 후 오류율이 올랐는데 EC2 로그, Lambda 로그, 큐 적체를 각각 따로 열어 보면 원인 파악이 늦습니다. 메트릭과 알람이 한곳에 모이지 않으면 장애는 이미 커진 뒤에야 눈에 들어옵니다.

왜 이런 방식이 등장했나요?

서버 기반 운영 시대에는 장애가 발생하면 서버마다 직접 SSH로 접속해 로그 파일을 열어봐야 했습니다. 서비스가 5대, 10대로 늘면 로그는 각 서버에 산재하고, 어느 서버에서 오류가 시작됐는지 파악하는 데만 수십 분이 걸렸습니다. AWS가 수백 개의 분산 리소스를 다루는 환경으로 이동하면서, 각 리소스 상태를 중앙에서 수집하고 이상 징후를 즉시 알람으로 연결하는 관측 계층이 필요해졌습니다. CloudWatch는 그 압력에서 나온 결과입니다.

안에서 어떻게 동작하나요?

EC2 인스턴스나 Lambda 같은 AWS 리소스는 CPU 사용률, 오류 수, 지연 시간 같은 메트릭을 CloudWatch로 자동 전송합니다. CloudWatch는 수집한 메트릭을 설정해 둔 임계치와 지속적으로 비교하고, 임계치를 넘는 순간 알람 상태로 전환됩니다. 알람이 트리거되면 연결해 둔 SNS 토픽으로 알림이 전송되거나, Auto Scaling 정책이 실행되어 인스턴스를 추가하는 자동 조치가 이어집니다. 로그 역시 같은 흐름 안에서 CloudWatch Logs로 모이기 때문에, 메트릭과 로그를 나란히 놓고 원인을 추적할 수 있습니다.

무엇과 헷갈리나요?

CloudWatch와 CloudTrail은 둘 다 운영을 돕지만 보는 대상이 다릅니다. CloudWatch는 시스템 상태와 성능 지표를 관측하고, CloudTrail은 누가 어떤 API를 실행했는지 남기는 감사 기록을 다룹니다. 현재 상태를 보고 임계치에 반응해야 하면 CloudWatch를 보고, 변경 행위를 추적해야 하면 CloudTrail을 보면 됩니다.

언제 쓰나요?

CPU 급증, 함수 오류율, 대기열 적체, 지연 시간 악화처럼 운영 상태를 계속 봐야 하는 거의 모든 워크로드에 적합합니다. 관측값을 바탕으로 자동 복구나 후속 조치를 붙이고 싶을 때도 유용합니다. 누가 어떤 API를 호출했는지 같은 행위 감사에는 맞지 않습니다.

인프라 모니터링애플리케이션 로그 분석자동 경보대시보드