저지연 트레이딩 시스템에서 Memory Copy가 중요한 이유 | Trading Engineering #9

저지연 트레이딩 시스템에서 Memory Copy가 중요한 이유

Trading Engineering Series — 09

저지연 트레이딩 시스템에서 latency를 줄이기 위해서는 CPU 성능이나 네트워크 속도뿐만 아니라 데이터가 메모리 사이에서 어떻게 이동하는지도 살펴봐야 합니다.

하나의 데이터가 여러 프로세스와 모듈을 거치면서 반복적으로 복사되면, 각각의 작업은 작더라도 전체 시스템에서는 상당한 processing overhead가 될 수 있습니다.

특히 시장 데이터와 주문처럼 높은 빈도로 처리되는 데이터에서는 Memory Copy가 latency-critical path의 중요한 요소가 될 수 있습니다.

---

1. 데이터는 시스템 안에서 계속 이동한다

트레이딩 시스템의 데이터 흐름을 단순화하면 다음과 같습니다.

Network → FEP → Application → Strategy → Risk → Order → FEP → Network

각 단계에서 데이터를 처리하기 위해 Buffer가 사용될 수 있습니다.

예를 들어 하나의 Market Data가 다음과 같이 이동할 수 있습니다.

Network Buffer
↓
FEP Buffer
↓
Application Buffer
↓
Strategy Buffer

각 단계에서 데이터가 새로운 메모리 영역으로 복사된다면, 동일한 데이터가 여러 번 메모리를 이동하게 됩니다.

---

2. Memory Copy는 왜 비용이 발생하는가?

Memory Copy는 단순히 데이터를 복사하는 작업처럼 보입니다.

하지만 실제로는 CPU가 source memory에서 데이터를 읽고 destination memory에 기록하는 작업이 발생합니다.

데이터 크기가 커지고 복사 횟수가 증가하면:

• CPU instruction
• Memory bandwidth
• Cache traffic
• CPU cycle

등의 자원이 사용됩니다.

한 번의 Copy가 매우 빠르다고 하더라도, 초당 수많은 메시지를 처리하는 시스템에서는 누적 비용이 커질 수 있습니다.

특히 불필요한 Copy가 여러 단계에서 반복된다면 전체 latency에 영향을 줄 수 있습니다.

---

3. 작은 데이터도 문제가 될까?

반드시 데이터가 커야만 문제가 되는 것은 아닙니다.

트레이딩 시스템에서는 하나의 메시지가 크지 않더라도 메시지 빈도 자체가 매우 높을 수 있습니다.

예를 들어:

작은 메시지 × 매우 높은 빈도

라는 환경에서는 각각의 처리 비용이 반복적으로 발생합니다.

따라서 저지연 시스템에서는 단순히:

"이 메시지는 작으니까 Copy해도 괜찮다."

라고 판단하기보다,

얼마나 자주 복사되고, 전체 Critical Path에서 몇 번 반복되는가

를 살펴보는 것이 중요합니다.

---

4. Process 간 데이터 전달

여러 프로세스로 구성된 시스템에서는 Memory Copy가 더욱 중요한 문제가 될 수 있습니다.

예를 들어:

Process A → Process B

로 데이터를 전달한다고 생각해 보겠습니다.

일반적인 구조에서는:

Process A Buffer → IPC → Process B Buffer

와 같은 데이터 이동이 발생할 수 있습니다.

이를 여러 단계로 확장하면:

Market Data → Process A → Process B → Process C → FEP

각 프로세스에서 데이터를 다시 복사하는 구조가 만들어질 수도 있습니다.

이러한 구조에서는 IPC와 함께 Memory Copy 비용도 고려해야 합니다.

---

5. Shared Memory를 활용하면?

앞선 7편에서 살펴본 Shared Memory는 이러한 문제를 줄이기 위한 방법 중 하나입니다.

일반적인 데이터 전달:

Process A Buffer → Copy → Process B Buffer

대신:

Process A → Shared Memory ← Process B

와 같이 동일한 메모리 영역을 공유할 수 있습니다.

이를 적절하게 설계하면 프로세스 간에 발생하는 불필요한 Data Copy를 줄일 수 있습니다.

하지만 Shared Memory를 사용한다고 해서 모든 Copy가 자동으로 사라지는 것은 아닙니다.

데이터 구조와 Buffer 설계까지 함께 고려해야 합니다.

---

6. Zero-Copy란 무엇인가?

저지연 시스템에서는 Zero-Copy라는 개념도 자주 등장합니다.

Zero-Copy는 말 그대로 모든 메모리 복사가 완전히 "0번"이라는 의미로 단순하게 이해하기보다는, 데이터 경로에서 불필요한 복사를 최소화하는 설계 방식으로 이해하는 것이 좋습니다.

예를 들어:

Data Source → Buffer → Processing → Destination

과정에서 동일한 데이터를 여러 번 복사하는 대신, 가능한 한 기존 Buffer를 직접 활용하도록 설계할 수 있습니다.

이렇게 하면 데이터 이동에 필요한 CPU 작업과 Memory Traffic을 줄일 수 있습니다.

---

7. Buffer 설계가 중요하다

Memory Copy를 줄이기 위해서는 Buffer 구조도 중요합니다.

예를 들어 고정된 크기의 메시지를 사용하는 경우:

Fixed-size Structure

를 활용하면 동적인 메모리 할당이나 불필요한 데이터 변환을 줄일 수 있습니다.

또한:

• Buffer 재사용
• Memory Pool
• Ring Buffer
• Fixed-size Message
• 명확한 Data Ownership

등의 방법을 활용할 수 있습니다.

특히 고빈도 데이터 처리에서는 반복적인 Memory Allocation과 Free 역시 성능에 영향을 줄 수 있기 때문에 가능한 한 데이터 생명주기를 단순하게 만드는 것이 중요합니다.

---

8. Copy보다 더 중요한 것은 Data Movement

저지연 시스템에서는 단순히 memcpy()의 실행 시간만 측정해서는 충분하지 않습니다.

중요한 것은 전체 Data Movement입니다.

예를 들어:

NIC → Kernel → Application → Strategy → Order

전체 과정에서 데이터가 어디에 존재하고, 어디로 이동하며, 몇 번 복사되는지를 확인해야 합니다.

어떤 경우에는 단순한 Memory Copy보다:

• Cache Miss
• IPC
• Context Switch
• Synchronization
• Memory Allocation

등이 더 큰 비용을 만들 수도 있습니다.

따라서 Memory Copy 최적화는 전체 시스템의 Data Path를 기준으로 접근해야 합니다.

---

9. 모든 Memory Copy를 제거해야 하는가?

그렇지는 않습니다.

Memory Copy는 시스템의 안정성과 구조를 단순하게 만드는 데 도움이 되는 경우도 있습니다.

예를 들어 데이터를 별도의 Buffer로 복사하면:

• 데이터 Ownership이 명확해지고
• 프로세스 간 결합도가 낮아지고
• 원본 데이터의 변경에 영향을 받지 않으며
• 장애 격리가 쉬워질 수 있습니다.

반대로 Copy를 지나치게 제거하면 데이터 구조가 복잡해지고 관리하기 어려워질 수 있습니다.

따라서 중요한 것은:

Copy를 무조건 없애는 것

이 아니라

불필요한 Copy를 없애는 것

입니다.

---

10. Memory Copy와 CPU Cache

Memory Copy를 이해하기 위해서는 CPU Cache도 함께 고려해야 합니다.

CPU는 메인 메모리의 모든 데이터를 동일한 속도로 처리하지 않습니다.

일반적으로 CPU Cache에 있는 데이터는 메인 메모리에 있는 데이터보다 빠르게 접근할 수 있습니다.

따라서 Memory Copy가 발생하면 단순히 데이터의 이동만 생각할 것이 아니라:

• Cache Hit
• Cache Miss
• Cache Line
• Memory Bandwidth
• Core 간 Cache Coherence

등도 함께 고려해야 합니다.

특히 여러 CPU Core가 동일한 데이터를 처리하는 환경에서는 Memory Access Pattern이 성능에 큰 영향을 줄 수 있습니다.

---

11. Trading System에서의 적용

저지연 트레이딩 시스템에서는 다음과 같은 구조를 생각할 수 있습니다.

Market Data
↓
Shared Memory / Ring Buffer
↓
Strategy
↓
Pre-Trade Risk
↓
Order Manager
↓
DMA / FEP
↓
Exchange

이 과정에서 각 단계가 데이터를 어떻게 전달하는지 분석해야 합니다.

가능하다면:

Unnecessary Copy → 제거

Unnecessary Allocation → 제거

Unnecessary IPC → 최소화

Unnecessary Synchronization → 최소화

하는 방향으로 Critical Path를 단순화할 수 있습니다.

---

12. FontesFintech의 접근 방식

FontesFintech는 저지연 시스템을 설계할 때 단순히 특정 API나 기술을 적용하는 방식보다 End-to-End Data Path를 먼저 분석합니다.

주요 고려사항은 다음과 같습니다.

• 불필요한 Memory Copy 최소화
• Buffer 재사용
• Shared Memory
• Ring Buffer
• 효율적인 IPC
• Fixed-size Data Structure
• Memory Allocation 최소화
• CPU Cache 효율성
• 명확한 Data Ownership
• End-to-End Latency 측정

중요한 것은 특정 기술의 사용 여부가 아닙니다.

데이터가 어디에서 시작해서 어디까지 이동하는가?

그리고:

그 과정에서 불필요한 작업이 얼마나 발생하는가?

를 파악하는 것이 핵심입니다.

---

Conclusion

저지연 트레이딩 시스템에서 성능을 높이는 방법은 단순히 더 빠른 CPU나 네트워크를 사용하는 것이 아닙니다.

데이터가 시스템 내부에서 이동하는 과정 역시 최적화의 중요한 대상입니다.

Less Copy
Less Allocation
Less Data Movement

하지만 모든 Memory Copy를 제거하는 것이 정답은 아닙니다.

성능과 안정성, 유지보수성을 함께 고려하면서 Latency-Critical Path에서 불필요한 Data Movement를 줄이는 것이 중요합니다.

결국 좋은 저지연 시스템은 단순히 데이터를 빠르게 처리하는 시스템이 아니라,

필요한 데이터가 필요한 곳으로 가장 적은 비용으로 이동하는 시스템입니다.