이전 글이 CloudWatch와 X-Ray로 로그와 메트릭을 "읽는" 방법을 다뤘다면, 이 글은 코드 안에 관찰 가능성을 직접 "심는" 방법을 다룹니다. 문제가 생겼을 때 빠르게 원인을 찾을 수 있도록, 미리 측정 포인트를 코드에 삽입하는 것을 계측(Instrumentation)이라고 합니다.
X-Ray 코드 계측
계측이란 코드 실행 중 데이터를 수집할 수 있도록 코드에 측정 지점을 삽입하는 것입니다.
Annotations
Annotations는 X-Ray 추적 데이터에 검색 가능한 키-값 쌍을 추가합니다.
예: user_id="abc123"을 Annotation으로 추가하면, 나중에 X-Ray에서 "이 사용자의 모든 요청을 보여줘"라고 검색할 수 있습니다.
쉽게 말하면 도서관 책에 색인 카드를 만드는 것과 같습니다. 키워드로 빠르게 찾을 수 있게 되죠.
중요한 점: Metadata는 Annotations와 다릅니다. Metadata는 인덱싱되지 않아 검색이 불가능합니다. 참고용 보조 정보에만 사용합니다. 시험에서 이 차이를 자주 물어봅니다.
Subsegments
Subsegments는 하나의 서비스 안에서 개별 작업별로 걸린 시간을 측정합니다.
Lambda 함수 안에서 예를 들면: DynamoDB 쿼리: 50ms S3 업로드: 200ms 외부 API 호출: 500ms
각 작업을 서브세그먼트로 기록하면, 어디서 시간이 소모되는지 정확히 파악할 수 있습니다.
구조화된 로깅
로그를 일반 텍스트 대신 JSON 형식으로 출력하는 방법입니다.
일반 로그: ERROR: DB connection failed
구조화된 로그: {"level":"ERROR","message":"DB connection failed","requestId":"abc-123","userId":"user-456"}
구조화된 로깅의 장점: CloudWatch Logs Insights에서 특정 필드로 검색 가능 오류 통계와 패턴 분석이 쉬워짐 표준화된 형식으로 자동 처리 가능
커스텀 메트릭
AWS가 기본으로 제공하는 메트릭 외에도, 비즈니스에 맞는 측정값을 직접 CloudWatch로 전송할 수 있습니다.
예: 주문 처리 시간, 장바구니 이탈률, 로그인 성공/실패 비율
전송 방법: PutMetricData API: 메트릭 값을 CloudWatch에 직접 API로 전송 EMF(Embedded Metric Format): 구조화된 로그를 출력하면 메트릭이 자동으로 추출됨
헬스 체크
서비스가 정상 동작하는지 주기적으로 확인하는 것입니다. 쉽게 말하면 사람의 맥박을 재는 것과 같습니다.
ELB 헬스 체크: 로드 밸런서가 각 서버의 /health 주소로 주기적으로 신호를 보냅니다. 응답이 없으면 트래픽 전송을 중단합니다. ECS 헬스 체크: 컨테이너 안의 HEALTHCHECK 명령어로 확인합니다. 실패하면 자동으로 재시작합니다. Route 53 헬스 체크: 엔드포인트를 모니터링합니다. 장애가 감지되면 Failover 라우팅으로 트래픽을 다른 곳으로 전환합니다.
알림 구성
CloudWatch Alarms → SNS 토픽 → 이메일, SMS 또는 Lambda EventBridge 규칙 → 특정 이벤트(배포 완료, 할당량 초과) 발생 시 알림
시험 핵심 정리
"X-Ray에서 특정 사용자 요청 검색" -- Annotations (인덱싱됨)
"X-Ray에서 DB 쿼리/HTTP 호출 시간 측정" -- Subsegments
"JSON 형식 로그, 필드별 검색 가능" -- 구조화된 로깅
"애플리케이션 고유 메트릭 전송" -- PutMetricData 또는 EMF
"인스턴스가 정상인지 주기적 확인" -- ELB 헬스 체크
"컨테이너 상태 확인" -- ECS HEALTHCHECK
"배포 완료 알림" -- EventBridge + SNS
Annotations = 검색 가능 (인덱싱됨), Metadata = 검색 불가