대규모 시스템 설계 기초 2 (13장)

증권 거래소

증권 거래 101

브로커

대부분의 개인 고객은 브로커 시스템을 통해 거래소와 거래한다. 로빈후드, 피델리티 등이 유명한 브로커 회사다. 브로커 시스템은 개인 사용자가 증권을 거래하고 시장 데이터를 확인할 수 있도록 편리한 사용자 인터페이스를 제공한다.

기관 고객

기관 고객은 전문 증권 거래 소프트웨어를 사용한다.

지정가 주문

지정가 주문은 가격이 고정된 매도 또는 매수 주문이다.

시장가 주문

시장가 주문은 가격을 지정하지 않는 주문으로, 시장가로 즉시 체결된다. 체결은 보장되나 비용 면에서 손해를 볼 수 있다.

시장 데이터 수준

미국 주식 시장에는 L1, L2, L3 의 3가지 가격 정보 등급이 있다. 단계에 따라서 제공하는 정보가 다르다.

봉 차트

봉 차트는 특정 기간 동안의 주가다. 일정 시간 간격 동안 시작의 시장가, 종가, 최고과, 최저가를 표시할 수 있다.

FIX

FIX 는 금융 정보 교환 프로토콜의 약어다.

개략적 설계안

거래 흐름을 통해 하나의 주문이 어떤 절차로 처리되는지 살펴보자.

1. 고객이 브로커를 통해서 주문한다.
2. 브로커의 주문을 거래소에 전송한다.
3. 주문이 클라이언트 게이트웨이를 통해 거래소로 들어간다. 게이트웨이는 입력 유효성 제안, 인증, 정규화와 같은 게이트키핑 기능을 수행한다.
4. 주문 관리자가 위험 관리자가 설정한 규칙에 따라 위험성 점검을 한다.
5. 위험성 점검을 통과하면, 주문 관리자는 지갑에 주문 처리 자금이 충분한지 확인한다.
6. 주문이 체결 엔진으로 전송된다. 체결 가능 주문에 따라서, 체결 엔진은 매수 측과 매도 측에 2개의 집행 기록을 생성한다.
7. 주문 진행 사실을 클라이언트로 전송한다.

시장 데이터 흐름에 따라서, 주문이 체결 엔진부터 데이터 서비스를 거쳐서 브로커로 전달되기까지의 과정을 확인하자.

1. 체결 엔진은 주문이 체결되면 집행 기록 스트림을 만들며, 이는 시장 데이터 게시 서비스로 전송된다.
2. 시장 데이터 게시 서비스는 집행 기록 및 주문 스트림에서 얻은 데이터를 시장 데이터로 사용하여 봉 차트와 호가 창을 구성한다.
3. 시장 데이터는 실시간 분석 스토리지에 저장되며, 브로커는 데이터 서비스를 통해 시장 데이터를 읽어오고, 이 데이터를 고객에게 전달한다.

보고 흐름도 존재한다.

1. 보고 서비스는 주문 및 실행 기록에서 보고에 필요한 모든 필드의 값을 모은 다음, 그 값을 종합해 만든 레코드를 데이터베이스에 기록한다.

거래 흐름

거래 흐름은 거래소의 핵심이다.

체결 엔진

체결 엔진의 역할은 다음과 같다.

• 각 주식에 대한 주문서, 호가 창을 유지 관리한다.
• 매수 주문과 매도 주문을 연결한다. 주문 체결이 되면, 두 개의 집행 기록을 만든다.
• 집행 기록은 시장 데이터로 배포한다.

체결 순서는 결정론적으로, 입력으로 주어지는 주문 순서에 따라서 집행 기록 순서가 언제나 동일해야 한다.

시퀀서

시퀀서는 체결 엔진을 결정론적으로 만드는 핵심 구성 요소다. 시퀀서는 체결 엔진에 주문을 전달할 때, 순서 ID 를 붙여 보낸다. 또한 체결 엔진이 처리를 끝낸 모든 집행 기록에도 순서를 지켜 남긴다.
시퀀서는 순서 ID 만 생성하는 것이 아니며, 메시지 큐 역할도 한다. 체결 엔진에 메시지를 보내는 큐 역할도 하고, 주문 관리자에게 메시지를 회신하는 큐 역할도 한다.

주문 관리자

주문 관리자는 한쪽에서는 주문을 받고 다른 쪽에서는 집행 기록을 받는다. 주문 상태를 관리하는 것이 주문 관리자의 역할이다.
주문 관리자는 시퀀서를 통해 체결 엔진으로부터 집행 기록을 받는다. 주문 관리자는 체결된 주문에 대한 집행 기록을 클라이언트 게이트웨이를 통해 브로커에 반환한다.

클라리언트 게이트웨이

클라이언트 게이트웨이는 거래소의 문지기로, 클라이언트로부터 주문을 받아서 주문 관리자에게 보낸다. 지연 시간에 민감하며, 가벼워야 한다.

시장 데이터 흐름

시장 데이터 게시 서비스는 체결 엔진에서 집행 기록을 수신하고 집행 기록 스트림에서 호가 창과 봉 차트를 만들어 낸다.

보고 흐름

거래소에서 필수적인 부분 가운데 하나는 보고다. 입력으로 들어오는 주문과 그 결과로 나가는 집행 기록 모두에서 정보를 모아 속성들을 구성하는 것이 일반적 관행이다.

데이터 모델

세 가지 유형의 주요 데이터가 있다.

• 상품, 주문 및 집행
• 호가 창/주문서
• 봉 차트

상품, 주문, 집행

• 상품은 거래 대상 주식이 가진 속성으로 정의된다. 이 데이터는 자주 변질되지 않으며, 캐시를 적용하기도 좋다.
• 주문은 매수 또는 매도를 실행하라는 명령이다.
• 집행 기록은 체결이 이루어진 결과다.

주문과 집행 기록은 거래소가 취급하는 가장 중요한 데이터다.

• 중요 거래 정보는 주문과 집행 기록을 DB 에 저장하지 않고, 메모리에서 거래를 체결한다. 주문과 집행 기록은 빠른 복구를 위해 시퀀서에 저장하며, 데이터 보관은 장 마감 후에 실행한다.
• 보고 서비스는 조정이나 세금 보고 등을 위해 데이터베이스에 주문 및 집행 기록을 저장한다.

호가 창

호가 창은 매수 및 매도 주문 목록으로, 가격 수준별로 정리되어 있다.
호가 창을 구현할 때는, 이중 연결 리스트로 구현해서 모든 삭제 연산이 O(1) 에 처리되도록 해야 한다.

봉 차트

봉 차트는 시장 데이터 프로세서가 시장 데이털들 만들 때 호가창과 더불어 사용하는 핵심 자료 구조다. 봉 차트에서 많은 종목의 가격 이력을 다양한 시간 간격을 사용해 추적해야 한다. 다음과 같은 최적화 방법이 있다.

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

성능

지연 시간은 거래소에 아주 중요한 문제다. 지연 시간을 줄이기 위해서, 중요 매매 경로에는 필수적인 컴포넌트만 둔다. 로깅과 같은 항목도 지연 시간을 줄이기 위해 중요 경로에서는 뺴야 한다.
핵심 경로의 구성요소가 네트워크를 통해 연결된 개별 서버에서 실행된다고 가정해보자. 왕복 네트워크 지연 시간은 약 500 마이크로초다. 핵심 경로에 네트워크를 통해 통신하는 컴포넌트가 많을 수록 지연 시간도 늘어날 것이다.
뿐만 아니라, 시퀀서는 이벤트를 디스크에 저장하는 이벤트 저장소다. 디스크 액세스 지연 시간이 발생할 수 있기 때문이ㅔ 이를 모두 공려하면 지연 시간을 피할 수 없다.
이 문제를 해결하기 위한 설계는, 모든 것을 동일한 서버에 배치하여 네트워크를 통하는 구간을 없애는 것이다.

이벤트 소싱

전통적 어플리케이션은 상태를 db 에 유지한다. 이런 구조에서는 문제가 발생하면 원인을 추적하기 어렵다. 이벤트 소싱 아키텍쳐는 현재 상태를 저장하는 대신, 상태를 변경하는 모든 이벤트의 변경 불가능한 로그를 유지한다.
mmap 이벤트 저장소를 메시지 버스로 사용하는 이벤트 소싱 설계안이 있다. 카프카의 pub/sub 모델과 아주 유사하다. 이벤트 소싱 아키텍쳐를 따르면 시퀀서가 필요 없다. 모든 메시지는 동일한 이벤트 저장소를 사용하는데, 이벤트 저장소에 보관되는 항목에는 sequence 필드가 있기 대문이다.

고가용성

고가용성을 달성하기 위해서는 SPOIF 를 식별해야 하고, 장애 감지 및 백업 인스턴스의 장애 조치 결정이 빨라야 한다.
클라이언트 게이트웨이와 같은 무상태 서비스의 경우, 서버를 추가하면 쉽게 수평적 확장이 가능하다. 하지만, 상태를 저장하는 컴포넌트는 사본 간에 상태 데이터를 복사할 수 있어야 한다.
주 체결 엔진과, 부 체결 엔진을 두자. 주 체결 엔진은 신규 주문 이벤트를 수신하고, 처리한다. 부 체결 엔진은 수신만 할 뿐이다. 주 체결 엔진에 장애가 발생하면 부 체결 엔진이 그 역할을 대신한다.
주 체결 엔진의 문제를 감지할 메커니즘이 필요한데, 체결 엔진과 박동 메시지를 주고 받는 방안도 생각해 볼 수 있다.

체결 알고리즘

체결 코드는, FIFO 알고리즘을 사용할 수 있다. 특정 가격 수준에서 먼저 들어온 주문이 먼저 체결되고, 마지막 주문이 가장 나중에 체결된다.

결정론

경정론에는 기능적 결정론과 지연 시간 결정론이 있다. 시퀀스나 이벤트 소싱 아키텍쳐를 도입하면 기능적 결정론을 달성할 수 있다.
지연 시간 결정론은, 각 거래의 처리 시간이 거의 같다는 뜻이다. 지연 시간 변동 폭이 커지면 원인을 조사해야 한다.

시장 데이터의 공정한 배포

거래소에서 다른 사람보다 지연 시간이 낮다는 것은 미래를 예측할 수 있다는 것이다. 따라서, 모든 수신자가 동시에 시장 데이터를 받을 수 있도록 보장하는 것은 중요하다.
안정적 UDP 를 사용하는 멀티캐스는 한 번에 많은 참가자에게 업데이트를 브로드캐스트 하기 좋은 솔루션이다.

멀티캐스트

인터넷에서 데이터는 3가지 유형의 프로토콜을 통해 전송된다.

1. 유니캐스트 : 하나의 출처에서 하나의 목적지로만 보내는 전송 프로토콜이다.
2. 브로드캐스트 : 하나의 출처에서 전체 하위 네트워크로 보내는 방식이다.
3. 멀티캐스트 : 하나의 출처에서 다양한 하위 네트워크상의 호스트들로 보내는 방식이다.

멀티캐스트를 이용하면, 그룹에 속한 수신자는 이론적으로 동시에 데이터를 수신할 수 있다. 물론, UDP 방식이기에 신뢰성이 낮다. 따라서 재전송 처리 방안을 고민해보자.

네트워크 보안

DDOS 공격에 대응할 수 있는 능력이 필요하다.

1. 공개 서비스와 데이터를 비공개 서비스에서 분리하여 DDOS 공격이 가장 중요한 클라이언트에 영향을 미치지 않도록 한다. 동일한 데이터를 제공해야 하는 경우에는, 읽기 전용 사본을 여러개 만들어 문서를 격리한다.
2. 자주 업데이트 되지 않는 데이터는 캐싱한다. 캐싱이 잘 되어 있으면 대부분의 질의는 데이터베이스에 영향을 미치지 않는다.
3. 디도스 공격에 대비해 URL 을 강화한다. 질의 문자열이 담긴 URL 의 사용을 방지해라.
4. 효과적인 허용/차단 리스트 메커니즘을 사용해라.
5. 처리율 제한 기능을 활용해라.