본 보고서의 1부에서 저희는 비트멕스의 기원에 대해 살펴보았습니다.

오늘 저희는 본 시리즈의 2부를 게시하고자 합니다 – 즉, 과부하와 수평적 확장에 내재된 문제에 대한 심층적인 고찰입니다. 저희는 지금까지의 전례 없는 거래량을 처리하기 위한 노력을 결과를 살펴 볼 예정이며, 일렬 (단일)로 유지되어야 하는 비트멕스 엔진의 일부분을 비롯해 병렬화 (동시)될 수 있는 부분들과 비트멕스 API의 초기 설계에 대한 이점 또한 살펴 볼 예정입니다.

3부에서 저희는 이미 적용된 코드 최적화, 병렬화된 시스템, 그리고 특정 기능이 제거된 이유에 대해서 설명할 예정입니다. 저희는 또한 공정하고 동등한 기회에 대한 비트멕스만의 노력을 살펴 볼 예정입니다 – 그리고 이 부분이 동일 위치 제공 거부에 있어 어떤 의미로 해석되는지도 포함됩니다.

그럼 본격적으로 시작해보겠습니다.

성장

비트멕스는 암호화폐 업계에서 유일무이한 플랫폼입니다. 업계 최고의 레버리지와 기능을 제공하기 위해 비트멕스 거래 엔진은 암호화폐 및 전통적 금융 분야의 엔진과는 근본적으로 다릅니다. 저희는 예외적으로 정확한 거래 및 마진을 제공할 수 있지만 아직 특별히 빠른 편은 아니였습니다.

2017년 내내 비트멕스의 일일 평균 거래량은 129배 증가했습니다. 이는 놀라운 성장률이며 2018년과 2019년까지 계속 성장했습니다.

위의 도표에서 확인할 수 있듯이 주당 주문량도 2017년부터 급격히 증가했습니다. 특히 흥미로운 점은 주문율이 낮음에도 불구하고 2018년 7월 사상 최고치인 미화 8억 달러의 거래량에 달했습니다. 해당 기록은 11억 미화 달러가 거래된 지난 주 2019년 5월 11일까지 깨지지 않았습니다. 이러한 기록들은 여전히 단일 암호화폐 거래소에서 하루 동안 가장 많은 거래가 이루어지는 것을 의미하며, 비트코인 무기한 스왑 계약이 지금까지 개발된 상품 중에 가장 많이 거래되는 상품입니다. 그 이후로 설립된 열정적인 암호화폐 거래소들에 의해 수십 번 이상 모방되었습니다.

2018년 5월, 저희는 거래 엔진에서 주문 취소, 수정 및 이행 작업을 최적화하고, 내부 데이터 구조, 알고리즘 및 감사 점검을 재 작업하여 kdb+가 제공할 수 있는 종류의 속도를 구체적으로 조정하기 위한 집중적인 노력을 시작했습니다. 이는 기존의 거래 엔진이 수행하는 작업을 계속 수행할 수 있도록 하기 위한 초점적인 노력이었고, 단지 수행 속도가 훨씬 더 빨랐습니다. 저희는 이번 노력으로 불과 30일 만에 4.6배, 8월 말까지 10배 이상의 성능을 달성했다는 점에서 매우 자랑스럽게 생각합니다. 7월 중순까지 성능이 향상된 거래 엔진으로 인해 사실상 모든 과부하가 제거되었으며 저희는 이러한 놀라운 결과를 달성한 기술 팀이 매우 자랑스럽습니다.

아래는 과부하를 모든 쓰기 요청의 백분율로 나타낸 도표입니다 (주문 실행, 수정, 취소). 더 많은 빨간색 = 더 많은 과부하.

시장은 증가된 거래 처리 용량에 반응하며 비트멕스 거래량을 성층권으로 밀어 넣었습니다. 저희는 암호화폐 업계 사상 처음으로 거래량이 백만 비트코인에 이르는 날을 맞이했습니다. 여분의 거래 처리 용량으로 저희는 최초의 ETHUSD 콴토 무기한 스왑과 같은 혁신적인 신규 상품을 계속 출시할 수 있었습니다. 이는 상장 후 6주 이내에 거래된 ETHUSD 상품 중 1위를 차지했습니다. 2018년 11월, 저희 비트멕스는 24시간 만에 200만 비트코인에 도달했고 2019년 5월에는 11억 달러의 거래량을 달성했습니다.

7월 도표는 완전히 선명하게 보이지만, 본 글을 읽고 계신다면 여러분은 해당 도표는 앞서 언급한 바와 같이 유지되지 않았다는 것을 확인할 수 있습니다. 왜 완전히 고쳐지지 않는 걸까요? 왜 저희는 단순히 100배 이상에 도달하기 위한 노력을 계속하지 않았을까요?

그 배경을 살펴보도록 하겠습니다.

대기 행렬

비트멕스에서의 서비스 요청은 매표소에서 줄을 서서 기다리는 것과 유사합니다. 대기 행렬에 합류하고 대기 행렬이 원활해짐과 동시에 요청을 진행합니다.

티켓을 구매하는 데까지 시간이 얼마나 소요될까요? 음, 만일 대기 행렬이 없는 경우라면 매우 빠를 것입니다. 전체 상호 작용은 개별 요청을 처리하는 데에 걸리는 시간 동안만 지속됩니다. 이 때문에 부하와 거래량이 현저히 낮은 일부 다른 거래 서비스들은 최대 거래 처리 용량이 더 낮더라도 빠르게 느껴질 수 있습니다: 대기 행렬에 요청 수가 적습니다.

대기 행렬이 길면 어떤 일이 일어나는지 생각해 보시기 바랍니다. 요청이 처리될 때까지 기다려야 할 뿐만 아니라 앞서 대기하고 있는 모든 사람들의 요청이 완료될 때까지도 기다려야 합니다. 여러분 앞에는 세계에서 가장 효율적인 점원이 존재할 수는 있지만, 대기 행렬이 형성되기 시작하면 평균 사용자 경험은 매우 열악할 것입니다.

어떤 요청은 매우 간단하고 따라서 빠르지만, 어떤 요청은 더 복잡하고 더 많은 시간이 걸립니다. 만일 요청을 완전히 피할 수 있는 경우 (예: 사용자가 이를 완료하기 위한 충분한 잔고가 없는 경우), 자동 체크인 카운터 및 수화물 위탁과 같이 대기 행렬에 합류하지 않도록 최적화 방식을 도입합니다.

웹 서비스의 부하는 여러 가지 동일한 방식으로 작동합니다. 개별 요청을 처리하는 것이 매우 빠르더라도 단일 리소스에 대한 대기 행렬이 형성되면 사용자 경험이 저하됩니다.

여러분은 전에 이를 경험해 본적이 있을 것입니다. Amazon과 Alibaba는 휴일에 심각할 정도의 중단 시간을 겪은 적이 있습니다. Twitter는 악명 높은 고래 이미지 (과부하 될 시에 오류를 의미)를 내보내기도 했습니다. 그리고 비트멕스를 포함한 많은 플랫폼들은 때때로 역행의 대기 행렬 동작을 나타냅니다.

과부하

여러분이 알다시피 “시스템 과부하”는 저희 비트멕스가 본 문제를 해결하기 위해 활용하는 매커니즘 중 하나입니다. 혹시 의아해 하고 계신가요? 어떻게 과부하가 문제가 아닌 해결책이 될 수 있을까요? 과부하는 방어 매커니즘으로 업계에선 “부하 차단”으로 더 잘 알려져 있으며, 이는 정보 시스템에서 시스템을 손상시키고 어떠한 요청도 처리하지 못하게 하는 대신 일부 요청을 무시함으로써 시스템 과부하를 방지하는 기술입니다.

저희는 부하 차단과 관련된 명확한 규칙을 보여주고 해당 매커니즘을 설명하는 보고서를 게시했습니다:

이를 이해하기 위해서는 부하 차단이 없는 시스템을 고려해야 합니다. 수요가 증가 함에 따라 대기 행렬이 형성되고 증가하기 시작합니다.

이러한 상황은 얼마나 나빠질 수 있을까요? 시장이 움직이기 시작하면 거대한 무리의 거래자들이 자신들의 포지션 증가 혹은 감소를 위한 주문 경쟁을 합니다. 이러한 지연이 스스로를 규제할 것이라고 생각할 수 있습니다: 서비스 품질이 저하됨에 따라 거래자들은 다음 주문을 이행하기 앞서 이전 주문에 대한 확인을 기다리면서 더 느린 속도로 주문을 이행합니다. 하지만 사실 그 반대 현상이 일어납니다: 응답 시간이 증가 함에 따라 자동화된 차익거래자들은 다른 거래소들과 일치하는 시가를 유지하기 위해 빠르게 개입할 수 없습니다. 다른 현명한 거래자들은 가격 책정에서 감지된 차이를 수동으로 거래하려고 시도하며, 이는 대기 행렬의 규모를 더욱 증가시킵니다.

보호 기능이 없으면 대기 행렬이 오랫동안 지연될 수 있습니다. 주문장 스프레드는 사용자가 효과적으로 지정가 주문을 이행하지 못함에 따라 증가합니다. 굉장히 매력적인 시장 가격은 실제로 주문이 대기 행렬을 통과하여 이행될 때는 형편없는 가격이 됩니다. 이러한 환경에서는 거래가 사실상 불가능합니다. 이는 단지 가설적인 것이 아닙니다; 다른 암호화폐 시장에서도 직면하고 있는 일반적인 문제입니다.

이에 대한 비트멕스의 해결책은 거래 엔진의 대기 행렬에 있을 수 있는 최대 주문 관리 요청 수를 제한하는 것입니다. 읽기 (예. GET /api/v1/position과 같은 데이터 불러오기) 및 쓰기 (예. 주문 이행/수정/취소 및 레버리지 변경)로 요청을 식별하는 서비스가 거래 엔진 앞에 존재합니다. 만일 요청이 쓰기인 경우, 주요 엔진에 할당되며 대기 행렬이 형성됩니다. 만일 이 대기 행렬이 너무 길어지는 경우, 주문은 대기 행렬에서 기다리지 않고 즉시 거부됩니다. 이러한 대기 행렬의 깊이는 엔진 성능에 맞춰 조정되어 최악의 경우 3초에서 5초까지로 대기 시간을 제한합니다.

저희 비트멕스의 부하 차단 문서에 따르면 취소와 같은 특정 유형의 요청은 크기와 관계없이 대기 행렬에 합류할 수 있지만, 다른 요청과 마찬가지로 대기 행렬의 뒤에서부터 합류하게 됩니다.

결과: 거래자들은 주문이 대기 행렬에 존재하는 것을 확인하는 대신 시스템에 지연이 겪고 있다는 것을 즉시 알 수 있으며, 주문을 이행하는 데까지는 몇 초가 소요됩니다. 해당 엔진은 속도를 늦추지 않습니다: 사실 과부하 중에 엔진은 최대 주문율에 도달하고 주문장과 거래 정보는 매우 빠르게 움직입니다.

과부하 시 거래

일부 거래자들은 과부하 중에도 거래가 지속된다는 점에 불만을 표했습니다. 사실 저희는 Twitter와 거래자들 간의 채팅 방에서 이는 특정 거래자들만이 시스템에 불공평하게 접근이 가능하기 때문이라는 점을 든 많은 음모론을 지켜봐 왔습니다. 이는 근본적으로 사실이 아닙니다: 비트멕스의 모든 거래자는 동일한 접근 권한을 가지며 동일한 대기 행렬에 합류합니다. 거래 엔진은 항상 대기 행렬의 요청을 가능한 한 빨리 처리합니다.

만일 시스템에 입력되는 주문 수가 시스템이 처리할 수 있는 주문의 5배일 경우, 총 주문 수의 20%만 승인되고 나머지 80%는 거부됩니다. 어떤 주문이 거부되고 어떤 주문이 받아들여지는지에 대한 결정은 단순히 주문이 제출되는 순간 대기 행렬에 공간이 있는지의 여부에 달려 있습니다. 만일 응답이 제공된 직후에 요청이 대기 행렬에 도달하는 경우, 대기 행렬이 최대 깊이 아래로 이동하면서 해당 요청은 승인됩니다. 여러분이 제출한 주문 이후의 주문은 여러분의 주문이 아닐 수도 있습니다.

거래가 가장 집중되는 시간 동안 비트멕스는 주문 입력율이 평균보다 20배에서 30배 증가하는 현상을 경험하게 됩니다! 실행된 거래량이 분당 100만 달러 이상의 최고점에 도달했습니다. 만일 이 비율이 지속되는 경우, 시간당 6억 미화 달러 혹은 하루에 144억 미화 달러 이상의 거래량을 달성할 수 있습니다. 이는 비트멕스 혹은 다른 암호화폐 플랫폼에서 하루 만에 기록된 상위 거래량의 13배입니다.

저희 비트멕스는 항상 원할한 거래 경험을 제공하기 위해 이와 같이 강력한 이벤트를 처리할 수 있는 큰 규모의 예비 용량을 보유해야 합니다. 저희는 본 목표를 달성하는 데에 있어 직면한 몇 가지 과제를 아래와 같이 문서화할 예정입니다.

높은 확장성과 암달의 법칙 (Amdahl’s Law)

확장성 문제는 어떻게 해결될 수 있을까요? 확장성에는 두 가지 유형이 있습니다: “수직” 및 “수평”입니다. 수직적 확장은 개별 시스템을 더 빨리 만드는 작업을 포함합니다. 본 작업은 더 빠른 프로세서 (행운을 빕니다; CPU에 대한 무어의 법칙은 더 이상 존재하지 않습니다)를 구매하거나 작업량을 줄일 수 있는 방법을 찾음으로써 수행할 수 있습니다. 반면에 수평적 확장은 “더 많은 돈을 쏟아 붓는 것”의 다양성을 의미합니다: 더 많은 서버를 운영하고 그 중에서 부하량을 분산시킵니다.

웹 서버는 수평적으로 확장 가능한 서비스의 좋은 예입니다. 가장 적절하게 구성된 시스템에서는 더 많은 웹 서버를 추가하여 고객의 요구를 처리할 수 있습니다. 하나의 응답이 다른 응답에 의존하지 않을 때, 식료품 점의 계산대 점원과 같이 서버가 동시에 작동하는 것이 안전합니다.

이는 대규모의 간소화 작업이지만 많은 사람들에게 확장성 해결책은 “문제 해결을 위한 막대한 비용”의 긴 버전입니다. 많은 시스템들이 수평으로 확장됩니다. 대부분의 고객 경험은 서로 완전히 독립적이며 단순히 더 많은 웹 서버에서 제공할 수 있습니다. 백업 데이터베이스는 흔히 서로 복제하여 수평적으로 확장될 수 있습니다.

수평적 확장이 가능한 정도에는 한계가 있으며 이를 흔히 암달의 법칙(Amdahl’s Law)으로 표현합니다. 간단히 말하자면, 시스템의 수평적 확장성은 연쇄 작업 (혹은 특정 순서에서 발생해야 하는 작업)에 의해 제한됩니다. 이는 다음과 같이 설명할 수 있습니다: 속도를 높이고자 하는 단순하고 단일 스레드 (하나의 프로그램 내에서 동작하는 여러 갈래의 작업 흐름) 서비스를 여러 서버를 통한 동시 작업을 상상해 보시기 바랍니다. 일부 성능 분석을 통해 작업의 25%만이 순서대로 완료되어야 한다는 것을 알 수 있습니다. 이는 아무리 많은 코어 혹은 서버를 해당 문제에 투입하더라도, 1/25% = 4 공식과 같이 4배까지만 속도를 낼 수 있다는 것을 의미합니다. 이 정도의 연쇄 작업은 병목 현상을 야기합니다.

이러한 연쇄 작업 요구사항은 비트멕스가 대부분의 일반 웹 서비스와 크게 차별을 두는 점입니다. 비트멕스 거래 엔진은 훨씬 더 많은 연쇄 작업 요구사항을 가지고 있어 병렬화 기회를 심각하게 제한하고 있습니다.

순차적인 문제: 주문 및 추가 증거금

비트멕스 거래 엔진은 순차적인 FIFO (First-In-First-Out, 선입선출법) 방식으로 주문을 처리합니다. 여러분이 가장 좋아하는 케이블 공급업체와의 통화를 기다리는 것과 마찬가지로, 거래 엔진으로의 요청은 수신되는 순서대로 처리됩니다.

이는 시장의 기본 원칙이며 변경될 수 없습니다. 주문장에는 순차적으로 주문이 적용되어야 합니다 – 즉, 주문 순서가 중요합니다. 공격적인 주문이 이행될 때, 해당 주문은 주문장에서 유동성을 취하고 다른 어떤 주문도 이를 소모하지 않습니다. 이러한 이유로 개별 시장에서의 일치성은 효과적으로 분산될 수 없습니다; 그러나 이러한 일치성은 시장별로 단일 프로세스에 할당될 수 있습니다.

보고서 작성 당시 비트멕스는 엔진에 앞서 프록시 (proxy, 서버와 클라이언트 사이에서 대리로 통신을 수행하는 기능)와 직접 통신을 수행하는 약 150개의 API 서버를 운영합니다. 본 프록시는 읽기 요청 및 웹소켓 데이터를 각각 데이터 이중화와 pub/sub 시스템에 할당하며, 쓰기 요청은 엔진에 직접 할당합니다.

쓰기 요청은 예상대로 시스템의 가장 비싼 부분이며 규모를 확장하기가 가장 어렵습니다. 거래 시스템이 효과적으로 작동하기 위해서는 다음 사항이 충족되어야 합니다:

• 모든 참여자는 동일한 시장 데이터를 동시에 받아볼 수 있어야 합니다.
• 참여자는 언제든지 쓰기 요청을 전송할 수 있습니다.
  • 만일 본 쓰기 요청이 유효하고 공용 상태를 변경하는 경우, 수정된 실제 상태는 승인되고 실행된 후에 모든 참여자에게 전송되어야 합니다.

최적화되지 않은 본 시스템은 2차 확장을 수행합니다: 분당 1개의 주문을 보내는 100명의 사용자가 각 참가자에 대해 1개씩 10,000개 (100 * 100)의 시장 데이터 패킷을 생성합니다. 사용자가 1000명으로 10배 증가하는 경우 시장 데이터 (1000 x 1000)가 100배 이상 생성됩니다.

본 보고서의 앞부분에서 언급했듯이 비트멕스는 2017년에 129배 성장하였습니다. 해당 기간 동안 저희 비트멕스의 사용자 기반은 비례적으로 확장되었습니다. 이는 2017년 12월 31일, 저희가 2017년 1월 1일에 비해 16,641배 (129 * 129) 더 많은 메시지를 전송하고 있었다는 것을 의미합니다.

시스템 일관성

비트멕스에 있어 확장은 분명 어려운 작업입니다. 저희 비트멕스는 전형적인 현물 혹은 파생 상품 플랫폼이 아닙니다: 저희는 가입, 입금, 거래에 이르기까지 고객의 전체 생애주기를 관리합니다.

100배의 레버리지를 안전하게 제공하기 위해서는 비트멕스의 시스템이 정확해야 하며 속도 또한 빨라야 합니다. 비트멕스는 사용자가 추가 증거금을 투입하는 데에 있어 마지막 거래 가격이 아닌 계약의 기본이 되는 현물 거래소 가격의 종합지수를 사용하며, 독창적이고 흔히 모방된 공정가격 표시 시스템을 갖추고 있습니다. 이는 외부 유동성을 참고함으로써 비트멕스 시장 내에서의 조작을 훨씬 더 효과적으로 방지합니다.

본 시스템이 제대로 작동하기 위해서는 비트멕스 엔진이 일관성을 유지해야 합니다. 시장 평균가가 변동될 때마다 해당 시스템은 포지션을 보유하고 있는 사용자들의 추가 증거금을 재설정합니다. 이때 시스템 전체가 제어 루틴에 의해 감사가 이루어집니다. 모든 오픈포지션, 미체결주문 및 잔여 마진은 모든 입금 금액과 정확하게 동일해야 합니다. 단 하나의 사토시라도 누락되지 않아야 하며, 그렇지 않으면 시스템이 종료될 수 있습니다! 이는 저희 비트멕스의 초기 운영 시절에 몇 번 발생한 적이 있습니다; 매번 추천인 프로그램 수익 혹은 수수료에 대한 사토시의 반올림 오류가 원인이었습니다. 오류가 발생할 경우 소규모의 완충자금을 구축하고 싶은 유혹은 있었지만, 저희 비트멕스 팀은 본 시스템의 지불 능력이 최고라고 믿습니다: 저희는 가능한 한 최고 수준의 기준을 고수합니다. 본 시스템은 오늘 날에도 상태에 주요한 변경사항이 있을 때마다 정확한 사토시 합계에 대한 감사를 수행하고 있습니다.

비트멕스에서 데이터베이스 접근 권한을 가진 악의적인 해커가 단순히 자신의 잔고를 편집할 수 없습니다: 해당 시스템은 비정상적인 방식으로 발생한 돈을 즉시 인식하여 치명적인 오류를 내보내고 종료합니다.

감사가 이루어지기 전, 전체 계정의 현재 가치는 처음부터 재계산되어야 합니다; 이는 새로운 가격으로 인한 모든 오픈 포지션과 미체결주문의 가치입니다. 이로 인해 거래자들은 자신들이 감당할 수 없는 규모의 계약을 체결할 수 없게 됩니다. 거래자들은 비트멕스에서 음수의 잔고에 도달할 수 없습니다. 다시 말해, 잔고가 마이너스가 되지 않습니다.

본 시스템의 속도를 높이는 것이 저희의 확장성 노력의 주요 목표 중 하나입니다. 일치성은 상대적으로 시간이 적게 소요되고 쉽게 확장할 수 있습니다; 반대로 증거금 산출은 쉽지 않습니다. 비트멕스는 항상 “정확성 우선, 속도는 차후에” 라는 마음가짐으로 노력해왔습니다 – 따라서 본 작업에 소요되는 시간은 앞서 언급한 정확성을 바로잡기 위한 저희 비트멕스의 약속이기 때문입니다. 잘못된 결과는 용인할 수 없으므로 올바르게 배포된 시스템은 느리거나 실패한 산출 결과 제공 기능을 감지하고, 부하를 재조정하여 빠듯한 시간 예산 내에서 필수적인 절차를 완료할 수 있어야 합니다. 이를 위해서는 신중하고 체계적인 주의와 엄격한 테스트가 요구됩니다.

저희 비트멕스의 엔지니어들은 최적화가 안전하게 이루어질 수 있는 몇 몇의 핵심 영역을 확인하였으며, 플랫폼의 거래 처리 용량을 획기적으로 증가시킬 수 있는 새롭고 탄탄한 플랫폼 구조를 제공하기 위해 끊임없이 노력하고 있습니다.

API 우선 설계

비트멕스는 타 경쟁사들과 비교하여 훨씬 유일무이한 거래 플랫폼입니다: 비트멕스 플랫폼은 API를 우선 순위로 구현되었습니다. 비트멕스의 구조는 세 가지 주요 부분으로 구성되어 있습니다: 거래 엔진, API 및 웹 프런트 엔드입니다. 저희가 왜 “특정” 프런트엔드라는 단어를 사용하지 않았는지에 대해 주목해 주시기 바랍니다. 그 이유는 무엇일까요?

비트멕스를 구축할 당시에 저희가 구현하고자 하는 API가 동종 업계 최고 수준이기를 바랬습니다. 훌륭한 API는 개발자들이 견고한 도구를 쉽게 개발할 수 있도록 기여합니다. 이는 심지어 저희가 상상해 보지도 않았을 상호적인 시각화 및 인터페이스 또한 구현합니다. 저희가 코딩 작업을 시작했을 당시, 암호화폐 거래에 있어 API 사용은 그다지 큰 의미가 없다는 의견이 팽배했습니다. 많은 사람들이 규칙성, 문서화 또는 사전에 작성된 어댑터의 유사성을 놓치고 있었고, 중요한 데이터는 흔히 누락되었으며, 중요한 기능은 웹사이트를 통해서만 수행할 수 있었습니다. 설상가상으로 이 중 대부분은 웹소켓 정보 제공 기능 조차도 없었을 뿐만 아니라, 그나마 해당 기능을 가지고 있던 소수의 사람들은 이를 비공개로 유지하고 웹사이트를 통해서만 접근할 수 있었습니다.

저희 비트멕스는 이러한 추세를 거스르고 암호화폐 API에 대한 새로운 표준을 수립했습니다. 저희는 타 프로그램에서 API가 사용 가능할 수도 있는 것처럼 당사 웹사이트에서도 API 사용 의무를 규정함으로써 시험 사용에 대해 신중한 정책을 채택했습니다. 이는 “특정” 프런트엔드가 아닌 단순히 비트멕스의 공식적인 프런트엔드만이 존재한다는 것을 의미합니다. 하나의 프로젝트로써의 비트멕스 웹사이트는 API 개발자들의 선호감과 몇 가지 로그인/등록 오용방지 메커니즘 이외에 특별한 접근 권한이 없습니다.

이는 또한 비트멕스에 접근하는 메커니즘이 또 다른 메커니즘보다 빠르거나 느리지 않음을 의미합니다. 모든 사용자는 모바일 장치, 브라우저, 사용자 지정 API 연결기 혹은 시에라 차트의 DTC (Data and Trading Communication, 데이터 및 거래 통신) 통합을 통해 접근하는 경우와 관계없이 동일한 데이터 경로와 대기 행렬에 합류합니다.

처음부터 비트멕스는 아래의 기능을 갖추고 있었습니다:

• 동일한 형식을 따르며 주문, 거래, 주문장, 포지션, 마진, 금융상품 등을 포함한 모든 테이블에 대한 웹소켓 변경 제공 기능,
• 스웨거 사양 (현재 공개 API로 칭함)을 통해 사람과 기계가 모두 사용할 수 있는 완전히 문서화된 API,
• GitHub 상의 여러 예시 프로젝트, 그리고
• 웹사이트 및 API 사용자를 위한 통합 데이터 경로.

실시간 데이터

비트멕스의 API 우선 설계에 대한 노력은 웹소켓을 통해 노출된 실시간 데이터를 구현하는 데서 빛을 바라고 있습니다. 위에서 언급했듯이 모든 테이블에는 실시간 정보 제공 기능이 존재합니다. 이는 암호화폐 업계에서는 처음이며 오늘날에는 극히 드문 경우입니다. 또한 모든 테이블은 동일한 형식을 따르므로 스트림을 처리할 수 있는 코드 줄을 최소 30줄까지 쓸 수 있습니다. 혹은 당사의 GitHub에서 입수하여 사용하실 수도 있습니다.

본 데이터는 개별 사용자 서명을 위해 필터링이 이루어진 엔진 자체에서 생성된 변경 스트림에서 처리됩니다. 이는 비트멕스 상단의 인터페이스를 구축할 때 매우 손쉬운 처리 방식을 가능케 합니다: 테이블에 서명 후 요청을 보내며 또한 스트림에서 변경사항을 수신 대기합니다. 일반적으로 HTTP 요청에 대한 응답은 오류가 아닌 이상 무시할 수 있습니다. 이는 웹소켓 스트림과 HTTP 응답 모두를 별도로 읽고 병합해야 하는 어플리케이션에서 공통적인 이원성을 방지하여 다루기 힘든 코드와 버그를 생성합니다.

저희는 최상위 어플리케이션 인터페이스를 구축하는 이러한 철학이 최고의 사용자 공간 통합을 제공할 뿐만 아니라, 비트멕스 웹사이트와 곧 출시될 모바일 앱 또한 최상의 상태로 만들어질 것이라 믿습니다.

저희의 실시간 정보 제공 기능은 비트멕스 플랫폼이 정상적으로 작동하는 데에 있어 가장 중요합니다. 이를 위해 저희는 외부 변경 없이 대기 시간과 처리량을 크게 개선시킬 것으로 기대되는 본 시스템의 주요 내부 재 작업을 준비 중에 있습니다. 저희는 곧 이와 관련하여 출시 날짜와 결과를 발표할 예정입니다.

다음 단계

저희는 플랫폼의 향후 100배 성장을 위해 확장하는 동시에 위의 내용을 통해 비트멕스가 직면한 도전에 대하여 어느 정도 이해하셨기를 바랍니다. 저희는 해당 플랫폼의 성공과 사용자들에게 감사한 마음을 가지고 있는 한편, 앞으로 몇 년 동안 지속적으로 개선해 나갈 필요가 있다고 생각합니다.

비트멕스 거래 엔진 팀은 일주일에 여러 번 플랫폼에 대한 업데이트를 발표합니다. 이러한 점진적 변화들은 모두 엔진에 대한 전술적 용량 개선의 일환일 뿐만 아니라 거래 플랫폼의 지속적인 장기 재구축 작업이기도 합니다. 이러한 노력, 성공, 실패는 본 시리즈의 3부에서 살펴 볼 예정입니다.

비트멕스 엔진 팀은 정기적으로 시스템 처리량에 대한 주요 업그레이드를 수행할 수 있었습니다. 엔진 팀은 최근 2019년 5월 23일에 새로운 주문 처리 용량을 70%까지 증가시킨 주요 인프라 업그레이드를 수행하였습니다. 이와 같이 상당한 용량 개선은 향후 몇 개월 동안 계속 제공될 예정이며 해당 플랫폼의 대규모 재구축 작업 또한 병행될 것입니다.

이와 같이 당사 거래 엔진을 확장하는 작업이 빠르게 진행되는 동안에도 저희는 비트멕스 팀 또한 활발히 늘려가고 있습니다. 저희 비트멕스는 전자 거래 시스템, 확장성, 인프라, 보안, 웹 등의 분야에서 세계적으로 저명한 전문가들을 고용하고 있으며, 배우기를 두려워하지 않고 어떠한 업무에도 흔쾌히 참여할 준비가 되어있는 사람들을 위한 중간자 역할을 수행하고 있습니다. 만일 본 보고서가 여러분께 흥미롭게 다가온다면, 여러분은 저희 비트멕스가 바라는 인재상일 수 있습니다; 비트멕스 채용과 관련하여 더 자세한 사항은 비트멕스 채용정보 페이지에서 확인해 주시기 바랍니다.