멀티테넌트 SaaS 플랫폼을 위한 엔드‑투‑엔드 인그레스 요청 추적 설계

출처: CNCF Blog

2026년 5월 22일 게시   작성자: Mridula Chilakamarri, CNCF 기술 자문 그룹

현대의 클라우드‑네이티브 아키텍처 위에 구축된 SaaS 플랫폼은 수십 개의 독립적으로 배포된 마이크로서비스로 구성되는 경우가 많습니다. 인그레스 레이어에 들어오는 단일 고객 요청은 인증 서비스, 오케스트레이션 엔진, 데이터 서비스, 그리고 하위 통합 서비스를 거쳐 최종적으로 완료됩니다. 장애나 성능 저하가 발생하면, 플랫폼 운영자는 근본적인 질문에 답해야 합니다: 이 특정 요청에 무슨 일이 일어났으며, 어디서 일어났는가?

많은 환경에서 이 질문에 답하기는 여전히 어렵습니다. 서비스들은 로그와 메트릭을 내보내지만, 이 신호들은 서로 연결되어 있지 않습니다. 텔레메트리는 각 서비스가 공유 요청 컨텍스트 없이 독립적으로 생성되기 때문에, 장애, 재시도, 지연 스파이크 등을 엔드‑투‑엔드 스토리로 연결하기가 어렵습니다.

이 글에서는 멀티‑테넌트 SaaS 플랫폼에서 인그레스 요청 추적을 설계하기 위한 제품‑주도 프레임워크를 소개합니다. 구현 코드는 다루지 않고 설계 원칙과 관측 가능한 시스템 동작에 초점을 맞춥니다. 이 프레임워크는 OpenTelemetry와 W3C Trace Context와 같은 산업 표준을 기반으로 하며, Kubernetes 기반 환경에 적용할 수 있습니다.

관측성 문제

엔드‑투‑엔드 트레이싱이 없으면 인그레스 요청이 하위 서비스들을 통과할 때 신뢰성 있게 추적할 수 없습니다. 장애는 고립된 이벤트로 나타나고, 지연 회귀는 집계 메트릭에서만 확인됩니다. 다중 서비스 워크플로와 간헐적인 문제는 특히 진단이 어렵습니다.

운영 팀은 타임스탬프, 휴리스틱, 부분 식별자를 이용해 로그를 수동으로 연관시키는 방식으로 보완합니다. 이 방법은 서비스가 늘어날수록 확장되지 않으며, 사고 대응 시 진단 속도가 느려지고 인지 부하가 증가하며, 근본 원인 분석에 대한 신뢰도가 떨어집니다.

핵심 과제는 텔레메트리 부족이 아니라, 모든 작업을 하나로 묶는 일관된 요청‑레벨 컨텍스트가 없다는 점입니다.

인그레스 요청 추적을 위한 제품‑주도 프레임워크

이 프레임워크는 분산 트레이싱을 서비스‑레벨 구현 선택이 아닌 플랫폼 수준의 일급 기능으로 취급합니다. 핵심은 두 개의 보완적인 식별자입니다: 단일 고객 요청의 모든 작업을 그룹화하는 Trace ID와, 그 트레이스 내에서 개별 작업(예: 서비스 호출 또는 DB 쿼리)을 식별하는 Span ID.

모든 인그레스 요청은 반드시 연관된 Trace ID를 가져야 합니다. 들어오는 요청에 Trace ID가 없으면 인그레스 레이어가 새로 생성합니다. 유효한 Trace ID가 이미 존재하면 그대로 보존합니다.

1. Trace ID 및 Span ID 생성 및 보존

요청을 처리하는 각 서비스는 자체 Span을 생성하고 해당 작업에 고유한 Span ID를 할당합니다. 서비스가 하위 호출을 할 때는 변경되지 않은 Trace ID와 자신의 Span ID(다음 서비스의 부모 Span ID가 됨)를 함께 전달합니다. 이를 통해 관측성 플랫폼은 모든 작업의 정확한 순서와 계층 구조를 재구성할 수 있습니다.

이 “생성‑또는‑보존” 규칙은 상위 시스템과의 상호 운용성을 보장하면서 플랫폼 내에서 트레이스 연속성을 유지합니다. Trace ID와 현재 Span ID는 요청 컨텍스트에 붙어 응답 헤더에도 포함되어, 조사 시 결정적인 조회 키로 활용됩니다.

그림 1: 엔드‑투‑엔드 Trace ID 및 Span ID 전파

위 다이어그램에서 단일 Trace ID가 모든 서비스(인증, 오케스트레이션, 데이터 레이어)를 거치며 변하지 않고 흐르고, 이는 고객의 전체 요청을 나타냅니다. 각 서비스는 자체 Span ID를 생성하고, Service A가 Service B를 호출할 때 Trace ID와 자신의 Span ID를 전달합니다( Service B는 이를 부모 Span ID로 기록). 이 계층 구조를 통해 운영자는 단순히 요청이 실패했음을 넘어, 정확히 어느 서비스의 어느 단계에서 문제가 발생했는지를 파악할 수 있습니다.

2. 일관된 컨텍스트 전파

동기식 서비스‑간 호출은 동일한 Trace ID를 재사용합니다. 각 서비스는 자체 작업을 위해 새로운 Span ID를 생성합니다. 재시도 작업은 원본 Trace ID를 보존하지만, 재시도 시도마다 추가 Span ID를 생성해 원본 호출과 후속 시도를 구분하면서도 동일 트레이스 아래에 그룹화합니다.

비동기 처리에서는 워크플로가 진화하더라도 관측성 공백이 발생하지 않도록 메시지 메타데이터를 통해 Trace ID와 부모 Span ID를 전파합니다.

3. 보안‑우선 Trace 메타데이터

Trace 데이터는 운영 메타데이터에 한정합니다: Trace ID, Span ID, 부모 Span ID, 서비스명, 작업명, 타임스탬프, 지속시간, 실행 상태.

요청 페이로드, 자격 증명, 비밀키, 토큰, 개인 식별 정보(PII)는 설계상 명시적으로 제외됩니다. 데이터 제외를 설계 제약으로 삼음으로써 보안 검토가 간소화되고 장기적인 컴플라이언스 위험이 감소합니다.

4. 설정‑전용 텔레메트리 내보내기

Trace 내보내기는 전적으로 Kubernetes 설정을 통해 관리됩니다. 운영자는 애플리케이션 코드를 변경하지 않고도 익스포터, 인증 정보, 라우팅 파라미터 등을 구성할 수 있습니다.

이 방식은 트레이싱 작업을 릴리스 사이클과 분리하고, 기존 SRE 워크플로를 활용해 관측성을 진화시킬 수 있게 합니다.

5. 비방해형 장애 모드

트레이싱은 절대 요청 처리를 차단해서는 안 됩니다. 텔레메트리 백엔드가 사용 불가능하거나 잘못 구성된 경우에도 요청은 정상적으로 완료됩니다. Trace 데이터는 버퍼링되거나 손실될 수 있지만, 고객 경험에는 영향을 주지 않습니다.

부분적인 트레이스는 허용됩니다. 실패한 요청은 허용되지 않습니다.

실행 가능한 계약으로서의 수용 기준

명확한 수용 기준은 구현 세부 사항이 아닌 관측 가능한 시스템 결과를 정의합니다. 이 프레임워크에서는 수용 기준이 제품 관리와 엔지니어링 사이의 실행 가능한 계약 역할을 합니다. 각 기준은 특정 요구 사항에 매핑되며 독립적으로 테스트할 수 있습니다.