증권거래소

증권거래소의 일부는 금융 산업 수직적 세분화에 초점을 맞추고, 기술측면을 강조하며[1], 일부는 공정성에 중심을 둔다[2].

다루는 문제의 규모를 확인해보자면 NYSE는 하루 수십억건 거래[3], HKEX는 하루 2천억건의 주식거래를 처리한다.[4]

 

문제 이해 및 설계 범위 확정

1. 어떤걸 거래할까?  주식, 옵션, 선물 등이 있는데

-> 간단하게 주식만 거래하는 것으로 시작한다. 

2. 새 주문, 주문 취소, 주문 교체 중 어떤 유형의 주문을 지원해야할까?

지정가주문(Limit order), 시장가 주문(market order), 조건부 주문(conditional order)등의 주문 유형을 전부 지원하나? 

-> 새주문 넣고, 체결안된 주문은 취소가 되고, 지정가 주문, 시장가 주문, 조건부 주문이 모두 가능하다ㅏ. 

3. 시간 외 거래가 가능해야하나?

아니다. 시간내 거래만 처리하도록 하자

4. 갖추어야 하는 최소 mvp는 어떻게 설정하나?  사용자 수, 증권 가짓수, 주문수, 거래소 규모

-> 새로운 지정가 주문 접수, 또는 기존 주문 취소 가능

- 주문 체결시 실시간으로 그 사실을 알림

- 호가창 정보는 실시간 갱신

- 호가창은 매수 및 매도 주문 목록이 표시

- 최소 수만명이 사용자가 동시 거랙 ㅏ가능

- 최소 100가지 이상의 주식거래가 가능

- 거래량의 경우 하루 수십억건의 주문이 발생

- 규제시설임으로 위험성 점검이 필요 (애플 주식 한사람당 백만주 이하로 제한하면, 그걸 위반하는 요청은 진행x)

5. 사용자 지갑관리?

- 주문 전 충분한 자금이 있는지 확인

- 체결전 주문이 있을때에는, 해당 주문에 이용된 자금은 다른 주문에 쓰이면 안됌

 

비기능 요구사항

 

- 가용성(availiability):최소 99.9% 거래소의 가용성은 매우 중요하다. 몇 밀리초의 장애로도 평판 손상이된다.  

- 결함 내성: 제품 장애 파급을 줄이기 위해 설계시 결함 내성과 빠른 복구 메커니즘이 필요하다. 

- 지연시간 : 왕복 지연시간은 밀리초 수준이어야하며, 지연시간이 중요하다.

왕복 지연시간은 주문이 거래소에 온 순간부터, 주문의 체결 사실이 고개겡게 반환되는 시점까지다. 

지연시간이 매우 짧으면 사용자들의 거래소 이용경험이 좋게 즉감 체감될 것이다.

- 보안: 거래소는 계정 관리시스템이 필수다. 

법률 및 규정 준수를 위해서, 새 계좌 개설 전에 사용자 신원확인을 위한 KYC(Know Your Client)확인을 수행한다.

시장데이터가 포함된 웹페이지의 공개 자원의 경우에는 DDoS(Distributed Denial-of-Service)[6] 공격을 방지하는 장치를 구비해 두어야한다. 

 

 

개략적 설계안 제시 및 동의 구하기

규모 추정

시스템 설계 규모에 따른, 간단한 계산을 진행해서 규모를 인식해보자. 

 

- 100가지 주문

- 하루 10억 건의 주문

- NY따라서, 월~금, 오전 9시 30분~오후 4시(EST) 영업. 총 6.5시간

- QPS : 10억 / (6.5시간 X 3600) = ~ 43,000

- 최대 QPS : 5XQPS = 43,000 X 5 = 215, 000 거래량은 장 시작 직후, 장 마감 직전에 훨씬 높은 트래픽이 생긴다. 

 

브로커(Broker)

브로커 시스템은 개인 사용자가 증권을 거래하고, 시장데이터를 확인할 수 있도록 편리한 UI를 제공한다.

대부분 개인 고객은 브로커 시스템으로 거래소 거래를 한다. Charles Schwab, Robinhood, ETrade, Fidelity, 하나증권  등이 유명 브로커 회사다. 

 

기관 고객(Institutional client)

기관고객은 전문 증권거래 SW를 사용해서 대량 거래한다. 기관 고객마다 요구사항은 다르다. 연기금은 안정적 수익이 목표이고, 거래빈도가 낮고, 거래량이 많을것이다. 대규모 주문이 시장에 미치는 영향[7]을 최소화 하기위해서 주문분할을 진행한다. 

헤지 펀드는 시장 조성을 전문으로 하면서 수수료 리베이트를 통해서 수익을 얻는다. 아주 낮은 시간으로 거래하길 원한다.

일반 사용자들처럼 웹페이지나 모바일 앱에서 시장 데이터를 확인하게 하면 곤란하다.  

 

지정가 주문(limit order)

지정가 주문은 가격이 고정한 매수 or 매도 주문이다. 시장가 주문과 달리 체결이 즉시 안이뤄질 수 있다. 부분만 체결될 수도 있다.

- LOC

- LOL

 

시장가 주문(Market order)

시장가 주문은 가격을 정하지 않는 주문이다. 시장가로 즉시 체결한다. 체결이 보장되지만 비용손해 가능성이 있다. 급변하는 시장에서 바로 체결을 원할때 유용하다. 

 

 

시장 데이터 수준 

시장가 주문은  미국 주식 시장에는 L1,L2,L3의세가지 정보(price quote) 등급이있다. 

L1 : 시장데이터에는 최고 매수 호가(Best bid price), 매도호가(ask price) 및 수량 (quantity)가 포함된다. 

최고 매수 호가는 구매자가 주식을 지불할 의사가 있는 최고 가격이고, 매도 호가는 매도자가 주식을 팔고자 하는 최저 가격이다. 

L2 : 더 많은 수준의 가격정보를 제공한다. 깊이(depth)는 체결을 기다리는 물량의 호가를 어디까지 보여주는지 나타낸다. 

L3 : L3는 L2에서 더 나아가서, 각 가격에 체결을 기다리는 물량까지 보여준다.

 

봉 차트

특정 기간 동안의 주가이다. 일반적으로 캔들이라고 한다. 하나의 봉 막대로 일정 시간 간격 동안 시장의 시작가, 종가, 최고가, 최저가를 표시한다. 일반적으로 지원하는 기간 설정은 1분, 5분, 1시간, 1주일, 1개월이다.

FIX

FIX는 Financial Information Exchange Protocol, 금융정보교환프로토콜(FIX) 의 약어이다. [8]

기업 중립 통신 프로토콜이다. FIX로 인코딩한 증권 거래의 사례를 보면 아래와 같다.  

 

 

거래 흐름(Trading Flow)

하나의 주문이 다이어그램의 구성요소들 사이에서 어떠한 트랜지션을 흐르는지 추적하며, 동작 Flow를 설명해보겠다. 

위는 지연시간 요건이 매우 엄격하다. 신속한 처리가 중요하다. 

1. 고객이 브로커 웹 또는 모바일 앱을통해서 주문한다. 

2. 브로커가 주문을 거래소에 전송한다.

3. 주문이 클라이언트 게이트웨이를 통해서 거래소로 들어간다.

- 클라이언트   게이트 웨이 : 입력 유효성, 속도 제한, 인증, 정규화 같은 게이트키핑 기능을 수행한다. 

4. 게이트웨이 통과하면, 주문 관리자에게 전달한다.

5. 주문관리자가 위험관리자가 설정한 규칙을 보면서, 주문의 위험성 점검 수행을 진행한다.  

6. 위험성 점검을 통과한 주문은 주문관리자가 지갑에 처리 자금이 충분한지 체크한다. 

7. 주문이 체결 엔진으로 전송된다. 

8. 체결 가능 주문이 발견되면 체결엔진은 매수측과 매도 측에 각각 하나씩 집행을 생성한다. 

9.   시퀀서는 과정을 일정 순서로 기록한다. 나중에 과정을 재생할때 결정론적으로 동일한 결과가 나오도록 보장하기 위해서이다. 

10~14. 주문 집행 사실을 클라이언트에게 다시 과정들을 타고 돌아가서, 전달한다. 

 

시장 데이터 흐름(market data flow) 

하나의 주문이 체결 엔진에서 시작되어서 데이터 서비스를 거쳐서, 브로커에 전달되어 집행되기 까지의 과정 

M1 : 체결 엔진은 주문이 체결되면 집행 기록 스트림(충족기록 스트림)을 만든다. 이 스트림은 시장데이터 게시 서비스로 전송된다. 

M2 : 시장 데이터 게시 서비스는 집행 기록 및 주문 스트림에서 얻은 데이터를 시장데이터로 사용해서 봉 차트와 호가 창을 구성한다. 그리고 시장 데이터를 데이터 서비스로 보낸다.

M3 : 시장 데이터는 실시간 분석 전용 스토리지에 저장된다. 브로커는 데이터 서비스로 실시간 시장 데이터를 읽는다. 브로커는 이 시장 데이터를 고객에게 전달한다.  

 

보고 흐름(Report flow) 

R1~R2 : 보고 서비스는 주문 및 실행 기록에서 보고에 필요한 모든 필드의 값을 모은다음에 그값을 종합해서 만든 기록을 DB에 기록하는 것이다. (고객아이디, Pice, quantity, order_type, filled_quantitiy, remaining_quantity등) 

 

거래흐름 1~14는 중요경로, 시장데이터 흐름과 보고흐름은 그렇지 않다. 두가지는 지연 시간 요구사항이 다르다.

 

거래 흐름 체결엔진(matching engin)

체결엔진(matching engin)은 교차 엔진(cross engine)라고도 부른다. 체결엔진의 주요 역할은 다음과 같다.

1. 각 주문에 대한 주문서(order book) 또는 호가창을 유지 관리해야한다.

특정 주식에 대한 매수 및 매도 주문목록을 의미한다. 

2. 매수 주문과 매도 주문을 연결해야한다.  주문 체결의 결과는 하나의 매수주문과 하나의 매도주문의 연결이다.. 주문이 체결되며 두개  (매수쪽1, 매도쪽1) 의 집행 기록이 만들어진다.

3. 집행 기록 스트림을 시장 데이터로 배포한다. 

 

가용성이 높아야하는 엔진의 체결 순서는 결정론적(deteministic)이어야 한다. 입력으로 주어지는 주문순서가 같으면 체결 엔진이 만드는 집행 기록 순서는 언제나 동일하다. 이러한 결정론적 특성은 고가용성 특성의 뒷받침이된다.

 

시퀀서(Sequencer)

시퀀서는 체결 엔진을 결정론적으로 만들기 위한 핵심 요소이다. 체결 엔진에 주문을 전달하기 전에 순서 ID(Sequnce ID)를 붙여서 보낸다. 체결 엔진이 처리를 끝낸 모든 집행 쌍에도 순서 ID를 붙인다. 

시퀀서에는 입력 시퀀서(Inbound sequencer)와 출력 시퀀서(outbount sequence) 두가지가 있고, 각각 고유한 순서를 유지해야한다. 시퀀서가 만드는 순서 ID는 누락항목을 쉽게 발견해야함으로 일련번호여야 한다. 

1. 시의성(timeliness) 및 공정성(fairness) 

2. 빠른 복구(recovery) 및 재생(replay)

3. 정확한 1회 실행을 보증(exactly-once quarantee)

 

시퀀서는 메세지 큐 역할도 한다. 

체결 엔진에 메세지(수신 주문)을 보내는 큐 역할도 하고,

다른 하나는 주문 관리자에게 메세지(집행 기록)을 회신하는 큐 역할도 자연스레 하게한다. 

주문과, 집행기록 이벤트 우편을 저장하는 우편함으로 볼수있다(근데 순서대로 일련번호로 우편을 정리해야하는) 

 

체결 엔진에 두 개 카프카 이벤트 스트림이 연결되어 있는 것과 비슷하다. 하나는 입력되는 주문용, 다른하나는 출력될 집행 기록용. 

카프카의 지연 시간이 더 짧고 예측 가능하다면 정말로 시퀀서 구현에 카프카를 사용할 수 있었을 것이다. 

 

주문 관리자(order manager) 

한 쪽은 받은 주문을 넘기고, 다른쪽은 체결 엔진으로부터 집행 기록을 받는다. 

1. 종합적 위험 점검 담당 컴포넌트에 주문을 보내서, 검토한다. 설계안에 따라 위험 점검 규칙은 달라질 것이다. 

예시로 사용자 거래량이 하루 100만 달러 미만인지 확인하는것 등이 단순히 있다. 

2. 사용자 지갑에 거래 처리하기에 충분한 자금이 있는지 확인한다. 

3. 주문을 시퀀서에 전달한다. 시퀀서는 받으면 해당 주문에 순서ID를 붙이고, 체결엔진에 보내서 처리한다.

주문에는 많은 속성이 있지만 모든 속성을 체결엔진에 전달할 필요는 없다.

메세지 크기를 줄이기 위해서, 필요한 속성만 전송하게된다.

 

시장 데이터 흐름

시장 데이터 게시 서비스(Market Data Publisher, MDP) 는 체결 엔진에서 집행 기록을 수신하고, 집행 스트림에서 호가창, 봉 차트를 만든다.  호가창 봉차트를 통칭으로 시장 데이터라고 한다.

시장 데이터는 데이터 서비스로 전달해서 해당 서비스 구독자가 사용할 수 있게한다.

보고 흐름

거래 이력, 세금 보고, 규정 준수 여부 보고, 결산(SETTLEMENT) 등 기능을 제공한다. 

보고는 정확성과 규정 준수가 핵심이다. 빠른 것과 지연시간 최소화가 덜중요하다. 

입력 정보의 주문과, 결과나가는 주문 속성을 모두 모아 구성한다.

들어오는 새 주문에는 주문의 세부정보만 있고, 나가는 집행기록에는 주문id, 가격, 수량 및 집행 상태만 있기때문이다.

 

 

 

이 13.6 그림은 증권 주문이 접수되고 체결될 때까지의 전체 흐름을 보여주는 구조도예요.

쉽게 보면 다음 순서입니다.

1. 사용자
   • 로빈후드, 골드만삭스 같은 증권사 앱이나 프로그램에서 매수·매도 주문을 냅니다.
2. 브로커
   • 사용자의 주문을 받아 거래소로 전달할 준비를 합니다.
   • 거래소에서 받은 체결 결과도 다시 사용자에게 돌려줍니다.
3. 클라이언트 게이트웨이
   • 증권사와 거래소 사이의 출입구 역할을 합니다.
   • 외부에서 들어온 주문을 거래소 내부 형식으로 전달하고, 결과를 다시 외부로 보냅니다.
4. 주문 관리자
   • 주문의 상태를 관리하는 핵심 컴포넌트입니다.
   • 주문이 정상인지, 취소되었는지, 일부 체결되었는지 등을 관리합니다.
   • 내부의 지갑은 주문 가능한 자금이나 보유 수량을 확인하는 역할로 이해하면 됩니다.
5. 종합적 위험 점검
   • 주문 금액이 너무 크지 않은지,
   • 계좌에 충분한 돈이나 주식이 있는지,
   • 비정상적인 주문은 아닌지 검사합니다.
6. 시퀀서
   • 여러 주문이 동시에 들어와도 처리 순서가 꼬이지 않도록 순서를 확정합니다.
   • 거래의 공정성과 일관성을 보장하는 역할입니다.
7. 체결 엔진
   • 실제 매수 주문과 매도 주문을 서로 매칭합니다.
   • 가격과 수량이 맞으면 거래가 체결됩니다.
8. 호가창
   • 아직 체결되지 않은 매수·매도 주문을 가격별로 정리해 둔 공간입니다.
   • 예를 들어 “10,000원에 사고 싶다”, “10,100원에 팔고 싶다” 같은 주문들이 쌓입니다.
9. 시장 데이터 게시 서비스
   • 체결가, 매수·매도 호가, 거래량 같은 시장 정보를 외부에 전달합니다.
10. 데이터 서비스

• 시장 데이터를 받아 브로커나 증권사에 제공합니다.
• 사용자는 이 정보를 앱에서 실시간 시세로 보게 됩니다.

1. 보고 서비스와 DB

• 주문 기록과 체결 기록을 저장합니다.
• 나중에 조회, 감사, 정산, 분석에 사용됩니다.

한 문장으로 정리하면,
사용자가 주문을 내면 브로커와 게이트웨이를 거쳐 위험 검사를 받고, 시퀀서가 순서를 정한 뒤 체결 엔진이 매수·매도를 매칭하며, 그 결과는 다시 사용자와 시장 데이터 시스템으로 전달되는 구조입니다.

 

 

API 설계 

고객은 브로커를 통해서 증권 거래소와 작용해서 주문, 체결 조회 시장데이터 조회, 분석을 위한 과거 데이터 다운로드를 수행한다. 

브로커와 클라이언트 게이트웨이 간의 인터페이스 명세 작성에는 RESTful 컨벤션을 사용한다. (데이터 모델절 참고) 

RESTful   API로는 헤지 펀드같은 기관 고객의 지연 시간 요구사항을 충족 못할 수 있다. 

이런 기관에 공급되는 특수 SW는 다른 프로토콜을 사용해야한다. 그러나, 프로토콜이 어떤 특성을 갖든지 아래 기본 기능은 동일하게 제공되어야만 한다. 

 

주문

POST /v1/order

인자

이 엔드포인트는 주문을 처리한다. 인증이 필요하다

- symbol : 주식 나타내는 표시. 자료형 string

- side : 매수 또는 매도. 자료형 string

- price : 지정가 주문의 가격. 자료형 long 

-orderType : limit(지정가) 또는 market(시장가). 이번엔 지정가 주문만, 자료형 String.

-quantity : 주문 수량. 자료형 long

 

 

주문
POST /v1/order

이 엔드포인트는 주문을 처리한다. 인증이 필요하다.

인자
symbol: 주식을 나타내는 심벌(symbol)이다. 자료형 String
side: buy(매수) 또는 sell(매도). 자료형 String
price: 지정가 주문의 가격. 자료형 Long
orderType: limit(지정가) 또는 market(시장가). 이번 장에서는 지정가 주문만 지원함에 유의하자. 자료형 String
quantity: 주문 수량. 자료형 Long

응답

본문(body):
id: 주문 ID. 자료형 Long
creationTime: 주문이 시스템에 생성된 시간. 자료형 Long
filledQuantity: 집행이 완료된 수량. 자료형 Long
remainingQuantity: 아직 체결되지 않은 주문 수량. 자료형 Long
status: new/canceled/filled. 자료형 String
나머지 속성은 입력 인자와 같다.

코드:
200: 성공
40x: 인자 오류/접근 불가/권한 없음
500: 서버 오류

---

집행
GET /v1/execution?symbol={:symbol}&orderId={:orderId}&startTime={:startTime}&endTime={:endTime}

이 엔드포인트는 집행 정보를 질의한다. 인증이 필요하다.

인자
symbol: 주식 심벌. 자료형 String
orderId: 주문의 ID. 선택적 인자(optional). 자료형 String
startTime: 질의 시작 시간. 기원 시간(epoch) 기준. [11] 자료형 Long
endTime: 질의 종료 시간. 기원 시간 기준. 자료형 Long

응답

본문:
executions: 범위 내 모든 집행 기록의 배열. 자료형 Array
id: 집행 기록 ID. 자료형 Long
orderId: 주문 ID. 자료형 Long
symbol: 주식 심벌. 자료형 String
side: buy(매수) 또는 sell(매도). 자료형 String
price: 체결 가격. 자료형 String
orderType: limit(지정가) 또는 market(시장가). 자료형 String
quantity: 체결 수량. 자료형 Long

코드:
200: 성공
40x: 인자 오류/해당 자원 없음/접근 불가/권한 없음
500: 서버 오류

---

호가 창/주문서
GET /v1/marketdata/orderBook/L2?symbol={:symbol}&depth={:depth}

이 엔드포인트는 주어진 주식 심벌, 주어진 깊이 값에 대한 L2 호가 창 질의 결과를 반환한다.

인자
symbol: 주식 심벌. 자료형 String
depth: 반환할 호가 창의 호가 깊이. 자료형 Int
startTime: 질의 시작 시간. 기원 시간 기준. 자료형 Long
endTime: 질의 종료 시간. 기원 시간 기준. 자료형 Long

응답

본문:
bids: 가격과 수량 정보를 담은 배열. 자료형 Array
asks: 가격과 수량 정보를 담은 배열. 자료형 Array

코드:
200: 성공
40x: 인자 오류/해당 자원 없음/접근 불가/권한 없음
500: 서버 오류

---

가격 변동 이력(봉 차트)
GET /v1/marketdata/candles?symbol={:symbol}&resolution={:resolution}&startTime={:startTime}&endTime={:endTime}

주어진 시간 범위, 해상도(resolution), 심벌에 대한 봉 차트 데이터

인자
symbol: 주식 심벌. 자료형 String
resolution: 봉 차트의 윈도 길이(초 단위). 자료형 Long
startTime: 질의 시작 시간. 기원 시간 기준. 자료형 Long
endTime: 질의 종료 시간. 기원 시간 기준. 자료형 Long

응답

본문:
candles: 각 봉의 데이터를 담은 배열. 자료형 Array
open: 해당 봉의 시가. 자료형 Double
close: 해당 봉의 종가. 자료형 Double
high: 해당 봉의 고가. 자료형 Double
low: 해당 봉의 저가. 자료형 Double

코드:
200: 성공
40x: 인자 오류/해당 자원 없음/접근 불가/권한 없음
500: 서버 오류

---
데이터 모델
증권 거래소에는 세 가지 유형의 주요 데이터가 있다. 하나씩 살펴보자.
• 상품, 주문 및 집행
• 호가 창/주문서
• 봉 차트

상품, 주문, 집행
상품(product)은 거래 대상 주식(즉, 심벌)이 가진 속성으로 정의된다. 상품의 유형, 거래에 쓰이는 심벌, UI에 표시될 심벌, 결산에 이용되는 통화 단위, 매매 수량 단위(lot size), 호가 가격 단위(tick size) 등이다. 이 데이터는 자주 변경되지 않는다. 주로 UI 표시를 위한 데이터다. 아무 데이터베이스에나 저장 가능하며, 캐시를 적용하기 좋다.
주문은 매수 또는 매도를 실행하라는 명령이며, 집행 기록은 체결이 이루어진 결과다. 집행 기록(execution)은 충족(fill)이라고도 부른다. 모든 주문이 집행되지는 않는다. 체결 엔진은 하나의 주문 체결에 관여한 매수 행위와 매도 행위를 나타내는 두 개의 집행 기록을 결과로 출력한다.

그림 13.12는 이 세 정보 사이의 관계를 보여주는 논리 모델 다이어그램이다. 데이터베이스 스키마가 아니라는 점에 유의하자.

 

 

주문과 집행 기록은 거래소가 취급하는 가장 중요한 데이터다. 개략적 설계안에 포함된 세 가지 중요 흐름에서 해당 데이터가 아주 조금씩 다른 형태로 이용되는 것을 살펴본 바 있다.

• 중요 거래 경로는 주문과 집행 기록을 데이터베이스에 저장하지 않는다. 성능을 높이기 위해 메모리에서 거래를 체결하고 하드디스크나 공유 메모리를 활용하여 주문과 집행 기록을 저장하고 공유한다. 특히 주문과 집행 기록은 빠른 복구를 위해 시퀀서에 저장하며, 데이터 보관은 장 마감 후에 실행한다. 시퀀서의 효율적 구현 방안은 상세 설계안을 설명하면서 살펴보겠다.
• 보고 서비스는 조정이나 세금 보고 등을 위해 데이터베이스에 주문 및 집행 기록을 저장한다.
• 집행 기록은 시장 데이터 프로세서로 전달되어 호가 창/주문서와 봉 차트 데이터 재구성에 쓰인다. 

호가 창

호가 창은 특정 증권 또는 금융 상품에 대한 매수 및 매도 주문 목록으로, 가격 수준별로 정리되어 있다.[12][13] 체결 엔진이 빠른 주문 체결을 위해 사용하는 핵심 자료 구조다. 호가 창의 자료 구조는 다음 요구사항을 만족할 수 있는, 효율성이 높은 것이어야 한다.

• 일정한 조회 시간: 이 요건을 만족해야 하는 작업에는 특정 가격 수준의 주문량 조회, 특정 가격 범위 내의 주문량 조회 등이 포함된다.
• 빠른 추가/취소/실행 속도: 가급적 O(1) 시간 복잡도를 만족해야 한다. 여기 해당하는 작업에는 새 주문 넣기, 기존 주문 취소하기, 주문 체결하기 등이 있다.
• 빠른 업데이트: 여기 해당하는 작업에는 주문 교체 등이 있다.
• 최고 매수 호가/최저 매도 호가 질의
• 가격 수준 순회(iteration)

그림 13.13의 호가 창 예제를 통해 주문이 어떻게 집행되는지 알아보자.

1. 위쪽 박스 (매도 호가 창, 빨간색 계열): 주식을 팔려는 사람들의 주문 현황입니다.
   • 가격: 100.10부터 100.13까지 팔고 싶은 가격들이 나열되어 있습니다.
   • 수량: 각 가격에 얼마나 많은 주식 물량이 쌓여 있는지 사각형 블록의 개수로 시각화되어 있습니다. 가격이 낮을수록 (100.10) 매수자가 먼저 채가기 때문에 '매도 주문 깊이'가 얕고, 가격이 높을수록 (100.13) 깊어지는 것을 볼 수 있습니다.
2. 아래쪽 박스 (매수 호가 창, 파란색 계열): 주식을 사려는 사람들의 주문 현황입니다.
   • 팔려는 가격보다 낮은 100.05부터 100.08까지의 가격들이 나열되어 있습니다.
   • 가장 높은 가격인 100.08이 '최고 매수 주문'이며, 가격이 낮아질수록 더 많은 주문이 쌓이는 것을 블록으로 보여줍니다.
3. 화살표와 아래 계산식: 실제 거래가 체결되는 과정을 설명합니다.
   • 누군가가 시장가로 2700주를 매수하려고 할 때, 가장 저렴한 매도 물량부터 차례대로 사들이게 됩니다.
   • 화살표는 매도 호가창에 쌓여 있던 200, 400, 1100, 100, 900주의 물량들이 차례로 소각(매수)되는 과정을 보여줍니다.
   • 마지막 계산식은 2700주의 주문이 매도 물량들과 매칭되어 최종적으로 사려는 수량이 '0'이 되며 주문이 완료되었음을 나타냅니다.

요약하자면, 이 그림은 주식의 매도 물량과 매수 물량이 가격별로 어떻게 쌓여 있는지, 그리고 대량 주문이 들어왔을 때 어떻게 거래가 체결되는지를 시각적으로 보여주는 자료입니다.

이 예제에서 애플 주식 2,700주에 대한 대량 시장가 매수 주문은 어떻게 처리될까? 최저 매도 호가 큐의 모든 매도 주문과 체결된 후에 호가 100.11 큐의 첫 번째 매도 주문과 체결되며 거래가 끝난다. 이 대량 주문의 체결 결과로 매수/매도 호가 스프레드, 즉 둘 간의 가격 차이가 넓어지고 주식 가격은 한 단계 상승한다(최저 매도 호가는 100.11으로 바뀐다).
다음 코드는 호가 창이 실제로 어떻게 구현되는지 보여 준다.

class PriceLevel {
    private Price limitPrice;
    private long totalVolume;
    private List<Order> orders;
}
class Book<Side> {
    private Side side;
    private Map<Price, PriceLevel> limitMap;
}
class OrderBook {
    private Book<Buy> buyBook;
    private Book<Sell> sellBook;
    private PriceLevel bestBid;
    private PriceLevel bestOffer;
    private Map<OrderID, Order> orderMap;
}

이 코드는 앞서 살펴본 모든 설계 요구사항을 만족할 수 있을까? 예를 들어, 지정가 주문을 추가/취소하는 시간 복잡도가 O(1)인가? 일반 연결 리스트를 사용하고 있으므로 대답은 ‘아니요’다(private List<Order> orders). 

보다 효율적인 호가 창을 만들려면 “orders”의 자료 구조는 이중 연결 리스트(doubly linked list)로 변경하여 모든 삭제 연산(주문 취소나 체결 처리에 필요)이 O(1)에 처리되도록 해야 한다. 이런 연산들의 시간 복잡도가 어떻게 O(1)가 되는지 알아보자.

1. 새 주문을 넣는다는 것은 PriceLevel 리스트 마지막(tail)에 새 Order를 추가하는 것을 의미한다. 이중 연결 리스트에서 이 연산은 O(1)에 처리된다.
2. 주문을 체결한다는 것은 PriceLevel 리스트의 맨 앞(head)에 있는 Order를 삭제한다는 것과 같다. 이중 연결 리스트의 경우 이 연산의 시간 복잡도는 O(1)이다.
3. 주문을 취소한다는 것은 호가 창, 즉 OrderBook에서 Order를 삭제한다는 뜻이다. OrderBook에 포함되어 있는 도움(helper) 자료 구조 Map<OrderID, Order> orderMap을 활용하면 O(1) 시간 내에 취소할 주문을 찾을 수 있다. 주문을 찾았더라도 orders가 단일 연결 리스트였더라면 전체 목록을 순회하여 이전 포인터를 찾아야 주문을 삭제할 수 있으므로 O(n)의 시간이 걸렸을 것이다. 하지만 이중 연결 리스트를 사용하는 경우에는 발견된 Order 안에 이전 주문을 가리키는 포인터가 있으므로 전체 주문 목록을 순회하지 않고도 주문을 삭제할 수 있다.

그림 13.14는 이 세 가지 연산이 어떻게 작동하는지 보여 준다.

 

이 13.14그림의 핵심은 주문을 새로 넣거나, 체결하거나, 취소할 때 전체 주문 목록을 처음부터 뒤지지 않고 바로 찾아가도록 만든 구조예요.

전체 구조부터 보면

왼쪽의 limitMap은 가격별 주문 묶음을 관리합니다.

예를 들어:

• 100.08원에 걸린 주문들
• 100.07원에 걸린 주문들
• 100.06원에 걸린 주문들

이렇게 가격마다 하나의 PriceLevel이 있고, 각 가격 안에는 여러 주문이 연결 리스트 형태로 저장됩니다.

즉 구조는 대략 이렇게 생각하면 됩니다.

100.08원 → [500개 주문] ↔ [600개 주문] ↔ [900개 주문]
100.07원 → [100개 주문] ↔ [700개 주문] ↔ [200개 주문]
100.06원 → [1100개 주문] ↔ [400개 주문] ↔ [300개 주문] ↔ [200개 주문]

 

---

1. 새로운 매수 주문을 넣을 때

그림의 ①번입니다.

새로운 주문이 다음과 같이 들어왔다고 해볼게요.

가격: 100.07
수량: 200

 

먼저 limitMap에서 가격이 100.07인 PriceLevel을 바로 찾습니다.

그다음 그 가격의 주문 목록 맨 뒤에 새 주문을 붙입니다.

기존

[100개] ↔ [700개]

추가 후

[100개] ↔ [700개] ↔ [200개]

 

여기서 tail은 마지막 주문을 가리키고 있기 때문에, 목록 전체를 순회하지 않고 바로 뒤에 붙일 수 있습니다.

그래서 주문 추가가 빠릅니다.

---

2. 주문이 체결됐을 때

그림의 ②번입니다.

100.08 가격의 500개 주문이 체결되었다고 해볼게요.

[500개] ↔ [600개] ↔ [900개]

 

500개 주문은 맨 앞에 있고, head가 이 주문을 가리키고 있습니다.

따라서 체결 엔진은 첫 번째 주문을 바로 꺼낼 수 있습니다.

500개 주문이 완전히 체결되면 목록에서 제거합니다.

제거 전

[500개] ↔ [600개] ↔ [900개]

제거 후

[600개] ↔ [900개]

 

그리고 head는 이제 600개 주문을 가리키게 됩니다.

이것도 첫 번째 주문을 바로 알고 있기 때문에 빠르게 처리할 수 있습니다.

---

3. 주문을 취소할 때

그림의 ③번입니다.

다음 주문을 취소한다고 해볼게요.

가격: 100.06
수량: 400

 

문제는 이 주문이 목록 중간에 있다는 점입니다.

[1100개] ↔ [400개] ↔ [300개] ↔ [200개]

 

단순한 구조라면 1100개 주문부터 하나씩 확인하며 400개 주문을 찾아야 합니다.

하지만 그림에서는 별도의 orderMap을 사용합니다.

HashMap<OrderID, Order> orderMap

 

이곳에는 주문 ID와 실제 주문 객체가 연결되어 있습니다.

주문 ID → 해당 주문의 위치

 

따라서 취소 과정은 두 단계입니다.

Step 1: 주문 ID로 주문을 바로 찾기

orderMap.get(orderId)

 

이렇게 하면 400개 주문 객체를 바로 찾습니다.

Step 2: 연결 리스트에서 해당 주문 제거

400개 주문은 이전 주문과 다음 주문을 알고 있습니다.

이전 주문: 1100개
현재 주문: 400개
다음 주문: 300개

 

따라서 400개 주문을 빼고, 1100개 주문과 300개 주문을 바로 연결합니다.

제거 전

[1100개] ↔ [400개] ↔ [300개]

제거 후

[1100개] ↔ [300개]

 

목록 전체를 검색하지 않아도 됩니다.

---

왜 DoubleLinkedList를 사용할까?

각 주문은 두 가지 정보를 가지고 있습니다.

before: 이전 주문
after: 다음 주문

 

그래서 중간 주문을 삭제할 때 양쪽 주문을 바로 연결할 수 있습니다.

단일 연결 리스트였다면 이전 노드를 찾기 위해 처음부터 탐색해야 할 수 있지만, 이중 연결 리스트는 이전 노드와 다음 노드를 둘 다 알고 있습니다.

---

왜 O(1)이라고 하나요?

O(1)은 주문이 100개든 100만 개든, 처리에 필요한 핵심 단계 수가 거의 일정하다는 뜻입니다.

각 작업은 다음처럼 처리됩니다.

작업사용 구조처리 방식

가격 찾기	limitMap	가격으로 바로 조회
신규 주문 추가	tail	맨 뒤에 바로 연결
체결 주문 제거	head	맨 앞 주문 바로 제거
취소 주문 찾기	orderMap	주문 ID로 바로 조회
중간 주문 제거	이중 연결 리스트	앞뒤 노드를 바로 연결

즉, 전체 주문 목록을 매번 처음부터 훑지 않습니다.

한 문장으로 정리하면

이 설계는 가격으로 주문 그룹을 바로 찾고, 주문 ID로 개별 주문을 바로 찾은 뒤, 이중 연결 리스트를 이용해 주문을 빠르게 추가·체결·삭제하는 구조입니다.

봉 차트
봉 차트(candle chart)는 시장 데이터 프로세서가 시장 데이터를 만들 때 호가 창과 더불어 사용하는 핵심 자료 구조다.
봉 차트를 모델링하기 위해서 Candlestick 클래스와 CandlestickChart 클래스를 사용한다. 하나의 봉이 커버하는 시간 범위가 경과하면 다음 주기(interval)를 커버할 새 Candlestick 클래스 객체를 생성하여 CandlestickChart 객체 내부 연결 리스트에 추가한다.

class Candlestick {
    private long openPrice;
    private long closePrice;
    private long highPrice;
    private long lowPrice;
    private long volume;
    private long timestamp;
    private int interval;
}
class CandlestickChart {
    private LinkedList<Candlestick> sticks;
}

봉 차트에서 많은 종목의 가격 이력을 다양한 시간 간격을 사용해 추적하려면 메모리가 많이 필요하다. 어떻게 최적화할 수 있을까? 두 가지 방법이 있다.

1. 미리 메모리를 할당해 둔 링(ring) 버퍼에 봉을 보관하면 새 객체 할당 횟수를 줄일 수 있다.
2. 메모리에 두는 봉의 개수를 제한하고 나머지는 디스크에 보관한다.

이 최적화 방안에 대해서는 “시장 데이터 게시 서비스” 절에서 자세히 살펴보겠다.
시장 데이터는 일반적으로 실시간 분석을 위해 메모리 상주 칼럼형 데이터베이스(가령 KDB[15])에 둔다. 시장이 마감된 후에는 데이터를 이력 유지 전용 데이터베이스에도 저장한다.

 

 

현대 거래소 상세 설계

아마 많은 사람이 놀랄 수 있을것이다. 일부 대형 거래소는 하나의 거대한 서버로 거의 모든걸 운영한다.

극단적이여 보이지만 좋은 교훈들을 얻을 수 있다. 

 

현대 거래소 성능 ~지연시간 = Sum(중요 경로 컴포넌트 실행시간)

지연시간을 줄이는 방법은 

1. 중요 경로 실행 작업 수를 줄이거나

2. 각 작업의 소요시간을 줄이는 것이다. a. 네트워크 및 디스크 사용량 경감 b. 각작업 실행 시간 경감

 

중요 매매 경로에는 다음 컴포넌트가 포함된다. 게이트 웨이 -> 주문 관리자 -> 시퀀서 -> 체결엔진 

중요 경로엔 반드시 필요한 요소만 둔다. 로깅도 심지어 뺀다. 

 

각 작업의 소요시간을 줄이는 방법으로, 개략적 설계안에서 핵심 경로의 구성요소가 네트워크를 통해서 연결된 개별 서버에서 실행된다고 사정했다. 왕복 네트워크 지연시간은 약 500micro sec이다. 

통신하는 컴포넌트가 많으면 총 네트워크 지연시간은 한 자릿수 밀리초 까지 늘어날 것이다. 

시퀀서는 이벤트를 디스크에 저장하는 저장소임으로, 순차적 쓰기 성능 이점을 활용해서 효율 설계를 해도 디스크 액세스 지연시간은 여전히 수십 밀리초 단위일 것이다. [16]

따라서, 네트워크 및 디스크 액세스 지연시간을 모두 고려하면 총 end-to-end 지연시간은 수십 밀리초에 달한다. 

경쟁에 앞서 나가기 위해서 각 거래소는 주로 네트워크 및 디스크 액세스 지연 시간을 줄이거나 없애는 방안을 통해서 수십 마이크로 초로 줄였다. 

그 설계안에 요체는 모든 걸 동일 서버에 배치해서 네트워크를 통하는 구간을 아예 없애는 것이다. 

같은 서버 내의 컴포넌트간 통신은 이벤트 저장소 mmapp[17] 을 통한다. 

 

 

1. 문맥 전환, 즉 컨텍스트 스위치(context switch)가 없다.[18] CPU 1이 주문 관리자의 애플리케이션 루프 처리에 온전히 할당된다.
2. 상태를 업데이트하는 스레드가 하나뿐이라서 락을 사용할 필요가 없고 잠금 경합(lock contention)도 없다.

이 두 가지 모두 p99 지연 시간 경감에 기여한다.

CPU를 고정하는 방안의 단점은 코딩이 더 복잡해진다는 것이다. 엔지니어는 각 작업이 애플리케이션 루프 스레드를 너무 오래 점유하지 않도록 각 작업에 걸리는 시간을 신중하게 분석해야 한다. 그렇지 않으면 후속 작업을 제때 실행하지 못할 수 있다.

다음으로, 그림 13.15 중앙에 ‘mmap’이라고 표시된 긴 직사각형 컴포넌트에 대해 좀 더 자세히 알아보자. ‘mmap’은 파일을 프로세스의 메모리에 매핑하는 mmap(2)라는 이름의 POSIX 호환 UNIX 시스템 콜(system call)을 일컫는다.

mmap(2)은 프로세스 간 고성능 메모리 공유 메커니즘을 제공한다. 메모리에 매핑할 파일이 /dev/shm에 있을 때 성능 이점은 더욱 커진다. /dev/shm은 메모리 기반 파일 시스템이다. dev/shm에 위치한 파일에 mmap(2)을 수행하면 공유 메모리에 접근해도 디스크 I/O는 발생하지 않는다.

최신 거래소는 이를 활용하여 중요 경로에서 가능한 한 디스크 접근이 일어나지 않도록 한다. 서버에서 mmap(2)를 사용하여 중요 경로에 놓인 구성 요소가 서로 통신할 때 이용할 메시지 버스를 구현하는 것이다. 이 통신 경로를 사용하면 네트워크나 디스크에 접근하는 일은 없으며, 메시지 전송에 마이크로초 미만이 걸린다. 이렇게 mmap(2)을 활용하여 만든 이벤트 저장소에 다음에 설명할 이벤트 소싱 설계 패러다임을 결합하면 거래소는 서버에 지연 시간이 낮은 마이크로서비스들을 구축할 수 있게 된다.

우선 애플리케이션 루프부터 살펴보자. 애플리케이션 루프는 흥미로운 개념이다. 이 애플리케이션 루프의 주된 작업 실행 메커니즘은 while 순환문을 통해 실행할 작업을 계속 폴링(polling)하는 것이다. 엄격한 지연 시간 요건을 만족하려면 목적 달성에 가장 중요한 작업만 이 순환문 안에서 처리해야 한다.

이 메커니즘의 목표는 각 구성 요소의 실행 시간을 줄여 전체적인 실행 시간이 예측 가능하도록(가령 p99 지연 시간을 낮추어서) 보장하는 것이다. 다이어그램의 각 상자는 컴포넌트를 나타낸다. 컴포넌트는 서버의 프로세스이다. CPU 효율성을 극대화하기 위해 애플리케이션 루프(주 처리 루프라고 생각하면 된다)는 단일 스레드로 구현하며, 특정 CPU 코어에 고정시킨다. 주문 관리자를 예로 들면 그림 13.16의 다이어그램과 같다.

이 다이어그램에서 주문 관리자의 애플리케이션 루프는 CPU 1에 고정되어 있다. 애플리케이션 루프를 CPU에 고정하면 상당한 이점이 있다:

이제 두 번째 방법을 살펴보자. 종전에 살펴본 개략적 설계안에서는 핵심 경로의 구성요소가 네트워크를 통해 연결된 개별 서버에서 실행된다고 가정하였다. 왕복 네트워크 지연 시간은 약 500마이크로초다. 핵심 경로에 네트워크를 통해 통신하는 컴포넌트가 많으면 총 네트워크 지연 시간은 한 자릿수 밀리초까지 늘어난다. 또한 시퀀서는 이벤트를 디스크에 저장하는 이벤트 저장소다. 순차적 쓰기의 성능 이점을 활용하여 효율적으로 설계한다 해도 디스크 액세스 지연 시간은 여전히 수십 밀리초 단위다. 네트워크 및 디스크 액세스 지연 시간에 대해 자세히 알고 싶다면 [16]을 참고하기 바란다.

네트워크 및 디스크 액세스 지연 시간을 모두 고려하면 총 단대단(end-to-end) 지연 시간은 수십 밀리초에 달한다. 거래소 초창기에는 이 정도도 놀라운 값이었지만, 모든 거래소가 지연 시간을 극도로 낮추는 경쟁에 나서면서 더 이상 충분하지 않게 되었다.

경쟁에서 앞서 나가기 위해 거래소는 주로 네트워크 및 디스크 액세스 지연 시간을 줄이거나 없애는 방안을 통해 중요 경로의 단대단 지연 시간을 수십 마이크로초로 줄였다. 오랜 시간 동안 검증된 그 설계안의 요체는, 모든 것을 동일한 서버에 배치하여 네트워크를 통하는 구간을 없애는 것이다. 같은 서버 내 컴포넌트 간 통신은 이벤트 저장소인 mmap[17]을 통한다(자세한 내용은 곧 설명하겠다).

그림 13.15는 모든 구성요소를 단일 서버에 배치하여 낮은 지연 시간을 달성하는 설계안이다.

이벤트 소싱의 개념은 이해하기 어렵지 않다. 전통적 애플리케이션은 상태를 데이터베이스에 유지한다. 이런 구조에서는 문제가 발생하면 원인을 추적하기가 어렵다. 데이터베이스는 현재 상태만 유지할 뿐, 현재 상태를 초래한 이벤트의 기록은 없다.

 

이벤트 소싱 아키텍처는 현재 상태를 저장하는 대신 상태를 변경하는 모든 이벤트의 변경 불가능한(immutable) 로그를 유지한다. 이 로그를 절대적 진실의 원천으로 삼는 것이다. 그림 13.17은 두 아키텍처의 차이점을 보여 준다.

왼쪽은 일반적인 데이터베이스 스키마다. 주문 상태를 추적하지만 현재 상태에 도달하는 방법에 대한 정보는 포함하지 않는다. 오른쪽은 이벤트 소싱 아키텍처를 따르는 경우다. 주문 상태를 변경하는 모든 이벤트를 추적하므로, 모든 이벤트를 순서대로 재생하면 주문 상태를 복구할 수 있다.

1번 이미지: 주문 관리자의 애플리케이션 루프 스레드

이 그림은 증권 주문이 주문 관리자 내부에서 어떤 스레드를 거쳐 처리되는지 보여줍니다.

전체 흐름을 한 문장으로 정리하면 다음과 같습니다.

외부에서 주문이 들어오면 네트워크 스레드가 주문을 받아 애플리케이션 처리 스레드에 넘기고, 처리 결과로 주문 상태를 갱신한 뒤 다시 네트워크 스레드를 통해 다음 시스템으로 전달합니다.

① 주문이 시스템으로 들어옴

맨 위의 주문은 외부에서 들어오는 주문 요청입니다.

예를 들면 사용자가 다음과 같은 주문을 냈다고 생각하면 됩니다.

삼성전자 10주를 70,000원에 매수해 주세요.

이 요청은 네트워크를 통해 주문 관리자에게 도착합니다.

---

② 입력 스레드 / Netloop가 주문을 받음

첫 번째로 주문을 받는 컴포넌트가 입력 스레드 또는 Netloop입니다.

Netloop는 쉽게 말하면 다음 역할을 합니다.

• 네트워크 연결을 감시함
• 새로운 주문 메시지가 도착했는지 확인함
• 주문 데이터를 읽음
• 읽은 주문을 실제 업무 처리 스레드에 넘김

즉, 입력 스레드는 주문 내용을 깊게 판단하는 역할보다 택배 접수 창구에 가깝습니다.

택배 창구가 물건을 받은 뒤 실제 분류 담당자에게 넘기는 것처럼, 입력 스레드는 주문을 받은 뒤 애플리케이션 루프 스레드에 전달합니다.

---

③ 애플리케이션 루프 스레드가 주문을 처리함

점선 상자 안의 애플리케이션 루프 스레드가 주문 관리자의 핵심 처리 부분입니다.

이 스레드는 입력받은 주문을 하나씩 순서대로 처리합니다.

예를 들어 다음과 같은 작업을 수행할 수 있습니다.

• 주문 형식이 올바른지 검사
• 주문 가능 수량인지 검사
• 주문 번호 생성
• 신규 주문 상태 저장
• 체결 메시지 처리
• 취소·정정 주문 처리
• 주문 상태 변경
• 다음 시스템에 전달할 메시지 생성

그림 안의 세로로 쌓인 작은 칸들은 처리 대기 중인 작업이나 이벤트가 순서대로 쌓이는 모습으로 볼 수 있습니다.

즉, 주문들이 줄을 서 있고 애플리케이션 루프 스레드가 위에서부터 하나씩 처리하는 구조입니다.

---

④ 주문 상태를 갱신함

애플리케이션 루프 스레드가 주문을 처리하면 오른쪽의 주문 상태가 변경됩니다.

예를 들어 주문 상태는 다음처럼 바뀔 수 있습니다.

신규 주문 접수
→ 거래소 전송
→ 일부 체결
→ 전량 체결

 

또는 다음과 같이 바뀔 수도 있습니다.

신규 주문 접수
→ 취소 요청
→ 취소 완료

 

여기서 중요한 점은 애플리케이션 루프 스레드가 단순히 주문을 전달하기만 하는 것이 아니라, 현재 주문이 어떤 상태인지 관리한다는 것입니다.

주문 상태에는 일반적으로 다음 정보가 포함됩니다.

• 주문 번호
• 종목
• 매수 또는 매도
• 주문 수량
• 주문 가격
• 체결 수량
• 미체결 수량
• 현재 주문 상태
• 마지막 변경 시간

---

⑤ 스레드를 특정 CPU 코어에 고정함

그림에서는 애플리케이션 루프 스레드가 1번 CPU 코어에 고정되어 있습니다.

이것을 CPU affinity, 즉 CPU 코어 고정이라고 합니다.

일반적으로 운영체제는 스레드를 여러 CPU 코어 사이에서 이동시킬 수 있습니다.

처음에는 1번 코어에서 실행
→ 잠시 후 3번 코어로 이동
→ 다시 5번 코어로 이동

 

하지만 초고속 주문 시스템에서는 이런 이동이 성능을 불안정하게 만들 수 있습니다.

스레드가 다른 CPU 코어로 이동하면 기존 코어에 저장되어 있던 캐시 데이터를 다시 불러와야 하기 때문입니다.

그래서 주문 처리 스레드를 1번 코어에 고정하면 다음과 같은 장점이 있습니다.

• CPU 캐시를 더 효율적으로 사용
• 스레드 이동 비용 감소
• 주문 처리 지연시간 감소
• 처리 시간이 더 일정해짐
• 갑자기 느려지는 현상 감소

즉, 평균 속도만 빠르게 하는 것이 아니라 주문 처리 속도를 예측 가능하게 만드는 것이 핵심입니다.

증권 시스템에서는 평균 1ms보다도 다음처럼 들쭉날쭉한 응답이 더 위험할 수 있습니다.

0.2ms → 0.3ms → 0.2ms → 갑자기 20ms

 

CPU 코어 고정은 이런 지연시간의 급격한 증가를 줄이기 위한 방법입니다.

---

⑥ 처리된 주문을 다시 Netloop로 전달함

애플리케이션 루프 스레드가 처리를 끝내면 결과를 아래쪽의 Netloop에 전달합니다.

그림에는 아래쪽도 입력 스레드/Netloop라고 적혀 있지만, 흐름상으로는 처리 결과를 외부로 보내는 송신 측 Netloop 또는 네트워크 처리 영역으로 이해할 수 있습니다.

예를 들어 다음과 같은 메시지가 전달될 수 있습니다.

• 거래소로 보낼 신규 주문
• 사용자에게 보낼 주문 접수 결과
• 체결 시스템으로 보낼 주문 정보
• 다른 내부 서버로 보낼 상태 변경 이벤트

---

⑦ 주문이 다음 시스템으로 나감

마지막으로 처리된 주문 메시지가 주문 관리자 밖으로 전달됩니다.

전체 흐름은 다음과 같습니다.

외부 주문 도착
→ 입력 Netloop가 메시지를 수신
→ 애플리케이션 루프 스레드에 전달
→ 주문 검증 및 상태 변경
→ 주문 상태 저장
→ 송신 Netloop로 전달
→ 거래소 또는 다른 시스템으로 전송

 

이 구조를 사용하는 핵심 이유

애플리케이션 루프 스레드 하나가 주문 상태를 순서대로 변경하면 여러 스레드가 동시에 같은 주문을 수정하는 문제를 줄일 수 있습니다.

예를 들어 여러 스레드가 동시에 처리하면 다음과 같은 충돌이 생길 수 있습니다.

스레드 A: 주문을 체결 상태로 변경
스레드 B: 같은 주문을 취소 상태로 변경

 

두 작업이 동시에 실행되면 어떤 상태가 최종 상태인지 꼬일 수 있습니다.

반면 하나의 애플리케이션 루프 스레드가 순차적으로 처리하면 다음처럼 명확해집니다.

1번: 체결 이벤트 처리
2번: 취소 이벤트 처리

 

따라서 이 구조는 다음을 목표로 합니다.

네트워크 입출력과 업무 처리를 분리하고, 중요한 주문 상태 변경은 하나의 스레드에서 순서대로 빠르게 처리한다.

---

2번 이미지: 비 이벤트 소싱과 이벤트 소싱 비교

이 그림은 주문 상태를 저장하는 두 가지 방법을 비교합니다.

왼쪽은 비 이벤트 소싱, 오른쪽은 이벤트 소싱입니다.

예시에서는 주문이 다음과 같이 변합니다.

Order V1: 신규 주문
→ OrderFilledEvent 발생
→ Order V2: 체결된 주문

 

즉, 처음에는 신규 상태였던 주문이 체결 이벤트를 만나 체결 상태로 변경된 상황입니다.

---

왼쪽: 비 이벤트 소싱 아키텍처

비 이벤트 소싱에서는 주문 상태를 테이블의 값으로 직접 저장합니다.

그림의 주문 테이블에는 다음과 같이 저장되어 있습니다.

버전주문 상태

V1	신규
V2	체결

쉽게 말하면 주문 상태의 결과를 저장하는 방식입니다.

주문이 처음 접수되면 다음 상태를 저장합니다.

V1 = 신규

 

나중에 주문이 체결되면 다음 상태를 저장합니다.

V2 = 체결

 

실제 일반적인 데이터베이스에서는 과거 버전을 모두 남기지 않고 현재 행을 직접 수정하기도 합니다.

변경 전: 주문 상태 = 신규
변경 후: 주문 상태 = 체결

 

이 경우 데이터베이스에는 현재 상태인 체결만 남습니다.

---

비 이벤트 소싱의 관점

비 이벤트 소싱은 다음 질문에 답하는 방식입니다.

이 주문은 지금 어떤 상태인가?

데이터베이스를 조회하면 현재 주문 상태를 빠르게 알 수 있습니다.

주문번호: 12345
현재 상태: 체결

 

하지만 현재 상태가 왜 그렇게 되었는지 상세한 과정은 별도 로그가 없다면 알기 어렵습니다.

예를 들어 주문 상태가 체결이라는 것은 알 수 있지만 다음 내용은 바로 알기 어렵습니다.

• 언제 신규 주문이 생성되었는가
• 어떤 체결 이벤트가 발생했는가
• 누가 상태를 변경했는가
• 상태가 어떤 순서로 바뀌었는가
• 중간에 취소 요청이 있었는가

---

비 이벤트 소싱의 장점

구조가 상대적으로 단순합니다.

• 현재 상태 조회가 쉬움
• 일반적인 관계형 데이터베이스에 구현하기 쉬움
• 개발자가 이해하기 쉬움
• 조회 쿼리가 단순함
• 저장 데이터가 상대적으로 적음

예를 들어 다음처럼 바로 조회할 수 있습니다.

 

SELECT order_status
FROM orders
WHERE order_id = 12345;

 

---

비 이벤트 소싱의 단점

상태가 변경된 이유와 과정을 추적하기 어렵습니다.

예를 들어 데이터가 잘못되어 다음과 같은 상태가 되었다고 생각해 보겠습니다.

현재 주문 상태 = 취소 완료

 

현재 값만 저장했다면 다음 질문에 답하기 어렵습니다.

• 누가 취소했는가
• 몇 시에 취소 요청이 들어왔는가
• 취소 전에는 어떤 상태였는가
• 체결 후 취소가 잘못 적용된 것은 아닌가
• 어떤 메시지가 상태 변경을 발생시켰는가

이 문제를 해결하려면 별도의 이력 테이블이나 감사 로그를 추가해야 합니다.

---

오른쪽: 이벤트 소싱 아키텍처

이벤트 소싱에서는 주문의 현재 상태만 저장하는 것이 아니라, 주문에서 발생한 모든 사건을 시간 순서대로 저장합니다.

그림의 이벤트 로그에는 다음과 같이 기록되어 있습니다.

이벤트 순서 번호이벤트 유형

100	NewOrderEvent
101	OrderFilledEvent

뜻은 다음과 같습니다.

100번 이벤트: 신규 주문이 만들어짐
101번 이벤트: 주문이 체결됨

 

현재 상태를 알고 싶다면 이벤트를 처음부터 순서대로 적용합니다.

초기 상태: 주문 없음

100번 NewOrderEvent 적용
→ 주문 상태 = 신규

101번 OrderFilledEvent 적용
→ 주문 상태 = 체결

 

최종적으로 Order V2, 즉 체결 상태가 만들어집니다.

---

이벤트 소싱에서는 이벤트가 원본 데이터임

일반적인 방식에서는 현재 주문 상태가 가장 중요한 원본입니다.

현재 상태 = 체결

 

하지만 이벤트 소싱에서는 이벤트 기록 자체가 원본입니다.

신규 주문 이벤트 발생
→ 주문 체결 이벤트 발생

 

현재 상태는 이 이벤트들을 계산하여 만들어낸 결과입니다.

쉽게 비유하면 다음과 같습니다.

일반적인 상태 저장

은행 통장에 현재 잔액만 적어두는 것과 비슷합니다.

현재 잔액: 100만 원

 

이벤트 소싱

모든 입출금 내역을 저장하는 것과 비슷합니다.

+300만 원 입금
-100만 원 출금
-100만 원 출금
= 현재 잔액 100만 원

 

이벤트 소싱에서는 현재 잔액보다도 입출금 내역 전체가 원본 데이터입니다.

---

이벤트 순서 번호의 의미

그림의 100, 101은 이벤트가 발생한 순서를 나타냅니다.

100: 신규 주문
101: 주문 체결

 

순서 번호가 중요한 이유는 이벤트 적용 순서가 달라지면 결과가 달라질 수 있기 때문입니다.

올바른 순서:

신규 주문 생성
→ 주문 체결

 

잘못된 순서:

주문 체결
→ 신규 주문 생성

 

아직 존재하지 않는 주문을 먼저 체결할 수는 없으므로 이벤트 순서를 정확하게 보장해야 합니다.

---

이벤트를 다시 재생할 수 있음

이벤트 소싱의 가장 큰 특징은 저장된 이벤트를 다시 읽어 현재 상태를 재구성할 수 있다는 점입니다.

이를 이벤트 리플레이 또는 재생이라고 합니다.

NewOrderEvent
→ OrderFilledEvent
→ 현재 상태: 체결

 

예를 들어 주문 상태 테이블이 손상되더라도 이벤트 로그가 남아 있다면 이벤트를 다시 적용하여 상태를 복원할 수 있습니다.

또 특정 시점의 상태도 재현할 수 있습니다.

100번 이벤트까지만 적용

주문 상태 = 신규

 

101번 이벤트까지 적용

주문 상태 = 체결

 

따라서 다음 질문에도 답할 수 있습니다.

10시 30분 당시 이 주문은 어떤 상태였는가?

---

이벤트 소싱의 장점

1. 모든 변경 이력을 추적할 수 있음

어떤 사건 때문에 주문 상태가 바뀌었는지 알 수 있습니다.

신규 주문 생성
→ 주문 접수
→ 부분 체결
→ 추가 체결
→ 전량 체결

 

2. 감사와 장애 분석에 유리함

금융 시스템에서는 다음 질문에 정확히 답할 수 있어야 합니다.

• 주문이 언제 생성되었는가
• 거래소에서 어떤 응답이 왔는가
• 어떤 순서로 상태가 바뀌었는가
• 중복 체결 처리가 있었는가
• 잘못된 이벤트가 적용되었는가

이벤트 로그가 있으면 원인을 추적하기 쉽습니다.

3. 과거 상태를 복원할 수 있음

특정 시점까지 이벤트를 재생하면 그 시점의 주문 상태를 알 수 있습니다.

4. 새로운 기능에 기존 이벤트를 활용할 수 있음

처음에는 주문 처리만 했더라도, 나중에 같은 이벤트를 이용해 다음 기능을 만들 수 있습니다.

• 실시간 주문 모니터링
• 거래 통계
• 이상 거래 탐지
• 고객 알림
• 리스크 관리
• 감사 시스템
• 거래 재현 시스템

---

이벤트 소싱의 단점

이벤트 소싱이 항상 더 좋은 것은 아닙니다. 구조가 훨씬 복잡해집니다.

1. 현재 상태를 얻으려면 이벤트를 계산해야 함

이벤트가 수백만 개라면 매번 처음부터 재생하는 것은 느립니다.

그래서 실제로는 중간 상태인 스냅샷을 저장합니다.

1번부터 10,000번 이벤트까지 계산한 상태 저장
→ 이후에는 10,001번 이벤트부터 적용

 

2. 이벤트를 쉽게 수정하거나 삭제하면 안 됨

이미 발생한 이벤트는 과거 사실을 의미합니다.

따라서 기존 이벤트를 직접 수정하기보다 새로운 보정 이벤트를 추가해야 합니다.

잘못된 이벤트 삭제

 

보다는 다음처럼 처리합니다.

잘못된 체결 이벤트
→ 체결 정정 이벤트 추가

 

3. 이벤트 버전 관리가 필요함

과거에는 다음 형식의 이벤트를 사용했을 수 있습니다.

 

{
  "orderId": 123,
  "price": 70000
}

 

나중에는 필드가 추가될 수 있습니다.

 

{
  "orderId": 123,
  "price": 70000,
  "quantity": 10,
  "market": "KOSPI"
}

 

과거 이벤트와 새로운 이벤트를 모두 읽을 수 있도록 버전 호환성을 관리해야 합니다.

4. 중복 이벤트 처리에 주의해야 함

동일한 체결 이벤트가 네트워크 문제로 두 번 전달될 수 있습니다.

OrderFilledEvent 101 수신
OrderFilledEvent 101 다시 수신

 

이를 두 번 처리하면 체결 수량이 중복 반영될 수 있으므로 이벤트 ID를 확인해 한 번만 적용하는 멱등성 처리가 필요합니다.

---

두 방식의 핵심 차이

구분비 이벤트 소싱이벤트 소싱

저장 대상	현재 상태 또는 상태 버전	발생한 모든 이벤트
핵심 질문	지금 상태가 무엇인가	어떤 사건을 거쳐 지금 상태가 되었는가
현재 상태 조회	간단하고 빠름	이벤트 재생 또는 별도 조회 모델 필요
과거 이력	별도 이력 테이블 필요	이벤트 로그에 자연스럽게 존재
장애 분석	상대적으로 어려움	원인 추적에 유리
과거 상태 복원	어려움	가능
구현 난이도	비교적 낮음	높음
데이터 양	비교적 적음	계속 증가
적합한 시스템	단순 CRUD 서비스	금융·결제·주문·감사 중심 시스템

---

두 이미지를 연결해서 이해하기

첫 번째 그림은 주문 이벤트를 어떤 스레드가 처리하는가를 설명하고, 두 번째 그림은 처리한 결과를 어떤 방식으로 저장하는가를 설명합니다.

두 그림을 합치면 다음과 같은 구조가 됩니다.

1. 네트워크에서 신규 주문이 들어옴
2. 입력 Netloop가 주문을 수신함
3. 애플리케이션 루프 스레드가 주문을 처리함
4. NewOrderEvent를 생성함
5. 이벤트 로그에 저장함
6. 주문 상태를 '신규'로 구성함
7. 체결 메시지가 들어옴
8. OrderFilledEvent를 생성함
9. 이벤트 로그에 저장함
10. 주문 상태를 '체결'로 갱신함

 

결국 첫 번째 그림의 애플리케이션 루프 스레드는 다음과 같은 역할을 할 수 있습니다.

들어온 주문 이벤트를 순서대로 처리하고, 주문 상태를 변경하며, 이벤트 소싱 구조라면 그 변경 원인이 되는 이벤트도 순서대로 저장하는 핵심 실행 스레드입니다.

가장 쉽게 표현하면 다음과 같습니다.

첫 번째 그림 = 주문을 누가, 어떤 순서로 처리하는가
두 번째 그림 = 주문의 변화 과정을 어떻게 기록하는가

 

 

 

 

 

그림 13.18은 mmap 이벤트 저장소를 메시지 버스로 사용하는 이벤트 소싱 설계안이다. 카프카의 펍섭(Pub-Sub) 모델과 아주 비슷하다. 사실, 지연 시간에 대한 엄격한 요구사항만 없었으면 카프카를 사용할 수도 있었을 것이다.
다이어그램에서 외부 도메인(external domain)은 “증권 거래 101” 절에서 소개한 FIX를 사용하여 거래 도메인(trading domain)과 통신한다.

 

• 게이트웨이는 빠르고 간결한 인코딩을 위해 FIX를 SBE(FIX over Simple Binary Encoding)로 변환하고, 각 주문을 이벤트 저장소 클라이언트를 사용하여 미리 정의된 형식의 NewOrderEvent 형태로 전송한다(다이어그램에서는 ‘이벤트 저장소 항목’ 부분을 보기 바란다).
• 체결 엔진에 내장된 주문 관리자는 이벤트 저장소로부터 NewOrderEvent를 수신하면 유효성을 검사한 다음 내부 주문 상태에 추가한다. 그 후 해당 주문은 처리 담당 CPU 코어로 전송된다.
• 주문이 체결되면 OrderFilledEvent가 생성되어 이벤트 저장소로 전송된다.
• 시장 데이터 프로세서 및 보고 서비스 같은 다른 구성요소는 이벤트 저장소를 구독하고, 이벤트를 받을 때마다 적절히 처리한다.

이 설계는 앞서 살펴본 개략적 설계안에 대체적으로 부합하지만, 이벤트 소싱 아키텍처에서 더 효율적으로 동작할 수 있도록 조정한 부분이 몇 가지 있다.

첫 번째 차이는 주문 관리자다. 이벤트 소싱 아키텍처에서 주문 관리자는 컴포넌트에 내장되는 재사용 가능 라이브러리다. 주문 상태는 많은 컴포넌트에 중요하므로 이런 설계가 말이 된다. 다른 컴포넌트가 주문 상태 업데이트 또는 질의를 위해 중앙화된 주문 관리자를 이용하도록 할 경우, 지연 시간은 길어질 수 있다. 보고 서비스처럼 중요 거래 경로에 있지 않은 컴포넌트는 더욱 그렇다. 각 컴포넌트가 주문 상태를 자체적으로 유지하기는 하겠으나 이벤트 소싱 아키텍처의 특성상 그 모두는 전부 동일하며 재현 가능할 것이다.

또 다른 주요 차이점은 이 다이어그램에서는 시퀀서가 없다는 점이다. 어떻게 된 것일까?
이벤트 소싱 아키텍처를 따르게 되면 모든 메시지는 동일한 이벤트 저장소를 사용한다. 이벤트 저장소에 보관되는 항목에는 sequence 필드가 있다. 이 필드의 값은 이벤트 저장소에 있는 시퀀서가 넣는다.

각 이벤트 저장소에는 하나의 시퀀서만 있다. 시퀀서가 여러 개 있으면 이벤트 저장소에 쓰는 권한을 두고 경쟁하게 되므로 좋지 않다. 거래소 같이 바쁜 시스템의 경우에는 락 경합에 낭비할 시간이 없다. 따라서 시퀀서는 이벤트 저장소에 보내기 전에 이벤트를 순서대로 정렬하는 유일한 쓰기 연산 주체다. 개략적 설계에서 살펴본 시퀀서는 메시지 저장소 역할도 하였지만 지금 살펴보는 시퀀서는 한 가지 간단한 작업만 수행하며 아주 빠르다. 그림 13.19는 메모리 맵(mmap) 환경에서의 시퀀서 설계를 보여 준다.

이 시퀀서는 각 컴포넌트에 고유한 링 버퍼에서 이벤트를 가져온다. 각 이벤트에 순서 ID를 찍은 다음 이벤트 저장소로 보낸다. 주 시퀀서가 다운될 경우를 대비해, 백업 시퀀서를 두면 가용성을 높일 수 있다.

고가용성

본 설계안은 99.99%의 가용성을 염두에 두고 설계하였다. 거래소가 다운될 수 있는 시간은 하루에 8.64초를 넘으면 안 된다는 뜻이다. 따라서 서비스가 다운되면 즉각 복구해야 한다.
가용성을 높여야 할 때는 다음과 같은 사항을 살펴보아야 한다.

• 첫째로, 거래소 아키텍처의 단일 장애 지점(SPOF)을 식별해야 한다. 예를 들어 체결 엔진에 발생하는 장애는 거래소에는 재앙이다. 따라서 주 인스턴스를 다중화해야 한다.
• 둘째, 장애 감지 및 백업 인스턴스로의 장애 조치 결정이 빨라야 한다.

클라이언트 게이트웨이와 같은 무상태(stateless) 서비스의 경우, 서버를 추가하면 쉽게 수평적 확장이 가능하다. 하지만 주문 관리자나 체결 엔진처럼 상태를 저장하는 컴포넌트는, 사본 간에 상태 데이터를 복사할 수 있어야 한다.

그림 13.20은 데이터를 복사하는 사례다. 주 체결 엔진은 소위 주 인스턴스이고, 부 체결 엔진은 동일한 이벤트를 수신하고 처리하지만 이벤트 저장소로 이벤트를 전송하지는 않는다. 주 인스턴스가 다운되면 부 인스턴스는 즉시 주 인스턴스 지위를 승계한 후 이벤트를 전송한다. 부 인스턴스가 다운된 경우, 일단 재시작 하고 나서 이벤트 저장소 데이터를 사용해 모든 상태를 복구한다. 이벤트 소싱 아키텍처는 거래소에 적합하다. 그 결정론적(deterministic) 특성 때문에 상태 복구가 쉽고 정확하기 때문이다.

이 아키텍처에서는 주 체결 엔진의 문제를 자동 감지할 메커니즘이 필요하다. 하드웨어와 프로세스를 모니터링하는 일반적인 방안 외에도, 체결 엔진과 박동 메시지를 주고받는 방안도 생각해 볼 수 있다. 박동 메시지를 시간 내에 받지 못하면 체결 엔진에 문제가 있는 것으로 판단하는 것이다.

이 주/부 체결 엔진 설계안의 문제점은 단일 서버 안에서만 동작한다는 것이다. 고가용성을 달성하려면 이 개념을 여러 서버 또는 데이터 센터 전반으로 확장해야 한다. 주/부 체결 엔진이 아니라 주/부 서버의 클러스터를 구성해야 한다는 뜻이다. 아울러 주 서버의 이벤트 저장소는 모든 부 서버로 복제해야 한다. 이벤트 저장소를 여러 서버로 복제하는 데는 시간이 걸린다. 안정적 UDP(reliable UDP)를 사용하면 모든 부 서버에 이벤트 메시지를 효과적으로 브로드캐스트(broadcast)할 수 있다.[19] 그런 사례로는 [20]에서 다루는 에어론(Aeron)의 설계를 참고하기 바란다.

다음 절에서는 주/부 체결 엔진 기반의 설계안을 개선하여 가용성을 더 높이는 방안을 살펴보겠다.

결함 내성

위의 주/부 설계안은 비교적 간단하다. 비교적 잘 작동하지만 부 서버까지 전부 다운되면 어떻게 될까? 확률은 낮지만 치명적인 상황이 발생할 수 있으므로 이에 대비해야 한다.

이는 대형 기술 기업이 직면한 문제다. 이런 기업들은 핵심 데이터를 여러 지역의 데이터센터에 복제하여 이 문제를 해결한다. 이를 통해 지진이나 대규모 정전과 같은 자연재해의 위험을 완화할 수 있다. 결함 내성(fault-tolerant) 시스템을 만들려면 많은 질문에 답해야 한다.

1. 주 서버가 다운되면 언제, 그리고 어떻게 부 서버로 자동 전환하는 결정을 내리나?
2. 부 서버 가운데 새로운 리더는 어떻게 선출하는가?
3. 복구 시간 목표(Recovery Time Objective, RTO)는 얼마인가?
4. 어떤 기능을 복구해야 하는가(Recovery Point Objective, RPO)? 시스템이 성능 저하 상태로도 동작할 수 있는가?

이 질문에 하나씩 답해 보자.

먼저, ‘장애가 생겼다는 것’, 즉 다운되었다는 것이 실제로 무엇을 의미하는지 이해해야 한다. 생각만큼 간단하지 않은 문제다. 다음과 같은 상황들을 고려해보자.

1. 시스템에서 잘못된 경보를 전송하면 불필요한 장애 극복 절차, 즉 부 시스템으로의 자동 전환이 발생할 수 있다.
2. 코드의 버그로 인해 주 서버가 다운되었다면 부 서버로 자동 전환되더라도 같은 버그 때문에 부 서버까지 다운될 수 있다. 그 결과 모든 주/부 서버가 중단되면 시스템은 더 이상 사용할 수 없는 상태에 빠진다.

이는 해결하기 어려운 문제다. 몇 가지 해결책을 생각해 볼 수 있다. 새 시스템을 처음 출시할 때는 수동으로 장애 복구 조치를 수행한다. 충분한 시그널, 운영 경험을 축적하여 시스템에 자신이 생기면 그때 자동으로 장애를 감지하여 복구하는 프로세스를 도입하는 것이다. 카오스 엔지니어링(chaos engineering)[21]은 드물게 발생하는 까다로운 사례를 수면으로 이끌어내고 운영 경험을 빠르게 축적하는 데 좋은 방법이다.

이제 장애 복구 조치를 시작한다는 결정은 자동으로 올바르게 내릴 수 있게 되었다고 하자. 어떤 서버가 주 서버 역할을 인계 받을지는 어떻게 정하면 좋을까? 다행히도 이것은 잘 알려진 문제다. 실전에서 검증된 리더 선출 알고리즘이 많다. 여기서는 래프트(Raft)를 예로 들어 보겠다.[22]

 

 

 

왼쪽은 “이벤트를 한 줄로 순서대로 정리하는 방법”, 오른쪽은 “그 이벤트를 여러 서버에 똑같이 복제하는 방법”을 보여줘요.

1. 왼쪽 이미지: 시퀀서 설계

핵심은 게이트웨이와 체결 엔진에서 발생한 데이터를 시퀀서가 한곳에 모아 순서를 정한 뒤 저장하는 구조예요.

① 게이트웨이와 체결 엔진이 링 버퍼에 기록

게이트웨이는 외부에서 들어온 주문을 받습니다.

예를 들어 사용자가 매수 주문을 보내면 게이트웨이는 그 주문 정보를 바로 디스크에 저장하지 않고, 먼저 링 버퍼에 넣습니다.

체결 엔진도 주문 처리 결과를 자기 링 버퍼에 넣습니다.

게이트웨이 → 링 버퍼
체결 엔진 → 링 버퍼

 

링 버퍼는 쉽게 말하면 아주 빠른 임시 대기 줄이에요.

디스크에 바로 기록하는 것보다 메모리에 먼저 넣는 것이 훨씬 빠르기 때문에, 주문 처리 속도를 떨어뜨리지 않습니다.

---

② 시퀀서가 두 링 버퍼의 데이터를 가져옴

시퀀서는 게이트웨이와 체결 엔진의 링 버퍼에서 데이터를 가져옵니다.

그림에 있는 pull은 시퀀서가 데이터를 기다리는 것이 아니라, 직접 링 버퍼를 확인해서 가져온다는 뜻이에요.

시퀀서의 가장 중요한 역할은 각 이벤트에 순서를 붙이는 것입니다.

예를 들어 동시에 이런 이벤트가 발생했다고 해볼게요.

신규 주문 발생
주문 체결 발생
다른 신규 주문 발생

 

시퀀서는 이를 다음처럼 정리합니다.

1번 이벤트: 신규 주문
2번 이벤트: 주문 체결
3번 이벤트: 신규 주문

 

이렇게 해야 나중에 시스템이 이벤트를 다시 읽을 때도 정확히 같은 순서로 재현할 수 있습니다.

---

③ 시퀀서가 이벤트 저장소에 기록

순서가 정해진 이벤트는 mmap 기반 이벤트 저장소에 순서대로 저장됩니다.

[1번 이벤트][2번 이벤트][3번 이벤트][4번 이벤트]...

 

여기서는 기존 데이터를 수정하기보다 새로운 이벤트를 뒤에 계속 붙이는 방식으로 동작합니다.

즉, 시퀀서는 다음 역할을 해요.

여러 곳에서 동시에 발생한 이벤트를 모아서 하나의 정확한 순서로 정리하고 저장한다.

---

왼쪽 이미지의 핵심

시퀀서가 없다면 게이트웨이와 체결 엔진이 동시에 저장하면서 이벤트 순서가 뒤섞일 수 있습니다.

시퀀서를 두면 모든 이벤트가 한 줄로 정리되기 때문에:

• 이벤트 순서가 명확해지고
• 동시성 충돌을 줄일 수 있으며
• 장애 후 상태를 다시 재현하기 쉬워집니다.

---

2. 오른쪽 이미지: 래프트 클러스터에서 이벤트 복제

오른쪽은 하나의 이벤트 저장소에만 데이터를 두지 않고, 여러 서버에 동일한 이벤트를 복사하는 구조를 보여줍니다.

핵심은 주 서버가 이벤트를 기록하고, 그 이벤트를 여러 부 서버에 똑같이 복제하는 것이에요.

---

주 체결 엔진과 부 체결 엔진

맨 위에는 두 종류의 체결 엔진이 있습니다.

• 주 체결 엔진: 실제로 주문을 처리하는 중심 서버
• 부 체결 엔진: 주 서버에 장애가 생겼을 때 대신 처리할 수 있는 대기 서버

주 체결 엔진은 현재 주문을 처리하고, 부 체결 엔진은 같은 이벤트를 전달받아 상태를 맞춰둡니다.

---

NewOrderEvent 흐름

신규 주문이 이벤트 저장소에 기록되면 NewOrderEvent가 주 체결 엔진으로 전달됩니다.

이벤트 저장소
→ NewOrderEvent
→ 주 체결 엔진

 

주 체결 엔진은 이 이벤트를 보고 주문장에 신규 주문을 추가합니다.

부 체결 엔진도 같은 NewOrderEvent를 받습니다.

그래서 주 서버와 부 서버가 같은 주문 상태를 유지할 수 있습니다.

주 체결 엔진: 신규 주문 반영
부 체결 엔진: 동일한 신규 주문 반영

 

---

OrderFilledEvent 흐름

주 체결 엔진에서 주문이 체결되면 OrderFilledEvent가 발생합니다.

주 체결 엔진
→ OrderFilledEvent
→ 이벤트 저장소

 

즉, 체결 결과도 다시 이벤트로 저장됩니다.

이 덕분에 나중에 다음과 같은 내용을 확인할 수 있습니다.

어떤 주문이 들어왔는지
언제 체결되었는지
얼마나 체결되었는지

 

---

AppendEntries RPCs란?

가운데에 있는 AppendEntries RPCs는 래프트에서 사용하는 복제 메시지입니다.

쉽게 말하면 주 서버가 다른 서버에 이렇게 말하는 거예요.

“내 이벤트 저장소에 새 이벤트가 생겼으니 너희 저장소에도 똑같이 추가해.”

그래서 첫 번째 이벤트 저장소의 내용이 아래 여러 이벤트 저장소로 복제됩니다.

주 저장소
 ├→ 부 저장소 1
 ├→ 부 저장소 2
 ├→ 부 저장소 3
 └→ 부 저장소 4

 

각 서버의 이벤트 저장소에는 같은 순서의 이벤트가 기록됩니다.

---

왜 여러 곳에 복제할까?

이벤트를 한 서버에만 저장하면 그 서버가 고장났을 때 주문 기록을 잃을 수 있습니다.

반면 여러 서버에 복제해두면:

• 주 서버가 고장나도 다른 서버가 이어받을 수 있고
• 데이터 유실 가능성이 줄어들며
• 장애 복구가 빨라집니다.

즉, 오른쪽 그림은 고가용성과 장애 대응을 위한 구조예요.

---

두 이미지를 함께 이해하면

전체 흐름은 다음과 같습니다.

1. 게이트웨이와 체결 엔진에서 이벤트 발생
2. 링 버퍼에 임시 저장
3. 시퀀서가 이벤트 순서를 결정
4. 이벤트 저장소에 기록
5. 래프트가 여러 서버에 이벤트를 복제
6. 주 서버 장애 시 부 서버가 대신 동작

 

한 문장씩 정리하면

왼쪽 이미지:
시퀀서는 여러 곳에서 발생한 이벤트를 모아 정확한 순서를 붙인 뒤 이벤트 저장소에 기록합니다.

오른쪽 이미지:
래프트는 저장된 이벤트를 여러 서버에 동일하게 복제해, 서버 장애가 발생해도 시스템이 계속 동작하도록 합니다.

리더 선출 과정을 간단히 살펴보자. 리더는 팔로어에게 박동 메시지(그림 13.21에 표시된 것처럼 내용이 없는 AppendEntries 호출)를 보낸다. 일정 기간 동안 박동 메시지를 받지 못한 팔로어는 새 리더를 선출하는 선거 타이머를 시작한다. 가장 먼저 그 타이머가 타임아웃된 팔로어는 후보가 되고, 다른 나머지 팔로어에게 투표를 요청한다(RequestVote 호출). 그 팔로어가 과반수 이상의 표를 받으면 새로운 리더가 된다. 첫 번째 팔로어의 임기(term) 값이 새 노드보다 짧으면 리더가 될 수 없다. 여러 명의 팔로어가 동시에 후보가 되는 경우는 분할 투표라고 한다. 이 경우 기존 선거의 타임아웃을 선언하고 새로운 선거를 시작한다. ‘임기’에 대한 설명은 그림 13.22를 참조하라. 시간 축이 정상 운영 기간과 선거 기간을 나타내는 임의 구간으로 분할되어 있으며, 이 각 구간이 어떤 리더의 임기다.

다음으로 복구 시간을 살펴보자. 복구 시간 목표(Recovery Time Objective, RTO)는 애플리케이션이 다운되어도 사업에 심각한 피해가 없는 시간의 최댓값이다. 증권 거래소의 경우, 2등급(second-level) RTO를 달성해야 하는데 그러려면 서비스의 자동 복구가 반드시 가능해야 한다. 이를 위해 우선순위에 따라 서비스를 분류하고 최소 서비스 수준을 유지하기 위한 성능 저하 전략(degradation strategy)을 정의한다.

마지막으로 데이터 손실이 허용될 수 있는 범위를 파악해야 한다. 복구 지점 목표(Recovery Point Objective, RPO)는 비즈니스에 심각한 피해가 발생하기 전에 손실될 수 있는 데이터의 양, 즉 손실 허용 범위를 의미한다. 실무에서는 ‘데이터는 자주 백업해야 한다’는 것과 같은 뜻으로 받아들인다. 증권 거래소는 데이터 손실을 용납할 수 없으므로 RPO가 거의 0에 가깝다. 래프트 메커니즘을 사용하면 데이터 사본은 많다. 모든 클러스터 노드가 같은 상태를 갖도록 보장할 수도 있다. 현재 리더에 장애가 생기면 새로운 리더가 중단 없이 작업을 계속할 수 있다.

체결 알고리즘
잠시 방향을 틀어, 체결 알고리즘을 자세히 살펴보자. 다음 의사 코드(pseudo code)는 체결이 어떻게 이루어지는지 개략적으로 설명한다.

return SUCCESS(MATCH_SUCCESS, order);
}

이 의사 코드는 FIFO(선입선출) 체결 알고리즘을 사용한다. 특정 가격 수준에서 먼저 들어온 주문이 먼저 체결되고, 마지막 주문이 가장 나중에 체결된다.
체결 알고리즘은 많다. 이런 알고리즘들은 선물 거래에 흔히 사용된다. 예를 들어, FIFO에 LMM(Lead Market Maker)을 결합한 알고리즘의 경우, FIFO 대기열보다 LMM에 먼저 일정 수량을 할당한다. 그 비율은 LMM 회사가 거래소와 협상하여 결정한다. CME 웹사이트에 가면 체결 알고리즘으로 어떤 것이 있는지 확인할 수 있다.[24] 체결 알고리즘은 다른 많은 시나리오에도 이용되는데, 대표적으로 다크 풀(dark pool)이 있다.[25]

결정론
결정론(determinism)에는 기능적 결정론(functional determinism)과 지연 시간 결정론(latency determinism)이 있다. 기능적 결정론에 대해서는 앞서 설명한 바 있다. 시퀀서나 이벤트 소싱 아키텍처를 도입함으로써 이벤트를 동일한 순서로 재생하면 항상 같은 결과를 얻을 수 있도록 보장하였는데, 그것이 기능적 결정론이다.

 

기능적 결정론에서는 이벤트가 발생하는 실제 시간은 대체로 중요하지 않다. 중요한 것은 순서다. 그림 13.23에서는 시간 축 위에 불규칙하게 나열된 타임스탬프들이 연속된 점들로 변환되었는데, 그렇게 되면 재생과 복구에 소요되는 시간이 크게 줄어든다.

지연 시간 결정론은 각 거래의 처리 시간이 거의 같다는 뜻이다. 사업에서 가장 중요한 부분이다. 이를 측정하는 수학적인 방법은, 99번 백분위수 지연 시간(p99)이나 99.99번 백분위수 지연 시간을 재는 것이다. 지연 시간 계산에는 HdrHistogram을 활용할 수 있다.[26] p99 지연 시간이 낮다는 것은 거래소가 거의 모든 거래에 안정적인 성능을 제공한다는 뜻이다.
지연 시간 변동 폭이 커지면 원인을 조사해야 한다. 자바의 경우에는 안전 지점(safe points)이 원인인 경우가 많다. 핫스팟 JVM의 Stop-the-World 쓰레기 수집 알고리즘이 그 사례다.[27]
이것으로 주요 거래 경로에 대한 상세 설계는 마친다. 이번 장의 나머지 지면에서는 거래소의 다른 흥미로운 측면을 자세히 살펴보도록 하겠다.

시장 데이터 게시 서비스 최적화
체결 알고리즘에서 알 수 있듯이 L3 호가 창/주문서 데이터를 보면 시장을 더 잘 파악할 수 있다. 구글 파이낸스(Google Finance) 사이트에 가면 하루치 봉 차트 데이터는 무료로 얻을 수 있지만 더 자세한 L2/L3 호가 창 데이터를 얻으려면 돈이 많이 든다. 많은 헤지 펀드가 거래소 실시간 API를 통해 데이터를 직접 기록하여 봉 차트를 비롯해 기술적 분석을 위한 많은 차트를 자체적으로 구축한다.
시장 데이터 게시 서비스(Market Data Publisher, MDP)는 체결 엔진의 체결 결과를 받아 이를 기반으로 호가 창과 봉 차트를 재구축한 다음 구독자에게 그 데이터를 게시(publish)한다.
호가 창 재구축 과정은 위의 “체결 알고리즘” 절에서 다룬 의사 코드와 유사하다. MDP는 다양한 수준의 서비스를 제공한다. 예를 들어 개인 고객은 기본적으로 다섯 레벨의 L2 데이터만 볼 수 있으며 열 개 레벨을 보려면 추가 비용을 지불해야 한다. MDP의 메모리는 무한대로 확장할 수 없으므로 봉 차트에는 상한선을 두어야 한다. 봉 차트에 대해서는 데이터 모델 절을 참고하기 바란다. 

 

그림 13.24는 MDP 설계를 보여 준다.

이 설계안은 링 버퍼를 활용한다. 원형 버퍼(circular buffer)라고도 하는 링 버퍼는 앞과 끝이 연결된 고정 크기 큐다. 여기에 생산자는 계속 데이터를 넣고, 하나 이상의 소비자는 데이터를 꺼낸다. 링 버퍼의 공간은 사전에 할당된 것이다. 객체를 생성하거나 삭제하는 연산은 필요 없다는 뜻이다. 또한 이 데이터 구조는 락을 사용하지 않는다. 그 외에도 데이터 구조를 더 효율적으로 만들 방법들은 있다. 예를 들어 패딩(padding)은 링 버퍼의 순서 번호가 다른 것과 같은 캐시 라인(cache line)에 오지 않도록 한다. 상세한 내용은 [28]을 참고하기 바란다.

시장 데이터의 공정한 배포
거래소에서 다른 사람보다 지연 시간이 낮다는 것은 미래를 예측할 수 있다는 것이나 같다. 규제를 받는 거래소의 경우 모든 수신자가 동시에 시장 데이터를 받을 수 있도록 보장하는 것이 중요하다. 왜일까? 예를 들어 MDP는 데이터 구독자 목록을 갖고 있는데, 구독자 순서는 게시 서비스에 연결한 순서에 따라 결정되며, 항상 첫 번째 구독자가 먼저 데이터를 수신한다고 하자. 그러면 어떻게 될까? 똑똑한 고객들은 시장이 열리면 첫 번째 구독자가 되기 위해 달려들 것이다.
이를 완화할 수 있는 몇 가지 방법이 있다. 안정적 UDP를 사용하는 멀티캐스트(multicast)는 한 번에 많은 참가자에게 업데이트를 브로드캐스트 하기 좋은 솔루션이다. 구독자가 연결하는 순서로 데이터를 주는 대신, 무작위 순서로 주는 방법도 있다. 그 가운데 멀티캐스트 방안에 대해 더 자세히 알아보도록 하자.

멀티캐스트
인터넷에서 데이터는 세 가지 유형의 프로토콜을 통해 전송된다.
- 유니캐스트(unicast): 하나의 출처에서 하나의 목적지로만 보내는 전송 프로토콜이다.
- 브로드캐스트(broadcast): 하나의 출처에서 전체 하위 네트워크로 보내는 방식이다.
- 멀티캐스트(multicast): 하나의 출처에서 다양한 하위 네트워크상의 호스트들로 보내는 방식이다.

거래소 설계에 보편적으로 이용되는 것은 멀티캐스트다. 같은 멀티캐스트 그룹에 속한 수신자는 이론적으로는 동시에 데이터를 수신한다. 그러나 UDP는 신뢰성이 낮은 프로토콜이며 그 데이터그램(datagram)은 모든 수신자에게 도달하지 못할 수도 있다. 재전송을 처리하는 방안이 궁금하다면 [29]를 참고하기 바란다.

코로케이션
앞서 공정성을 강조하기는 하였으나, 많은 거래소가 헤지 펀드 또는 브로커의 서버를 거래소와 같은 데이터 센터에 둘 수 있도록 하는 코로케이션 서비스(colocation service)를 제공한다. 체결 엔진에 주문을 넣는 지연 시간은 기본적으로 전송 경로 길이에 비례한다. 코로케이션 서비스가 공정성을 훼손한다고 보지는 않는다. 유료 VIP 서비스로 본다.

네트워크 보안
거래소는 일반적으로 몇 가지 인터페이스를 공개하고 있으므로 DDoS 공격에 대응할 수 있는 능력을 갖추는 것이 중요하다. 다음과 같은 기술이 흔히 사용된다.
공개 서비스와 데이터를 비공개 서비스에서 분리하여 DDoS 공격이 가장 중요한 클라이언트에 영향을 미치지 않도록 한다. 동일한 데이터를 제공해야 하는 경우에는 읽기 전용 사본을 여러 개 만들어 문제를 격리한다.
자주 업데이트되지 않는 데이터는 캐싱한다. 캐싱이 잘 되어 있으면 대부분의 질의는 데이터베이스에 영향을 미치지 않는다.
디도스 공격에 대비해 URL을 강화한다. 예를 들어 https://my.website.com/data?from=123&to=456과 같은 URL을 사용하면 공격자가 질의 문자열을 변경하여 다양한 요청을 쉽게 만들 수 있다. https://my.website.com/data/recent와 같은 URL이 더 효과적이다. CDN 단에서 캐시할 수도 있다.
효과적인 허용/차단 리스트(safelist/blocklist) 메커니즘을 사용한다. 많은 네트워크 게이트웨이 제품이 이런 기능을 제공한다.
처리율 제한(rate limiting) 기능을 활용한다. DDoS 공격 방어에 자주 사용되는 기능이다.

4단계: 마무리
이 장을 읽고 나면, 여러분은 대형 거래소를 위한 이상적인 배포 모델은 모든 것을 하나의 거대한 서버 또는 단일 프로세스에 배치하는 것이라는 결론에 도달할 것이다. 실제로 일부 거래소는 이런 방식을 따른다.
최근 암호화폐 산업이 발전함에 따라 많은 암호화폐 거래소가 클라우드 인프라를 사용하여 서비스를 배포한다.[30] 일부 탈중앙화 금융 프로젝트는 AMM(Automatic Market Making) 개념을 기반으로 하며, 심지어 호가 창도 없다.
클라우드 생태계가 제공하는 편리함은 설계의 방향을 바꾸었을 뿐 아니라 업계 진입 문턱도 낮추고 있다. 이런 흐름은 금융업에 혁신적인 에너지를 불어넣을 것이다.
이번 장도 성공적으로 마무리한 여러분, 축하한다! 스스로를 마음껏 격려하도록 하자!

참고 문헌
[1] LMAX 거래소(LMAX exchange was famous for its open-source Disruptor). https://www.lmax.com/exchange
[2] 거래 공정성(IEX attracts investors by “playing fair”, also is the “Flash Boys Exchange”). https://en.wikipedia.org/wiki/IEX
[3] NYSE 거래 체결 규모(NYSE matched volume). https://www.nyse.com/markets/us-equity-volumes
[4] HKEX 일일 거래 규모(HKEX daily trading volume). https://www.hkex.com.hk/Market-Data/Statistics/Consolidated-Reports/Securities-Statistics-Archive/Trading_Value_Volume_And_Number_Of_Deals?sc_lang=en#select1=0
[5] 전세계 거래소 규모 순위(All of the World's Stock Exchanges by Size). http://money.visualcapitalist.com/all-of-the-worlds-stock-exchanges-by-size/
[6] DDoS 공격(Denial of service attack). https://en.wikipedia.org/wiki/Denial-of-service_attack
[7] 시장 영향(Market impact). https://en.wikipedia.org/wiki/Market_impact
[8] FIX 트레이딩(Fix trading). https://www.fixtrading.org/
[9] 이벤트 소싱(Event Sourcing). https://martinfowler.com/eaaDev/EventSourcing.html
[10] CME 코로케이션 및 데이터 센터 서비스(CME Co-Location and Data Center Services). https://www.cmegroup.com/trading/colocation/co-location-services.html
[11] 기원 시간(Epoch). https://www.epoch101.com/
[12] 호가 창(Order book). https://www.investopedia.com/terms/o/order-book.asp
[13] 호가 창(Order book). https://en.wikipedia.org/wiki/Order_book
[14] 고속 지정가 주문 호가 창 구축법(How to Build a Fast Limit Order Book). https://bit.ly/3ngMtEO
[15] kdb+와 q 언어를 통한 개발(Developing with kdb+ and the q language). https://code.kx.com/q/
[16] 모든 프로그래머가 알아야 하는 지연 시간 수치(Latency Numbers Every Programmer Should Know). https://gist.github.com/jboner/2841832
[17] mmap. https://en.wikipedia.org/wiki/Memory_map
[18] 컨텍스트 스위치(Context switch). https://bit.ly/3pva7A6
[19] 안정적인 UDP 프로토콜(Reliable User Datagram Protocol). https://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol
[20] 에어론(Aeron). https://github.com/real-logic/aeron/wiki/Design-Overview
[21] 카오스 엔지니어링(Chaos engineering). https://en.wikipedia.org/wiki/Chaos_engineering
[22] 래프트(Raft). https://raft.github.io/
[23] 이해 중심적 설계: 래프트의 합의 알고리즘(Designing for Understandability: the Raft Consensus Algorithm). https://raft.github.io/slides/uiuc2016.pdf
[24] 지원되고 있는 체결 알고리즘 목록(Supported Matching Algorithms). https://bit.ly/3aYoCEo
[25] 다크 풀(Dark pool). https://www.investopedia.com/terms/d/dark-pool.asp
[26] HdrHistogram: A High Dynamic Range Histogram. http://hdrhistogram.org/
[27] 핫스팟 가상 머신(HotSpot virtual machine). https://en.wikipedia.org/wiki/HotSpot_(virtual_machine
[28] 캐시 라인 패딩(Cache line padding). https://bit.ly/3lZTFWz
[29] NACK 기반의 안정적 멀티캐스트(NACK-Oriented Reliable Multicast). https://en.wikipedia.org/wiki/NACK-Oriented_Reliable_Multicast
[30] AWS 코인베이스 사례 연구(AWS Coinbase Case Study.) https://aws.amazon.com/solutions/case-studies/coinbase/