샘플링과 카디널리티: 문제 단서는 남기고 데이터 폭증은 막는 법

30초 요약

샘플링과 카디널리티는 모두 관측 비용에 영향을 주지만 줄이는 대상이 다르다.

반복해서 기억할 문장은 이것이다.

샘플링은 남길 사건 수를 줄이고, 카디널리티 관리는 분류 칸 수를 줄인다.

질문 정하기 → 분류 축 제한 → 표본 규칙 설계 → 희귀 실패 보호 → 손실·비용 검증

관측 데이터를 무조건 많이 남기면 비용만 늘고 질문은 흐려질 수 있다. 반대로 비율부터 낮추고 필드를 지우면 필요한 실패 사례까지 사라진다. 먼저 답할 질문을 정하고, 그 질문을 유지하는 데 필요한 분류와 표본을 따로 설계한다.

이 글의 대표 상황은 결제 오류를 조사할 수 있는 상태를 유지하면서 관측 비용을 줄이는 일이다. 정상 트레이스를 덜 남길지, 오류를 더 남길지, route와 release를 어떻게 분류할지를 이 한 질문에 대입하면 샘플링과 카디널리티를 같은 비용 조절 장치로 오해하지 않게 된다.

먼저 사건 수와 분류 칸 수를 나눈다

두 문제를 간단한 예로 나누어 보자.

요청 트레이스 10,000개 중 1,000개를 남김
  → 샘플링: 사건 수 10,000 → 1,000
 
checkout_total을 platform × route × result로 분류
  → 카디널리티: 관측된 고유 조합마다 별도 시계열 생성

트레이스를 10%만 남겨도 메트릭 속성에 사용자 ID를 넣으면 시계열은 사용자 수만큼 늘 수 있다. 반대로 메트릭 분류를 네 개로 제한해도 모든 상세 트레이스를 저장하면 사건 수 비용은 그대로다. 따라서 “데이터가 많다”는 한 문장으로 두 원인을 합치지 않는다.

샘플링은 전체를 대신할 표본을 고르는 일이다

여기서 먼저 세 단어를 구분한다.

• 모집단: 알고 싶은 전체 사건. 예를 들면 운영 Web 결제 요청 전체다.
• 표본: 실제로 골라 남긴 일부 사건이다.
• 대표성: 표본으로 전체의 성질을 추정할 때 선택 규칙 때문에 특정 종류가 부당하게 많거나 적지 않은 성질이다.

무작위로 10%를 남기면 정상·느린 요청·오류가 대체로 원래 비율을 따라갈 가능성이 있다. 그러나 트래픽이 적거나 희귀 오류가 매우 드물면 이번 표본에 그 오류가 하나도 없을 수 있다. 샘플링 비율은 비용 숫자만으로 정하지 않고 다음을 함께 본다.

1. 어떤 모집단을 대표하려는가?
2. 어느 정도로 드문 사건을 발견해야 하는가?
3. 분포·비율 추정과 개별 실패 진단 중 어느 목적이 우선인가?
4. 선택되지 않은 사건을 잃었을 때 감수할 위험은 무엇인가?
5. 샘플링 파이프라인 자체의 계산·운영 비용은 얼마인가?

데이터가 적고 비용이 허용되거나 규정상 사건을 버릴 수 없다면 샘플링하지 않는 선택도 맞다. 집계 결과만 필요하다면 상세 트레이스를 뽑기보다 처음부터 메트릭으로 집계하는 편이 맞을 수 있다. OpenTelemetry 공식 안내도 데이터 양, 분석 목적, 규정과 샘플러 운영 비용을 함께 보고 샘플링 여부를 결정하라고 한다.

헤드는 일찍 테일은 결과를 본 뒤 결정한다

헤드 샘플링(Head sampling)은 트레이스가 시작되는 쪽인 머리에서 일찍 선택한다. 테일 샘플링 (Tail sampling)은 여러 스팬이 끝난 뒤 트레이스의 꼬리에서 결과를 보고 선택한다.

요청 시작
  → trace ID로 10% 선택 여부 결정
  → 부모 결정을 따르는 구성에서 자식 작업이 선택 결과를 이어 감
  → 선택한 트레이스만 내보냄

장점은 일찍 버려 처리량을 줄일 수 있고 규칙이 비교적 단순하다는 점이다. 대신 요청이 끝나기 전에 결정하므로 이 트레이스가 나중에 오류가 될지, 아주 느려질지 알 수 없다. 헤드 샘플링만으로 “최종 오류 트레이스는 모두 남긴다”를 보장할 수 없다.

여러 서비스의 스팬 도착
  → 같은 trace ID끼리 잠시 모음
  → 완료·시간 초과 판단
  → 오류인가? 매우 느린가? 새 릴리스인가?
  → 규칙에 따라 전체 트레이스를 남기거나 버림

테일 샘플링은 “늦게 결정하므로 항상 더 좋다”가 아니다. 모든 스팬을 같은 샘플러가 볼 수 있게 보내야 하고, 늦게 도착한 스팬과 시간 초과를 다뤄야 하며, 샘플러 자체가 밀리거나 실패하는지도 관측해야 한다. 앞 단계인 상류에서 헤드 샘플링으로 이미 버린 트레이스는 뒤의 테일 샘플러가 되살릴 수 없다.

조건부 판단은 다음과 같다.

희귀 실패를 보호하면 표본 비율은 달라진다

“오류는 100%, 정상은 1%” 같은 규칙은 오류 조사에 유용하다. 그러나 남은 자료에서 오류가 차지하는 비율은 원래 모집단과 달라진다.

실제 요청
  정상 9,900 / 오류 100  → 실제 오류율 1%
 
샘플링 뒤
  정상 99 / 오류 100     → 저장소에서 오류 비중 약 50%

전체 비율과 추세는 샘플링 전에 모든 측정을 집계한 메트릭을 우선 사용한다. 확률 표본으로 전체를 추정하려면 각 표본의 선택 확률과 통계적 불확실성을 반영해야 한다. 선택 기준이 계속 바뀌거나 확률을 기록하지 않았다면 사후에 정확히 보정할 수 있다고 가정하지 않는다.

전체 영향 질문  → 샘플링 전 집계 메트릭
구체적 원인 질문 → 더 많이 보존한 오류·긴 지연 트레이스

이 역할 분리가 12편의 “숫자로 감지하고 흐름으로 좁힌다”와 이어진다. 진단 사례를 풍부하게 남기는 정책과 전체 사용자 비율을 계산하는 자료를 서로 대체하지 않는다.

카디널리티는 값 하나가 아니라 조합으로 늘어난다

메트릭의 속성은 측정값을 나눠 볼 분류 기준이다. Prometheus 계열에서는 이런 키·값 분류를 레이블(label)이라고도 부른다. 예를 들어 결제 시도 수를 플랫폼과 결과로 나눌 수 있다.

checkout_total{platform="web", result="success"}
checkout_total{platform="web", result="failure"}
checkout_total{platform="ios", result="success"}
checkout_total{platform="ios", result="failure"}

각 속성의 가능한 값이 모두 조합된다는 가정에서 상한을 계산해 보자.

route 30개 × platform 3개 × result 5개 × release 10개
  = 최대 4,500개 시계열

실제 시계열 수는 관측된 조합만큼이므로 항상 이 상한과 같지는 않다. 그러나 사용자 ID, trace ID, 주문 ID나 매번 다른 오류 문장처럼 값의 범위가 계속 늘어나는 속성이 하나만 들어가도 상한을 예측하기 어려워진다. 이를 제한 없는 값 집합이라고 부를 수 있다.

카디널리티가 높으면 저장량만 늘지 않는다. 메모리에서 유지할 집계 상태, 내보낼 데이터, 질의가 읽을 시계열과 대시보드가 그릴 결과도 함께 늘 수 있다. 정확한 비용 단위는 사용하는 저장소와 20편의 비용 모델에서 따로 확인한다.

프론트엔드에서는 개별 값보다 제한된 분류를 남긴다

예를 들어 상품별 주소를 그대로 분류하지 않는다.

나쁜 메트릭 분류
  route="/products/8192?coupon=summer"
  user_id="user-94720"
  trace_id="4bf92f..."
  error_message="timeout after 3017ms"
 
제한된 메트릭 분류
  route="/products/:productId"
  platform="ios"
  result="timeout"
  release_channel="stable"

좋은 분류값은 “자세하지 않다”가 아니라 운영 질문에 맞게 종류가 제한돼 있다.

React에서는 컴포넌트 인스턴스 ID, 사용자 입력값이나 컴포넌트에 전달한 입력값(props) 전체를 메트릭 속성으로 넣지 않는다. 화면 종류, 상호작용 종류와 성공·실패 결과처럼 팀이 목록을 관리할 수 있는 값을 우선한다.

React Native에서는 플랫폼, 네이티브 앱 버전, JavaScript 업데이트 채널과 주요 운영체제 구간이 유용할 수 있다. 그러나 모든 장치 ID, 세션 ID나 전체 장치 문자열을 시계열로 만들지 않는다. 버전도 영원히 값이 늘어나므로 보존 기간과 지원 중인 버전 범위를 고려해 예산에 포함한다.

카디널리티 제한은 설계가 아니라 마지막 안전장치다

제한은 메모리와 내보내기 폭증을 막는 안전장치다. 다음 설계를 대신하지 않는다.

1. 각 메트릭이 답할 질문을 한 문장으로 쓴다.
2. 그 질문에 쓰이지 않는 속성을 제거한다.
3. 남길 속성마다 값의 허용 목록이나 증가 상한을 정한다.
4. 조합 상한과 실제 활성 시계열 수를 계산한다.
5. 마지막에 구현이 지원하는 카디널리티 제한을 둔다.

overflow(초과분)가 자주 생기면 비용 상한은 지킬 수 있어도 어떤 화면·플랫폼에서 문제가 생겼는지 구분할 자료가 한 칸에 섞인다. overflow 발생 자체를 관측하고, 원인이 새 정상 분류인지 예상하지 못한 개별 값 유입인지 조사한다.

엑셈플러는 집계에서 구체적인 흐름으로 이어 준다

결제 지연 시간 분포 악화
  → 느린 구간의 엑셈플러 선택
  → 연결된 trace ID 열기
  → 브라우저·서버 스팬과 로그 조사

trace ID를 메트릭 속성으로 넣으면 요청마다 새 시계열이 생긴다. 엑셈플러는 메트릭 분류를 작게 유지하면서 제한된 구체 사례로 이동하는 별도 연결 고리다. 모든 느린 요청을 보존하거나 원인을 자동 판정하는 기능은 아니다.

엑셈플러를 쓸 수 없다면 집계 시각·릴리스·화면 종류를 기준으로 같은 범위의 샘플 트레이스를 검색할 수 있다. 중요한 것은 상세 식별자를 메트릭의 분류 축으로 밀어 넣지 않는 것이다.

샘플링은 개인정보 보호 방법이 아니다

1%만 남겨도 그 1%에 이메일, 인증 값이나 검색어 원문이 들어 있으면 위험은 남는다. 사용자 ID를 메트릭에서 빼는 이유도 비용뿐 아니라 개인별 추적과 노출 범위를 줄이기 위해서다. 조사에 개별 값이 꼭 필요하다면 목적, 허용 필드, 가림 규칙, 보존 기간과 접근자를 먼저 정한다.

실제 예산은 질문부터 역으로 설계한다

1단계 질문을 하나로 고정한다

“관측 비용을 줄인다”가 아니라 실제 판단을 적는다.

새 릴리스에서 결제 실패율이 늘었는가?
느린 상호작용은 어느 화면 종류와 플랫폼에 집중되는가?
한 오류 요청은 브라우저에서 어느 서버 단계까지 갔는가?

첫 두 질문은 집계 메트릭, 마지막 질문은 상세 트레이스가 중심이다.

2단계 분류 축의 값 목록을 쓴다

메트릭마다 속성 이름, 가능한 값, 값이 늘어나는 조건과 보존 기간을 기록한다.

3단계 표본 규칙과 선택 시점을 정한다

전체 분포를 추정할 확률 표본과 진단을 위한 우선 보존 규칙을 구분한다. 헤드에서 먼저 버린다면 뒤에서 어떤 사건을 복구할 수 없는지 적는다. 테일에서 고른다면 모을 시간, 메모리, 불완전 트레이스와 샘플러 장애를 어떻게 확인할지 정한다.

4단계 희귀 실패의 별도 경로를 둔다

오류·긴 지연·새 릴리스를 더 남길 수 있다. 다만 이 표본의 비율을 전체 비율로 읽지 않고, 샘플링 전 집계 메트릭과 연결한다. 우선 보존 규칙이 적용되지 못한 사건과 샘플러 손실도 함께 측정한다.

5단계 비용과 진단 가능성을 같이 검증한다

다음 값이 바뀔 때 설정을 재검토한다.

• 초당 들어오는 사건 수와 내보낸 사건 수
• 규칙별 실제 샘플 비율과 선택되지 않은 수
• 활성 시계열 수와 속성별 고유 값 수
• 카디널리티 overflow 발생량
• 샘플러의 대기 시간·메모리·버린 스팬 수
• 오류·긴 지연·새 릴리스 사례를 실제로 찾을 수 있는 비율
• 저장·질의 비용과 장애 조사 시간

비용만 줄고 필요한 실패를 찾지 못하면 성공이 아니다. 반대로 모든 데이터를 남겨 조사 시간이 오히려 길어지거나 예산을 넘겨도 좋은 관측 체계가 아니다.

자주 실패하는 설계

모든 상세 값을 메트릭에 넣고 나중에 고른다

메트릭은 집계 질문에 맞는 제한된 분류를 가져야 한다. 사용자·세션·trace ID와 전체 URL은 상세 로그나 트레이스에서 필요한 범위로 다루고, 메트릭 시계열로 만들지 않는다.

샘플 비율만 낮추면 카디널리티도 해결된다고 생각한다

트레이스 사건 수와 메트릭 시계열 수는 다른 축이다. 두 값을 각각 측정하고 별도 예산을 둔다.

오류 100퍼센트 보존을 절대 보장처럼 쓴다

테일 규칙이 오류를 고르더라도 상류에서 이미 버렸거나, 계측·전송·버퍼가 실패했거나, 오류 표시가 누락되면 남지 않는다. 규칙의 목표와 실제 보존 결과를 분리한다.

카디널리티 제한에 자주 닿아도 안전하다고 생각한다

overflow는 합계를 보존할 수 있지만 분류 의미를 잃는다. 한도 도달을 정상 운영 상태로 두지 않고 속성 규칙 위반 신호로 조사한다.

표본의 원시 개수를 전체 개수처럼 읽는다

선택 확률이 다르면 원시 개수 비교는 왜곡된다. 집계 메트릭, 확률과 가중치를 이용하거나 분석 가능하지 않다고 명시한다.

어떤 값을 어디에 둘지 고르는 기준

도구 이름이 바뀌어도 판단은 같다. 이 값이 전체 영향 범위를 나눌 안정된 분류인지, 한 사건을 찾기 위한 상세 문맥인지 먼저 묻는다.

한 문장으로 다시 설명하기

샘플링은 전체 사건 중 어떤 일부를 남길지 정해 사건 수를 줄이고, 카디널리티 관리는 메트릭 속성 조합이 만드는 시계열 수를 제한한다. 전체 비율은 대표성 있는 집계로 보고, 희귀 오류는 진단용으로 더 남길 수 있지만 두 자료를 같은 비율로 읽지 않는다. 경로 틀과 고정 결과처럼 값이 제한된 분류를 쓰고, 개별 trace ID는 엑셈플러나 상세 신호로 연결하며, 비율·overflow·비용과 실제 진단 성공률을 함께 검증한다.

스스로 확인하기

1. 샘플링과 카디널리티가 각각 줄이는 대상은 무엇인가?
2. 헤드 샘플링이 최종 오류를 보고 결정할 수 없는 이유는 무엇인가?
3. 오류를 더 많이 남긴 표본의 오류 비율을 전체 오류율로 읽으면 왜 안 되는가?
4. 메트릭의 전체 URL을 경로 틀로 바꾸면 어떤 비용과 의미가 달라지는가?
5. 카디널리티 제한이 속성 이름과 허용 값 규칙 설계를 대신하지 못하는 이유는 무엇인가?
6. 엑셈플러는 메트릭과 트레이스 사이에서 어떤 역할을 하는가?
7. 관측 예산을 바꾼 뒤 비용과 함께 어떤 진단 가능성 신호를 확인해야 하는가?