모놀리식 애플리케이션에서 "왜 느린가"는 프로파일러 하나로 답할 수 있었다. 한 프로세스 안에서 함수 호출 스택을 따라 내려가며 어느 함수가 시간을 잡아먹는지 보면 됐다. 그런데 요청 하나가 API Gateway → Lambda → DynamoDB → 외부 API → ElastiCache를 거치는 마이크로서비스 구조에서는 이 방법이 통하지 않는다. 각 서비스는 자기 안에서만 일어난 일을 알 뿐, 요청 전체가 어디서 시간을 흘렸는지는 아무도 갖고 있지 않다. 로그를 다 모아도 "이 요청"에 속한 로그들을 어떻게 묶을지부터 막힌다. AWS X-Ray는 바로 이 "분산된 요청을 하나로 꿰는" 문제를 푸는 분산 추적(distributed tracing) 서비스다.
DVA-C02 시험에서 X-Ray는 "지표는 무엇이 느린지 알려주지만 어디서 느린지는 못 알려준다"는 한계의 답으로 등장한다. Lambda에서는 토글 하나, EC2/ECS에서는 데몬 설치라는 활성화 방식의 차이, Annotation과 Metadata의 인덱싱 차이, 샘플링의 작동 원리가 단골 출제 포인트다. 이번 글은 분산 추적이라는 분야가 어디서 왔는지(Google Dapper), Trace ID가 어떻게 서비스 경계를 넘어 전파되는지, 그리고 왜 X-Ray가 "모든 요청을 추적하지 않는가"를 깊이 들여다본다.
X-Ray의 개념은 AWS의 발명이 아니다