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

이것은 Exchange의 운영을 보장하는 강력하고 고부하 시스템을 만들기 위한 우리의 험난한 길에 대한 긴 이야기의 연속입니다. 첫 번째 부분은 다음과 같습니다. habr.com/en/post/444300

신비한 오류

수많은 테스트 끝에 업데이트된 거래 및 청산 시스템이 가동되었고, 우리는 탐정적이고 신비로운 이야기를 쓸 수 있는 버그에 직면했습니다.

메인 서버에서 실행한 직후 트랜잭션 중 하나에 오류가 발생했습니다. 그러나 백업 서버에서는 모든 것이 정상이었습니다. 메인 서버에서 지수를 계산하는 간단한 수학적 연산이 실제 인수와 부정적인 결과를 가져온 것으로 나타났습니다! 우리는 연구를 계속했고 SSE2 레지스터에서 부동 소수점 숫자로 작업할 때 반올림을 담당하는 XNUMX비트의 차이를 발견했습니다.

우리는 반올림 비트 세트를 사용하여 지수를 계산하는 간단한 테스트 유틸리티를 작성했습니다. 우리가 사용했던 RedHat Linux 버전에서는 불운한 비트가 삽입될 때 수학 함수 작업에 버그가 있는 것으로 나타났습니다. 우리는 이것을 RedHat에 보고했고, 잠시 후 RedHat으로부터 패치를 받아 출시했습니다. 오류가 더 이상 발생하지 않았지만 이 비트가 어디서 왔는지 확실하지 않습니까? 함수가 이를 담당했습니다. fesetround C 언어에서 우리는 가정된 오류를 찾기 위해 코드를 주의 깊게 분석했습니다. 가능한 모든 상황을 확인했습니다. 반올림을 사용한 모든 함수를 살펴보았습니다. 실패한 세션을 재현하려고 시도했습니다. 다른 옵션을 가진 다른 컴파일러를 사용했습니다. 정적 및 동적 분석이 사용되었습니다.

오류의 원인을 찾을 수 없습니다.

그런 다음 하드웨어 점검을 시작했습니다. 프로세서의 부하 테스트를 수행했습니다. RAM을 확인했습니다. 우리는 한 셀에서 다중 비트 오류가 발생할 가능성이 거의 없는 시나리오에 대한 테스트도 실행했습니다. 소용이 없습니다.

결국 우리는 고에너지 물리학 세계의 이론에 정착했습니다. 일부 고에너지 입자가 데이터 센터로 날아와 케이스 벽을 뚫고 프로세서에 부딪혀 트리거 래치가 바로 그 부분에 달라붙게 되었습니다. 이 터무니없는 이론을 '중성미자'라고 불렀습니다. 입자 물리학과 거리가 멀다면 중성미자는 외부 세계와 거의 상호 작용하지 않으며 확실히 프로세서 작동에 영향을 미칠 수 없습니다.

장애 원인을 찾을 수 없었기 때문에 만약을 대비해 '문제가 있는' 서버는 운영에서 제외됐다.

얼마 후 우리는 핫 백업 시스템을 개선하기 시작했습니다. 소위 "웜 예약"(웜), 즉 비동기식 복제본을 도입했습니다. 서로 다른 데이터 센터에 위치할 수 있는 트랜잭션 스트림을 수신했지만 Warms는 다른 서버와 적극적으로 상호 작용하지 않았습니다.

왜 이런 일이 일어났습니까? 백업 서버에 장애가 발생하면 기본 서버에 연결된 웜 연결이 새 백업이 됩니다. 즉, 장애 발생 후 시스템은 거래 세션이 끝날 때까지 하나의 메인 서버에 남아 있지 않습니다.

그리고 새 버전의 시스템을 테스트하고 가동했을 때 반올림 비트 오류가 다시 발생했습니다. 게다가 웜 서버 수가 늘어나면서 오류가 더 자주 나타나기 시작했습니다. 동시에 판매자는 구체적인 증거가 없었기 때문에 보여줄 것이 없었습니다.

다음 상황 분석에서 문제가 OS와 관련이 있을 수 있다는 이론이 나타났습니다. 우리는 무한 루프에서 함수를 호출하는 간단한 프로그램을 작성했습니다. fesetround, 현재 상태를 기억하고 슬립을 통해 확인하는데, 이는 많은 경쟁 스레드에서 수행됩니다. 절전 매개변수와 스레드 수를 선택한 후 유틸리티를 실행한 지 약 5분 후에 비트 오류가 지속적으로 재현되기 시작했습니다. 그러나 Red Hat 지원팀에서는 이를 재현할 수 없었습니다. 다른 서버를 테스트한 결과 특정 프로세서를 사용하는 서버만 오류에 취약한 것으로 나타났습니다. 동시에 새 커널로 전환하면 문제가 해결되었습니다. 결국 우리는 단순히 OS를 교체했을 뿐, 버그의 진정한 원인은 여전히 ​​불분명했습니다.

그리고 작년에 갑자기 Habré에 기사가 게재되었습니다.Intel Skylake 프로세서에서 버그를 발견한 방법" 여기에 설명된 상황은 우리의 상황과 매우 유사했지만 저자는 조사를 더 진행하여 오류가 마이크로코드에 있다는 이론을 제시했습니다. 그리고 Linux 커널이 업데이트되면 제조업체는 마이크로코드도 업데이트합니다.

시스템의 추가 개발

오류를 제거했지만 이 이야기로 인해 시스템 아키텍처를 재고하게 되었습니다. 결국, 우리는 그러한 버그의 반복으로부터 보호받지 못했습니다.

다음 원칙은 예약 시스템의 다음 개선을 위한 기초를 형성했습니다.

• 누구도 믿을 수 없습니다. 서버가 제대로 작동하지 않을 수 있습니다.
• 다수 예약.
• 합의를 보장합니다. 다수 예약에 대한 논리적 추가.
• 이중 실패가 가능합니다.
• 활력. 새로운 핫 스탠바이 방식은 이전 방식보다 나쁘지 않아야 합니다. 마지막 서버까지 거래가 중단 없이 진행되어야 합니다.
• 대기 시간이 약간 증가합니다. 가동 중지 시간은 막대한 재정적 손실을 수반합니다.
• 네트워크 상호 작용을 최소화하여 대기 시간을 최대한 낮게 유지합니다.
• 몇 초 안에 새로운 마스터 서버를 선택합니다.

시중에서 사용할 수 있는 솔루션 중 어느 것도 우리에게 적합하지 않았고 Raft 프로토콜은 아직 초기 단계에 있었기 때문에 자체 솔루션을 만들었습니다.

네트워킹

예약 시스템 외에도 네트워크 상호 작용을 현대화하기 시작했습니다. I/O 하위 시스템은 여러 프로세스로 구성되어 있어 지터와 대기 시간에 가장 큰 영향을 미쳤습니다. TCP 연결을 처리하는 수백 개의 프로세스가 있기 때문에 우리는 그들 사이를 지속적으로 전환해야 했으며 마이크로초 단위로 이는 다소 시간이 많이 걸리는 작업입니다. 그러나 최악의 부분은 프로세스가 처리할 패킷을 수신할 때 이를 하나의 SystemV 대기열로 보낸 다음 다른 SystemV 대기열에서 이벤트를 기다렸다는 것입니다. 그러나 노드 수가 많은 경우 한 프로세스에서 새 TCP 패킷이 도착하고 다른 프로세스의 큐에 데이터가 수신되는 것은 OS에 대한 두 가지 경쟁 이벤트를 나타냅니다. 이 경우 두 작업에 사용할 수 있는 물리적 프로세서가 없으면 하나는 처리되고 두 번째는 대기 대기열에 배치됩니다. 결과를 예측하는 것은 불가능합니다.

이러한 상황에서는 동적 프로세스 우선순위 제어를 사용할 수 있지만 이를 위해서는 리소스 집약적인 시스템 호출을 사용해야 합니다. 결과적으로 우리는 classic epoll을 사용하여 하나의 스레드로 전환했는데, 이로 인해 속도가 크게 향상되고 트랜잭션 처리 시간이 단축되었습니다. 또한 별도의 네트워크 통신 프로세스와 SystemV를 통한 통신을 없애고 시스템 호출 횟수를 대폭 줄였으며 작업 우선 순위를 제어하기 시작했습니다. I/O 하위 시스템에서만 시나리오에 따라 약 8~17마이크로초를 절약할 수 있었습니다. 이 단일 스레드 방식은 그 이후로 변경되지 않고 사용되었으며 여유가 있는 하나의 epoll 스레드는 모든 연결을 서비스하는 데 충분합니다.

거래 처리

시스템의 부하가 증가함에 따라 거의 모든 구성 요소를 업그레이드해야 했습니다. 그러나 불행하게도 최근 몇 년간 프로세서 클럭 속도의 성장 정체로 인해 더 이상 프로세스를 정면으로 확장하는 것이 불가능해졌습니다. 따라서 우리는 엔진 프로세스를 세 가지 수준으로 나누기로 결정했으며 그 중 가장 바쁜 것은 계정의 자금 가용성을 평가하고 거래 자체를 생성하는 위험 검사 시스템입니다. 그러나 돈은 다른 통화로 표시될 수 있으므로 요청 처리를 어떤 기준으로 나누어야 하는지 파악해야 했습니다.

논리적인 해결책은 이를 통화로 나누는 것입니다. 한 서버는 달러로, 다른 서버는 파운드로, 세 번째 서버는 유로로 거래합니다. 그러나 이러한 계획을 사용하여 서로 다른 통화를 구매하기 위해 두 개의 거래가 전송되면 지갑 비동기화 문제가 발생합니다. 그러나 동기화는 어렵고 비용이 많이 듭니다. 따라서 지갑별로, 악기별로 별도로 샤딩하는 것이 맞을 것입니다. 그건 그렇고, 대부분의 서구 거래소는 우리만큼 엄격하게 위험을 확인하는 작업을 수행하지 않으므로 대부분 오프라인에서 수행됩니다. 온라인 검증을 구현해야 했습니다.

예를 들어 설명해 보겠습니다. 거래자는 30달러를 사고 싶어하며 요청은 거래 검증으로 이동합니다. 우리는 이 거래자가 이 거래 모드에 허용되는지와 필요한 권리를 가지고 있는지 확인합니다. 모든 것이 정상이면 요청은 위험 검증 시스템으로 전달됩니다. 거래를 성사시키기 위한 자금이 충분한지 확인합니다. 현재 필요한 금액이 차단되어 있다는 안내가 있습니다. 그런 다음 요청은 거래를 승인하거나 거부하는 거래 시스템으로 전달됩니다. 거래가 승인되었다고 가정해 보겠습니다. 그러면 위험 확인 시스템에서 자금이 차단 해제되었음을 표시하고 루블이 달러로 전환됩니다.

일반적으로 위험 검사 시스템은 복잡한 알고리즘을 포함하고 리소스 집약적인 대량 계산을 수행하며, 언뜻 보기에 단순히 "계정 잔액"을 확인하는 것이 아닙니다.

엔진 프로세스를 레벨별로 나누기 시작했을 때 문제가 발생했습니다. 당시 사용 가능한 코드가 유효성 검사 및 확인 단계에서 동일한 데이터 배열을 적극적으로 사용했기 때문에 전체 코드 베이스를 다시 작성해야 했습니다. 결과적으로 우리는 최신 프로세서의 명령 처리 기술을 차용했습니다. 각 명령은 작은 단계로 나누어지고 여러 작업이 한 주기에 병렬로 수행됩니다.

코드를 약간 수정한 후 병렬 트랜잭션 처리를 위한 파이프라인을 만들었습니다. 여기서 트랜잭션은 파이프라인의 4단계(네트워크 상호 작용, 검증, 실행 및 결과 게시)로 나뉩니다.

예를 살펴보겠습니다. 우리는 직렬과 병렬의 두 가지 처리 시스템을 가지고 있습니다. 첫 번째 트랜잭션이 도착하고 두 시스템 모두에서 검증을 위해 전송됩니다. 두 번째 트랜잭션은 즉시 도착합니다. 병렬 시스템에서는 즉시 작업이 시작되고 순차 시스템에서는 첫 번째 트랜잭션이 현재 처리 단계를 통과할 때까지 기다리는 대기열에 배치됩니다. 즉, 파이프라인 처리의 주요 장점은 트랜잭션 대기열을 더 빠르게 처리한다는 것입니다.

이것이 우리가 ASTS+ 시스템을 생각해낸 방법입니다.

사실, 컨베이어를 사용해도 모든 것이 그렇게 순조롭게 진행되는 것은 아닙니다. 이웃 트랜잭션의 데이터 배열에 영향을 미치는 트랜잭션이 있다고 가정해 보겠습니다. 이는 교환의 일반적인 상황입니다. 이러한 트랜잭션은 다른 트랜잭션에 영향을 미칠 수 있으므로 파이프라인에서 실행할 수 없습니다. 이러한 상황을 데이터 위험이라고 하며 이러한 트랜잭션은 단순히 개별적으로 처리됩니다. 대기열의 "빠른" 트랜잭션이 모두 실행되면 파이프라인이 중지되고 시스템이 "느린" 트랜잭션을 처리한 다음 파이프라인을 다시 시작합니다. 다행스럽게도 전체 흐름에서 이러한 트랜잭션의 비율은 매우 작기 때문에 파이프라인이 거의 중지되지 않아 전체 성능에 영향을 미치지 않습니다.

그런 다음 우리는 세 가지 실행 스레드를 동기화하는 문제를 해결하기 시작했습니다. 그 결과 고정된 크기의 셀이 있는 링 버퍼 기반 시스템이 탄생했습니다. 이 시스템에서는 모든 것이 처리 속도에 따라 달라지며 데이터는 복사되지 않습니다.

• 들어오는 모든 네트워크 패킷은 할당 단계에 들어갑니다.
• 이를 배열에 배치하고 1단계에서 사용 가능한 것으로 표시합니다.
• 두 번째 트랜잭션이 도착했으며 다시 1단계에서 사용할 수 있습니다.
• 첫 번째 처리 스레드는 사용 가능한 트랜잭션을 확인하고 이를 처리한 후 두 번째 처리 스레드의 다음 단계로 이동합니다.
• 그런 다음 첫 번째 트랜잭션을 처리하고 해당 셀에 플래그를 지정합니다. deleted — 이제 새로운 용도로 사용할 수 있습니다.

전체 대기열은 이러한 방식으로 처리됩니다.

각 단계의 처리에는 단위 또는 수십 마이크로초가 걸립니다. 그리고 표준 OS 동기화 체계를 사용하면 동기화 자체에 더 많은 시간을 낭비하게 됩니다. 이것이 우리가 spinlock을 사용하기 시작한 이유입니다. 그러나 이는 실시간 시스템에서는 매우 나쁜 형태이며 RedHat에서는 이를 엄격히 권장하지 않으므로 100ms 동안 스핀락을 적용한 다음 세마포어 모드로 전환하여 교착 상태의 가능성을 제거합니다.

그 결과, 초당 약 8만 건의 트랜잭션을 달성하는 성능을 달성했습니다. 그리고 말 그대로 두 달 뒤, 기사 LMAX Disruptor에 대해 동일한 기능을 가진 회로에 대한 설명을 보았습니다.

이제 한 단계에서 여러 실행 스레드가 있을 수 있습니다. 모든 거래는 접수된 순서대로 하나씩 처리되었습니다. 그 결과 최대 성능은 초당 18건에서 50건으로 증가했습니다.

환위험관리시스템

완벽에는 한계가 없으며 곧 다시 현대화를 시작했습니다. ASTS+ 프레임워크 내에서 위험 관리 및 결제 운영 시스템을 자율 구성 요소로 이동하기 시작했습니다. 우리는 유연한 현대 아키텍처와 새로운 계층적 위험 모델을 개발하고 가능한 경우 클래스를 사용하려고 노력했습니다. fixed_point 대신 double.

그러나 즉시 문제가 발생했습니다. 수년 동안 작동해 온 모든 비즈니스 로직을 어떻게 동기화하고 이를 새 시스템으로 전송할 수 있을까요? 그 결과, 새로운 시스템 프로토타입의 첫 번째 버전은 폐기되어야 했습니다. 현재 생산 중인 두 번째 버전은 거래 및 위험 부분 모두에서 작동하는 동일한 코드를 기반으로 합니다. 개발 중에 가장 어려웠던 일은 두 버전을 git merge하는 것이었습니다. 우리 동료 Evgeniy Mazurenok은 매주 이 작업을 수행했으며 매번 그는 아주 오랫동안 저주했습니다.

새로운 시스템을 선택할 때 우리는 즉시 상호작용 문제를 해결해야 했습니다. 데이터 버스를 선택할 때는 안정적인 지터와 최소 지연 시간을 보장하는 것이 필요했습니다. InfiniBand RDMA 네트워크는 이에 가장 적합했습니다. 평균 처리 시간은 4G 이더넷 네트워크보다 10배 짧습니다. 하지만 우리를 정말 매료시켰던 것은 백분위수(99와 99,9)의 차이였습니다.

물론 InfiniBand에는 어려움이 있습니다. 첫째, 소켓 대신 ibverb라는 다른 API입니다. 둘째, 널리 사용 가능한 오픈 소스 메시징 솔루션이 거의 없습니다. 우리는 자체 프로토타입을 만들려고 했지만 매우 어려운 것으로 판명되어 상용 솔루션인 Confinity Low Latency Messaging(이전 IBM MQ LLM)을 선택했습니다.

그러다가 위험 시스템을 적절하게 분할하는 작업이 발생했습니다. 단순히 위험 엔진을 제거하고 중간 노드를 생성하지 않으면 두 소스의 거래가 혼합될 수 있습니다.

소위 Ultra Low Latency 솔루션에는 재정렬 모드가 있습니다. 두 소스의 거래는 수령 시 필요한 순서로 정렬될 수 있으며, 이는 주문에 대한 정보 교환을 위한 별도의 채널을 사용하여 구현됩니다. 그러나 우리는 아직 이 모드를 사용하지 않습니다. 이는 전체 프로세스를 복잡하게 만들고 많은 솔루션에서는 전혀 지원되지 않습니다. 또한 각 트랜잭션에는 해당 타임스탬프가 할당되어야 하며 우리 체계에서는 이 메커니즘을 올바르게 구현하기가 매우 어렵습니다. 따라서 우리는 메시지 브로커, 즉 위험 엔진 간에 메시지를 배포하는 디스패처와 함께 고전적인 방식을 사용했습니다.

두 번째 문제는 클라이언트 액세스와 관련이 있었습니다. Risk Gateway가 여러 개인 경우 클라이언트는 각 게이트웨이에 연결해야 하며 이를 위해서는 클라이언트 계층을 변경해야 합니다. 우리는 이 단계에서 이 문제를 벗어나고 싶었기 때문에 현재 Risk Gateway 설계는 전체 데이터 스트림을 처리합니다. 이는 최대 처리량을 크게 제한하지만 시스템 통합을 크게 단순화합니다.

복사

우리 시스템에는 단일 실패 지점이 없어야 합니다. 즉, 메시지 브로커를 포함한 모든 구성 요소가 중복되어야 합니다. 우리는 CLLM 시스템을 사용하여 이 문제를 해결했습니다. 여기에는 두 개의 디스패처가 마스터-슬레이브 모드에서 작동할 수 있는 RCMS 클러스터가 포함되어 있으며, 하나가 실패하면 시스템이 자동으로 다른 시스템으로 전환됩니다.

백업 데이터 센터와의 협력

InfiniBand는 랙 마운트 장비를 연결하는 로컬 네트워크로 작동하는 데 최적화되어 있으며 지리적으로 분산된 두 데이터 센터 사이에 InfiniBand 네트워크를 배치할 수 없습니다. 따라서 우리는 일반 이더넷 네트워크를 통해 메시지 저장소에 연결하고 모든 트랜잭션을 두 번째 IB 네트워크로 중계하는 브리지/디스패처를 구현했습니다. 데이터 센터에서 마이그레이션해야 하는 경우 지금 사용할 데이터 센터를 선택할 수 있습니다.

결과

위의 모든 작업은 한 번에 완료되지 않았으며 새로운 아키텍처를 개발하는 데 여러 번의 반복이 필요했습니다. 우리는 한 달 만에 프로토타입을 만들었지만 작동 가능한 상태로 만드는 데는 2년 이상이 걸렸습니다. 우리는 트랜잭션 처리 시간 증가와 시스템 안정성 향상 사이에서 최선의 절충안을 찾으려고 노력했습니다.

시스템이 대대적으로 업데이트되었기 때문에 우리는 두 개의 독립적인 소스에서 데이터 복구를 구현했습니다. 어떤 이유로 메시지 저장소가 올바르게 작동하지 않는 경우 위험 엔진의 두 번째 소스에서 트랜잭션 로그를 가져올 수 있습니다. 이 원칙은 시스템 전체에서 준수됩니다.

무엇보다도 우리는 브로커나 다른 누구도 새로운 아키텍처에 대한 상당한 재작업을 요구하지 않도록 클라이언트 API를 보존할 수 있었습니다. 일부 인터페이스를 변경해야 했지만 운영 모델을 크게 변경할 필요는 없었습니다.

우리는 아키텍처에서 가장 눈에 띄는 두 가지 혁신인 Risk Engine과 BUS의 약어로 플랫폼의 현재 버전을 Rebus라고 불렀습니다.

처음에는 청산 부분만 할당하려고 했으나 결과적으로 거대한 분산 시스템이 탄생했습니다. 이제 클라이언트는 Trade Gateway, Clearing Gateway 또는 둘 다와 상호 작용할 수 있습니다.

우리가 궁극적으로 달성한 것:

대기 시간 수준을 줄였습니다. 적은 양의 트랜잭션으로 시스템은 이전 버전과 동일하게 작동하지만 동시에 훨씬 더 높은 부하를 견딜 수 있습니다.

최고 성능은 초당 트랜잭션 50개에서 180개로 증가했습니다. 유일한 주문 일치 흐름으로 인해 추가 증가가 방해됩니다.

추가 개선을 위한 두 가지 방법이 있습니다. 일치를 병렬화하고 게이트웨이와 작동하는 방식을 변경하는 것입니다. 이제 모든 게이트웨이는 이러한 부하가 발생하면 정상적으로 작동하지 않는 복제 체계에 따라 작동합니다.

마지막으로 엔터프라이즈 시스템을 마무리하는 사람들에게 몇 가지 조언을 드리고 싶습니다.

• 항상 최악의 상황에 대비하세요. 문제는 항상 예기치 않게 발생합니다.
• 일반적으로 아키텍처를 빠르게 리메이크하는 것은 불가능합니다. 특히 여러 지표에 걸쳐 최대의 신뢰성을 달성해야 하는 경우. 노드가 많을수록 지원에 더 많은 리소스가 필요합니다.
• 모든 맞춤형 및 독점 솔루션에는 연구, 지원 및 유지 관리를 위한 추가 리소스가 필요합니다.
• 시스템 신뢰성 및 장애 후 복구 문제 해결을 미루지 말고 초기 설계 단계에서 고려하세요.

출처 : habr.com