금융 거래 시스템 아키텍처

IT 전문가 및 기타 전문가를위한 실용적인 주제.

고정 프로토콜 FAQ가 게시됩니다.

9 월 26 일 Fixed Income Trading System Architecture 워크샵.

Fixed Income Instruments Fixed Income Trading의 개요 Fixed Income Markets의 브로커 / 딜러 회사의 요구 사항 브로커 / 딜러의 Fixed Income Trading System의 요구 사항 / 특징 Fixed Income Trading Platform의 아키텍처 다양한 구성 요소 및 역할 사용 된 주요 기술 및 공급 업체 제품.

관련 게시물.

위험 관리 USA 2016 & # 8211; 위험 데이터 문제 & # 038; 빅 데이터 플랫폼 솔루션.

My Book & Derivatives Managing Contracts & # 8221; 출시 됨.

팩토링 개념이란 무엇입니까?

2 개의 댓글.

[[# 8230;] Fixed Income Trading System Architecture [& # 8230;]

Hi Khader, 귀하의 웹 블로그는 훌륭합니다. 그것을 지켜라. 그것의.

도움이됩니다. 우리는 여기서 다시 계속 될 것입니다. 정보가 필요해. 어떤 SQL.

분석 역할은에 대한 보안 마스터를 구성하는 사람을 수행합니다.

회사 (eg. Fixed Income) 실행? 레코드가있는 데이터베이스 테이블이 필요합니다.

그 안에있는 이름과 필드 이름과 SQL 문. 서둘러주세요.

회신을 남겨주 답장을 취소하십시오.

내 책 "관리 파생 계약"이 발표되었습니다.

알고리즘 트레이딩 시스템 아키텍처.

이전에이 블로그에서 지적 알고리즘 트레이딩 시스템의 개념적 아키텍처와 생산 알고리즘 트레이딩 시스템의 기능적 및 비 기능적 요구 사항에 대해 작성했습니다. 그 이후로 필자는 이러한 아키텍처 요구 사항을 충족시킬 수 있다고 믿는 시스템 아키텍처를 설계했습니다. 이 글에서는 ISO / IEC / IEEE 42010 시스템의 지침과 소프트웨어 엔지니어링 아키텍처 설명 표준을 따르는 아키텍처에 대해 설명합니다. 이 표준에 따르면 아키텍처 설명은 다음과 같아야합니다.

여러 표준화 된 아키텍처 뷰 (예 : UML) 및 설계 결정과 아키텍처 요구 사항 간의 추적 가능성 유지.

소프트웨어 아키텍처 정의.

시스템 아키텍처가 무엇인지에 대해서는 아직 합의가 이루어지지 않았습니다. 이 기사의 맥락에서 기능 요구 사항을 충족시키는 응용 프로그램 구성 요소를 지정, 배포 및 실행할 수있는 인프라로 정의됩니다. 기능 요구 사항은 시스템 및 해당 구성 요소의 예상 기능입니다. 비 기능 요구 사항은 시스템의 품질을 측정 할 수있는 방법입니다.

비 기능 요구 사항이 만족스럽지 않으면 기능 요구 사항을 완전히 만족시키는 시스템은 기대에 미치지 못할 수 있습니다. 이 개념을 설명하기 위해 다음 시나리오를 고려하십시오. 방금 구입했거나 구축 한 알고리즘 거래 시스템이 우수한 거래 결정을 내리지 만 조직의 위험 관리 및 회계 시스템과 완전히 작동하지 않습니다. 이 시스템이 귀하의 기대에 부응합니까?

개념적 아키텍처입니다.

개념적보기는 높은 수준의 세분화 수준에서 시스템에 존재하는 고급 개념과 메커니즘을 설명합니다. 이 수준에서 알고리즘 트레이딩 시스템은 4 개의 레이어와 두 가지 아키텍처 측면에서 분리 된 이벤트 기반 아키텍처 (EDA)를 따릅니다. 각 레이어 및 aspect 참조 아키텍처 및 패턴이 사용됩니다. 건축 패턴은 특정 요구 사항을 달성하기위한 입증 된 일반 구조입니다. 건축 측면은 여러 구성 요소에 걸쳐있는 교차 절단 문제입니다.

이벤트 중심 아키텍처 - 이벤트를 생성, 감지, 소비 및 반응하는 아키텍처입니다. 이벤트에는 실시간 시장 이동, 복잡한 이벤트 또는 트렌드, 거래 이벤트가 포함됩니다. 주문 제출.

이 다이어그램은 알고리즘 거래 시스템의 개념적 아키텍처를 보여줍니다.

참조 아키텍처.

비유를 사용하기 위해 기준 아키텍처는 내 하중 벽에 대한 청사진과 유사합니다. 이 청사진은 공통적으로 발생하는 요구 사항을 충족시키기 때문에 어떤 건물이 건설되고 있는지에 관계없이 여러 건물 설계에 재사용 할 수 있습니다. 마찬가지로 참조 아키텍처는 특정 요구 사항을 만족하는 구체적인 소프트웨어 아키텍처를 구성하는 데 사용할 수있는 일반 구조 및 메커니즘을 포함하는 템플릿을 정의합니다. 알고리즘 거래 시스템의 아키텍처는 공간 기반 아키텍처 (SBA)와 모델 뷰 컨트롤러 (MVC)를 참조로 사용합니다. 운영 데이터 저장소 (ODS), 추출 변환 및로드 (ETL) 패턴 및 데이터웨어 하우스 (DW)와 같은 우수 사례도 사용됩니다.

모델보기 컨트롤러 - 정보의 표현과 사용자의 상호 작용을 구분하는 패턴입니다. 공간 기반 아키텍처 - 느슨하게 연결된 처리 장치가 공간이라고하는 공유 연관 메모리 (아래 참조)를 통해 서로 상호 작용하는 인프라를 지정합니다.

구조보기.

아키텍처 구조 뷰는 알고리즘 거래 시스템의 구성 요소와 하위 구성 요소를 보여줍니다. 또한 이러한 구성 요소가 물리적 인프라에 어떻게 배치되는지를 보여줍니다. 이 뷰에 사용 된 UML 다이어그램에는 구성 요소 다이어그램과 배포 다이어그램이 포함됩니다. 다음은 SBA 참조 아키텍처의 전체 알고리즘 트레이딩 시스템 및 처리 단위의 배포 다이어그램과 각 계층의 관련 구성 요소 다이어그램 갤러리입니다.

자동화 된 상인 / 이벤트 처리 구성 요소 다이어그램 데이터 소스 및 사전 처리 계층 구성 요소 다이어그램 MVC 기반 사용자 인터페이스 구성 요소 다이어그램.

건축 전술.

소프트웨어 엔지니어링 연구소에 따르면 아키텍처 전술은 아키텍처 설계 결정을 통해 품질 속성 모델의 일부 측면을 조작하여 품질 요구 사항을 충족시키는 수단입니다. 알고리즘 거래 시스템 아키텍처에서 사용되는 간단한 예제는 연속적인 쿼리 구성 요소로 운영 데이터 저장소 (ODS)를 '조작'하는 것입니다. 이 구성 요소는 복합 이벤트를 식별하고 추출하기 위해 ODS를 지속적으로 분석합니다. 아키텍처에서 사용되는 전술은 다음과 같습니다.

이벤트 및 순서 큐의 장애 패턴 이벤트 및 순서 큐의 공유 메모리 ODS의 CQL (지속적인 쿼리 언어) 수신 데이터의 필터 디자인 패턴을 사용한 데이터 필터링 모든 수신 및 송신 연결의 정체 방지 알고리즘 활성 큐 관리 (AQM ) 및 명시 적 정체 통지 업그레이드 용량을 갖춘 상용 컴퓨팅 리소스 (확장 가능) 모든 단일 실패 지점에 대한 능동 중복 ODS의 인덱싱 및 최적화 된 지속성 구조 ODS에 대한 정기적 인 데이터 백업 및 정리 스크립트 예약 모든 데이터베이스의 트랜잭션 내역 모든 오류를 탐지하는 명령 타임 스탬프가있는 이벤트에 주석 처리하여 '부실'이벤트를 건너 뜁니다. 최대 거래량 자동화 된 상인 구성 요소는 분석을 위해 메모리 내 데이터베이스를 사용합니다. AT에 연결하는 사용자 인터페이스의 2 단계 인증 사용자 인터페이스 및 AT 연결에 대한 암호화 MVC가보기를 관리하기위한 관찰자 디자인 패턴.

위의 목록은 아키텍처 설계 중 확인한 몇 가지 설계 결정 사항입니다. 그것은 전술의 완전한 목록이 아니다. 시스템이 개발됨에 따라 기능적 및 비 기능적 요구 사항을 충족시키기 위해 여러 가지 수준의 세분화 된 수준에서 추가적인 전술을 사용해야합니다. 다음은 장애 요인 디자인 패턴, 필터 디자인 패턴 및 연속 쿼리 구성 요소를 설명하는 세 가지 다이어그램입니다.

행동 적 견해.

이 아키텍처보기는 구성 요소와 계층이 서로 상호 작용하는 방법을 보여줍니다. 이는 아키텍처 설계를 테스트하고 시스템을 종단 간으로 이해하기위한 시나리오를 작성할 때 유용합니다. 이 뷰는 시퀀스 다이어그램과 활동 다이어그램으로 구성됩니다. 알고리즘 트레이딩 시스템의 내부 프로세스와 트레이더가 알고리즘 트레이딩 시스템과 상호 작용하는 방법을 보여주는 활동 다이어그램은 아래와 같습니다.

기술 및 프레임 워크.

소프트웨어 아키텍처 설계의 마지막 단계는 아키텍처를 실현하는 데 사용할 수있는 잠재적 기술 및 프레임 워크를 식별하는 것입니다. 일반적인 원칙으로서 기존 기술의 기능적 및 비 기능적 요구 사항을 적절하게 충족시키는 경우 더 나은 방법을 사용하는 것이 좋습니다. 프레임 워크는 구현 된 참조 아키텍처이다. JBoss는 JEE 참조 아키텍처를 구현하는 프레임 워크입니다. 알고리즘 트레이딩 시스템을 구현할 때 다음 기술과 프레임 워크가 흥미롭고 고려되어야합니다.

CUDA - NVidia는 고성능 전산 금융 모델링을 지원하는 많은 제품을 보유하고 있습니다. CPU 대신 GPU에서 몬테카를로 시뮬레이션을 실행할 때 성능을 최대 50 배 향상시킬 수 있습니다. Apache River - River는 분산 시스템을 개발하는 데 사용되는 툴킷입니다. 이것은 SBA 패턴 인 Apache Hadoop을 기반으로 애플리케이션을 구축하기위한 프레임 워크로 사용되었습니다. 퍼베이시브 로깅이 필수 인 경우 Hadoop을 사용하면 큰 데이터 문제에 대한 흥미로운 솔루션을 제공합니다. Hadoop은 CUDA 기술을 지원하는 클러스터 환경에 배치 될 수 있습니다. AlgoTrader - 오픈 소스 알고리즘 거래 플랫폼. AlgoTrader는 자동화 된 상인 구성 요소의 위치에 잠재적으로 배치 될 수 있습니다. FIX 엔진 - FIX, FAST 및 FIXatdl을 포함한 FIX (Financial Information Exchange) 프로토콜을 지원하는 독립 실행 형 응용 프로그램입니다.

기술이나 프레임 워크는 아니지만 시스템과 구성 요소의 상호 운용성을 향상시키기 위해 API (Application Programming Interface)로 구성 요소를 구축해야합니다.

결론.

제안 된 아키텍처는 알고리즘 거래 시스템에서 확인 된 매우 일반적인 요구 사항을 충족 시키도록 설계되었습니다. 일반적으로 알고리즘 거래 시스템은 각 구현마다 다른 세 가지 요소로 복잡합니다.

외부 엔터프라이즈 및 Exchange 시스템에 대한 종속성 비 기능 요구 사항에 대한 도전과 진화하는 아키텍처 제약.

따라서 제안 된 소프트웨어 아키텍처는 특정 조직 및 규정 요구 사항을 충족시키고 지역 제약 조건을 극복하기 위해 사례별로 적용해야합니다. 알고리즘 거래 시스템 아키텍처는 자신의 알고리즘 거래 시스템을 설계하고자하는 개인 및 조직을위한 참고서 일뿐입니다.

사용 된 전체 사본 및 출처는 내 보고서 사본을 다운로드하십시오. 고맙습니다.

이전 이야기.

알고리즘 트레이딩 시스템 요구 사항.

다음 이야기.

Particle Swarm Optimization을 이용한 포트폴리오 최적화.

멋진 개관과 아키텍처에 대한 좋은 출발. 당신의 결론은 적절한 것이었고, 알고리즘 거래 소프트웨어 시스템이 관련성을 유지하기 위해 지속적인 백 테스트 및 조정이 필요한 이유를 지적했습니다. 좋은 읽을 거리!

2016 년 2 월 1 일

상품 또는 고정 수입의 데이터가 부정확하거나 수신 속도가 느린 경우 모델은 특히 Black Swann 이벤트의 공간에서 계산하기가 어려울 수 있습니다.

이 기사를 주셔서 대단히 감사합니다. 1990 년대 후반부터 AI에 대해 생각해 봤는데 마침내 기술과 API가 일반적으로 제공됩니다. 기사와 블로그는 이전 연도의 꿈을 실현하는 첫 걸음을 내딛는 데 큰 도움이됩니다. 당신의 추가 벤처에 많은 감사와 행운을 빕니다!

귀하의 진전 상황을 계속 알려 주시기 바랍니다. 나는 아주 흥미 롭다. 고맙습니다.

댓글을 제출하십시오.

답장 취소.

Turing Finance를 팔로우하십시오.

Turing 금융 메일 링리스트.

Turing Finance의 친구들.

Quantocracy는 매일 매일 게시되는 새로운 분석에 대한 링크가있는 최고의 양적 금융 블로그 수집기입니다.

NMRQL은 내가 속한 양적 헤지 펀드 다. 우리는 기계 학습을 사용하여 시장을 이기고 시도합니다.

거래 시스템의 기능.

알고리즘 자동 거래 또는 알고리즘 거래 (Algorithmic Trading)는 10 년이 넘는 기간 동안 거래 세계의 중심 단계에있었습니다. 알고리즘 자동 거래로 인한 거래량의 비율은 지난 10 년간 크게 증가했습니다. 결과적으로, 기술에 크게 의존하는 매우 경쟁이 치열한 시장이되었습니다. 결과적으로, 알고리즘 전략을 실행하는 자동화 된 거래 시스템의 기본 아키텍처는 지난 10 년 동안 큰 변화를 겪었으며 계속 그렇게하고 있습니다. 기업, 특히 고주파 거래 시스템을 사용하는 기업의 경우 알고리즘 거래 세계에서 경쟁하기 위해 기술 혁신을해야하므로 알고리즘 거래 분야를 컴퓨터 및 네트워크 기술 발전의 온상이되게합니다.

이 글에서는 독자를 위해 자동화 된 트레이딩 시스템의 아키텍처를 설명합니다. 자동화 된 거래 시스템의 새로운 아키텍처를 전통적인 거래 아키텍처와 비교하고 이러한 시스템의 주요 구성 요소 중 일부를 이해합니다.

전통 건축.

개념적으로 모든 거래 시스템은 서로 다른 두 스트림에서 거래소와 상호 작용하는 계산 블록 일뿐입니다.

시장 데이터 수신 주문 요청을 보내고 거래소로부터 응답을받습니다.

일반적으로 수신되는 시장 데이터는 최신 주문서를 시스템에 알립니다. 지금까지 거래 된 거래량, 마지막 거래 가격 및 거래량과 같은 몇 가지 추가 정보가 포함될 수 있습니다. 그러나 데이터를 결정하기 위해 상인은 이전 값을 보거나 과거 매개 변수를 가져와야 할 수 있습니다. 이를 해결하기 위해 기존 시스템에는 시장 데이터를 저장하는 히스토리 데이터베이스와 해당 데이터베이스를 사용하는 도구가 있습니다. 분석은 상인에 의한 과거 거래에 대한 연구도 포함합니다. 따라서 거래 결정을 저장하기위한 또 다른 데이터베이스입니다. 마지막으로, 상인이 화면에서이 모든 정보를 볼 수있는 GUI 인터페이스.

전체 거래 시스템을 이제 분해 할 수 있습니다.

거래소 - 외부 세계 서버 시장 데이터 수신자 시장 데이터 저장 사용자가 생성 한 주문 저장 응용 프로그램에서 거래 의사 결정을 포함한 사용자 입력을받습니다. 데이터 및 주문을 포함한 정보를 볼 수있는 인터페이스 교환.

새로운 아키텍처.

전통적인 아키텍처는 DMA로 자동화 된 거래의 요구와 요구 사항까지 확장 할 수 없었습니다. 순서 생성에 대한 이벤트의 시작 시간과 지연 시간은 사람이 제어 할 수있는 범위를 넘어 밀리 초 및 마이크로 초의 영역으로 들어갔다. 따라서 시장 데이터와 분석을 처리하는 도구는 적절하게 적응해야했습니다. 주문 관리는보다 견고하고 초당 더 많은 주문을 처리 할 수 있어야합니다. 시간 프레임은 사람의 반응 시간에 비해 너무 작기 때문에 위험 관리는 실시간 및 완전 자동화 된 방식으로 주문을 처리해야합니다.

예를 들어, 주문에 대한 반응 시간이 1 밀리 초 (현재보고있는 대기 시간과 비교하면 많음) 인 경우에도 시스템은 여전히 1 초 내에 1000 건의 거래 결정을 내릴 수 있습니다. 즉, 1000 건의 거래 의사 결정은 거래소에 도달하기 위해 동일한 초 내에 위험 관리를 통과해야합니다. 이것은 단지 복잡성의 문제 일뿐입니다. 이 아키텍처는 이제 자동화 된 로직을 포함하고 있기 때문에 100 명의 거래자를 하나의 자동화 된 거래 시스템으로 대체 할 수 있습니다. 이로 인해 문제의 규모가 커집니다. 따라서 각 논리 단위는 1000 개의 주문을 생성하고 100 개의 단위는 매초 100,000 개의 주문을 의미합니다. 즉, 데이터 전송률을 맞추기 위해 의사 결정 및 주문 송신 부분이 시장 데이터 수신자보다 훨씬 더 빨라야합니다.

따라서이 모듈이 요구하는 인프라의 수준은 기존 시스템의 수준보다 훨씬 더 높아야합니다 (이전 섹션에서 논의 됨). 따라서 '복잡한 이벤트 처리'엔진 또는 CEP라고도하는 의사 결정 논리를 실행하는 엔진이 응용 프로그램 내에서 서버로 이동했습니다. 이제 응용 프로그램 계층은 CEP에 매개 변수를보고 제공하기위한 사용자 인터페이스에 불과합니다.

스케일링의 문제는 또한 흥미로운 상황을 초래합니다. 단일 시장 데이터 이벤트를 통해 100 개의 다른 로직이 실행되고 있다고 가정 해 보겠습니다 (앞의 예제에서 설명한 것처럼). 그러나 100 개의 로직 유닛의 대부분을 실행해야하는 복잡한 계산의 일반적인 부분이있을 수 있습니다. 예를 들어 옵션에 대한 greeks를 계산합니다. 각각의 로직이 독립적으로 기능한다면 각 유닛은 불필요하게 프로세서 리소스를 소모하는 동일한 그리스 계산을 수행합니다. 계산의 중복성을 최적화하기 위해 복잡한 중복 계산은 일반적으로 그리스를 CEP의 입력으로 제공하는 별도의 계산 엔진으로 분산됩니다.

응용 프로그램 계층은 기본적으로보기이지만 일부 위험 검사 (규모 문제 때문에 리소스가 부족한 작업)는 응용 프로그램 계층, 특히 뚱뚱한 손가락과 같은 사용자 입력의 온전함과 관련이있는 부분에 대해 오프로드 할 수 있습니다 오류. 나머지 위험 확인은 주문을 릴리스하기 직전에 주문 관리자 (OM) 내의 별도의 위험 관리 시스템 (RMS)에 의해 수행됩니다. 규모의 문제는 이전에 위험을 관리하는 100 명의 다른 상인이 있었지만 이제는 모든 논리 단위 / 전략에서 위험을 관리하는 RMS 시스템이 하나만 있음을 의미합니다. 그러나 일부 위험 확인은 특정 전략에만 적용될 수 있으며 일부는 모든 전략에서 수행되어야 할 수도 있습니다. 따라서 RMS 자체에는 전략 수준 RMS (SLRMS) 및 글로벌 RMS (GRMS)가 포함됩니다. 또한 SLRMS 및 GRMS를보기위한 UI가 필요할 수도 있습니다.

자동화 된 거래 시스템을위한 프로토콜 등장.

혁신과 함께 필수품이옵니다. 새로운 아키텍처는 서버 당 많은 전략으로 확장 할 수 있었기 때문에 단일 서버에서 여러 대상에 연결할 필요성이 대두되었습니다. 따라서 주문 관리자는 주문을 여러 대상으로 보내고 여러 교환기에서 데이터를 받기 위해 여러 어댑터를 호스팅했습니다. 각 어댑터는 교환기가 이해하는 프로토콜과 시스템 내의 통신 프로토콜 사이의 인터프리터 역할을합니다. 다중 교환이란 다중 어댑터를 의미합니다.

그러나 시스템에 새 교환을 추가하려면 각 교환이 교환기가 제공하는 기능에 최적화 된 프로토콜을 따르기 때문에 새 어댑터를 설계하고 아키텍처에 플러그인해야합니다. 어댑터 추가의 번거 로움을 피하기 위해 표준 프로토콜이 설계되었습니다. 그 중 가장 두드러진 것은 FIX (Financial Information Exchange) 프로토콜입니다 (FIX 프로토콜 소개 부분 참조). 이렇게하면 즉시 다른 대상에 연결할 수있을뿐만 아니라 새로운 대상과 연결하는 경우 시장 진출로 크게 줄어 듭니다. 추가 읽기 : FIX를 통한 FXCM 연결, 자세한 자습서.

표준 프로토콜이 존재하기 때문에 분석이나 시장 데이터 피드를 위해 타사 공급 업체와 쉽게 통합 할 수 있습니다. 결과적으로 시장은 새로운 목적지 / 벤더와의 통합이 더 이상 제약 조건이 아니므로 매우 효율적으로됩니다.

또한 실제 시장에서 데이터를 수신하고 시뮬레이터에 주문을 보내면 시뮬레이션이 매우 쉬워집니다. FIX 프로토콜을 사용하여 시뮬레이터에 연결하는 것만으로 문제가됩니다. 시뮬레이터 자체는 사내에서 제작되거나 제 3 자 공급 업체로부터 조달 될 수 있습니다. 마찬가지로 기록 된 데이터는 어댑터가 라이브 시장 또는 기록 된 데이터 세트로부터 데이터를 수신하는지 여부에 대해 불가지론 적으로 재생 될 수 있습니다.

지연이 적은 아키텍처의 출현.

알고리즘 거래 시스템의 구축 블록을 통해 실시간으로 막대한 양의 데이터를 처리하고 신속한 거래 결정을 내릴 수있는 능력에 최적화 된 전략. 그러나 FIX와 같은 표준 통신 프로토콜의 출현으로 알고리즘 트레이딩 데스크를 설치하는 기술 진입 장벽이 낮아지고 경쟁력이 높아졌습니다. 서버의 메모리와 클럭 주파수가 높아짐에 따라 의사 결정에 대한 대기 시간이 줄어들 기 시작했습니다. 시간이 지남에 따라 대기 시간을 줄이는 것은 다음과 같은 여러 가지 이유로 인해 필요했습니다.

전략은 낮은 지연 시간 환경에서만 의미가 있습니다. 적자 생존 - 경쟁자가 충분히 빠르지 않으면 당신을 선택합니다.

그러나 문제는 대기 시간이 실제로 여러 가지 지연을 포함하는 포괄적 인 용어라는 것입니다. 하나의 일반적인 용어로 그것들 모두를 정량화하는 것은 일반적으로별로 의미가 없을 수도 있습니다. 매우 쉽게 이해할 수 있지만 수량을 정하기는 매우 어렵습니다. 따라서 대기 시간을 줄이는 문제에 접근하는 방법이 점차 중요 해지고 있습니다.

기본적인 생명주기를 살펴보면,

시장 데이터 패킷이 교환기에 의해 게시 됨 패킷이 유선을 통해 이동 패킷이 서버 측의 라우터에 도착합니다. 라우터는 서버 측의 네트워크를 통해 패킷을 전달합니다. 패킷은 서버의 이더넷 포트에 도착합니다. 이것이 UDP / TCP 처리인지 여부에 따라 헤더와 트레일러의 패킷이 제거되어 어댑터의 메모리로 이동합니다. 그런 다음 어댑터는 패킷을 구문 분석하여 알고리즘 거래 플랫폼의 형식으로 변환합니다. 이 패킷은 시스템의 여러 모듈 (CEP, 틱 저장소 등)을 통해 이동합니다. CEP는 주문 요청을 분석하고 전송합니다. 주문 요청이 다시 진행됩니다 시장 데이터 패킷과 같은 사이클의 역순으로.

이 단계들 중 높은 레이턴시는 전체 사이클 동안 높은 대기 시간을 보장합니다. 따라서 대기 시간 최적화는 일반적으로이주기의 첫 번째 단계, 즉 "패킷이 유선을 통해 이동"하는 것으로 시작됩니다. 가장 쉬운 방법은 목적지까지의 거리를 최대한 단축하는 것입니다. 콜로 네이션은 교환기가 교환기에 근접하여 호스트하는 교환기가 제공하는 기능입니다. 다음 다이어그램은 거리를 절단하여 얻을 수있는 이득을 보여줍니다.

단일 목적지를 포함하는 모든 고주파수 전략의 경우, Colocation은 반드시 필요한 것입니다. 그러나 여러 목적지를 포함하는 전략에는 신중한 계획이 필요합니다. 이러한 결정을 내리기 전에 대상이 주문 요청에 응답하는 데 걸리는 시간과 두 대상 간의 핑 시간과의 비교를 고려해야합니다. 결정은 전략의 성격에 달려 있습니다.

일반적으로 네트워크 대기 시간은 알고리즘 거래 시스템의 전반적인 대기 시간을 줄이는 첫 번째 단계입니다. 그러나 아키텍처를 최적화 할 수있는 많은 장소가 있습니다.

전파 대기 시간.

전파 대기 시간은 와이어를 따라 비트를 전송하는 데 걸리는 시간을 나타내며 물론 빛의 속도로 제한됩니다.

물리적 인 거리를 줄이는 것과는 별도로 전파 대기 시간을 줄이기 위해 몇 가지 최적화가 도입되었습니다. 예를 들어 시카고와 뉴욕 사이의 일반 케이블의 예상 왕복 시간은 13.1 밀리 초입니다. 2012 년 10 월에 확산 네트워크를 통해 대기 시간이 향상되어 예상 왕복 시간이 12.98 밀리 초가되었습니다. Tradeworx와 같은 회사에서 마이크로파 통신을 채택하여 예상 왕복 시간을 8.5 밀리 초로 유지했습니다. 이론적 최소값은 약 7.5 밀리 초입니다. 계속되는 혁신은 과학의 한계를 뛰어 넘으며 이론적 인 빛의 속도 한계에 빠르게 도달하고 있습니다. 이전에 방위 기술에 채택 된 레이저 통신의 최근 개발은 단거리에서 이미 나노 세컨드 (nanosecond) 단위로 이미 얇아진 대기 시간을 줄였습니다.

네트워크 처리 대기 시간.

네트워크 처리 대기 시간은 라우터, 스위치 등의 대기 시간을 나타냅니다.

알고리즘 거래 시스템의 아키텍처에서 다음 수준의 최적화는 패킷이 A 지점에서 B 지점으로 이동하는 데 걸리는 홉 수입니다. 홉 (hop)은 소스와 대상 사이의 경로 중 한 부분으로 정의됩니다. 패킷은 라우터 또는 스위치와 같은 물리적 장치를 통과하지 못합니다. 예를 들어, 패킷은 두 개의 서로 다른 경로를 통해 동일한 거리를 이동할 수 있습니다. 그러나 첫 번째 경로에서 두 번 홉을, 두 번째에서는 세 번 홉을 가질 수 있습니다. 전파 지연이 동일하다고 가정하면 라우터와 스위치는 각각 자신의 지연 시간을 도입하고 대개 엄지 손가락 규칙으로 추가함으로써 더 많은 지연이 추가됩니다.

네트워크 프로세싱 대기 시간은 우리가 마이크로 버스트라고 부르는 것에 영향을받을 수 있습니다. 마이크로 버스트는 평균 데이터 전송 속도에 반드시 영향을주지 않는 데이터 전송 속도의 급격한 증가로 정의됩니다. 알고리즘 거래 시스템은 규칙을 기반으로하므로 모든 시스템은 동일한 이벤트로 동일한 방식으로 대응합니다. 결과적으로 참여하는 많은 시스템이 주문을 보내 참가자와 대상 간의 갑작스런 데이터 전송으로 인해 마이크로 버스트가 발생할 수 있습니다. 다음 다이어그램은 마이크로 버스트가 무엇인지 나타냅니다.

첫 번째 그림은 데이터 전송 속도의 1 초보기입니다. 평균 속도는 1Gbps의 대역폭보다 훨씬 낮습니다. 그러나 다이브가 깊어지고 초 이미지 (5 밀리 초보기)를 볼 때 전송 속도가 매초마다 여러 번 사용 가능한 대역폭보다 높게 나타납니다. 결과적으로 네트워크 엔드 포인트와 라우터 및 스위치의 네트워크 스택에있는 패킷 버퍼가 오버 플로우 할 수 있습니다. 이를 피하기 위해 일반적으로 관찰 된 평균 속도보다 훨씬 높은 대역폭이 일반적으로 알고리즘 거래 시스템에 할당됩니다.

직렬화 대기 시간.

직렬화 대기 시간은 와이어를 비트로 끄는 데 걸리는 시간을 의미합니다.

T1 라인 (1,544,000 bps)에서 전송되는 1500 바이트의 패킷 크기는 약 8 밀리 초의 직렬화 지연을 생성합니다. 그러나 56K 모뎀 (57344bps)을 사용하는 동일한 1500 바이트 패킷은 200 밀리 초가 걸립니다. 1G 이더넷 회선은이 대기 시간을 약 11 마이크로 초로 줄입니다.

인터럽트 대기 시간.

인터럽트 대기 시간은 서버에서 패킷을 수신하는 동안 인터럽트로 인한 대기 시간을 나타냅니다.

인터럽트 대기 시간은 인터럽트가 생성 된 후 인터럽트 원본이 처리 될 때까지의 경과 시간으로 정의됩니다. 인터럽트는 언제 생성됩니까? 인터럽트는 하드웨어 나 소프트웨어에 의해 방출되는 프로세서에 대한 신호로, 이벤트가 즉각적인주의가 필요함을 나타냅니다. 프로세서는 현재 활동을 일시 중단하고 상태를 저장하고 인터럽트를 처리하여 응답합니다. NIC에서 패킷이 수신 될 때마다 인터럽트가 전송되어 NIC의 수신 버퍼에로드 된 비트를 처리합니다. 이 인터럽트에 응답하는 데 걸리는 시간은 새로 도착하는 페이로드의 처리뿐만 아니라 프로세서에서 기존 프로세스의 대기 시간에도 영향을 미칩니다.

Solarflare는 2011 년에 open onload를 발표했습니다. 이 기술은 커널 바이 패스 (bypass)로 알려진 기술을 구현합니다. 이 기술은 패킷 처리가 운영 체제 커널에 맡겨지지 않고 사용자 공간 자체에 남겨 둡니다. 전체 패킷은 NIC에 의해 사용자 공간에 직접 매핑되고 거기에서 처리됩니다. 결과적으로 인터럽트는 완전히 방지됩니다.

결과적으로 각 패킷을 처리하는 속도가 빨라집니다. 다음 다이어그램은 커널 우회의 이점을 명확하게 보여줍니다.

응용 프로그램 대기 시간.

응용 프로그램 대기 시간은 응용 프로그램이 처리하는 데 걸리는 시간을 나타냅니다.

이는 여러 패킷, 응용 프로그램 논리에 할당 된 처리, 관련된 계산의 복잡성, 프로그래밍 효율성 등에 따라 달라집니다. 시스템의 프로세서 수가 증가하면 일반적으로 응용 프로그램 대기 시간이 줄어 듭니다. 증가 된 클럭 주파수에서도 마찬가지입니다. 많은 알고리즘 거래 시스템은 예를 들어 전략 논리와 같이 응용 프로그램의 핵심 요소에 프로세서 코어를 사용하는 이점을 활용합니다. 이렇게하면 코어 간 프로세스 전환으로 인한 대기 시간을 피할 수 있습니다.

마찬가지로, 전략의 프로그래밍이 캐시 크기와 메모리 액세스의 지역을 염두에두고 수행되면, 많은 메모리 캐시 히트가 발생하여 대기 시간이 더 감소하게됩니다. 이것을 용이하게하기 위해 많은 시스템이 매우 낮은 수준의 프로그래밍 언어를 사용하여 코드를 프로세서의 특정 아키텍처에 최적화합니다. 일부 회사는 Fully Programmable Gate Arrays (FPGA)를 사용하여 복잡한 계산을 하드웨어에 적용하는 범위까지갔습니다. 복잡성이 증가함에 따라 비용이 증가하고 다음 다이어그램에이를 잘 설명합니다.

세련미의 수준.

고주파 알고리즘 거래의 세계는 치열한 경쟁 시대에 접어 들었습니다. 각 참가자가 경쟁 퇴출의 새로운 방법을 채택함에 따라 기술은 도약과 경계로 발전했습니다. 오늘날의 알고리즘 거래 아키텍처는 초기 단계의 트랜잭션 아키텍처에 비해 상당히 복잡합니다. 따라서 첨단 시스템은 시간과 비용 측면에서보다 많은 비용을 필요로합니다.

결론:

이것은 알고리즘 트레이딩 시스템 아키텍처에 대한 자세한 게시물이었으며 관련 구성 요소에 대한 매우 통찰력있는 지식과 강력한 자동 거래 시스템을 구축하기 위해 아키텍처 개발자가 처리해야하는 다양한 과제에 대한 정보를 제공했습니다.

알고리즘 트레이딩의 다양한 측면을 배우고 싶다면 알고리즘 트레이딩의 이그 제 큐 티브 프로그램 (EPAT ™)을 확인하십시오. 이 과정에서는 통계 및 amp; 계량 경제학, 금융 컴퓨팅 & amp; 기술 및 알고리즘 & amp; 양적 거래. EPAT ™는 알고리즘 거래에서 유망한 경력을 쌓기 위해 필요한 기술 세트를 제공합니다. 지금 등록!

외환 蔚山廣域市

Search This Blog

금융 거래 시스템 아키텍처

Comments

Post a Comment

Popular posts from this blog

123 갭 forex

Aeat 스톡 옵션

데이 트레이더 컴퓨터 시스템