암호통화거래소 만들기 둘째

1.
암호통화거래소 만들기 첫째에 이어지는 글입니다. 앞서 글은 DB Schema 및 구조 더하여 개발시 유의할 점을 소개했습니다. 이번에는 직접 개발할 때 참고할 수 있는 오픈소스 프로젝트를 소개할까 합니다. 초창기에 나왔던 암호화폐 거래소 시스템에 비하여 최근에 공개된 프로젝트를 보면 완성도가 남드릅니다. 물론 직접 운용을 하려면 여러가지 변경을 하여야 하지만 충분히 참고할 가치가 있습니다. 더우기 오픈소스를 기반으로 시스템을 구축하고자 할 때 오픈소스화한 프로젝트는 더 유용하지 않을까 생각합니다.

처음 블록체인을 기반으로 암호통화거래소를 만들었던 프로젝트를 조사할 때 살펴보았던 프로젝트들입니다.

Blink Trade
Wlox
Peatio
CoreCX

이 중에서 현재까지 유지되고 있는 프로젝트는 Peatio입니다. 물론 Github의 주소가 https://github.com/rubykube/peatio으로 바뀌었습니다.

Peatio is a free and open-source crypto currency exchange implementation with the Rails framework. Peatio.tech is a fork of Peatio designed for micro-services architecture. We have simplified the code in order to use only Peatio API with external frontend and server components.

Ruby로 개발된 프로젝트이면서 기업용 서비스까지 제공합니다. Peatio의 핵심은 Peatio-Core입니다. DBMS 및 RabitMQ 및 인증과 관련한 공통프레임워크입니다. 그리고 DB Schema와 관련한 정보는 MVC모델로 개발한 프로젝트라 Models에 있습니다. 그 중 Order와 관련한 부분입니다.

DB Schema는 아래와 같습니다.

2.
다음으로 소개할 프로젝트는 ViaBTC Exchange Server입니다. 중국 viaBTC가 공개한 오픈소스 프로젝트입니다. 제가 본 소스중에서 유일한 C로 개발한 프로젝트입니다.(^^)

ViaBTC Exchange Server

트위터를 보니까 2017년에 공개하였던군요.

Typical Bitcoin exchanges use relational database for their trade matching machine. The advantage is that it can rapidly realize business logic and guarantee data accuracy and reliability using data-dependent index, transaction etc. mechanisms. But it would also invite problems to the database and result in poor performance. With the development of quantitative trading, an increasing number of orders are now processed systematically and most of them are high-frequency trading with large order quantity which requires high standard for transaction interface delay. When faced with these technical issues, mainstream exchanges are now aware that these traditional data-dependent database can no longer meet the growing demand of trading. In order to break through the bottlenecks of database performance, we have chosen single process to avoid spending on database transactions and locks, and memory calculation to avoid spending on data persistence in return of significant performance improvement.

Fundamentally, the mechanism of a matching machine is simple: Submit orders by time, and match trading based on preferences of price and time efficiency. User balance change indicates the trading result. Since user deposit and withdrawal will also affect account balance, therefore, the final result should be identical to operational log. This is very similar to AOF mode of Redis, which essentially is an in-memory database that relies on operational logs for data recovery. Besides, by generating data state slices periodically, the matching engine can upload slice data and then log data to complete data recovery, hence reducing time of loading historical data to restart services.

Based on calculation of Benchmark of Redis, a single write server is fully capable of supporting up to 10,000+ orders. For the common benefit of achieving high availability, matching service requires one-master multi-slave cluster and in our case, we use Zookeeper to ensure its management. In addition, database is required for asynchronous persistent storage of order history, transaction history, asset change history etc.


Peatio와 비교하면 Redis와 Kafka를 사용하고 있습니다. 또한 MySQL 을 적용하는 방식도 다릅니다. 운영로그를 기록하고 데이타를 복구할 때 사용합니다.

matchengine: This is the most important part for it records user balance and executes user order. It is in memory database, saves operation log in MySQL and redoes the operation log when start. It also writes user history into MySQL, push balance, orders and deals message to kafka.

기본적으로 모든 데이타는 Shared Memory를 이용하고 Linked List방식의 자료구조를 가지고 있습니다. 매매체결엔진 퀀트컵을 보시면 비슷한 방식으로 Limit OrderBook을 관리하는 사례를 보실 수 있습니다.

3.
비동기식 데이타를 처리하기 위해 AMQP나 Kafka를 사용하는 것은 무척 좋은 선택입니다. 이상의 프로젝트를 보면서 두가지 생각이 들었습니다.

첫째는 매칭엔진의 기능 정의입니다. Peatio와 viaBTC의 매칭엔진는 Limit Orderbook기능외에 금융시장에서의 위험관리, 계좌관리, 잔고관리 및 포지션 관리에 더한 개념입니다. 여의도의 경험에 익숙한 분이라면 증권회사와 거래소의 기능을 분리합니다. 저도 예전에 프로젝트를 했을 때 같은 방식으로 설계구현했습니다. 분리하지 않고 통합을 하니까 Central Limit Orderbook이 일반적인 거래소와 다른 방식을 가집니다. 지금 되돌아보면 하나의 거래소에 여럿 중개회사가 아닌 구조라고 하면 굳이 분리할 필요가 있을까 하는 의문을 가집니다. 분리할 경우 관리비용이 증가합니다. 프로세스를 나누어야 하고 장애에 따른 복구도 복잡해지기 때문입니다.

둘째 Scalibility입니다. 두경우 모두 MySQL을 중요히 사용합니다. 후자는 운영로그관리라고 하지만 프로세스를 시작할 때 기준은 MySQL의 데이타입니다. 만약에 동시에 다량의 거래가 발생하여 MySQL부하가 늘어날 때 어떤 방식이 가능할까요? Read Only일 경우에는 간단하지만 Write일 경우 쉽지 않습니다. Scaling a cryptocurrency exchange using Go and microservices와 같은 글을 읽어보면 Microservice가 중요한 해결지점이라고 하지만 어떤 구조를 택하더라도 MySQL에서 병목이 발생하면 다른 프로세스의 지연으로 이어집니다.

거래소사업을 한다고 할 때 어떤 목적을 가질지, 하나로 정의할 수 없습니다. 다만 거래소를 지속적으로 운영하여 다양한 비즈니스기회를 보고자 한다면 최소한 개발팀을 직접 만들고 운영능력을 키워야 합니다. 유지보수비용도 고려해야 합니다. 맨땅에서 시작하고자 할 경우 오픈소스를 분석하면서 시작하는 것도 좋은 방법이라고 생각합니다. 물론 UI와 API도 중요합니다.

Leave a Comment

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다

이 사이트는 스팸을 줄이는 아키스밋을 사용합니다. 댓글이 어떻게 처리되는지 알아보십시오.