177. 서버리스 옵저버빌리티 (Serverless Observability) - AWS X-Ray

핵심 인사이트 (3줄 요약)

본질: Function as a Service (FaaS) 환경의 관측은 서버를 보는 일이 아니라, 짧게 생성·삭제되는 실행 단위 사이로 흐르는 요청 컨텍스트를 추적하는 일이다.

가치: AWS X-Ray, CloudWatch 메트릭·로그, OpenTelemetry 계측을 결합하면 콜드 스타트, 다운스트림 지연, 비동기 큐 적체를 하나의 요청 흐름에서 설명할 수 있다.

판단 포인트: 서버리스는 100% 수집보다 경계 지점 계측이 중요하며, 사용자 경로는 지연·오류·스로틀·콜드 스타트, 이벤트 처리 경로는 Iterator Age와 Dead Letter Queue (DLQ) 신호를 우선 관리해야 한다.

Ⅰ. 개요 및 필요성

서버리스 옵저버빌리티 (Serverless Observability)는 서버 프로세스나 호스트 에이전트를 직접 보는 대신, 요청이 API Gateway, Lambda, 큐, 데이터베이스(Database, DB), 외부 서비스 사이를 어떻게 통과하는지 복원하는 관측 방식이다. 전통적 Application Performance Management (APM)는 오래 살아 있는 프로세스에 에이전트를 붙여 메트릭과 트레이스를 수집하지만, FaaS는 실행 환경이 짧게 열렸다 닫히므로 같은 접근이 잘 맞지 않는다.

문제는 서버가 사라진다고 원인까지 사라지는 것은 아니라는 점이다. 사용자는 단지 "응답이 느리다"고 느끼지만 실제 원인은 콜드 스타트, 함수 동시성 한도, 외부 Application Programming Interface (API) 지연, 메시지 큐 적체, 재시도 폭증 중 어디에든 있을 수 있다. 특히 비동기 이벤트 흐름에서는 로그만으로 요청의 인과 관계를 이어 붙이기 어렵다.

┌──────────────────────────────────────────────────────────────┐
│ Serverless trace가 끊어지기 쉬운 지점                         │
├──────────────────────────────────────────────────────────────┤
│ API Gateway -> Lambda A -> SQS Queue -> Lambda B -> DB       │
│                cold start     async gap       downstream call│
│                                                              │
│ 서버는 사라져도 요청 원인은 남으므로 context가 핵심 키가 됨   │
└──────────────────────────────────────────────────────────────┘

AWS X-Ray가 중요한 이유는 이 단절을 "요청 ID를 가진 서비스 맵"으로 바꿔 주기 때문이다. 루트 세그먼트(Segment)와 하위 세그먼트(Subsegment)를 통해 어느 함수의 초기화가 느렸는지, 어느 다운스트림 호출이 병목인지, 비동기 경계에서 컨텍스트가 끊겼는지를 한눈에 볼 수 있다.

📢 섹션 요약 비유: 서버리스 관측은 고정 CCTV를 달아 두는 일이 아니라, 잠깐 열렸다 닫히는 팝업 매장마다 손님의 입장권 번호를 따라 이동 경로를 추적하는 일과 같다.

Ⅱ. 아키텍처 및 핵심 원리

서버리스에서 핵심은 메트릭·로그·트레이스를 각각 따로 보는 것이 아니라, 같은 요청 식별자 아래에서 연결하는 것이다. AWS X-Ray는 API Gateway나 Lambda에서 루트 트레이스를 시작하고, AWS Distro for OpenTelemetry (ADOT) Lambda Layer는 OpenTelemetry 표준 계측을 추가해 벤더 중립적인 수집도 가능하게 한다. CloudWatch Logs에는 구조화 로그를 남기고, Embedded Metric Format (EMF)으로 비즈니스 메트릭을 같이 보낼 수 있다.

아래 그림은 동기 호출과 비동기 경계를 모두 포함한 전형적 구성을 보여준다.

┌─────────────┐   trace header   ┌──────────────────────┐
│ API Gateway │────────────────▶ │ Lambda A             │
└──────┬──────┘                  │ Init / Handler       │
       │                         │ DynamoDB / SQS span  │
       ▼                         └─────────┬────────────┘
  X-Ray Root Segment                        │ message attr
                                            ▼
                                  ┌──────────────────────┐
                                  │ Lambda B             │
                                  │ HTTP / DB subsegment │
                                  └─────────┬────────────┘
                                            ▼
                            X-Ray Service Map + Logs + Metrics

Lambda 관점에서는 두 구간을 분리해 봐야 한다. 첫째는 초기화 구간(Init)으로, 패키지 로딩과 런타임 부팅이 포함된 콜드 스타트 지연이다. 둘째는 핸들러 실행 구간으로, 실제 비즈니스 로직과 외부 호출 시간이 포함된다. 둘을 구분하지 않으면 "함수가 느리다"는 사실만 알 뿐, 코드가 느린지 초기화가 느린지 판단할 수 없다.

신호	답하는 질문	대표 예시
메트릭 (Metrics)	얼마나 자주 느리거나 실패하는가?	`Duration`, `Errors`, `Throttles`, `ConcurrentExecutions`, `IteratorAge`
로그 (Logs)	어떤 입력·상태에서 발생했는가?	`requestId`, `traceId`, `cold_start`, `status_code`
트레이스 (Traces)	어디서 시간이 소비되는가?	segment/subsegment, downstream latency
어노테이션 (Annotations)	어떤 축으로 집계할 것인가?	route, tenant, function name

X-Ray의 어노테이션과 메타데이터 구분도 실무적으로 중요하다. 어노테이션은 저카디널리티(low cardinality) 키-값으로 인덱싱되어 검색과 필터에 적합하고, 메타데이터는 더 상세한 디버그 정보에 적합하지만 검색 효율이 낮다. 즉 집계용 태그와 자세한 페이로드를 한곳에 마구 섞어 넣으면 분석성과 비용이 동시에 나빠진다.

📢 섹션 요약 비유: X-Ray는 단순한 지도 앱이 아니라, 출발 시각·환승 지점·막힌 구간을 함께 기록하는 내비게이션이다. 길이 있다는 사실보다 어디서 막혔는지 보여 줄 때 관측성이 생긴다.

Ⅲ. 비교 및 연결

서버리스 관측 도구를 비교할 때는 "무엇을 더 많이 보여 주는가"보다 "어떤 경계에서 자동화가 되는가"를 봐야 한다. AWS X-Ray는 Lambda, API Gateway, DynamoDB처럼 AWS 네이티브 서비스 연계가 강하고, OpenTelemetry는 멀티벤더·하이브리드 환경에서 일관된 계측 모델을 주는 대신 초기 설계가 더 복잡하다. 전통적 에이전트 기반 APM은 호스트 수준 시야가 좋지만, 서버리스에서는 배포 방식 자체가 다르다.

모델	강점	약점	잘 맞는 경우
AWS X-Ray	AWS 서비스 맵, 빠른 활성화, Lambda 친화적	AWS 종속성, 세밀한 커스텀 분석 한계	AWS 중심 서버리스 운영
OpenTelemetry + ADOT	벤더 중립, 표준 계측, OTLP 확장	초기 설정과 컨텍스트 설계가 복잡	멀티클라우드·하이브리드 환경
에이전트 기반 APM	호스트·프로세스 수준 가시성 우수	서버리스 배포 모델과 부조화	장기 실행 컨테이너·VM 중심 시스템

또한 서버리스에서는 동기 경계와 비동기 경계를 각각 봐야 한다. HTTP 호출은 헤더 전파가 상대적으로 쉽지만, Amazon Simple Queue Service (SQS), EventBridge, Simple Notification Service (SNS) 같은 메시징 경계는 메시지 속성이나 본문에 추적 컨텍스트를 실어야 한다. 그래서 서버리스 옵저버빌리티는 결국 분산 추적(Distributed Tracing)과 메시지 설계를 함께 요구한다.

Site Reliability Engineering (SRE) 관점에서는 이것이 곧 Service Level Indicator (SLI) 설계로 이어진다. 사용자 요청 경로는 P95/P99 지연과 오류율이 중심이고, 비동기 파이프라인은 큐 적체와 재시도율, Dead Letter Queue (DLQ) 건수가 중심이다. 즉 같은 Lambda라도 "사용자 경로"인지 "배치 경로"인지에 따라 봐야 할 신호가 달라진다.

📢 섹션 요약 비유: AWS X-Ray와 OpenTelemetry는 같은 여행을 기록하는 두 종류의 여행 수첩과 같다. 하나는 국내 교통망에 최적화된 수첩이고, 다른 하나는 나라가 바뀌어도 같은 형식으로 적을 수 있는 국제 표준 수첩이다.

Ⅳ. 실무 적용 및 기술사 판단

실무에서는 모든 호출을 다 기록하는 것보다, 비용 대비 가치가 높은 경계를 선별해 계측하는 편이 좋다. 사용자 응답을 직접 좌우하는 Lambda는 액티브 트레이싱과 세밀한 지연 분석이 필요하지만, 초고빈도 배치 함수는 100% 샘플링이 오히려 비용 폭증을 부를 수 있다. 따라서 샘플링, 컨텍스트 전파, 구조화 로그 규칙을 시나리오별로 달리 두는 것이 현실적이다.

운영 상황	권장 설정	이유
사용자 요청 경로 Lambda	Active Tracing + Provisioned Concurrency + 오류 우선 샘플링	콜드 스타트와 다운스트림 지연이 체감 품질에 직접 영향
SQS/EventBridge 소비자 Lambda	메시지 속성에 trace context 포함, `IteratorAge`·DLQ 알람	큐 내부 지연은 로그만으로 잘 드러나지 않음
초고빈도 배치/ETL 함수	낮은 샘플링 + EMF 비즈니스 메트릭	비용 통제와 추세 파악 균형
멀티클라우드 또는 컨테이너 혼합	OpenTelemetry 중심 계측	서버리스와 비서버리스 간 일관된 추적 모델

체크리스트

API Gateway, SQS, SNS, EventBridge 등 경계마다 trace context 전파 방식이 정의되어 있는가?
JSON 로그에 traceId, requestId, cold_start, tenant, operation 같은 핵심 필드가 포함되는가?
운영 환경 샘플링 규칙이 정상 트래픽과 오류 트래픽을 다르게 다루는가?
Duration 평균값뿐 아니라 P99, Throttles, IteratorAge, 다운스트림 5xx가 함께 알람에 묶여 있는가?

안티패턴

고트래픽 경로에 100% 트레이싱을 걸어 비용을 제어하지 못하는 경우
비동기 메시지에 컨텍스트를 싣지 않아 서비스 맵이 중간에서 끊기는 경우
평균 지연만 보고 tail latency 악화를 놓치는 경우
추적 메타데이터나 로그에 개인정보나 토큰을 그대로 남기는 경우

운영 팁도 중요하다. 예를 들어 오류가 난 트레이스는 100% 보존하고, 정상 요청은 5~10% 수준으로 샘플링하는 식의 차등 정책이 흔히 쓰인다. 또 cold_start=true 같은 플래그를 첫 호출에만 태깅해 두면, 느린 요청이 초기화 비용인지 핸들러 문제인지 빠르게 나눌 수 있다.

📢 섹션 요약 비유: 서버리스 운영은 모든 거리를 24시간 생중계하는 것보다, 사고가 자주 나는 교차로와 출퇴근 시간대에 카메라를 더 촘촘히 두는 도시 교통관제와 비슷하다.

Ⅴ. 기대효과 및 결론

서버리스 옵저버빌리티가 잘 갖춰지면 "Lambda가 느리다"는 막연한 표현이 "콜드 스타트 320ms + 외부 API 1.8초 + SQS 재시도 3회"처럼 행동 가능한 문장으로 바뀐다. 이는 장애 복구 시간을 줄일 뿐 아니라, 어떤 함수에는 Provisioned Concurrency가 필요한지, 어떤 구간은 구조를 비동기로 바꿔야 하는지까지 판단하게 해 준다.

한계도 분명하다. 샘플링된 트레이스만으로는 모든 요청을 재현할 수 없고, 서버리스 특성상 호스트 내부 프로파일링이나 eBPF 기반 세밀한 관측이 제한될 수 있다. AWS X-Ray만 쓰면 벤더 종속성이 커질 수 있으며, 반대로 OpenTelemetry만 고집하면 초기에 복잡도가 올라간다. 결국 관측 체계는 기술 선택보다도 요청 경로와 이벤트 경계를 얼마나 의식적으로 설계했는가에 좌우된다.

결론적으로 서버리스 옵저버빌리티는 서버 시대의 APM을 그대로 옮겨 심는 일이 아니다. 기억해야 할 핵심은 트레이스 우선 설계, 구조화 로그, 큐 지연 메트릭을 함께 묶어 요청의 인과 관계를 복원하는 것이다.

📢 섹션 요약 비유: 좋은 서버리스 관측 체계는 반딧불이 수천 마리를 한 번에 보는 야간 관찰 장비와 같다. 개별 빛은 짧지만, 이동 경로를 이어 보면 생태계 전체가 보인다.

📌 관련 개념 맵

개념	연결 포인트
AWS X-Ray	서버리스 요청 흐름을 Segment/Subsegment로 시각화하는 AWS 네이티브 분산 추적 서비스
OpenTelemetry	서버리스와 컨테이너를 아우르는 벤더 중립 계측 표준
Provisioned Concurrency	콜드 스타트 민감 경로의 초기화 지연을 줄이는 실행 환경 예열 전략
Iterator Age	스트림·큐 소비 지연을 보여 주는 서버리스 비동기 SLI
EMF (Embedded Metric Format)	로그에서 비즈니스 메트릭을 함께 추출하는 CloudWatch 방식
DLQ (Dead Letter Queue)	반복 실패 이벤트를 격리해 원인 분석과 재처리를 돕는 안전장치

📈 관련 키워드 및 발전 흐름도

호스트 에이전트 중심 모니터링
    │
    ▼
CloudWatch Metrics / Logs
    │
    ▼
AWS X-Ray 기반 분산 추적
    │
    ▼
OpenTelemetry + Async Context Propagation
    │
    ▼
SLO 기반 Serverless Operations

이 흐름은 "서버 상태 관찰"에서 "이벤트와 요청의 경로 복원"으로 관측 중심축이 이동하는 과정을 보여준다.

👶 어린이를 위한 3줄 비유 설명

서버리스 함수는 잠깐 열렸다 닫히는 작은 가게라서, 가게 안에 카메라를 오래 설치해 둘 수 없어요.
그래서 손님 표에 번호를 붙여서 어느 가게를 거쳤는지 계속 따라가야 해요.
AWS X-Ray는 그 번호들을 이어서 어디서 오래 기다렸는지 지도로 보여 줘요.