거래소 데이터의 event time과 receive time: 지연을 측정하는 기준

event time은 거래소가 사건 또는 메시지에 붙인 시각이고, receive time은 내 수집기가 바이트를 받은 시각입니다. 둘의 차이는 네트워크만이 아니라 거래소 내부 발행 대기와 양쪽 시계 오차까지 포함합니다. 따라서 `receive – event` 하나를 실제 전송 시간으로 단정하면 안 됩니다. 가능하면 체결 시각, 이벤트 발행 시각, 로컬 수신 시각, 파싱 완료 시각을 각각 저장하고, NTP 상태와 단조 시계 간격을 함께 기록해야 네트워크 구간과 내 처리 큐를 나눠 볼 수 있습니다.

한 메시지에 네 개의 시계를 둡니다

Binance Spot의 trade 스트림 예시는 `T`를 trade time, `E`를 event time으로 구분합니다. 수집기는 여기에 소켓 프레임을 읽은 `received_at`과 파싱·저장을 끝낸 `processed_at`을 추가할 수 있습니다. `E-T`는 거래소 내부에서 체결이 이벤트로 만들어지기까지의 관측 간격, `received_at-E`는 서버와 로컬 시계를 가로지르는 도착 간격, `processed_at-received_at`은 내 파이프라인 처리 간격입니다. 서로 다른 구간이므로 한 열로 덮어쓰지 않습니다.

운영체제 벽시계는 NTP 보정으로 앞뒤로 움직일 수 있습니다. 같은 프로세스 안의 처리 시간은 단조 시계로도 재고, 외부 메시지와 대조할 UTC 시각은 벽시계로 남기세요. 두 값을 함께 두면 로컬 시각이 조정된 순간에도 처리 지연 급증과 시계 점프를 구분할 수 있습니다.

지연은 하나의 숫자가 아니라 서로 다른 시계 사이 구간을 나눈 진단표입니다.

JOBCOIN 해설

VISUAL GUIDE시장 지표를 함께 읽기

1. 01
   한 메시지에 네 개의 시계를 둡니다

   Binance Spot의 trade 스트림 예시는 `T`를 trade time, `E`를 event time으로 구분합니다.

2. 02
   가정 패킷으로 구간별 지연을 검산합니다

   가상 메시지의 체결 시각이 12:00:00.

3. 03
   timestamp 정렬보다 sequence를 우선합니다

   서로 다른 메시지가 같은 밀리초를 가질 수 있고 네트워크 경로에서 늦게 도착한 이전 사건이 뒤 메시지 다음에 보일 수 있습니다.

AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.

가정 패킷으로 구간별 지연을 검산합니다

가상 메시지의 체결 시각이 12:00:00.100, 이벤트 시각이 .125, 로컬 수신이 .205, 처리 완료가 .265라고 합시다. 거래소 내부 관측 간격은 `125-100=25ms`, 시계 오차가 섞인 도착 간격은 `205-125=80ms`, 내 처리 간격은 `265-205=60ms`, 체결부터 저장까지는 `265-100=165ms`입니다. 네 값의 단위는 모두 ms이며 이 숫자는 실제 거래소 성능이 아닌 산식 확인용 가정입니다.

만약 로컬 시계가 서버보다 30ms 빠르다는 측정치가 있다면 80ms에는 그 차이가 섞여 있습니다. 단순 보정 추정치는 `80-30=50ms`지만 NTP 오차 자체에도 불확실성이 있으므로 ‘네트워크 50ms 확정’이 아니라 ‘관측 도착 80ms, 추정 시계 편차 +30ms’로 원값을 함께 보고합니다.

timestamp 정렬보다 sequence를 우선합니다

서로 다른 메시지가 같은 밀리초를 가질 수 있고 네트워크 경로에서 늦게 도착한 이전 사건이 뒤 메시지 다음에 보일 수 있습니다. timestamp로만 정렬하면 실제 거래소 순서를 다시 쓴 셈이 됩니다. 제공되는 sequence, trade ID 또는 업데이트 범위를 먼저 사용하고, 같은 순번이 중복 수신되면 고유키로 한 번만 적용합니다. 순번 공백은 지연이 아니라 누락 가능성으로 따로 집계합니다.

Binance 문서는 timestamp 단위를 기본 밀리초로 설명하며 스트림 URL 옵션으로 마이크로초를 받을 수 있다고 안내합니다. 정밀도가 높아졌다고 순서 보장이 생기는 것은 아닙니다. 저장 스키마에는 원 단위와 변환 단위를 명시하고, 밀리초를 마이크로초 열에 넣을 때 1,000배가 빠진 값처럼 보이지 않도록 원본 정수를 보존합니다.

• 원본 event·trade 시각과 단위를 변환 전 값으로 보관합니다.
• 소켓 콜백 첫 줄에서 receive time을 찍어 애플리케이션 큐를 제외합니다.
• sequence 공백·중복·역전을 지연 통계와 별도 카운터로 둡니다.
• NTP offset과 동기화 상태를 같은 시간축에 기록합니다.

평균 한 값 대신 분포와 역전을 봅니다

100개 메시지 중 99개가 20ms이고 한 개가 2,000ms라면 평균은 약 `39.8ms=(99×20+2000)/100`로 평소보다 높아지지만 장애의 꼬리를 충분히 보여 주지 못합니다. p50, p95, p99, 최대값과 함께 0 미만 관측치 비율을 표시하세요. 음수는 ‘미래 데이터’라기보다 시계 불일치 또는 필드 정의 오해를 먼저 의심할 신호입니다.

시장별 트래픽이 다른데 전체 표본을 섞으면 활발한 시장이 분위수를 지배합니다. venue·symbol·stream·connection_id별로 분리하고 동일한 1분 창에서 메시지 수와 지연 분포를 함께 냅니다. 연결 재수립 직후 백로그가 몰린 구간과 정상 구간도 분리해야 평상시 경로와 복구 비용을 혼동하지 않습니다.

지연 급증의 위치를 단계별로 찾습니다

`event-trade`만 커지고 `receive-event`는 평소와 같다면 거래소 내부 발행 구간이나 필드 정의를 살펴볼 차례입니다. 반대로 여러 스트림의 `receive-event`가 동시에 커졌는데 내 `process-receive`는 안정적이면 네트워크 또는 서버-로컬 시계 상태를 확인합니다. `process-receive`만 커질 때는 파서, 로그 쓰기, 데이터베이스 잠금, 가비지 컬렉션 등 내 수집기를 조사합니다.

웹소켓 heartbeat가 계속 왔다고 체결 스트림의 완전성이 증명되지는 않습니다. heartbeat와 마지막 trade ID는 연결 생존과 진전 여부를 판단하는 보조 근거입니다. 순번 공백이 확인되면 해당 구간을 REST로 보충하고, 보충 전 통계는 incomplete 상태로 표시해 지연 그래프가 데이터 누락을 정상 저지연처럼 보이게 하지 마세요.

비교 보고서는 측정 지점을 고정합니다

거래소 A는 소켓 콜백 시각, 거래소 B는 데이터베이스 commit 시각을 receive time으로 쓰면 B가 느리다는 결론은 측정 코드 차이일 수 있습니다. 동일 호스트, 동일 콜백 지점, 같은 타임스탬프 정밀도, 같은 표본 창을 맞춘 뒤 비교합니다. 지역과 네트워크 경로가 다르면 그 조건을 결과 제목에 포함합니다.

최종 보고에는 기간, 표본 수, p50·p95·p99, 음수 관측 비율, sequence 공백, 재연결 횟수, NTP offset 범위를 남기세요. 이 지표는 수집 경로 품질을 설명하며 체결 가능성이나 가격 방향을 보장하지 않습니다. 이상 구간의 원시 메시지와 로컬 로그를 함께 보존해야 같은 원인을 다시 검토할 수 있습니다. 수집 지연이 거래소별로 다르면 먼저 보인 가격이 실제로 공통 가격을 이끌었다고 오인할 수 있으므로 가격발견 분석에서는 event time 정렬과 receive time 진단을 함께 둡니다.

자주 묻는 질문