•
거래소의 기본 기능은 구매자와 판매자가 효율적으로 연결될 수 있도록 돕는 것이다.
1단계: 문제 이해 및 설계 범위 확정
비기능 요구사항
•
가용성 : 최소 99.99%
•
결함 내성 : 프로덕션 장애의 파급을 줄이려면 결함 내성과 빠른 복구 메커니즘이 필요하다.
•
지연 시간 : 왕복 지연 시간은 밀리초 수준이어야 하며 특히 p99 지연 시간이 중요하다.
•
보안 : 거래소는 계정 관리 시스템을 갖추어야 한다.
개략적 규모 추정
•
100가지 주식이라고 가정
•
하루 10억 건의 주문이 발생한다고 가정
•
영업 시간은 대략 6.5시간
•
QPS는 10억 / 6.5시간 * 3600 = 43,000
•
최대 QPS는 QPS의 5배인 215,000으로 가정
2단계: 개략적 설계안 제시 및 동의 구하기
증권 거래 101
•
브로커
◦
대부분의 개인 고객은 브로커 시스템을 통해 거래소와 거래한다.
◦
브로커 시스템은 개인 사용자가 증권을 거래하고 시장 데이터를 확인할 수 있도록 편리한 사용자 인터페이스를 제공한다.
•
기관 고객
◦
기관 고객의 경우, 전문 증권 거래 소프트웨어를 사용하여 대량으로 거래한다.
◦
기관 고객마다 거래 시스템에 대한 요구사항이 다르다.
•
지정가 주문
◦
가격이 고정된 매수 또는 매도 주문이다. 이는 즉시 체결이 이뤄지지 않을 수 있고 부분적으로 체결될 수도 있다.
•
시장가 주문
◦
가격을 지정하지 않는 주문으로 시장가로 즉시 체결된다.
•
시장 데이터 수준
◦
미국 주식 시장에는 L1, L2, L3 세 가지 가격 정보 등ㄱ비이 있다.
•
봉 차트
◦
특정 기간 동안의 주가로, 일반적인 봉(캔들이라고도 함)은 일정 시간 간격 동안의 시작가, 종가, 최고가, 최저가를 표시할 수 있다.
•
FIX
◦
Financial Information Eschange Protocol, 즉 금융 정보 교환 프로토콜의 약어로 기업 중립적 통신 프로토콜이다.
개략적 설계안
•
거래 흐름
1.
고객이 브로커의 웹 또는 모바일 앱을 통해 주문한다.
2.
브로커가 주문을 거래소에 전송한다.
3.
주문이 클라이언트 게이트웨이를 통해 거래소로 들어간다.
4.
주문 관리자가 위험 관리자가 설정한 규칙에 따라 위험성 점검을 수행한다.
5.
위험섬 점검을 통과한 주문에 대해 주문 관리자는 지갑에 주문 처리 자금이 충분한지 확인한다.
6.
주문이 체결 엔진으로 전송된다. 체결 가능 주문이 발견되면 체결 엔진은 매수 측과 매도 측에 각각 두 개의 집행 기록을 생성한다.
7.
주문 집행 사실을 클라이언트에 전송한다.
•
시장 데이터 흐름
1.
체결 엔진은 주문이 체결되면 집행 기록 스트림을 만든다.
2.
시장 데이터 게시 서비스는 집행 기록 및 주문 스트림에서 얻은 데이터를 기반으로 시장 데이터를 사용하여 봉 차트와 호가 창을 구성한다.
3.
시장 데이터는 실시간 분석 전용 스토리지에 저장된다. 브로커는 데이터 서비스를 통해 실시간 시장 데이터를 읽고, 이 데이터를 고객에게 전달한다.
•
보고 흐름
◦
보고 서비스는 주문 및 실행 기록에서 보고에 필요한 모든 필드의 값을 모은 다음, 그 값을 종합해 만든 레코드를 데이터베이스에 기록한다.
거래 흐름
•
체결 엔진
1.
각 주식 심벌에 대한 주문서 내지 호가 창을 유지 관리한다.
2.
매수 주문과 매도 주문을 연결한다.
3.
집행 기록 스트림을 시장 데이터로 배포한다.
•
시퀀서
◦
체결 엔진을 결정론적으로 만드는 핵심 구성요소로, 이는 체결 엔진에 주문을 전달하기 전 순서 ID를 붙여 보낸다.
◦
외에도 체결 엔진이 처리를 끝낸 모든 집행 기록 쌍에도 순서 ID를 붙인다.
◦
실행 명령에 순서 ID를 부여하는 이유는 다음과 같다.
▪
시의성 및 공정성
▪
빠른 복구 및 재생
▪
정확한 1회 실행 보증
•
주문 관리자
◦
한쪽에서 주문을 받고 다른 쪽에서는 집행 기록을 받는다. 주문 상태를 관리한다.
▪
종합적 위험 점검 담당 컴포넌트로 하여금 주문의 위험성을 검토한다.
▪
사용자의 지갑에 거래를 처리하기에 충분한 자금이 있는지 확인한다.
▪
주문을 시퀀서에 전달한다.
•
클라이언트 게이트웨이
◦
클라이언트 게이트웨이는 클라이언트로부터 주문을 받아 주문 관리자에 보낸다.
API 설계
•
주문
◦
POST /v1/order
▪
주문을 처리한다. 인증이 필요하다.
•
집행
◦
GET /v1/execution?symbol={:symbol}&orderId={:orderId}&startTime={:startTime}&endTime={:endTime}
▪
집행 정보를 질의하며, 인증이 필요하다.
•
호가 창/주문서
◦
GET /vq/marketdata/orderBook/L2?symbol={:symbol}&depth={:depth}
▪
주어진 주식 심벌, 깊이에 따라 L2 호가 창의 질의 결과를 반환한다.
3단계: 상세 설계
성능
•
지연 시간을 줄이기 위해 다음 방법들을 검토한다.
1.
중요 경로에서 실행할 작업 수를 줄인다.
2.
각 작업의 소요 시간을 줄인다.
a.
네트워크 및 디스크 사용량
b.
각 작업의 실행 시간
고가용성
•
단일 장애 지점을 식별한다.
•
장애 감지 및 백업 인스턴스로의 장애 조치 결정이 빨라야 한다.
결함 내성
•
만약 부서버까지 다운된다면 어떻게 될까? 이는 보통 핵심 데이터를 여러 지역의 데이터 센터에 복제하여 해결한다.
•
결함 내성이 갖춰진 시스템을 만들려면 다음 항목에 대답할 수 있어야 한다.
◦
주 서버가 다운되면 언제, 어떻게 부 서버로 자동 전환되는 결정을 내리는가?
◦
부 서버 가운데 새로운 리더는 어떻게 선출하는가?
▪
이는 이미 널리 알려진 래프트 합의 알고리즘을 이용해 해결해볼 수 있다.
◦
복구 시간 목표는 얼마인가?
▪
애플리케이션이 다운되어도 사업에 심각한 피해가 없는 수준의 최댓값으로 설정해야 한다.
◦
어떤 기능을 복구해야 하는가? 시스템이 성능 저하 상태로도 동작할 수 있는가?
체결 알고리즘
•
FIFO 체결 알고리즘을 사용하며 다크 풀의 시나리오에도 사용되기도 한다.
결정론
•
기능적 결정론
◦
시퀀서나 이벤트 소싱 아키텍처를 도입함으로써 이벤트를 동일한 순서로 재생하여 항상 같은 결과를 얻을 수 있도록 보장한다.
◦
이벤트가 실제로 발생하는 시간은 중요하지 않으며 시간이 중요하다.
•
지연 시간 결정론
◦
각 거래의 처리 시간이 거의 같다는 뜻으로 이를 측정하는 수학적인 방법은 99번 백분위수 지연시간이나 99.99번 백분위수 지연 시간을 재는 것이다.
네트워크 보안
•
DDos 공격에 대응할 수 있는 능력을 갖추는 것이 중요하다.
◦
공개 서비스와 데이터를 비공개 서비스에서 분리하여 DDos 공격이 가장 중요한 클라이언트에 영향을 미치지 않도록 한다.
◦
자주 업데이트되지 않는 데이터는 캐싱한다.
◦
디도스 공격에 대비해 URL을 강화한다.
◦
효과적인 허용/차단 메커니즘을 사용한다.
◦
처리율 제한 기능을 활용한다.
4단계: 마무리
•
지금까지의 내용으로 미루어보아 이상적인 배포 모델이 단일 프로세스에 배치하는 것이나 요근래의 암호화폐 거래소의 경우 클라우드 인프라를 사용하여 서비스를 배포한다.
