트레이딩 시스템의 End-to-End Latency는 어떻게 측정하는가? | Trading Engineering #10

트레이딩 시스템의 End-to-End Latency는 어떻게 측정하는가?

Trading Engineering Series — 10

저지연 트레이딩 시스템을 이야기할 때 가장 자주 등장하는 단어 중 하나가 Latency입니다.

CPU를 빠르게 하고, 네트워크를 최적화하고, Memory Copy를 줄이고, Lock 경합을 줄이는 것도 중요합니다.

하지만 여기서 한 가지 중요한 질문이 남습니다.

그래서 실제 주문은 얼마나 빨리 처리되고 있는가?

특정 함수의 실행 시간이 빠르다고 해서 전체 트레이딩 시스템이 빠른 것은 아닙니다.

실제 성능을 판단하기 위해서는 End-to-End Latency를 측정해야 합니다.

이번 글에서는 저지연 트레이딩 시스템의 Latency를 어떻게 정의하고, 어디에서 측정하며, 어떻게 분석해야 하는지 살펴봅니다.

---

1. Latency는 하나의 숫자가 아니다

트레이딩 시스템에서 흔히 이야기하는 Latency는 실제로 여러 구간으로 나눌 수 있습니다.

예를 들어 주문 처리 경로를 보면:

Strategy → Risk Check → Order Manager → DMA/FEP → Network → Exchange

각 구간마다 서로 다른 Latency가 발생합니다.

이를 세분화하면 다음과 같이 볼 수 있습니다.

• Strategy Processing Latency
• IPC Latency
• Risk Check Latency
• Order Manager Latency
• FEP Processing Latency
• Network Latency
• Exchange Response Latency

따라서 단순히

“우리 시스템은 10μs입니다.”

라고 말하는 것만으로는 충분하지 않습니다.

어떤 구간을 측정한 10μs인지가 중요합니다.

---

2. End-to-End Latency란?

End-to-End Latency는 시스템의 시작점부터 최종 목적지까지 걸리는 전체 시간을 의미합니다.

예를 들어 알고리즘 매매 시스템에서는:

Market Data Received

↓

Strategy Decision

↓

Pre-Trade Risk Check

↓

Order Generation

↓

DMA/FEP

↓

Network Transmission

↓

Exchange

까지의 전체 경로를 고려할 수 있습니다.

또는 주문 응답까지 포함한다면:

Market Data → Order → Exchange → Execution Response

전체를 하나의 흐름으로 볼 수도 있습니다.

중요한 것은 비즈니스와 시스템의 목적에 맞는 시작점과 종료점을 명확하게 정의하는 것입니다.

---

3. 왜 End-to-End 측정이 중요한가?

각각의 컴포넌트가 빠르더라도 전체 시스템이 빠르다는 보장은 없습니다.

예를 들어:

• Strategy: 5μs
• Risk Check: 3μs
• Order Manager: 4μs
• FEP: 5μs

라고 하더라도 실제 시스템에서는 그 사이에 추가적인 IPC, Memory Copy, Lock, Context Switch, Queueing 등이 발생할 수 있습니다.

결과적으로:

5 + 3 + 4 + 5 = 17μs

라고 단순하게 계산한 값보다 실제 End-to-End Latency가 훨씬 커질 수 있습니다.

따라서 중요한 것은 각각의 함수가 얼마나 빠른가가 아니라,

실제 데이터가 시스템 전체를 통과하는 데 얼마나 걸리는가?

입니다.

---

4. Critical Path를 찾아야 한다

모든 처리 과정이 동일하게 중요한 것은 아닙니다.

트레이딩 시스템에서는 실제 주문 실행에 직접 영향을 미치는 경로를 Critical Path라고 볼 수 있습니다.

예를 들어:

Market Data → Strategy → Risk → Order Manager → DMA/FEP → Exchange

가 주문 실행의 Critical Path라면,

로그 저장이나 통계 집계처럼 주문 실행에 직접 필요하지 않은 작업은 가능한 한 Critical Path에서 분리할 수 있습니다.

예를 들어:

Trading Path

→ 주문 처리

Async Path

→ Logging
→ Monitoring
→ Statistics
→ Database Storage

이러한 구조는 Latency에 영향을 주는 작업을 줄이는 데 도움이 됩니다.

---

5. 어디에서 Timestamp를 찍어야 하는가?

Latency를 측정하려면 적절한 지점에서 Timestamp를 기록해야 합니다.

예를 들어:

T1: Market Data Received
T2: Strategy Decision
T3: Risk Check Completed
T4: Order Generated
T5: FEP Processing Completed
T6: Network Send
T7: Exchange Response

그러면 각 구간의 시간을 계산할 수 있습니다.

Strategy Latency = T2 - T1

Risk Latency = T3 - T2

Order Processing = T4 - T3

FEP Latency = T5 - T4

Network-related Latency = T6 - T5

그리고 전체 End-to-End Latency는:

E2E Latency = T7 - T1

와 같이 계산할 수 있습니다.

이렇게 해야 어느 구간에서 시간이 증가하고 있는지 확인할 수 있습니다.

---

6. Timestamp 자체도 비용이 될 수 있다

여기서 한 가지 주의할 점이 있습니다.

Latency를 측정하기 위해 Timestamp를 너무 많이 기록하면 측정 코드 자체가 시스템 성능에 영향을 줄 수 있습니다.

특히 매우 짧은 Latency를 측정하는 시스템에서는 Timestamp를 가져오는 방법과 빈도도 중요합니다.

따라서:

측정은 필요하지만, 측정 자체가 시스템을 방해해서는 안 됩니다.

필요한 지점에 최소한의 계측을 적용하고, 실제 운영 환경의 성능과 테스트 환경의 성능을 구분해서 분석해야 합니다.

---

7. Average Latency만 보면 안 된다

Latency 분석에서 평균값만 보는 것은 위험합니다.

예를 들어:

Average: 10μs

라고 하더라도 실제 데이터가:

8μs
9μs
10μs
10μs
11μs
12μs
150μs

처럼 분포되어 있을 수 있습니다.

이 경우 평균값만 보면 시스템이 상당히 빠른 것처럼 보일 수 있습니다.

하지만 실제 트레이딩에서는 순간적으로 발생하는 큰 지연이 중요할 수 있습니다.

따라서 다음과 같은 지표를 함께 보는 것이 좋습니다.

• Average
• Minimum
• Maximum
• P50
• P90
• P95
• P99
• P99.9

특히 Tail Latency를 확인하는 것이 중요합니다.

---

8. Tail Latency가 중요한 이유

저지연 시스템에서 가장 흥미로운 부분은 평균이 아니라 최악의 일부 구간일 수 있습니다.

예를 들어:

P50 = 8μs
P99 = 15μs
P99.9 = 80μs

라면 대부분의 주문은 빠르게 처리되지만 일부 주문에서는 상당히 큰 지연이 발생하고 있다는 의미입니다.

이러한 지연은 다음과 같은 원인에서 발생할 수 있습니다.

• Lock Contention
• Context Switch
• Cache Miss
• Memory Allocation
• CPU Scheduling
• Queueing
• Network Retransmission
• Interrupt 처리
• 시스템 부하

따라서 평균 Latency가 개선되었더라도 Tail Latency가 악화된다면 실제 시스템의 품질은 반드시 좋아졌다고 볼 수 없습니다.

---

9. Latency는 부하에 따라 달라진다

테스트 환경에서 10μs가 나왔다고 해서 실제 시장에서도 항상 10μs가 나오는 것은 아닙니다.

시장 데이터와 주문량이 증가하면:

• Queue가 증가하고
• CPU 사용률이 올라가고
• Cache Miss가 증가하고
• Lock 경합이 증가하고
• Memory Bandwidth 압박이 커질 수 있습니다.

따라서 성능 테스트에서는 다양한 부하 조건을 고려해야 합니다.

예:

Low Load

→ 정상적인 시장 상황

Normal Load

→ 일반적인 고부하 상황

Peak Load

→ 급격한 거래량 증가

Stress Load

→ 시스템 한계에 가까운 상황

이러한 환경에서 Latency 분포가 어떻게 변화하는지 확인해야 합니다.

---

10. Latency Optimization은 측정에서 시작한다

저지연 시스템을 최적화할 때 가장 위험한 접근은 측정하지 않고 최적화하는 것입니다.

예를 들어:

“memcpy()가 느릴 것 같다.”

“Lock이 문제일 것 같다.”

“네트워크가 병목일 것 같다.”

라고 추측할 수 있습니다.

하지만 실제 병목은 전혀 다른 곳에 있을 수 있습니다.

따라서 다음과 같은 사이클이 중요합니다.

Measure

↓

Identify

↓

Redesign

↓

Benchmark

↓

Measure Again

성능 최적화는 한 번의 작업으로 끝나는 것이 아니라 반복적인 엔지니어링 과정입니다.

---

11. End-to-End 관점에서 지금까지의 내용을 다시 보면

이번 Trading Engineering 시리즈에서 다룬 내용들은 서로 독립적인 기술이 아닙니다.

하나의 데이터 경로에서 서로 연결되어 있습니다.

예를 들어:

Market Data

↓

FEP

↓

IPC / Shared Memory

↓

Strategy

↓

Lock / Synchronization

↓

Risk Check

↓

Order Manager

↓

Memory Copy

↓

DMA / FEP

↓

Network

↓

Exchange

각 단계에서 발생하는 작은 비용들이 최종적으로 End-to-End Latency를 결정합니다.

따라서 저지연 트레이딩 시스템의 핵심은 특정 기술 하나를 사용하는 것이 아닙니다.

전체 데이터 경로를 이해하고, 병목을 측정하고, 필요한 부분을 최적화하는 것입니다.

---

12. FontesFintech의 접근 방식

FontesFintech는 트레이딩 시스템의 성능을 특정 컴포넌트 하나의 속도로 판단하지 않습니다.

전체 시스템의 End-to-End Data Path를 기준으로 접근합니다.

주요하게 고려하는 요소는 다음과 같습니다.

• End-to-End Latency
• Critical Path
• Memory Copy
• IPC
• Shared Memory
• Ring Buffer
• Lock Contention
• CPU Cache
• Network Processing
• Message Parsing
• Queueing
• Fault Recovery

그리고 각 요소를 실제 시스템 환경에서 측정하고 분석하여 필요한 부분을 최적화합니다.

결국 중요한 것은:

“어떤 기술을 사용했는가?”가 아니라
“실제 주문이 얼마나 빠르고 안정적으로 목적지에 도달하는가?”

입니다.

---

Conclusion

저지연 트레이딩 시스템에서 Latency는 단순한 숫자가 아닙니다.

어디에서 시작해서 어디까지 측정했는지, 어떤 환경에서 측정했는지, 그리고 평균뿐 아니라 Tail Latency까지 어떻게 나타나는지를 함께 봐야 합니다.

그리고 가장 중요한 것은 End-to-End 관점입니다.

Measure the Path.
Find the Bottleneck.
Optimize the Critical Path.

지금까지의 1차 Trading Engineering 시리즈에서 우리는 FEP, DMA, Algorithmic Trading, Shared Memory, Lock Contention, Memory Copy 등 저지연 시스템을 구성하는 주요 요소들을 살펴보았습니다.

 

다음 단계에서는 한 단계 더 아래로 내려가 보겠습니다.

CPU Cache
Cache Line
CPU Affinity
NUMA
epoll & Busy Polling
NIC Offload
Kernel Bypass
TCP/UDP

 

다음 연재( Trading Engineering — Deep Dive ) 에서는 실제 OS와 CPU, Network Stack 수준에서

Latency가 어떻게 만들어지는지 살펴보겠습니다.

 

 

Measure First. Optimize with Evidence.

fontesfintech