Post

(인프라 4) 미니원장 - 나만 쓰는 주문 통로

DMA에서 원장 경유 시 발생하는 지연을 피하기 위해 미니원장을 사용합니다. 원장과 미니원장의 차이, 인메모리 캐시를 통한 저지연 구현, 체결 후 정산(후처리) 과정, 그리고 시스템 홉 수 감소로 얻는 속도 개선 효과를 알아봅니다.

(인프라 4) 미니원장 - 나만 쓰는 주문 통로

이전 글: 코로케이션과 빛의 속도

이 글은 매매 시스템 - 인프라 시리즈의 네 번째 글입니다.

다음 글: Kernel Bypass

원장이 느린 이유

첫 번째 글에서 주문 송신 흐름을 봤습니다. 주문이 거래소로 가기 전에 원장을 거친다고 했죠.

flowchart LR
    OS[주문서버] --> LED[원장]
    LED --> OFEP[주문 FEP]

원장에서는 매 주문마다 이런 일들이 일어납니다:

  1. 계좌 유효성 검사
  2. 비밀번호 인증
  3. 예수금 조회
  4. 주문가능금액 계산 (예수금 - 미결제 - 증거금)
  5. 종목별 증거금율 적용
  6. 신용/대출 한도 확인
  7. 포지션 리밋 체크
  8. 주문 원장 기록

이 과정에서 DB 조회가 반복적으로 발생합니다. 문제는 DB가 별도 서버에 있다는 점입니다.

  • 네트워크 통신: 매 쿼리마다 DB 서버와 왕복해야 합니다
  • 디스크 I/O: 메모리 접근은 나노초 단위지만, 디스크 접근은 밀리초 단위입니다
  • 캐시 보장 없음: 자주 쓰는 데이터가 버퍼풀에 올라와 있을 수 있지만, 보장되지 않습니다. 캐시 미스가 나면 디스크에서 읽어야 합니다

결국 쿼리 하나에 네트워크 왕복 + 디스크 I/O가 붙고, 이게 여러 번 반복됩니다. FEP와 BEP에서 본 것처럼 주문이 여러 시스템을 거치는데, 원장에서 이런 지연이 발생하면 전체 지연이 급격히 늘어납니다.


미니원장이란?

미니원장은 전체 원장 시스템의 경량화 버전입니다. DMA 거래에 필요한 최소한의 정보만 별도로 보관합니다. 전체 원장에는 고객의 모든 정보가 있지만, 미니원장에는 주문 가부를 판단하는 데 필요한 최소한의 정보만 들어갑니다:

  • 내 계좌 ID

  • 신용 한도

  • 현재 포지션

  • 주문 한도

위는 모든 고객의 정보가 아니라 미니원장을 사용하는 트레이더의 정보만을 의미 합니다.


왜 빠른가?

1. 시스템 홉 수 차이

flowchart TB
    subgraph NORMAL [원장 경유]
        direction LR
        A1[Gateway] --> A2[Account]
        A2 --> A3[Ledger DB]
        A3 --> A4[Risk]
        A4 --> A5[OMS]
        A5 --> A6[FEP]
        A6 --> A7[Exchange]
    end
flowchart TB
    subgraph DMA [전용 FEP + 미니원장]
        direction LR
        B1[Dedicated FEP] --> B2[Risk Check]
        B2 --> B3[Exchange]
    end
방식거치는 시스템 수
원장 경유5~7개
전용 FEP2~3개

각 시스템 간 네트워크 통신에 수십 마이크로초가 소요되므로, 홉이 줄어들수록 지연이 줄어듭니다.

2. DB 접근 패턴

방식DB 접근
원장 경유매 주문마다 원장 DB 동기 조회 (디스크 I/O, Lock 경합)
미니원장인메모리 캐시 조회 (나노초 단위)

미니원장은 인메모리로 동작합니다. Redis 같은 인메모리 DB를 쓰거나, 아예 프로세스 메모리에 올려놓습니다. 디스크를 건드리지 않으니 빠를 수밖에 없습니다.

3. 처리 로직 단순화

원장은 앞서 본 것처럼 8단계를 거칩니다. 미니원장은 사전 설정 한도 비교 → 거래소 전송, 2단계면 끝입니다. 복잡한 증거금 계산 대신 비교 연산 한 번이면 됩니다.


체결 후 정산: 후처리

여기서 질문이 생깁니다. 미니원장이 별도로 돌아가면, 원장과 미니원장 사이에 불일치가 생기지 않나요?

맞습니다. 생깁니다. 그래서 동기화 하는 과정을 보통 후처리라고 합니다.

flowchart LR
    ML[Mini Ledger] --> |주문| EX[Exchange]
    EX --> |체결| ML
    ML --> |후처리| MASTER[Master Ledger]
    MASTER --> |동기화| ML

FEP에서 체결 내역을 받으면 미니원장을 업데이트하고, 이 내역을 원장에도 보내서 동기화합니다. 반대로 원장에서 한도나 포지션이 변경되면 미니원장에도 반영합니다.


다음 글에서는

다음 글에서는 kernel bypass에 대해 다룹니다.


This post is licensed under CC BY 4.0 by the author.