추적 컨텍스트 레벨 2

분산 추적은 추적 도구가 여러 소프트웨어 구성 요소에 걸친 트랜잭션을 따라가고, 분석하며, 디버깅하기 위해 구현하는 방법론이다. 일반적으로 분산 추적은 둘 이상의 구성 요소를 통과하므로, 참여하는 모든 시스템에서 고유하게 식별될 수 있어야 한다. 추적 컨텍스트 전파는 이러한 고유 식별 정보를 함께 전달한다. 오늘날 추적 컨텍스트 전파는 각 추적 벤더가 개별적으로 구현한다. 다중 벤더 환경에서는 이로 인해 다음과 같은 상호 운용성 문제가 발생한다.

• 공유되는 고유 식별자가 없기 때문에 서로 다른 추적 벤더가 수집한 추적을 서로 연관시킬 수 없다.
• 전달되는 식별 정보 집합에 대해 일관되게 합의된 것이 없기 때문에, 서로 다른 추적 벤더 간 경계를 넘는 추적을 전파할 수 없다.
• 벤더별 메타데이터가 중개자에 의해 삭제될 수 있다.
• 따라야 할 표준이 없기 때문에 클라우드 플랫폼 벤더, 중개자, 서비스 제공자는 추적 컨텍스트 전파 지원을 보장할 수 없다.

과거에는 대부분의 애플리케이션이 단일 추적 벤더에 의해 모니터링되고 단일 플랫폼 제공자의 경계 안에 머물렀기 때문에 이러한 문제는 큰 영향을 미치지 않았다. 오늘날에는 점점 더 많은 애플리케이션이 고도로 분산되고, 여러 미들웨어 서비스와 클라우드 플랫폼을 활용한다.

이러한 현대 애플리케이션의 변화는 분산 추적 컨텍스트 전파 표준을 필요로 한다.

추적 컨텍스트 명세는 추적 컨텍스트 전파 데이터의 교환을 위해 보편적으로 합의된 형식을 정의하며, 이를 추적 컨텍스트라고 부른다. 추적 컨텍스트는 위에서 설명한 문제를 다음과 같이 해결한다.

• 개별 추적과 요청에 대한 고유 식별자를 제공하여 여러 제공자의 추적 데이터를 서로 연결할 수 있게 한다.
• 벤더별 추적 데이터를 전달하고, 여러 추적 도구가 단일 트랜잭션에 참여할 때 끊어진 추적을 방지하기 위한 합의된 메커니즘을 제공한다.
• 중개자, 플랫폼, 하드웨어 제공자가 지원할 수 있는 업계 표준을 제공한다.

추적 데이터를 전파하기 위한 통합된 접근 방식은 분산 애플리케이션의 동작에 대한 가시성을 향상시켜 문제 및 성능 분석을 쉽게 한다. 추적 컨텍스트가 제공하는 상호 운용성은 현대의 마이크로서비스 기반 애플리케이션을 관리하기 위한 전제 조건이다.

현재 버전의 Trace Context 명세는 브라우저 안에서 실행되는 웹 애플리케이션을 포함하여 애플리케이션과 서비스에 의한 구현을 대상으로 한다. 웹 브라우저 또는 사용자 에이전트는 현재 대상 구현 범위에 포함되지 않는다.

추적 컨텍스트는 상호 운용성과 벤더별 확장성을 지원하는 두 개의 개별 전파 필드로 나뉜다.

• traceparent는 들어오는 요청의 추적 그래프상 위치를 이식 가능한 고정 길이 형식으로 설명한다. 그 설계는 빠른 파싱에 초점을 둔다. 모든 추적 도구는 tracestate의 벤더별 정보에만 의존하는 경우에도 traceparent를 올바르게 설정해야 MUST 한다.
• tracestate는 이름/값 쌍의 집합으로 표현되는 벤더별 데이터로 traceparent를 확장한다. tracestate에 정보를 저장하는 것은 선택 사항이다.

추적 도구는 추적 컨텍스트와 상호 작용할 때 두 가지 수준의 준수 동작을 제공할 수 있다.

• 최소한 traceparent와 tracestate 헤더를 전파하고 추적이 끊어지지 않도록 보장해야 MUST 한다. 이 동작은 추적을 전달한다고도 한다.
• 또한 traceparent 헤더와 독점 정보를 포함하는 tracestate 헤더의 관련 부분을 수정하여 추적에 참여하도록 선택할 수도 MAY 있다. 이것도 추적에 참여한다고 한다.

추적 도구는 자신이 모니터링하는 구성 요소에 대한 각 개별 요청마다 이 동작을 변경하도록 선택할 수 있다.

traceparent 요청 헤더는 모든 벤더가 이해하는 공통 형식으로, 추적 시스템 안의 들어오는 요청을 나타낸다. 다음은 traceparent 헤더의 예이다.

traceparent: 00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01

tracestate 요청 헤더는 잠재적으로 벤더별 형식으로 부모를 포함한다.

tracestate: congo=t61rcWkgMzE

예를 들어, 한 시스템의 클라이언트와 서버가 서로 다른 추적 벤더인 Congo와 Rojo를 사용한다고 하자. Congo 시스템에서 추적되는 클라이언트는 나가는 HTTP 요청에 다음 헤더를 추가한다.

traceparent: 00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01
tracestate: congo=t61rcWkgMzE

참고: 이 경우 tracestate 값 t61rcWkgMzE는 부모 ID(b7ad6b7169203331)를 Base64로 인코딩한 결과이지만, 이러한 조작이 필수인 것은 아니다.

Rojo 추적 시스템에서 추적되는 수신 서버는 자신이 받은 tracestate를 이어받고 왼쪽에 새 항목을 추가한다.

traceparent: 00-0af7651916cd43dd8448eb211c80319c-00f067aa0ba902b7-01
tracestate: rojo=00f067aa0ba902b7,congo=t61rcWkgMzE

Rojo 시스템이 자신의 tracestate 항목에 traceparent의 값을 재사용한다는 점을 알 수 있다. 이는 해당 시스템이 일반 추적 시스템임을 의미한다(독점 정보가 전달되지 않는다). 그 밖의 경우 tracestate 항목은 불투명하며 벤더별일 수 있다.

다음 수신 서버가 Congo를 사용한다면, Rojo로부터의 tracestate를 이어받고 이전 항목의 왼쪽에 부모에 대한 새 항목을 추가한다.

traceparent: 00-0af7651916cd43dd8448eb211c80319c-b9c7c989f97918e1-01
tracestate: congo=ucfJifl5GOE,rojo=00f067aa0ba902b7

참고: ucfJifl5GOE는 부모 ID b9c7c989f97918e1를 Base64로 인코딩한 것이다.

Congo가 자신의 traceparent 항목을 쓸 때 그것은 인코딩되지 않았으며, 이는 상관관계를 수행하는 사람들에게 일관성을 제공하는 데 도움이 된다. 그러나 그 tracestate 항목의 값은 인코딩되어 있으며 traceparent와 다르다. 이는 괜찮다.

마지막으로, tracestate는 오른쪽으로 밀린 것을 제외하면 Rojo에 대한 항목을 정확히 그대로 유지한다. 가장 왼쪽 위치는 다음 서버가 어떤 추적 시스템이 traceparent에 대응하는지 알 수 있게 한다. 이 경우 Congo가 traceparent를 썼으므로, 그 tracestate 항목은 가장 왼쪽에 있어야 한다.

traceparent HTTP 헤더 필드는 추적 시스템 안의 들어오는 요청을 식별한다. 이는 네 개의 필드를 가진다.

• version
• trace-id
• parent-id
• trace-flags

HEXDIGLC = DIGIT / "a" / "b" / "c" / "d" / "e" / "f" ; lowercase hex character
value           = version "-" version-format

version         = 2HEXDIGLC   ; this document assumes version 00. Version ff is forbidden

version-format   = trace-id "-" parent-id "-" trace-flags
trace-id         = 32HEXDIGLC  ; 16 bytes array identifier. All zeroes forbidden
parent-id        = 16HEXDIGLC  ; 8 bytes array identifier. All zeroes forbidden
trace-flags      = 2HEXDIGLC   ; 8 bit flags.

static final byte FLAG_SAMPLED = 1; // 00000001
static final byte FLAG_RANDOM = 2; // 00000010
...
boolean sampled = (traceFlags & FLAG_SAMPLED) == FLAG_SAMPLED;
boolean random = (traceFlags & FLAG_RANDOM) == FLAG_RANDOM;

Value = 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
base16(version) = 00
base16(trace-id) = 4bf92f3577b34da6a3ce929d0e0e4736
base16(parent-id) = 00f067aa0ba902b7
base16(trace-flags) = 01  // sampled

Value = 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-00
base16(version) = 00
base16(trace-id) = 4bf92f3577b34da6a3ce929d0e0e4736
base16(parent-id) = 00f067aa0ba902b7
base16(trace-flags) = 00  // not sampled

tracestate HTTP 헤더의 주된 목적은 서로 다른 분산 추적 시스템 사이에서 추가적인 벤더별 추적 식별 정보를 제공하는 것이며, 이는 traceparent 필드의 동반 헤더이다. 또한 여러 분산 추적 그래프 안에서 요청의 위치에 대한 정보를 전달한다.

벤더가 traceparent를 파싱하지 못한 경우, tracestate를 파싱하려고 시도해서는 안 된다 MUST NOT. 반대는 참이 아니라는 점에 유의하라. 즉, tracestate 파싱 실패는 traceparent 파싱에 영향을 주어서는 안 된다 MUST NOT.

tracestate HTTP 헤더는 추적 시스템에 의해 정의되지 않은 어떠한 속성에도 사용되어서는 안 된다 MUST NOT. [BAGGAGE]는 이러한 애플리케이션 수준 속성을 정의하고 전파하는 데 사용될 수 MAY 있다.

list  = list-member 0*31( OWS "," OWS list-member )
list-member = (key "=" value) / OWS

key = ( lcalpha / DIGIT ) 0*255 ( keychar )
keychar    = lcalpha / DIGIT / "_" / "-"/ "*" / "/" / "@"
lcalpha    = %x61-7A ; a-z

value    = 0*255(chr) nblk-chr
nblk-chr = %x21-2B / %x2D-3C / %x3E-7E
chr      = %x20 / nblk-chr

tracestate: rojo=00f067aa0ba902b7

tracestate: rojo=00f067aa0ba902b7,congo=t61rcWkgMzE

traceparent 헤더가 없는 요청을 수신한 벤더는 발신 요청에 대해 traceparent 헤더를 생성하여 사실상 새 추적을 시작해야 SHOULD 한다. 이를 하지 않을 수 있는 가능한 이유는 벤더가 요청을 샘플링하지 않기로 결정한 성능 민감 시나리오일 수 있다. 대부분의 시나리오에서는 벤더가 샘플링하지 않는 경우에도 샘플링 결정을 하위로 전파하기 위해 헤더를 생성할 것으로 기대된다는 점에 유의하라.

traceparent 요청 헤더를 수신한 벤더는 이를 나가는 요청으로 보내야 MUST 한다. 벤더는 이를 나가는 요청으로 전달하기 전에 이 헤더의 값을 변경할 수 MAY 있다.

전파 전에 traceparent 필드의 값이 변경되지 않았다면, tracestate도 변경되어서는 안 된다 MUST NOT. 변경되지 않은 헤더 전파는 일반적으로 프록시 같은 통과 서비스에서 구현된다. 이 동작은 현재 분산 추적 정보를 수집하지 않는 서비스에서도 구현될 수 있다.

다음은 허용되는 변경 목록이다.

• parent-id 갱신: parent-id 필드의 값은 현재 작업의 ID를 나타내는 새 값으로 설정될 수 있다. 이는 가장 일반적인 변경이며 기본값으로 간주되어야 한다.
• sampled 갱신: sampled 필드의 값은 호출자의 기록 동작을 반영한다. 즉, 추적 데이터가 삭제되었거나 대역 외로 기록되었을 수 있음을 나타낸다. 이는 플래그를 양방향으로 토글하여 표시할 수 있다. 이 변경은 하위 벤더에게 부모의 정보가 기록되었을 가능성에 대한 정보를 제공한다. sampled 플래그 갱신과 함께 parent-id 필드는 새 값으로 설정되어야 MUST 한다.
• 추적 다시 시작: 모든 속성(trace-id, parent-id, trace-flags)이 다시 생성된다. 이 변경은 보안 네트워크로 들어가는 프런트 게이트로 정의된 서비스에서 사용되며, 잠재적인 서비스 거부 공격 표면을 제거한다. 벤더는 traceparent 재시작 시 tracestate 컬렉션을 정리해야 SHOULD 한다. 재시작 후에도 원래 tracestate 항목을 보존해야 하는 드문 경우가 있다. 이는 보통 추적 흐름의 어느 시점에서 trace-id가 다시 원래대로 되돌려질 때, 예를 들어 보안 네트워크를 떠날 때 발생한다. 그러나 이는 명시적인 결정이어야 SHOULD 하며, 기본 동작이어서는 안 된다.
• 버전 다운그레이드: 이 명세의 이 버전(00)은 더 높은 버전의 traceparent 헤더를 수신한 벤더의 동작을 정의한다. 이 경우 첫 번째 변경은 헤더의 버전을 다운그레이드하는 것이다. 다른 변경은 이 변경과 조합하여 허용된다.

벤더는 traceparent 헤더에 대해 어떠한 다른 변경도 해서는 안 된다 MUST NOT.

tracestate 요청 헤더를 수신한 벤더는 이를 나가는 요청으로 보내야 MUST 한다. 벤더는 이를 나가는 요청으로 전달하기 전에 이 헤더의 값을 변경할 수 MAY 있다. tracestate를 변경할 때, 변경되지 않은 키/값 쌍의 순서는 보존되어야 MUST 한다. 변경된 키는 목록의 시작(왼쪽)으로 이동되어야 MUST 한다.

다음은 허용되는 변경이다.

• 새 키/값 쌍 추가. 새 키/값 쌍은 목록의 시작에 추가되어야 SHOULD 한다. 키/값 쌍을 추가해도 같은 키가 여러 번 존재해서는 안 된다 MUST NOT.
• 기존 값 갱신. 주어진 키의 값은 갱신될 수 있다. 변경된 키는 목록의 시작(왼쪽)으로 이동되어야 SHOULD 한다.
• 키/값 쌍 삭제. 모든 키/값 쌍은 삭제될 수 MAY 있다. 벤더는 자신이 생성하지 않은 키를 삭제해서는 안 된다 SHOULD NOT. 알 수 없는 키/값 쌍의 삭제는 다른 시스템에서 상관관계를 깨뜨릴 수 있다. 이 변경은 세 가지 시나리오를 가능하게 한다. 첫 번째는 프록시가 개인정보 보호 및 보안 우려로 특정 tracestate 키를 차단할 수 있다는 것이다. 두 번째 시나리오는 긴 tracestate의 자르기이다. 마지막으로, 벤더는 자신이 생성하지 않은 중복 키를 폐기할 수도 MAY 있다.

traceparent 필드는 어떠한 개인 식별 가능 정보도 포함해서는 안 된다 MUST NOT. 이를 달성하는 한 가지 방법은 개인 식별 가능 정보를 노출하지 않는 난수 생성기를 사용하여 모든 추적 ID를 무작위로 생성하는 것이다. 추적 ID를 생성하는 데 사용되는 모든 난수 생성기는 잠재적으로 개인 식별 가능할 수 있는 어떠한 정보도 입력이나 시드 상태로 의존해서는 안 된다 MUST NOT.

traceparent 필드의 또 다른 개인정보 보호 위험은 단일 트랜잭션의 일부로 수행된 요청들을 서로 연관시킬 수 있는 능력이다. 하위 서비스는 단일 트랜잭션에서 이루어진 둘 이상의 요청을 추적하고 연관시킬 수 있으며, 다른 요청의 정보를 바탕으로 요청 호출자의 신원에 대해 가정할 수 있다.

traceparent 필드의 이러한 개인정보 보호 우려는 실제적이라기보다 이론적이라는 점에 유의하라. 요청을 시작하거나 수신하는 일부 서비스는 이러한 위험을 완전히 제거하기 위해 traceparent 필드를 다시 시작하도록 선택할 수 MAY 있다. 벤더는 추적 벤더의 상호 운용성을 촉진하기 위해 분산 추적 재시작 횟수를 최소화할 방법을 찾아야 SHOULD 한다. 재시작 대신 다른 기법이 사용될 수 있다. 예를 들어 서비스는 상류 및 하류 연결의 신뢰 경계와, 어떤 요청이 가져올 수 있는 노출 수준을 정의할 수 있다. 예컨대 벤더는 외부 서비스로부터 또는 외부 서비스로 가는 인증 요청에 대해서만 traceparent를 다시 시작할 수 있다.

서비스는 traceparent 필드의 들어오는 또는 나가는 난수의 무작위성을 검증하기 위한 알고리즘과 감사 메커니즘을 정의할 수도 있다. 이 알고리즘은 서비스별이며 이 명세의 일부가 아니라는 점에 유의하라. 한 예로 현재 시계 시간에 가역 해시 함수를 적용하는 시간 기반 알고리즘이 있을 수 있다. 수신자는 시간이 합의된 경계 안에 있음을 검증할 수 있으며, 이는 난수가 요구되는 알고리즘으로 생성되었고 실제로 어떠한 개인 식별 가능 정보도 포함하지 않는다는 것을 의미한다.

tracestate 필드는 어떤 키에서도 임의의 불투명 값을 포함할 수 있다. 이 헤더의 주된 목적은 서로 다른 분산 추적 시스템 사이에서 추가적인 벤더별 추적 식별 정보를 제공하는 것이다.

벤더는 tracestate 헤더에 어떠한 개인 식별 가능 정보도 포함해서는 안 된다 MUST NOT.

개인 정보 노출에 극도로 민감한 벤더는 알 수 없는 키에 대응하는 값의 선택적 제거를 구현할 수 MAY 있다. 벤더는 여러 추적 시스템이 협력하도록 허용하는 목적을 무력화하므로 tracestate 필드를 변경해서는 안 된다 SHOULD NOT.

벤더가 응답에 traceparent와 tracestate 헤더를 포함하면, 이러한 값이 의도치 않게 교차 출처 호출자에게 전달될 수 있다. 벤더는 추적에 참여한 시스템에 응답할 때만 이러한 응답 헤더를 포함하도록 해야 한다.

개인정보 보호 절에서 언급했듯이, traceparent와 tracestate 헤더의 정보는 민감하다고 간주될 수 있는 정보를 전달할 수 있다. 예를 들어, traceparent는 한 요청을 다른 요청과 함께 전송된 데이터와 연관시킬 수 있게 하거나, tracestate 헤더는 호출자가 사용하는 모니터링 소프트웨어의 버전을 암시할 수 있다. 이 정보는 잠재적으로 더 큰 공격을 만드는 데 사용될 수 있다.

애플리케이션 소유자는 tracestate에 독점 정보나 기밀 정보가 저장되지 않도록 보장하거나, 외부 시스템으로 가는 요청에 tracestate가 존재하지 않도록 보장해야 한다.

공개 API를 가진 서비스에서 분산 추적이 활성화되어 있고, sampled 플래그가 설정된 모든 추적을 순진하게 계속하면, 악의적인 공격자는 추적 오버헤드로 애플리케이션을 압도하거나, 모니터링 데이터를 사용할 수 없게 만드는 trace-id 충돌을 위조하거나, SaaS 추적 벤더에 대한 추적 비용을 증가시킬 수 있다.

추적 벤더와 플랫폼은 이러한 상황을 고려하고, 악의적이거나 잘못 작성된 호출자에 의한 모니터링 거부로부터 보호하기 위해 견제와 균형이 마련되어 있는지 확인해야 한다.

이러한 보호의 한 예로 인증된 요청과 인증되지 않은 요청에 대해 서로 다른 추적 동작을 사용하는 것이 있을 수 있다. 데이터 기록을 위한 다양한 속도 제한기도 구현될 수 있다.

애플리케이션 소유자는 traceparent와 tracestate 헤더 전송으로 이어지는 모든 코드 경로를 테스트해야 한다. 예를 들어, 단일 페이지 브라우저 애플리케이션에서는 교차 출처 요청을 보내는 것이 일반적이다. 이러한 코드 경로 중 하나가 Access-Control-Allow-Headers [FETCH]를 사용하여 제한되는 교차 출처 호출에 의해 traceparent와 tracestate 헤더가 전송되도록 하면, 실패할 수 있다.