OpenTelemetry 메트릭, CUMULATIVE vs DELTA 헷갈리면 큰일나는 이유 🚨

"분명히 메트릭을 보고 있는데... 왜 숫자가 이상하게 튀는 것 같지? 🤔"

"Prometheus에서는 잘 보이던 그래프가 다른 모니터링 툴에서는 왜 깨져 보일까?"

 

만약 이런 고민을 해보셨다면, 당신은 OpenTelemetry의 가장 핵심적인 개념 중 하나를 놓치고 있을지도 모릅니다. 바로 'Aggregation Temporality (집계 시간성)' 입니다.

 

오늘은 많은 분들이 헷갈려 하는 두 가지 개념, 'Aggregation Temporality'와 'Temporal Reaggregation'을 완벽하게 파헤쳐 보겠습니다. 이 둘을 구분하지 못하면 데이터는 완전히 왜곡될 수 있습니다!

 

---

🕵️‍♂️ 데이터의 본질: Aggregation Temporality (집계 시간성)

가장 먼저, 데이터가 '어떤 시간 관점'의 값인지를 정의하는 '집계 시간성'부터 알아봅시다. "이 숫자는 언제부터 언제까지의 값을 의미하나요?" 라는 근본적인 질문에 대한 답이죠.

두 가지 종류가 있습니다.

A) CUMULATIVE (누적): 지금까지 모든 것의 합 📈

• 의미: 프로세스(애플리케이션)가 시작된 후 지금까지 발생한 모든 값을 합산한 누적치입니다.
• 특징: 값은 계속 증가하거나 최소한 동일하게 유지됩니다. (카운터의 경우)
• 비유: 자동차의 총주행거리계(Odometer) 🚗 를 생각해보세요. 시동을 껐다 켜도 총주행거리는 리셋되지 않고 계속 누적되죠? 바로 그 원리입니다.
• 예시: http_requests_total 카운터보시다시피, 값은 계속해서 쌓여나갑니다.

# 10:00 - 10:01 (요청 5회 발생)
- 보고되는 값: requests_total = 5

# 10:01 - 10:02 (요청 3회 추가 발생)
- 보고되는 값: requests_total = 8  (기존 5 + 신규 3)

# 10:02 - 10:03 (요청 10회 추가 발생)
- 보고되는 값: requests_total = 18 (기존 8 + 신규 10)

B) DELTA (델타/변화량): 딱 지금 이 순간의 변화 📊

• 의미: 지난번 보고 이후, 이번 보고 주기 동안 발생한 변화량만을 의미합니다.
• 특징: 매 보고 주기마다 독립적인 값을 가집니다.
• 비유: 자동차의 구간 주행거리계(Trip Meter) 🛣️ 와 같습니다. 특정 지점에서 리셋하고, 다음 목적지까지의 거리만 측정하는 것과 똑같죠.
• 예시: http_requests_total 카운터각 시점의 변화량만 깔끔하게 보여줍니다.

# 10:00 - 10:01 (요청 5회 발생)
- 보고되는 값: requests_total = 5

# 10:01 - 10:02 (요청 3회 발생)
- 보고되는 값: requests_total = 3

# 10:02 - 10:03 (요청 10회 발생)
- 보고되는 값: requests_total = 10

---

👨‍🍳 데이터를 요리하는 법: Temporal Reaggregation (시간적 재집계)

자, 이제 데이터의 '본질'을 알았으니, 이 데이터를 '가공'하는 방법을 알아볼 차례입니다.

'시간적 재집계'는 수집된 메트릭 데이터의 시간 간격(granularity)을 변경하는 과정입니다. 예를 들어, 1분 단위로 촘촘하게 수집한 데이터를 10분 단위의 큼직한 데이터로 합쳐서 요약본을 만드는 거죠. 왜 할까요? 데이터 저장 공간을 아끼고, 장기 트렌드를 볼 때 쿼리 속도를 높이기 위해서입니다. 🚀

핵심 포인트: 재집계 방식은 원본 데이터의 Temporality가 CUMULATIVE인지 DELTA인지에 따라 완전히 달라집니다!

A) DELTA 데이터의 재집계: 그냥 더하면 끝! ✅

• 방식: 아주 간단합니다. 그냥 더하기만 하면 됩니다. ➕ 각 구간의 변화량을 모두 더하면 전체 구간의 변화량이 되니까요.
• 예시: 1분짜리 DELTA 값 5개를 합쳐 5분짜리 DELTA 값을 만들어 봅시다.

# 각 1분 동안의 DELTA 값들
1분차: 5
2분차: 3
3분차: 10
4분차: 2
5분차: 7

# 5분 동안의 총 DELTA 값
5min_delta = 5 + 3 + 10 + 2 + 7 = 27

B) CUMULATIVE 데이터의 재집계: 뺄셈의 마법 🔮

• 방식: 이걸 그냥 더하면 큰일납니다! 마지막 시점의 누적값에서 처음 시점의 누적값을 빼야 해당 기간 동안의 진짜 변화량(DELTA)을 얻을 수 있습니다.
• 예시: 1분 간격 CUMULATIVE 데이터로 5분간의 변화량을 계산해 볼까요?

# 각 시점의 CUMULATIVE 값 (총주행거리)
T0 (시작): 100
T1: 105
T2: 108
T3: 118
T4: 120
T5 (끝): 127

# 5분 동안의 총 변화량 (DELTA) 계산
5min_delta = (T5의 누적값) - (T0의 누적값)
           = 127 - 100
           = 27

 

• ❌ 이걸 그냥 더했다면 어떻게 될까요? 100 + 105 + 108 + 118 + 120 + 127 이라는 어마어마한 숫자가 나오겠죠? 이건 "총합들의 총합"이라는 의미 없는 데이터가 되어버립니다. 데이터가 완전히 왜곡되는 순간이죠!

---

💡 전체 맥락: 그래서 이게 왜 중요한데?

자, 이제 두 개념의 차이는 알겠습니다. 그런데 이게 왜 그렇게 중요할까요?

구분Aggregation Temporality (집계 시간성)Temporal Reaggregation (시간적 재집계)

구분	Aggergation Temporality(집계 시간성)	Temporal Reaggregation(시간적 재집계
핵심 질문	🕵️‍♂️ "이 값은 누적값인가, 변화량인가?"	👨‍🍳 "이 데이터들을 어떻게 합쳐야 하지?"
결정 주체	SDK (애플리케이션 코드 단)	Collector, Backend (수집/저장 시스템 단)
개념	데이터의 '근본적인 속성'	그 속성을 바탕으로 한 '데이터 가공 방법론'

 

쉽게 말해, 애플리케이션(SDK)에서 메트릭을 만들 때 "이건 누적값(CUMULATIVE)이야!" 라고 꼬리표를 붙여서 보냅니다. 그럼 데이터를 받는 수집기(Collector)나 저장소(Backend)는 그 꼬리표를 보고 "아, 누적값이구나! 그럼 재집계할 때 덧셈이 아니라 뺄셈을 해야겠네!" 라고 올바르게 판단하고 처리하는 것이죠.

만약 이 약속이 지켜지지 않거나, 시스템이 Temporality를 제대로 이해하지 못하면 끔찍한 일이 발생합니다.

• CUMULATIVE 데이터를 DELTA처럼 더해버린다 → 그래프가 하늘로 치솟는 말도 안 되는 스파이크가 발생합니다. 😱
• DELTA 데이터를 CUMULATIVE처럼 착각한다 → 값이 계속 0 근처에서만 머무는 것처럼 보여 실제 변화를 놓치게 됩니다. 😥

결국, 이 두 개념의 정확한 이해와 구분은 정확한 모니터링, 신뢰할 수 있는 알람, 그리고 올바른 데이터 분석의 가장 기초적인 전제 조건인 셈입니다.

 

결론: 데이터의 속성을 알고, 올바르게 요리하자!

'Aggregation Temporality'는 데이터의 정체성(What)이고, 'Temporal Reaggregation'은 그 정체성에 맞는 요리법(How)입니다. OpenTelemetry 기반으로 시스템을 관찰하고 있다면, 내가 보고 있는 데이터의 'Temporality'가 무엇인지 항상 인지하고, 그에 맞는 'Reaggregation'이 이루어지고 있는지 확인하는 습관이 중요합니다.

 

이제 여러분의 메트릭 그래프를 다시 한번 살펴보세요. 혹시 잘못된 요리법으로 데이터가 왜곡되고 있지는 않나요? 😉