Event Time vs Processing Time
직관적으로
친구가 어제 보낸 카카오톡 메시지를 오늘 확인했다고 해서, 그 메시지가 "오늘 쓰여진 것"이 되지는 않는다 — 메시지가 실제로 작성된 시각(어제)과, 내가 그걸 읽은 시각(오늘)은 별개의 정보다. 스트리밍 시스템도 똑같은 구분이 필요하다.
실제 사례
IoT 센서가 오전 9시 정각에 온도를 측정해 전송했는데, 네트워크 지연으로 서버에는 9시 5분에 도착했다고 하자. 이 데이터의 **event time**(이벤트 시간)은 9시 정각(실제로 측정된 시각)이고, **processing time**(처리 시간)은 9시 5분(서버가 실제로 받아 처리한 시각)이다. "9시부터 9시 10분까지의 평균 온도"를 구하는 게 목적이라면, 반드시 event time 기준으로 집계해야 정확하다 — processing time 기준으로 집계하면 지연된 데이터가 엉뚱한 윈도우에 잡힌다.
정확한 원리
Flink는 각 레코드마다 타임스탬프를 지정할 수 있게 하고(TimestampAssigner), 이 타임스탬프를 기준으로 시간 관련 연산(윈도우 등)을 수행하는 **event time** 모드와, 시스템의 현재 벽시계 시각을 그대로 쓰는 **processing time** 모드를 모두 지원한다. 실무의 대부분의 정확한 집계·분석은 event time을 요구한다 — 네트워크 지연, 재처리, 백필(backfill) 상황에서도 "실제로 언제 일어난 일인지" 기준을 일관되게 유지해야 하기 때문이다. processing time은 구현이 단순하고 지연이 없다는 장점은 있지만, 같은 배치를 재실행해도 결과가 달라질 수 있어(재현성이 없음) 정확성이 중요한 분석에는 부적합하다.
흔한 오해
"실시간 처리니까 당연히 processing time을 쓰는 게 맞지 않나?"라는 오해가 흔하다. 정확히는 정반대에 가깝다 — '실시간으로 들어오는 데이터를 다룬다'는 것과 '어느 시간 기준으로 집계할 것인가'는 완전히 별개의 문제이고, 실무에서 정확성이 중요한 대부분의 스트리밍 분석(매출 집계, 이상거래 탐지의 시간 윈도우 등)은 event time을 쓴다.
확인 문제
"실시간 대시보드에 지금 이 순간 서버로 들어오고 있는 요청 수(초당 처리량, throughput)를 보여주고 싶다"는 요구사항이라면, event time과 processing time 중 어느 쪽이 더 적합할까?
Answer Guide
이 경우는 processing time이 더 적합하다는 게 요지 — '지금 이 순간 시스템이 실제로 얼마나 바쁜지'를 보여주는 게 목적이라면 시스템의 현재 벽시계 기준이 오히려 정확하다(이벤트가 언제 발생했는지가 아니라 지금 시스템이 얼마나 부하를 받고 있는지가 관심사이기 때문). 모든 상황에서 event time이 항상 정답은 아니라는 점을 짚었다면 잘 이해한 것.