<aside>
CloudWave · W05 · 3/5 · 예상 읽기 7분
</aside>
셋째 날의 질문은 “문제가 생겼다는 것을 어떻게 알까?”였다. 모니터링이라는 말을 한 덩어리로 사용하면 수치와 기록과 알림이 섞인다. CloudWatch를 세 가지 신호의 흐름으로 나누자 무엇을 보고 있는지 훨씬 분명해졌다.
Metric은 시간에 따라 수집되는 수치다. 서비스와 리소스마다 namespace가 있고, metric name과 dimension으로 관측 대상을 구분한다. period는 수집 간격을 뜻하므로 짧은 변화와 장기 추세를 같은 방식으로 읽으면 안 된다. 예를 들어 요청 수와 지연 시간은 서로 다른 질문에 답한다.
EC2 메모리처럼 기본 제공되지 않는 항목은 별도 수집 설정이 필요할 수 있다. 따라서 “CloudWatch에 없으니 정상”이라고 단정하지 않고 수집 경로와 권한, 에이전트 설정을 함께 확인해야 한다.
Log는 애플리케이션과 시스템이 남긴 기록이다. 특정 요청의 오류 원인이나 재시작 시점처럼 수치만으로 설명하기 어려운 맥락을 제공한다. 로그 그룹과 보존 기간, 민감 정보 제거를 정해야 하며, 비밀번호나 토큰이 로그에 들어가지 않도록 애플리케이션 단계에서 막는 것이 우선이다.
Alarm은 하나 이상의 metric이 기준을 넘는지 평가하고 알림이나 후속 동작으로 연결한다. alarm 자체가 로그를 대신하지 않으며, metric이 왜 변했는지 설명해 주지도 않는다. 그래서 알람을 만들 때는 신호, 임계값, 평가 기간, 통지 대상, 대응 절차를 함께 적어 둔다.
VPC Peering은 격리된 VPC 사이의 연결을 만들 수 있지만 전이적 라우팅을 자동으로 제공하지 않는다. VPC endpoint는 AWS 서비스나 지원되는 서비스에 사설 경로를 제공하며 gateway와 interface의 동작 방식이 다르다. 연결을 확인할 때는 경로, 보안 그룹, 엔드포인트 정책, DNS, 그리고 실제 요청의 로그를 순서대로 본다.
실습에서는 수집된 신호가 무엇인지 확인하는 데 집중하고, Production에서는 대시보드의 의미, 알람 피로, 보존과 비용, 접근 권한까지 운영 기준으로 확장해야 한다. Local·Dev·QA·Staging은 각자 빠른 검증과 품질 확인의 목적이 있으므로 운영 알람을 그대로 복제하는 방식은 적절하지 않을 수 있다.
장애 대응은 대시보드 하나를 보는 일로 끝나지 않는다. 알람으로 이상을 감지하고, metric으로 범위를 좁히고, log로 사건의 순서를 확인한 뒤, 배포나 네트워크 변경 이력과 대조한다. 이 순서가 문서화되어 있으면 담당자가 바뀌어도 같은 질문을 반복할 수 있다.
Metric은 로그의 요약본이 아니고 log는 alarm이 아니다. 대시보드는 데이터를 저장하는 원천이 아니라 여러 관측값을 보여 주는 화면이다. VPC 연결이 있다고 해서 모든 서비스 요청이 성공하는 것도 아니다.