모스크바 거래소의 거래 및 청산 시스템 아키텍처의 발전. 1 부

안녕하세요 여러분! 제 이름은 Sergey Kostanbaev입니다. 저는 거래소에서 거래 시스템의 핵심을 개발하고 있습니다.

헐리우드 영화에서 뉴욕 증권 거래소를 보여줄 때면 항상 다음과 같은 모습입니다. 많은 사람들이 모여들고, 모두가 무언가를 외치고, 종이를 흔들고, 완전한 혼란이 일어나고 있습니다. 거래는 처음부터 전자적으로 이루어졌고 Spectra(외환 시장)와 ASTS(외환, 주식 및 화폐 시장)라는 두 가지 주요 플랫폼을 기반으로 하기 때문에 이곳 모스크바 거래소에서는 이런 일이 결코 발생하지 않았습니다. 그리고 오늘 저는 ASTS 거래 및 청산 시스템 아키텍처의 진화, 다양한 솔루션 및 결과에 대해 이야기하고 싶습니다. 이야기가 길어져서 XNUMX부로 나누어서 작성하게 되었습니다.

우리는 모든 등급의 자산을 거래하고 광범위한 교환 서비스를 제공하는 세계에서 몇 안 되는 거래소 중 하나입니다. 예를 들어 지난해 우리는 채권 거래량 세계 25위, 증권 거래소 중 13위, 상장 거래소 시가총액 XNUMX위를 기록했습니다.

전문 거래 참가자의 경우 응답 시간, 시간 분포의 안정성(지터) 및 전체 단지의 신뢰성과 같은 매개변수가 중요합니다. 우리는 현재 하루에 수천만 건의 거래를 처리하고 있습니다. 시스템 커널이 각 트랜잭션을 처리하는 데는 수십 마이크로초가 걸립니다. 물론, 섣달 그믐날의 이동통신사나 검색엔진 자체의 작업량은 우리보다 높지만 작업량 측면에서 위에서 언급한 특성과 결합하여 우리와 비교할 수 있는 사람은 거의 없는 것 같습니다. 동시에 시스템이 잠시도 느려지지 않고, 절대적으로 안정적으로 작동하며, 모든 사용자가 동등한 위치에 있다는 것이 우리에게 중요합니다.

약간의 역사

1994년에 호주 ASTS 시스템이 모스크바 은행간 통화 거래소(MICEX)에 출시되었으며 그 순간부터 러시아 전자 거래의 역사를 셀 수 있게 되었습니다. 1998년에는 인터넷 거래를 도입하기 위해 거래소 아키텍처가 현대화되었습니다. 그 이후로 모든 시스템과 하위 시스템의 새로운 솔루션 구현 및 아키텍처 변경 속도가 점점 빨라지고 있습니다.

그 당시 교환 시스템은 고성능 하드웨어인 매우 안정적인 HP Superdome 9000 서버에서 작동했습니다. PA-RISC), 여기에는 입력/출력 하위 시스템, 네트워크, RAM(실제로 RAM의 RAID 배열이 있음), 프로세서(핫 스왑 가능) 등 모든 것이 복제되었습니다. 시스템을 중지하지 않고도 서버 구성 요소를 변경할 수 있었습니다. 우리는 이러한 장치에 의존했으며 사실상 안전하다고 생각했습니다. 운영 체제는 Unix와 유사한 HP UX 시스템이었습니다.

그러나 2010년경부터 초단타매매(HFT), 즉 초단타매매, 간단히 말해서 증권거래소 로봇이라는 현상이 등장했습니다. 단 2,5년 만에 우리 서버의 부하가 140배 증가했습니다.

오래된 건축물과 장비로는 이러한 하중을 견디는 것이 불가능했습니다. 어떻게 든 적응해야했습니다.

처음

교환 시스템에 대한 요청은 두 가지 유형으로 나눌 수 있습니다.

• 업무. 달러, 주식 또는 기타 물건을 사고 싶다면 거래 시스템에 거래를 보내고 성공에 대한 응답을 받습니다.
• 정보 요청. 현재 가격을 알고 싶다면 주문장이나 지수를 확인한 후 정보 요청을 보내세요.

개략적으로 시스템의 핵심은 세 가지 수준으로 나눌 수 있습니다.

• 브로커와 클라이언트가 작동하는 클라이언트 수준입니다. 그들은 모두 액세스 서버와 상호 작용합니다.
• 게이트웨이 서버는 모든 정보 요청을 로컬에서 처리하는 캐싱 서버입니다. 현재 Sberbank 주식이 얼마에 거래되고 있는지 알고 싶으십니까? 요청이 액세스 서버로 이동합니다.
• 하지만 주식을 사고 싶다면 요청이 중앙 서버(거래 엔진)로 이동합니다. 각 유형의 시장마다 하나의 서버가 있으며 중요한 역할을 합니다. 우리가 이 시스템을 만든 것은 바로 서버입니다.

트레이딩 시스템의 핵심은 모든 거래가 교환 거래로 이루어지는 영리한 인메모리 데이터베이스입니다. 기본은 C로 작성되었으며 유일한 외부 종속성은 libc 라이브러리였으며 동적 메모리 할당은 전혀 없었습니다. 처리 시간을 줄이기 위해 시스템은 정적 배열 세트와 정적 데이터 재배치로 시작합니다. 먼저 오늘의 모든 데이터가 메모리에 로드되고 추가 디스크 액세스가 수행되지 않으며 모든 작업이 메모리에서만 수행됩니다. 시스템이 시작되면 모든 참조 데이터가 이미 정렬되어 있으므로 검색이 매우 효율적으로 작동하고 런타임에 거의 시간이 걸리지 않습니다. 모든 테이블은 동적 데이터 구조를 위한 침입형 목록과 트리로 만들어지므로 런타임 시 메모리 할당이 필요하지 않습니다.

우리의 거래 및 청산 시스템 개발 역사를 간략하게 살펴보겠습니다.
거래 및 청산 시스템 아키텍처의 첫 번째 버전은 소위 Unix 상호 작용을 기반으로 구축되었습니다. 공유 메모리, 세마포어 및 대기열이 사용되었으며 각 프로세스는 단일 스레드로 구성되었습니다. 이러한 접근 방식은 1990년대 초반에 널리 퍼졌습니다.

시스템의 첫 번째 버전에는 두 가지 수준의 게이트웨이와 거래 시스템의 중앙 서버가 포함되었습니다. 작업 흐름은 다음과 같았습니다.

• 클라이언트는 게이트웨이에 도달하는 요청을 보냅니다. 형식(데이터 자체는 아님)의 유효성을 확인하고 잘못된 트랜잭션을 거부합니다.
• 정보 요청이 전송되면 로컬로 실행됩니다. 거래에 관해 이야기하고 있다면 중앙 서버로 리디렉션됩니다.
• 그런 다음 거래 엔진은 트랜잭션을 처리하고, 로컬 메모리를 수정하고, 별도의 복제 엔진을 사용하여 복제를 위해 트랜잭션과 트랜잭션 자체에 응답을 보냅니다.
• 게이트웨이는 중앙 노드로부터 응답을 받아 클라이언트에 전달합니다.
• 얼마 후 게이트웨이는 복제 메커니즘을 통해 트랜잭션을 수신하고 이번에는 로컬에서 실행하여 다음 정보 요청이 최신 데이터를 표시하도록 데이터 구조를 변경합니다.

실제로 이는 게이트웨이가 거래 시스템에서 수행되는 작업을 완전히 복제하는 복제 모델을 설명합니다. 별도의 복제 채널을 통해 트랜잭션이 여러 액세스 노드에서 동일한 순서로 실행되도록 보장했습니다.

코드가 단일 스레드였기 때문에 많은 클라이언트에 서비스를 제공하기 위해 프로세스 포크가 있는 고전적인 방식이 사용되었습니다. 그러나 전체 데이터베이스를 포크하는 것은 매우 비용이 많이 들기 때문에 TCP 세션에서 패킷을 수집하여 하나의 큐(SystemV Message Queue)로 전송하는 경량 서비스 프로세스가 사용되었습니다. 게이트웨이와 거래 엔진은 이 대기열에서만 작동하여 실행을 위해 거기에서 트랜잭션을 가져옵니다. 어떤 서비스 프로세스가 이를 읽어야 하는지 명확하지 않기 때문에 더 이상 이에 대한 응답을 보낼 수 없습니다. 그래서 우리는 트릭을 사용했습니다. 각 분기된 프로세스는 자체적으로 응답 대기열을 생성하고 요청이 수신 대기열에 들어오면 응답 대기열에 대한 태그가 즉시 추가되었습니다.

대기열에서 대기열로 대량의 데이터를 지속적으로 복사하면 문제가 발생하며, 특히 정보 요청의 경우 일반적입니다. 따라서 우리는 또 다른 트릭을 사용했습니다. 응답 대기열 외에도 각 프로세스는 공유 메모리(SystemV 공유 메모리)도 생성했습니다. 패키지 자체가 그 안에 배치되었으며 태그만 대기열에 저장되어 원본 패키지를 찾을 수 있었습니다. 이는 프로세서 캐시에 데이터를 저장하는 데 도움이 되었습니다.

SystemV IPC에는 큐, 메모리 및 세마포어 개체의 상태를 보기 위한 유틸리티가 포함되어 있습니다. 우리는 이를 적극적으로 활용하여 특정 순간에 시스템에서 무슨 일이 일어나고 있는지, 패킷이 축적된 곳은 어디인지, 무엇이 차단되었는지 등을 파악했습니다.

첫 번째 업그레이드

우선, 단일 프로세스 게이트웨이를 제거했습니다. 중요한 단점은 하나의 복제 트랜잭션이나 클라이언트의 하나의 정보 요청을 처리할 수 있다는 것입니다. 로드가 증가하면 게이트웨이에서 요청을 처리하는 데 시간이 더 걸리고 복제 흐름을 처리할 수 없게 됩니다. 또한 클라이언트가 트랜잭션을 보낸 경우 유효성을 확인하고 추가로 전달하기만 하면 됩니다. 따라서 단일 게이트웨이 프로세스를 병렬로 실행될 수 있는 여러 구성 요소, 즉 RW 잠금을 사용하여 공유 메모리 영역에서 서로 독립적으로 실행되는 멀티 스레드 정보 및 트랜잭션 프로세스로 대체했습니다. 동시에 우리는 디스패치 및 복제 프로세스를 도입했습니다.

고주파 거래의 영향

위 버전의 아키텍처는 2010년까지 존재했습니다. 한편 우리는 더 이상 HP Superdome 서버의 성능에 만족하지 못했습니다. 또한 PA-RISC 아키텍처는 사실상 중단되었으며 공급업체는 중요한 업데이트를 제공하지 않았습니다. 그 결과 우리는 HP UX/PA RISC에서 Linux/x86으로 전환하기 시작했습니다. 전환은 액세스 서버의 적응으로 시작되었습니다.

왜 아키텍처를 다시 변경해야 했나요? 사실 고주파 거래로 인해 시스템 코어의 로드 프로필이 크게 변경되었습니다.

상당한 가격 변화를 초래한 작은 거래가 있다고 가정해 보겠습니다. 누군가가 XNUMX억 달러를 구입했습니다. 몇 밀리초 후에 모든 시장 참가자는 이를 인지하고 수정을 시작합니다. 당연히 요청은 거대한 대기열에 늘어서 시스템이 이를 처리하는 데 오랜 시간이 걸립니다.

이 50ms 간격에서 평균 속도는 초당 약 16건의 트랜잭션입니다. 창을 20ms로 줄이면 초당 90개의 트랜잭션의 평균 속도를 얻을 수 있으며 최대 200개의 트랜잭션이 발생합니다. 즉, 부하가 일정하지 않고 갑작스럽게 발생합니다. 그리고 요청 대기열은 항상 빠르게 처리되어야 합니다.

그런데 왜 대기열이 있습니까? 따라서 우리의 예에서는 많은 사용자가 가격 변동을 알아차리고 그에 따라 거래를 보냈습니다. 그들은 게이트웨이에 와서 직렬화하고 특정 순서를 설정하여 네트워크로 보냅니다. 라우터는 패킷을 섞은 후 전달합니다. 누구의 패키지가 먼저 도착했는지, 해당 거래가 "성공"했습니다. 결과적으로 Exchange 클라이언트는 동일한 트랜잭션이 여러 게이트웨이에서 전송되면 빠른 처리 가능성이 높아진다는 사실을 깨닫기 시작했습니다. 곧 교환 로봇이 게이트웨이에 요청을 퍼붓기 시작했고 거래가 눈에 띄게 증가했습니다.

새로운 진화 라운드

광범위한 테스트와 연구 끝에 우리는 실시간 운영 체제 커널로 전환했습니다. 이를 위해 우리는 RedHat Enterprise MRG Linux를 선택했습니다. 여기서 MRG는 메시징 실시간 그리드를 나타냅니다. 실시간 패치의 장점은 가능한 가장 빠른 실행을 위해 시스템을 최적화한다는 것입니다. 모든 프로세스는 FIFO 대기열에 정렬되고 코어는 격리될 수 있으며 배출이 없으며 모든 트랜잭션은 엄격한 순서로 처리됩니다.

빨간색 - 일반 커널에서 큐로 작업하고, 녹색 - 실시간 커널에서 작업합니다.

그러나 일반 서버에서 짧은 대기 시간을 달성하는 것은 그리 쉽지 않습니다.

• x86 아키텍처에서 중요한 주변 장치 작업의 기반이 되는 SMI 모드는 크게 간섭합니다. 모든 종류의 하드웨어 이벤트 처리와 구성 요소 및 장치 관리는 소위 투명 SMI 모드에서 펌웨어에 의해 수행됩니다. 이 모드에서는 운영 체제가 펌웨어가 수행하는 작업을 전혀 볼 수 없습니다. 일반적으로 모든 주요 공급업체는 SMI 처리량을 줄일 수 있는 펌웨어 서버용 특수 확장을 제공합니다.
• 프로세서 주파수에 대한 동적 제어가 없어야 하며 이로 인해 추가 가동 중지 시간이 발생합니다.
• 파일 시스템 로그가 플러시되면 예측할 수 없는 지연을 일으키는 특정 프로세스가 커널에서 발생합니다.
• CPU 선호도, 인터럽트 선호도, NUMA와 같은 사항에 주의를 기울여야 합니다.

실시간 처리를 위해 Linux 하드웨어와 커널을 설정하는 주제는 별도의 기사에서 다루어야 한다고 말씀드리고 싶습니다. 우리는 좋은 결과를 얻기까지 많은 시간을 실험하고 연구했습니다.

PA-RISC 서버에서 x86으로 이동할 때 실제로 시스템 코드를 많이 변경할 필요가 없었고 단지 이를 조정하고 재구성했습니다. 동시에 우리는 몇 가지 버그를 수정했습니다. 예를 들어 PA RISC는 빅 엔디안 시스템이고 x86은 리틀 엔디안 시스템이라는 사실의 결과가 빠르게 드러났습니다. 예를 들어 데이터가 잘못 읽혔습니다. 더 까다로운 버그는 PA RISC가 사용하는 버그였습니다. 일관되게 일관되게 (순차적으로 일관성) 메모리 액세스, x86은 읽기 작업의 순서를 변경할 수 있으므로 한 플랫폼에서 절대적으로 유효한 코드가 다른 플랫폼에서는 손상되었습니다.

x86으로 전환한 후 성능은 거의 60배 증가했으며 평균 트랜잭션 처리 시간은 XNUMXμs로 감소했습니다.

이제 시스템 아키텍처에 어떤 주요 변경 사항이 적용되었는지 자세히 살펴보겠습니다.

핫 리저브 서사시

상용 서버로 전환했을 때 우리는 그 서버의 안정성이 낮다는 것을 알고 있었습니다. 따라서 새로운 아키텍처를 생성할 때 우리는 선험적으로 하나 이상의 노드에 장애가 발생할 가능성을 가정했습니다. 따라서 매우 신속하게 백업 시스템으로 전환할 수 있는 상시 대기 시스템이 필요했습니다.

또한 다음과 같은 다른 요구 사항도 있었습니다.

• 어떠한 경우에도 처리된 거래가 손실되어서는 안 됩니다.
• 시스템은 인프라에 절대적으로 투명해야 합니다.
• 클라이언트는 끊어진 연결을 볼 수 없습니다.
• 예약으로 인해 상당한 지연이 발생해서는 안 됩니다. 이는 교환에 있어 중요한 요소이기 때문입니다.

상시 대기 시스템을 생성할 때 이중 장애(예: 한 서버의 네트워크가 작동을 멈추고 메인 서버가 정지되는 경우)와 같은 시나리오를 고려하지 않았습니다. 테스트 중에 오류가 식별되므로 소프트웨어 오류 가능성을 고려하지 않았습니다. 하드웨어의 잘못된 작동을 고려하지 않았습니다.

결과적으로 우리는 다음과 같은 계획을 세웠습니다.

• 기본 서버는 게이트웨이 서버와 직접 상호 작용했습니다.
• 메인 서버에서 수신된 모든 거래는 별도의 채널을 통해 즉시 백업 서버로 복제되었습니다. 문제가 발생하면 중재자(지사)가 전환을 조정했습니다.

  

• 메인 서버는 각 트랜잭션을 처리하고 백업 서버의 확인을 기다렸습니다. 대기 시간을 최소화하기 위해 백업 서버에서 트랜잭션이 완료될 때까지 기다리지 않았습니다. 트랜잭션이 네트워크를 통해 이동하는 데 걸리는 시간은 실행 시간과 비슷하므로 추가 대기 시간이 추가되지 않았습니다.
• 이전 트랜잭션에 대한 메인 서버와 백업 서버의 처리 상태만 확인할 수 있었고, 현재 트랜잭션의 처리 상태는 알 수 없었습니다. 우리는 여전히 단일 스레드 프로세스를 사용하고 있었기 때문에 Backup의 응답을 기다리면 전체 처리 흐름이 느려졌을 것이므로 합리적인 절충안을 만들었습니다. 이전 트랜잭션의 결과를 확인했습니다.

이 계획은 다음과 같이 작동했습니다.

기본 서버가 응답을 중지했지만 게이트웨이는 계속 통신한다고 가정해 보겠습니다. 백업 서버에서 시간 초과가 발생하면 주지사에게 연락하여 주 서버의 역할을 할당하고 모든 게이트웨이가 새 주 서버로 전환됩니다.

기본 서버가 다시 온라인 상태가 되면 특정 시간 동안 게이트웨이에서 서버로의 호출이 없기 때문에 내부 시간 초과도 발생합니다. 그런 다음 그는 또한 주지사에게 의지하고 계획에서 그를 제외합니다. 결과적으로 거래소는 거래 기간이 끝날 때까지 하나의 서버로 작동합니다. 서버 장애 확률이 매우 낮기 때문에 이 방식은 복잡한 로직을 포함하지 않고 테스트하기 쉬웠기 때문에 상당히 수용 가능한 것으로 간주되었습니다.

계속 될거야.

출처 : habr.com