13.증권 거래소
대규모 시스템 설계 기초 2nd 13장을 요약한 내용입니다.
온라인 증권 거래 시스템 설계
1단계: 문제 이해 및 설계 범위 확정
비기능 요구사항
가용성: 최소 99.99%. 거래소의 가용성은 매우 중요한 문제. 단 몇 초의 장애로도 평판이 손상 가능
결함 내성: 프로덕션 장애의 파급을 줄이려면 결함 내성과 빠른 복구 메커니즘이 필요
지연 시간: 왕복 지연 시간은 밀리초 수준이어야 함(특히 p99(ppth 백분위수) 지연 시간이 중요)
왕복 지연 시간은 주문이 거래소에 들어오는 순간부터 주문의 체결 사실이 반환되는 시점까지
p99 지연 시간이 계속 높으면 일부 사용자의 거래소 이용 경험이 아주 나빠짐.
보안: 거래소는 계정 관리 시스템을 갖춰야 함.
새 계좌 개설 전 사용자 신원 확인을 위한 KYC 확인 수행
시장 데이터가 포함된 웹 페이지 등 공개 자원의 경우 DDoS 공격을 방지하는 장지 구비 필요
계략적 규모 추정
시스템 규모를 이해하기 위한 몇 가지의 간단한 계산
100가지 주식
하루 10억 건의 주문
뉴욕증권거래소는 일요일부터 금요일까지, 오전 9시 30분부터 오후 4시까지 영업. (총 6.5시간)
QPS: 10억 / (6.5시간 x 3600) = ~43,000
최대 QPS: 5 * QPS = 2150,000. 거래량은 장 시작 직후, 그리고 장 마감 직전에 훨씬 높음
2단계: 개략적 설계안 제시 및 동의 구하기
거래소 설계에 도움될만한 기본 개념과 용어
브로커
대부분 개인 고객은 브로커 시스템을 통해 거래소와 거래
ex. 하나증권 등의 중권사가 브로커에 해당
기관 고객
기관 고객은 전문 증권 거래 소프트웨어를 사용하여 대량으로 거래
기관 고객마다 거래 시스템에 대한 요구사항이 다름
아주 낮은 응답 시간으로 거래하길 희망
지정가 주문
가격이 고정된 매수 또는 매도 주문
시장가 주문과 달리 체결이 즉시 이루어지지 않을 수 있고, 부분적으로만 체결될 수 있음
시장가 주문
가격을 지정하지 않는 주문, 시장가로 즉시 체결
체결은 보장되나 비용 면에서 손해를 볼 수 있음
급변하는 특정 시장 상황에서 유용
시장 데이터 수준
미국 주식시장에는 L1, L2, L3의 세 가지 가격 정보 등급이 있다(Level)
L1 시장 데이터에는 최고 매수 호가, 매도 호가 및 수량이 포함
최고 매수 호가는 구매자가 주식에 지불할 의사가 있는 최고 가격
매도 호가는 매도자가 주식을 팔고자 하는 최저 가격
L2에는 더 많은 수준의 가격 정보가 제공
깊이는 체결을 기다리는 물량의 호가를 어디까지 보여 주는지
L3는 L2에서 한 걸음 더 나아가, 각 주문 가격에 체결을 기다리는 물량 정보까지 보여
봉 차트
특정 기간 동안의 주기
하나의 봉 막대로 일정 시간 간격 동안 시장의 시작가, 종가, 최고가, 최저가를 표시
일반적으로 지원되는 시간 간격은 1분, 5분, 1시간, 1일, 1주일, 1개월
FIX
Financial Information Exchange Protocol
금융 정보 교환 프로토콜로 증권 거래 정보 교환을 위한 기업 중립적 통신 프로토콜
FIX로 인코딩한 증권 거래의 사례
개략적 설계안
👉🏻 거래 흐름을 통해 하나의 주문이 어떤 절차로 처리될까?
1 단계: 고객이 브로커의 웹 또는 모바일 앱을 통해 주문
2 단계: 브로커가 주문을 거래소에 전송
3 단계: 주문이 클라이언트 게이트웨이를 통해 거래소로 들어감.
클라이언트 게이트웨이는 입력 유효성 검사, 속도 제한, 인증, 정규화 등 기본적인 게이트키핑 기능을 수행
그 후 주문 관리자에게 전달
4~5단계: 주문 관리자가 위험 관리자가 설정한 규칙에 따라 위험성 점검을 수행
6단계: 위험성 점검 과정을 통과한 주문에 대해, 주문 관리자는 지갑에 주문처리 자금이 충분한지 확인
7~9단계: 주문이 체결 엔진으로 전송.
체결 가능 주문이 발견되면 체결 엔진은 매수 측과 매도 측에 각각 하나씩 두 개의 집행 기록을 생성
10~14 단계: 주문 집행 사실을 클라이언트에 전송
👉🏻 시장 데이터 흐름을 따라서, 하나의 주문이 체결 엔진부터 데이터 서비스를 거쳐 브로커로 전달되어 집행되기까지의 과정
M1 단계: 체결 엔진은 주문이 체결되면 집행 기록 스트림(또는 충족 기록 스트림)을 만듦
이 스트림은 시장 데이터 게시 서비스로 전송
M2 단계: 시장 데이터 게시 서비스는 집행 기록 및 주문 스트림에서 얻은 데이터를 시장 데이터로 사용하여 봉 차트와 호가 창을 구성
그 다음 시장 데이터를 데이터 서비스로 보냄
M3 단계: 시장 데이터는 실시간 분석 전용 스토리지에 저장
브로커는 데이터 서비스를 통해 실시간 시장 데이터를 읽음
브로커는 이 시장 데이터를 고객에게 전달
👉🏻 보고 흐름
R1~R2 단계(보고 흐름): 보고 서비스는 주문 및 실행 기록에서 보고에 필요한 모든 필드의 값을 모든 다음 그 값을 종합해 만든 레코드를 데이터베이스에 기록
거래 흐름(1~14까지의 단계)은 중요 경로를 따라 진행되지만 시장 데이터 흐름이나 보고 흐름은 그렇지 않음
이제 세 가지 흐름 각각을 더 자세히 살펴보자.
거래 흐름
거래 흐름은 거래소의 중요 경로상에서 진행. 모든 것은 신속하게 진행되어야 한다.
거래 흐름의 핵심은 체결 엔진
✅ 체결 엔진
체결 엔진(matching engine)은 교차 엔진(cross engine)이라고도 한다.
체결 엔진의 주요 역할
(1) 각 주식 심벌에 대한 주문서 내지 호가 창을 유지 관리
주문서 또는 호가 창은 특정 주식에 대한 매수 및 매도 주문 목록
(2) 매수 주문과 매도 주문을 연결
주문 체결 결과로 두 개의 집행 기록이 생성(매수 1건, 매도 1건)
체결은 빠르고 신속하게 처리
(3) 집행 기록 스트림을 시장 데이터로 배포
✅ 시퀀서
체결 엔진을 결정론적으로 만드는 핵심 구성 요소
시퀀서는 체결 엔진에 주문을 전달하기 전에 순서 ID를 붙여 전송
또한, 체결 엔진이 처리를 끝낸 모든 집행 기록 쌍에도 순서 ID를 붙임
시퀀서에는 입력 시퀀서, 출력 시퀀서 두 가지가 있으며, 각각 고유한 순서를 유지
시퀀서가 만드는 순서 ID는 누락된 항목을 쉽게 발견할 수 있는 일련번호
입력 주문과 출력 실행 명령에 순서 ID를 찍는 이유
(1) 시의성(timeliness) 및 공정성(fairness)
(2) 빠른 복구(recovery) 및 재생(replay)
(3) 정확한 1회 실행 보증(exactly-once guarantee)
시퀀서는 순서 ID만 생성하는 것이 아니며, 메시지 큐 역할도 함
하나는 체결 엔진에 메시지(수신된 주문)를 보내는 큐 역할
다른 하나는 주문 관리자에게 메시지(집행 기록)를 회신하는 큐 역할
✅ 주문 관리자
주문 관리자는 한쪽에서는 주문을 받고 다른 쪽에서는 집행 기록을 받는다.
주문 상태를 관리하는 역할
클라이언트 게이트웨이를 통해 주문을 수신하고 다음을 실행
종합적 위험 점검 담당 컴포넌트에 주문을 보내어 위험성을 검토
위험 점검 규칙은 단순(ex. 사용자의 거래량이 하루 100만 달러 미만인지 확인)
사용자의 지갑에 거래를 처리하기에 충분한 자금이 있는지 확인
주문을 시퀀서에 전달
해당 주문에 순서 ID를 찍고 체결 엔진에 보내어 처리
메시지 크기를 줄이기 위해 주문 관리자는 필요한 속성만 전송
주문 관리자는 시퀀서를 통해 체결 엔진으로부터 집행 기록을 받는다.
주문 관리자는 체결된 주문에 대해 집행 기록을
클라이언트 게이트웨이를 통해 브로커에 반환
✅ 클라이언트 게이트웨이
클라이언트 게이트웨이는 거래소의 문지기
클라이언트의 주문을 받아 주문 관리자에게 전송
클라이언트 게이트웨이 구성요소
중요 경로상에 놓이며, 지연 시간에 민감하므로 가벼워야 함
가능한 한 빨리 올바른 목적지로 주문을 전달
복잡한 기능이라면 체결 엔진이나 위험 점검 컴포넌트에 맡겨야 함
고객 유형별(개인/기관) 클라이언트 게이트웨이는 다양하다.
주요 고려 사항은 지연 시간, 거래량, 보안 요구사항
거래소에 연결된 다양한 클라이언트 게이트웨이
✅ 시장 데이터 흐름
시장 데이터 게시 서비스(Market Data Publisher, MDP)는 체결 엔진에서 집행 기록을 수신하고 집행 기록 스트림에서 호가 창과 봉 차트를 만들어 낸다.
호가 창과 봉 차트를 통칭하여 시장 데이터라고 한다.
시장 데이터는 데이터 서비스로 전송되어 해당 서비스의 구독자가 사용할 수 있게 된다.
MDP의 구현과, 다른 구성 요소와의 조화
✅ 보고 흐름
거래소에서 필수적인 부분 가운데 하나는 보고(reporting)
보고 서비스는 거래의 중요 경로상에 있지는 않지만 여전히 시스템의 중요한 부분
거래 이력, 세금 보고, 규정 준수 여부 보고, 결산 등의 기능을 제공
효율성과 짧은 지연 시간보다 정확성과 규정 준수가 핵심
입력으로 들어오는 주문과 그 결과로 나가는 집행 기록 모두에서 정보를 모아 속성들을 구성하는 것이 일반적 관행
두 가지 출처에서 오는 정보를 잘 병합하여 보고서를 생성
보고 흐름의 구성 요소가 서로 어떻게 결합되는지
3단계: 상세 설계
4단계: 마무리
요약
Last updated