트레이딩 시스템의 Latency를 결정하는 5가지 요소 | Trading Engineering #5

트레이딩 시스템의 Latency를 결정하는 5가지 요소

Trading Engineering Series — 04

 

Low Latency Trading System을 개발할 때 흔히 가장 먼저 생각하는 것은 CPU 성능이나 네트워크 속도입니다.

하지만 실제 트레이딩 시스템의 latency는 하나의 요소로 결정되지 않습니다.

데이터가 시스템에 들어온 순간부터 주문이 거래소에 전달되기까지 발생하는 Memory Copy, Process Context Switch, Lock, Network Processing, Message Parsing 등 수많은 작은 작업들이 전체 latency를 구성합니다.

특히 알고리즘 매매, DMA, LP, MM, HFT와 같이 빠른 주문 처리가 중요한 환경에서는 이러한 차이가 누적될 수 있습니다.

이번 글에서는 트레이딩 시스템의 latency에 영향을 줄 수 있는 대표적인 5가지 요소를 살펴보겠습니다.

---

1. Memory Copy

고성능 시스템에서 생각보다 중요한 요소 중 하나가 Memory Copy입니다.

데이터를 한 메모리 영역에서 다른 영역으로 복사하는 작업 자체는 매우 빠르게 수행될 수 있습니다.

하지만 데이터가 여러 시스템과 프로세스를 거치면서 반복적으로 복사된다면 이야기가 달라집니다.

예를 들어 다음과 같은 구조를 생각해 볼 수 있습니다.

Market Data
     ↓
Buffer A
     ↓ copy
Buffer B
     ↓ copy
Process C
     ↓ copy
Strategy
     ↓ copy
Order Buffer
     ↓
FEP

개별 Copy의 비용은 작더라도 데이터가 반복적으로 복사되면 불필요한 CPU 사용과 latency가 발생할 수 있습니다.

따라서 Low Latency 시스템에서는 가능한 경우 불필요한 Memory Copy를 줄이고 데이터를 효율적으로 공유하는 구조를 고려해야 합니다.

Shared Memory와 Zero-Copy에 가까운 데이터 처리 방식 등이 이러한 목적에 활용될 수 있습니다.

---

2. Process Context Switch

두 번째 요소는 Process Context Switch입니다.

운영체제는 여러 프로세스와 Thread가 CPU를 공유할 수 있도록 실행 대상을 전환합니다.

일반적인 애플리케이션에서는 이러한 전환 비용이 큰 문제가 되지 않을 수 있습니다.

그러나 latency에 민감한 시스템에서는 상황이 다릅니다.

예를 들어 주문 처리 과정이 여러 프로세스로 분리되어 있다면:

Process A
    ↓
Process B
    ↓
Process C
    ↓
Process D

데이터 전달과 실행 과정에서 여러 번의 Process 또는 Thread 전환이 발생할 수 있습니다.

물론 프로세스를 하나로 통합하는 것이 항상 정답은 아닙니다.

금융 시스템에서는 장애 격리, 안정성, 운영 편의성 역시 중요하기 때문입니다.

중요한 것은 시스템의 목적에 따라 프로세스 구조를 설계하고, latency-critical path에서는 불필요한 Context Switch와 IPC 비용을 최소화하는 것입니다.

---

3. Lock & Synchronization

여러 Thread 또는 Process가 동일한 데이터를 사용하는 경우 데이터의 일관성을 유지하기 위한 Synchronization이 필요합니다.

대표적인 방법이 Lock입니다.

Thread A
    ↓
   LOCK
    ↓
Shared Data
    ↓
  UNLOCK

문제는 여러 Thread가 동시에 Lock을 기다리게 될 경우입니다.

Thread A ──→ LOCK ──→ Processing
Thread B ──→ WAIT
Thread C ──→ WAIT

이러한 대기 시간이 latency를 증가시킬 수 있습니다.

따라서 High-Performance Trading System에서는 무조건 Lock을 사용하는 것이 아니라 시스템 특성에 따라 Lock의 범위를 줄이거나 Lock-Free / Wait-Free에 가까운 구조, Single-Writer 구조, 효율적인 Ring Buffer 등의 방법을 검토할 수 있습니다.

중요한 것은 기술 자체가 아니라 실제 데이터 흐름에서 synchronization overhead가 어디에서 발생하는지 파악하는 것입니다.

---

4. Network Processing

트레이딩 시스템에서 Network latency 역시 중요한 요소입니다.

하지만 네트워크 latency를 단순히 "인터넷 속도"의 문제로 생각해서는 안 됩니다.

전체 네트워크 경로에서는 다음과 같은 다양한 요소가 영향을 줄 수 있습니다.

Application
    ↓
Socket
    ↓
Kernel
    ↓
Network Interface
    ↓
Switch
    ↓
Network
    ↓
Exchange

패킷 전달 시간뿐 아니라 시스템 내부에서 발생하는 Socket Processing, Kernel Overhead, Packet Handling, Network Buffering 등도 고려해야 합니다.

특히 거래소와 연결되는 FEP나 DMA Gateway에서는 안정적인 네트워크 연결과 함께 효율적인 Message I/O 구조를 설계하는 것이 중요합니다.

---

5. Message Parsing

마지막으로 Message Parsing입니다.

금융 시스템에서는 거래소와 외부 기관에서 전달되는 다양한 전문(Message)을 분석하고 필요한 데이터를 추출해야 합니다.

예를 들어 하나의 메시지가 다음과 같은 정보를 포함할 수 있습니다.

Message
 ├─ Message Type
 ├─ Sequence
 ├─ Account
 ├─ Symbol
 ├─ Price
 ├─ Quantity
 └─ Order Information

일반적인 업무 시스템에서는 Parsing 비용이 크게 중요하지 않을 수 있습니다.

하지만 초당 수천 또는 그 이상의 메시지를 처리하는 시스템에서는 Parsing 방식 역시 성능에 영향을 줄 수 있습니다.

불필요한 문자열 변환, 반복적인 Memory Allocation, 복잡한 객체 생성 등을 줄이고 고정 길이 전문이나 Binary Protocol의 특성에 맞는 효율적인 Parsing 구조를 설계할 수 있습니다.

---

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

Low Latency 시스템에서 중요한 또 하나의 개념은 End-to-End Latency입니다.

단순히 네트워크가 빠르다고 해서 전체 시스템이 빠른 것은 아닙니다.

예를 들어:

Market Data
    ↓
Network
    ↓
Message Parsing
    ↓
Strategy
    ↓
Risk Check
    ↓
Order Processing
    ↓
FEP
    ↓
Network
    ↓
Exchange

전체 latency는 이러한 각각의 단계에서 발생하는 처리 시간의 합으로 볼 수 있습니다.

따라서 특정 한 부분만 최적화하는 것보다 전체 Critical Path를 측정하고 가장 큰 병목을 찾아 개선하는 접근 방식이 중요합니다.

---

7. 빠르게 만드는 것과 안정적으로 만드는 것

트레이딩 시스템에서는 latency만 낮추는 것이 목표가 되어서는 안 됩니다.

예를 들어 지나치게 복잡한 최적화를 적용하면 시스템의 유지보수가 어려워지거나 장애 대응이 복잡해질 수 있습니다.

금융 시스템에서는 다음 네 가지 요소를 함께 고려해야 합니다.

    Performance

    빠른 데이터 처리와 주문 실행

    Stability

    장시간 안정적인 시스템 운영

    Reliability

    장애 상황에서도 데이터와 주문 상태를 안전하게 관리

    Maintainability

    시장 환경과 요구사항 변화에 지속적으로 대응할 수 있는 구조

결국 좋은 Low Latency Architecture는 단순히 가장 빠른 시스템이 아니라 성능과 안정성 사이에서 적절한 균형을 가진 시스템입니다.

---

8. FontesFintech의 Low Latency Approach

FontesFintech는 금융 시스템 개발 과정에서 이러한 latency 요소를 전체 데이터 흐름의 관점에서 분석합니다.

특히 다음과 같은 요소를 중요하게 고려합니다.

• Memory Copy 최소화
• 효율적인 Inter-Process Communication
• Context Switch 최소화
• Lock 및 Synchronization 최적화
• Efficient Message Parsing
• Network I/O 최적화
• Critical Path 단순화
• End-to-End Latency 측정

Low Latency는 특정 기술 하나를 적용해서 얻어지는 결과가 아닙니다.

Architecture → Data Flow → Memory → Process → Network → Message Processing

전체 구조를 함께 바라봐야 합니다.

FontesFintech는 C 언어 기반의 금융 시스템 개발 경험을 바탕으로 고성능 Trading System, DMA, FEP 및 Algorithmic Trading Infrastructure를 고객의 요구사항에 맞춰 설계하고 개발합니다.

---

Conclusion

트레이딩 시스템의 latency는 CPU나 네트워크 하나만으로 결정되지 않습니다.

Memory Copy, Context Switch, Lock, Network Processing, Message Parsing과 같은 수많은 요소가 전체 시스템의 성능을 구성합니다.

그리고 가장 중요한 것은 각각의 기술을 무조건 적용하는 것이 아니라, 실제 시스템의 Critical Path를 측정하고 병목을 찾아 적절한 방식으로 최적화하는 것입니다.

 

A Low Latency Trading System is not simply about using faster hardware.

It is about designing a better architecture, data flow, and execution path.

Fast. Efficient. Stable. Maintainable.

That is the approach FontesFintech takes when building high-performance financial trading infrastructure.