프론트 오피스 거래 시스템 아키텍처

프론트 엔드 (front-to-back) 무역 금융. 무역 서비스를 제공하는 대부분의 은행은 고객에게 기존 백 오피스 인프라를 보완 할 수있는 최상의 무역 금융 프론트 엔드 시스템을 제공 할 필요성을 인식하고 있습니다. 기능적으로 풍부한 은행을 통해 고객 만족도 및 유지력을 높일 수 있습니다. 경쟁 압력으로 인해 은행 고객에게 구체적인 결과를 입증하기 위해 이러한 시스템을 수 주 이내에 구현해야합니다. 고객 프론트 엔드의 사용 및 효율성을 극대화하려면 그러나 은행의 백 오피스 무역 금융 시스템과 완벽하게 통합되어야합니다. 그러나 고객 프론트 엔드 및 은행 백 오피스 시스템을 모두 포함하는 엔드 투 엔드 (end-to-end) 무역 금융 솔루션을 구축하는 것은 까다로운 작업입니다. 전면에서 후면으로의 통합은 어려울 수 있습니다 실시간 피드를 수신 할 수없고, 고객이 입력 한 데이터를 매핑하고, 필요한 데이터를 고객에게 다운로드 할 수없는 레거시 백 오피스 시스템 덕분입니다. 혁신적인 세계 수준의 프론트 투 백 (front-to-back) 솔루션을 확립하고 있습니다. 엔드 투 엔드 무역 금융 솔루션. 탁월한 수준의 프런트 엔드 및 백 오피스 시스템 은행의 백 오피스 측면에서 Surecomp는 각기 다른 수준의 사용, 지리적 위치 및 IT 인프라를 목표로하는 여러 시스템을 제공합니다. 고객의 프런트 엔드 측면에서 Surecomp는 모든 Surecomp 백 오피스 시스템과 완벽하게 통합 된 단일의 통합 J2EE 호환 시스템 개방형 아키텍처로 인해 프론트 엔드 시스템은 써드 파티 또는 사내 백 오피스 시스템과 쉽게 통합됩니다. 규모, 운영의 지리적 분포 또는 거래량에 따라 Surecomp는 각 고객의 특정 요구 사항을 충족시키는 전면적 인 무역 금융 솔루션을 제공합니다. Surecomp는 백 오피스 시스템 예를 들어, 은행은 시스템의 커스터마이징을 요구할 수 있습니다. 또한, 시스템은 여러 개의 내부 시스템에 인터페이스 된 특정 사례에 따라 설치되고 설치되어야합니다 테스트 및 생산 단계로 이동합니다. 결과적으로 Surecomp의 백 오피스 시스템 구현에는 수개월이 걸리지 만 모든 은행은 고객 프론트 엔드 서비스를 시작하기 전에 백 오피스 구현 완료를 기다릴 준비가되어 있지 않습니다. Surecomp가 단 몇 주 만에 임시 솔루션으로 시작할 수있는 프론트 엔드 시스템의 독립 실행 형 버전을 제공하는 이유입니다. 백 오피스 생산 실행 완료 직후에 완전히 통합 된 솔루션을 사용할 수 있습니다. 이 종단 간 접근법은 은행이 프런트 엔드 시스템과 함께 Surecomp 백 오피스 시스템에 라이센스를 부여하는 데 거의 별다른 어려움이 없음을 의미합니다. 종단 간 솔루션 B 이미 Surecomp 프론트 - 투 - 백 (front-to-back) 무역 금융 솔루션을 구현 한 전 세계의 은행들은 고객들과 함께 커다란 열정을 지닌 통합 된 엔드 - 투 - 엔드 솔루션을 채택하고 있습니다. Bank Perspective. Rapid 엔드 투 엔드 구현 및 통합. 자동 데이터 매핑으로 인해 데이터 입력이 크게 감소했습니다. 분당 완료되는 복잡한 트랜잭션 처리 복잡한 트랜잭션. 향상된 고객 만족으로 인해 비즈니스 볼륨이 증가했습니다 .6 개월이라는 짧은 ROI를 자랑합니다. 고객 관점 .24 X 7 시스템 사용 중단 없음. 프런트 엔드 시스템의 매우 빠른 구현. 소프트웨어 설치가 필요없는 위치에서 인터넷 액세스. 모든 유형의 무역 금융 거래를 고객이 시작합니다. 쉬운 언어 구성 도구 및 관리를 통한 다국 언어 지원 도구입니다. 왜 Surecomp. Proven Surecomp의 무역 금융 시스템은 이미 주요 국가, 지역을 포함하여 수백 개의 은행 및 전세계 기업에 구현되어 있습니다. 경험있는 Surecomp는 1987 년부터 무역 금융 업계에서 활동 해 왔으며 지역 및 지역 관행에 대한 방대한 지식을 습득했습니다. 첨단 Surecomp의 첨단 무역 금융 솔루션은 사내에서 개발되었습니다 전담 IT 및 금융 전문가 팀으로 구성됩니다. Surecomp의 백 오피스 및 프론트 엔드 시스템은 각 분야의 선도적 인 제품으로 널리 인정 받고 있습니다. 파라과이 주요 은행은 Surecomp의 Java End-to-End Trade Finance 솔루션. 자본 시장. 경쟁이 치열합니다. 급변하는 규제 및 기술 환경이 금융 시장을 변화시키고 있습니다. 이러한 새로운 시장 상황에 적응하는 것이 중요합니다. Dodd-Frank 및 EMIR은 전자 거래, 의무적 인 거래 및 파생 상품 운영에 중대한 영향을 미치는 무역 리스크 및 워크 플로우 판매 회사는 모든 시장, 신용 및 유동성 리스크를 가격 결정 및 리스크 관리 계산에 정확하게 반영해야합니다. 바젤 III에 의해 요구되는 더 많은 자본 요구 사항은 수익성에 대한 추가적인 압력을 제공합니다. 칼립소 (calypso)를 사용하면 쉽게 거래가 가능합니다. 거래 및 처리, 위험 관리 및 회계를위한 칼립소의 자산 간 프런트 - 투 - 백 플랫폼으로 거래 및 장외 파생 상품 시장의 모든 새로운 측면을 처리합니다. 당사의 솔루션은 고객이 값 비싼 기술 개발 없이도 업계의 급변하는 요구 사항을 충족 할 수있게 해줍니다. 교차 자산 거래 및 위험 관리 솔루션의 통합 스위트. 트레이딩 플로어 아키텍처. 실행 개요. 실행 증가, 새로운 규제 요구는 산업 변화의 원동력 중 일부 기업은 거래 전략을 지속적으로 변경하고 거래 속도를 높임으로써 경쟁 우위를 유지하려고 노력하고 있습니다. 실행 가능한 아키텍처에는 네트워크 및 애플리케이션 도메인의 최신 기술이 포함되어야합니다. 진화하는 관리 가능한 경로를 제공하는 모듈 식이어야합니다. 전체 시스템에 미치는 영향을 최소화 한 ch 구성 요소를 제공합니다. 따라서이 백서에서 제안하는 아키텍처는 서비스 프레임 워크를 기반으로합니다. 초 저 지연 메시징, 대기 시간 모니터링, 멀티 캐스트, 컴퓨팅, 스토리지, 데이터 및 응용 프로그램 가상화, 트레이딩 이동성 및 씬 클라이언트를 지원합니다. 차세대 거래 플랫폼의 복잡한 요구 사항에 대한 솔루션은 비즈니스 및 기술 또는 응용 프로그램 및 네트워킹과 같은 전통적인 사일로의 경계를 넘어 전체 론적 사고 방식으로 구축되어야합니다. 이 문서의 주요 목표는 시장 데이터 및 FIX 거래 주문에 대한 원시 처리량 및 메시지 속도를 최적화하면서 초 저 지연 트랜잭션 플랫폼을 구축하기위한 지침을 제공합니다. 이를 위해 다음 대기 시간 감소 기술을 제안합니다. 거래 클러스터를위한 고속 상호 연결 InfiniBand 또는 10Gbps 연결. 고속 메시징 버스. 애플리케이션 재 코딩없이 RDMA를 통한 애플리케이션 가속화. 실시간 레이턴시 모니터링 및 최소 대기 시간으로 경로에 대한 거래 트래픽의 방향 전환. 산업 동향 및 과제. 차세대 거래 아키텍처는 속도, 볼륨 및 효율성에 대한 증가하는 요구에 대응해야합니다. 예를 들어, 옵션 시장 데이터는 2007 년 페니 거래 옵션 도입 이후 두 배로 증가 할 것으로 예상됩니다. 또한 거래를위한 1M msg 초에 접근하는 요금으로 가격 업데이트를 처리해야하는 최상의 실행에 대한 규제 요구 사항 또한 데이터의 신선도에 대한 가시성을 요구합니다. 단기간에 거래와 혁신의 속도는 중요한 차별화 요소입니다 거래 집행 장소에 최대한 근접한 알고리즘 거래 응용 프로그램에 의해 처리되는 거래 건수가 증가합니다 이러한 블랙 박스 거래에 대한 도전 엔진은 주문을 취소하고 다시 제출하기 위해 주문을 발행하여 대량 생산량을 합성하는 것입니다. avior는 장소가 최상의 실행을 제공하는 가시성이 부족합니다. 인적 자원자는 이제 재무 기술자이자 프로그래밍 기술을 갖춘 수량 계량 분석가로서 즉시 거래 모델을 조정할 수 있습니다. 기업은 날씨 파생 상품이나 교차 자산 클래스 거래와 같은 새로운 금융 상품을 개발합니다 새로운 애플리케이션을 신속하고 확장 가능한 방식으로 배치해야합니다. 장기적으로, 경쟁 차별화는 지식뿐만 아니라 분석에서 나옵니다. 미래의 스타 트레이더는 위험을 감수하고, 진정한 고객 통찰력을 얻으며, 지속적으로 시장 출처 인 IBM을 이깁니다. 비즈니스 탄력성은 2001 년 9 월 11 일 이후 무역 회사의 주요 관심사 중 하나입니다. 이 지역의 솔루션은 여러 지리적 위치에 있고 중복 된 데이터 센터에서부터 여러 거래 장소에 이르기까지 다양하며 전력 거래자에게 거래 현장의 기능 대부분을 제공하는 가상 상인 솔루션에 이르기까지 다양합니다. 금융 서비스 산업은 IT 측면에서 가장 까다로운 요구 사항 중 하나입니다. 요구 사항 업계는 SOA (Service-Oriented Architecture)를 향한 아키텍처로의 전환을 경험하고 있습니다. SOA, 웹 서비스 및 IT 리소스의 가상화 SOA는 네트워크 속도의 향상을 활용하여 소프트웨어 구성 요소의 동적 바인딩 및 가상화를 가능하게합니다. 기존 시스템 및 인프라에 대한 투자이 개념은 통합이 완료되는 방식에 혁명을 일으킬 수있는 잠재력을 지니고있어 이러한 통합의 복잡성과 비용을 대폭 절감 할 수 있습니다. 또 다른 추세는 서버를 데이터 센터 서버 팜에 통합하는 것이지만 상인은 KVM 확장 및 초박형 클라이언트 (예 : SunRay 및 HP 블레이드 솔루션) 고속 Metro Area Networks를 사용하면 시장 데이터를 서로 다른 위치에서 멀티 캐스트 할 수 있으므로 거래 층의 가상화가 가능합니다. 높은 수준의 아키텍처. 그림 1은 높은 수준의 아키텍처 거래 환경의 시세 공장 및 알고리즘 c 거래 엔진은 회사의 데이터 센터 또는 교환소의 고성능 거래 클러스터에 위치합니다. 인간 거래자는 최종 사용자 응용 프로그램 영역에 있습니다. 기능적으로 기업 거래 환경, 게시자 및 가입자에는 두 가지 응용 프로그램 구성 요소가 있습니다. 메시징 버스는 게시자와 가입자 사이의 통신 경로를 제공합니다. 거래 환경과 관련된 두 가지 유형의 트래픽이 있습니다. 시장 데이터 금융 상품, 뉴스 및 기타 부가 가치 정보 (예 : 분석)에 대한 가격 정보를 전달합니다. 이는 단방향이며 매우 지연에 민감합니다. 일반적으로 UDP 멀티 캐스트를 통해 제공됩니다. 업데이트 초 및 Mbps로 측정됩니다. 하나 이상의 외부 증권 거래소, 데이터 수집기 ​​및 ECN과 같은 시장 데이터 제공 업체에서 제공하는 피드 공급 업체는 자체 시장 데이터 형식을 사용합니다. 피드 처리기, 데이터를 표준화 및 정리 한 특수 응용 프로그램에서 데이터를 수신 한 다음 가격 결정 엔진, 알고리즘 거래 응용 프로그램 또는 인적 자원 거래자 또한 판매 회사는 고객, 뮤추얼 펀드, 헤지 펀드 및 기타 자산 관리자와 같은 구매 측 기업에게 시장 데이터를 보냅니다. 일부 구매 측 기업은 직접 공급을 선택할 수 있습니다 구매자 측면의 소매 업체를위한 그림 1 거래 구조. 시장 데이터 형식에 대한 업계 표준은 없습니다. 각 교환 h 그들의 독점적 형식으로 로이터와 블룸버그와 같은 금융 컨텐츠 제공자는 시장 데이터의 다른 소스를 모으고, 표준화하고, 뉴스 또는 분석을 추가합니다. 통합 피드의 예는 RDF 로이터 데이터 피드, RWF 로이터 와이어 포맷 및 블룸버그 전문 서비스 데이터입니다. 낮은 대기 시간의 시장 데이터를 제공하는 두 벤더는 덜 처리되고 분석이 적은 실시간 시장 데이터 피드를 발표했습니다. 블룸버그 B - 파이프 B - 파이프와 블룸버그는 블룸버그 터미널이 B - 파이프를 얻기 위해 필요하지 않기 때문에 그들의 유통 플랫폼으로부터 그들의 시장 데이터 피드를 분리시킨다. 웜뱃과 로이터 피드 핸들러는 B - 파이프에 대한 지원을 발표했다. 대기 시간을 줄이기 위해 교환기에서 직접 피드를받을 수 있습니다. 전송 속도의 향상은 150 밀리 초에서 500 밀리 초 사이가 될 수 있습니다. 이러한 피드는 더 복잡하고 비용이 많이 들며 회사는 자체 시계열 플랜트를 만들고 유지 관리해야합니다. 거래 주문이 유형의 트래픽은 실제 거래를 수행합니다. 양방향이며 매우 지연에 민감합니다. 메시지 초 및 Mbps 단위로 측정됩니다. 주문은 구매 측 또는 판매 측 회사에서 시작하여 교환 또는 ECN과 같은 거래 장소로 전송됩니다. 실행 주문 전송을위한 가장 일반적인 형식은 FIX 재무 정보입니다. FIX 메시지를 처리하는 애플리케이션을 FIX 엔진이라고하며 주문 관리 시스템 OMS와 인터페이스합니다. FIX에 대한 최적화는 압축 스키마를 사용하여 스트리밍에 최적화 된 FAST Fix Adapted 메시지 길이 및 지연 시간 단축 FAST는 시장 데이터 제공에 더 많은 목표가 있으며 표준이 될 가능성이 있습니다. FAST는 독점 시장 데이터 형식을위한 압축 스키마로도 사용될 수 있습니다. 대기 시간을 줄이려면 기업에서 직접 시장 접근 (Direct Market Access)을 수립 DMA. DMA는 유가 증권 주문을 집행 장소로 직접 전달하는 자동화 된 프로세스이므로 타사 glossaryId 383 DMA는 실행 장소에 직접 연결해야합니다. 메시징 버스는 Tibco, 29West, Reuters RMDS 또는 AMQP와 같은 오픈 소스 플랫폼과 같은 공급 업체의 미들웨어 소프트웨어입니다. 메시징 버스는 신뢰할 수있는 메커니즘을 사용하여 메시지를 전달합니다 전송은 TCP IP TibcoEMS, 29West, RMDS 및 AMQP 또는 UDP 멀티 캐스트 TibcoRV, 29West 및 RMDS를 통해 수행 할 수 있습니다. 메시지 배포의 중요한 개념 중 하나는 주제 스트림으로, 시세 기호와 같은 기준으로 정의 된 시장 데이터의 하위 집합입니다 , 산업 또는 특정 금융 상품 묶음 가입자는 관련 정보 만 받기 위해 하나 또는 여러 개의 하위 주제에 매핑 된 주제 그룹에 가입 과거에는 모든 거래자가 모든 시장 데이터를 수신했습니다 현재 트래픽 양에서는 sub-optimum. The 네트워크는 거래 환경에서 중요한 역할을합니다. 시장 데이터는 인적 자원이 캠퍼스 또는 메트로 영역 고속 넷을 통해 위치하는 거래 층으로 운반됩니다. 고 가용성 및 낮은 대기 시간과 높은 처리량이 가장 중요한 척도입니다. 고성능 거래 환경에는 대부분의 구성 요소가 데이터 센터 서버 팜에 있습니다. 대기 시간을 최소화하려면 알고리즘 거래 엔진이 근접에 위치해야합니다 피드 처리기, FIX 엔진 및 주문 관리 시스템 대체 배포 모델에는 알고리즘 교환 시스템이 Exchange 또는 여러 교환기에 빠르게 연결되는 서비스 제공 업체에 있습니다. 배치 모델. 고성능 거래 플랫폼을위한 두 가지 배치 모델이 있습니다 기업은이 두 가지를 혼합하여 선택할 수 있습니다. 무역 회사의 데이터 센터 그림 2 이것은 모든 거래 장소에 대한 통신 링크가있는 본격적인 거래 플랫폼이 개발 및 유지되는 전통적인 모델입니다. 대기 시간은 링크 속도 및 홉 수 사이에 다릅니다 회사와 장소. 그림 2 전통적인 배포 모델. 트레이딩 장소 교환소, 금융 서비스 제공 업체 FSP의 공동 위치 그림 3. 트레이딩 회사는 지연 시간을 최소화하기 위해 가능한 한 자동 실행 플랫폼을 실행 장소에 가깝게 배치합니다. 그림 3 호스트 배포 모델. 서비스 지향적 인 거래 구조. 차세대 트레이딩 아키텍처 구축을위한 서비스 지향적 프레임 워크 제안이 접근법은 모듈화 및 상호 의존성 최소화에 기반한 개념적 프레임 워크 및 구현 경로를 제공합니다. 이 프레임 워크는 기업에게 방법론을 제공합니다. 서비스 측면에서 현재 상태를 평가하십시오. 비즈니스에 대한 가치에 따라 서비스의 우선 순위를 정하십시오. 모듈 형 접근 방식을 사용하여 거래 플랫폼을 원하는 상태로 발전시킵니다. 고성능 거래 아키텍처는 그림 4에 표시된 서비스 아키텍처 프레임 워크에 정의 된대로 다음 서비스를 사용합니다. 고성능 트레이딩을위한 서비스 아키텍처 프레임 워크. 초저 대기 시간 메시징 서비스. 이 서비스는 메시징 버스에서 제공합니다. 메시징 버스는 다 대 다 응용 프로그램을 연결하는 문제를 해결하는 소프트웨어 시스템입니다. 사전 정의 된 메시지 스키마 세트. 공통 명령 메시지 세트. 수신자에게 메시지를 전송하기위한 공유 애플리케이션 인프라 공유 인프라는 메시지 브로커 또는 게시 구독 모델을 기반으로 할 수 있습니다. 차세대 메시징 버스의 주요 요구 사항은 소스 29West입니다. 가능한 최저 대기 시간은 100 마이크로 초 미만입니다. 무거운 하중 하에서 안정성, 1 백만 분의 4 초 이상. 제어 및 유연성 속도 제어 및 구성 가능한 전송. 메시징 버스를 표준화하려는 업계의 노력이 있습니다. 고급 메시지 대기열 프로토콜 AMQP는 JP Morgan Chase가 옹호하고 Cisco, Envoy Technologies와 같은 공급 업체 그룹이 지원하는 공개 표준의 한 예입니다. , Red Hat, TWIST Process Innovations, Iona, 29West 및 iMatix 두 가지 주요 목표는 미들웨어가 쉽게 진화 할 수 있도록 다양한 플랫폼 및 모듈 방식으로 작성된 응용 프로그램에 대한 상호 운용성에보다 간단한 경로를 제공하는 것입니다. 용어로 AMQP 서버는 메시지 교환 에이전트 및 각 메시지 대기열을 사서함으로 사용하는 전자 메일 서버와 유사합니다. 바인딩은 각 전송 에이전트에서 라우팅 테이블을 정의합니다. 게시자는 개별 전송 에이전트로 메시지를 보내고 메시지를 라우팅합니다 사서함으로 메시지 보내기 소비자는 사서함에서 메시지를 가져와 간단한 소스 인 강력하고 유연한 모델을 만듭니다. 이 서비스에 대한 주요 요구 사항은 다음과 같습니다. 밀리 초 단위의 측정 단위. 거래 트래픽에 대기 시간을 추가하지 않고 실시간에 가까운 가시성 제공. 응용 프로그램 처리 대기 시간과 네트워크 전송 대기 시간을 구별 할 수있는 기능. 높은 메시지 속도를 처리 할 수있는 능력. 대기 시간 데이터를 수신하도록 거래 응용 프로그램을위한 프로그래밍 인터페이스를 제공하여 알고리즘 거래 엔진이 변화하는 조건에 적응할 수있게합니다. 문제 해결을 위해 네트워크 이벤트를 응용 프로그램 이벤트와 관련시킵니다. 긴급 성은 거래 주문이 전송 된 시점과 수신자가 동일한 주문을 승인하고 처리 한 시점 간의 시간 간격으로 정의 할 수 있습니다. 대기 시간 문제를 처리하는 것은 복잡한 문제입니다. 모든 지연 소스를 확인하고 시스템의 여러 레이어에서 서로 다른 기술을 적용하는 전체 론적 접근 방식입니다. 그림 5는 OSI 스택의 각 레이어에서 대기 시간을 도입 할 수있는 다양한 구성 요소를 보여줍니다. 각 지연 소스를 가능한 솔루션으로 매핑하고 모니터링 솔루션이 계층화 된 접근 방식을 통해 기업은 대기 시간 문제를보다 구조화 된 방식으로 공격 할 수 있으므로 각 구성 요소를 서비스로 간주하고 회사 전체에서 일관되게 처리 할 수 ​​있습니다. 대체 시간에 대한이 시간 간격의 동적 상태를 정확하게 측정합니다 노선 및 목적지는 전술적 인 거래 결정에 큰 도움이 될 수 있습니다. 고객 에지 네트워크, 중앙 처리 허브 또는 트랜잭션 응용 프로그램 수준의 지연 여부에 관계없이 서비스 공급자가 거래 서비스 수준 계약을 충족시킬 수있는 능력을 크게 결정합니다. SLA 구매자 및 판매 측 양식의 경우, 시장 데이터 신디케이터뿐만 아니라 병목 현상의 신속한 식별 및 제거는 향상된 거래 기회 및 수익으로 직접 변환됩니다. 그림 5 지연 관리 아키텍처 Cisco Low-Latency Monitoring Tools. 전통적 네트워크 모니터링 도구는 수분 또는 초 단위로 작동합니다. 특히 알고리즘 거래를 지원하는 차세대 거래 플랫폼은 대기 시간이 5ms 미만이고 패킷 손실 수준이 극히 낮아야합니다. 기가비트 LAN에서 100ms 마이크로 버스트는 10,000 건의 거래가 손실되거나 지나치게 지연 될 수 있습니다. Cisco는 고객에게 거래 환경에서 대기 시간을 측정하는 도구. Corvil의 대역폭 품질 관리자 BQM OEM. Cisco AON 기반 금융 서비스 대기 시간 모니터링 솔루션 FSMS. Bandwidth Quality Manager. 대역폭 품질 관리자 BQM 4 0은 고객이 제어 된 대기 시간 및 손실 성능 수준을 위해 네트워크를 모니터링하고 프로비저닝 할 수있게 해주는 차세대 네트워크 어플리케이션 성능 관리 제품입니다. BQM 지능형 대역폭 프로비저닝 기능과 결합 된 마이크로 초 가시성은 이러한 까다로운 환경에 이상적입니다. Cisco BQM 4 0은 특허 및 특허 출원중인 광범위한 트래픽 측정 및 네트워크 분석 기술을 구현하여 사용자에게 전례가없는 가시성 및 최대 애플리케이션 성능을위한 네트워크 최적화 방법에 대한 이해 Cisco BQM은 현재 Cisco Application Deployment Engine ADE 제품군에서 지원됩니다. Cisco ADE 제품군은 시스코 네트워크 관리 응용 프로그램에 가장 적합한 플랫폼입니다. BQM 이점. Cisco BQM 미시적 가시성은 능력이다. 트래픽 지연 및 지터 및 손실에 대한 트래픽 이벤트의 영향을 감지하고 결정할 수 있습니다. BQM은 TCP 및 UDP 멀티 캐스트 트래픽 모두에 대해 일방향으로 대기 시간, 손실 및 지터 측정을 지원할 수 있습니다. 이는 거래 트래픽 및 시장 데이터 피드 모두를 원활하게보고 함을 의미합니다. BQM을 사용하면 사용자가 포괄적 인 임계 값 세트를 지정할 수 있습니다 모든 인터페이스에서의 마이크로 버스트 활동, 대기 시간, 손실, 지터, 사용률 등 BQM은 백그라운드 롤링 패킷 캡처를 실행합니다. 임계 값 위반 또는 기타 잠재적 성능 저하 이벤트가 발생할 때마다 Cisco BQM은 나중에 분석하기 위해 패킷 캡처를 디스크에 저장하도록 트리거합니다. 사용자는 성능 저하로 인해 영향을받은 애플리케이션 트래픽과 희생자를 모두 자세히 조사 할 수 있습니다. e 트래픽 성능 저하를 일으키는 원인이 범인이 크게 네트워크 성능 문제를 진단하고 해결하는 데 소비하는 시간을 줄일 수 있습니다. BQM은 또한 사용자가 원하는 네트워크를 달성하기 위해 직접 적용 할 수있는 상세한 대역폭과 서비스 품질 QoS 정책 제공 권장 사항을 제공 할 수 있습니다 BQM 측정 설명. 기존의 측정 기술과 BQM이 제공하는 가시성 간의 차이점을 이해하기 위해 몇 가지 비교 그래프를 볼 수 있습니다. 그림 6과 그림 7의 첫 번째 세트에서 우리는 대기 시간은 BQM에 의해 측정 됨 패시브 네트워크 품질 모니터 PNQM 및 트래픽 스트림에 ping 패킷을 1 초마다 주입하여 측정 한 대기 시간. 그림 6에서 실제 네트워크 트래픽에 대해 1 초 ICMP ping 패킷에 의해보고 된 대기 시간을 2로 나눈 값 단방향 지연에 대한 추정치를 제공합니다. 거의 모든 경우에 약 5ms 미만의 지연을 보여줍니다. 그림 6에서 실제 네트워크 트래픽에 대해 1 초 ICMP Ping 패킷으로보고 한 대기 시간입니다. 그림 7에서 동일한 트래픽에 대해 PNQM이보고 한 대기 시간을 볼 수 있습니다. 실제 트래픽의 단방향 대기 시간을 측정하여 응용 프로그램 패킷, 우리는 근본적으로 다른 그림을 얻을 수 있습니다 여기 대기 시간은 약 20ms 정도 가끔 발생하는 것으로 보입니다. 가끔은 파열이 훨씬 큽니다. 핑은 매 초마다 패킷을 전송하기 때문에 대부분의 응용 프로그램 트래픽 대기 시간이 빠져 있습니다. 사실 핑 결과는 네트워크를 통한 실제 애플리케이션 대기 시간보다는 라운드 트립 전파 지연만을 나타냅니다. 그림 7 실제 네트워크 트래픽에 대한 PNQM에 의해보고 된 대기 시간 두 번째 예에서 그림 8에서는보고 된 링크로드 또는 포화 레벨의 차이를 5 분 평균보기 및 5ms 마이크로 버스트보기 BQM은 마이크로 버스트를 약 10-100 나노초 정확도로보고 할 수 있습니다. 녹색 선은 5 분에 평균 사용률을 나타냅니다 평균 5Mbps로 낮을 수 있습니다. 진한 파란색 플롯은 5ms 마이크로 버스트 활동이 75Mbits ~ 100Mbits 사이에 이르는 것을 보여줍니다. LAN 속도는 모든 응용 프로그램에서이 세분성 수준을 효과적으로 보여 주며 명확한 프로비저닝을 제공합니다 규칙을 사용하여 사용자가 이러한 마이크로 버스트를 제어하거나 중화 할 수 있습니다. 그림 8 : 5 분 평균보기와 5ms 마이크로 버스트보기 사이의보고 된 링크로드의 차이. Trading Network의 BQM 배치. 그림 9는 거래에서 일반적인 BQM 배치를 보여줍니다 그림 9 일반적인 Trading Network의 BQM 배치. BQM을 사용하여 이러한 유형의 질문에 대답 할 수 있습니다. 제 기가비트 LAN 코어 링크가 X 밀리 초 이상 포화 상태에 있습니까? 이것이 Etherchannel 또는 10 기가비트 속도로 업그레이드 할 때 가장 큰 이점을 얻을 수있는 링크입니다. 내 1 기가비트 링크가 포화 상태에 빠지는 응용 프로그램 트래픽 시장 데이터가 종단 간 손실을 경험하고 있습니까? 장애 조치 데이터 센터 환경에서 추가로 대기 시간이 링크는 마이크로 버스트를 처리하기 위해 올바르게 크기 조정됩니다. 내 거래자가 시장 데이터 배포 계층에서 지연 시간이 짧은 업데이트를 받고 있습니까? 지연 시간이 X 밀리 초보다 큰지 확인합니다. 이러한 질문에 간단하고 효과적으로 응답 할 수 있으므로 거래 네트워크를 실행하는 데 시간과 비용을 절약 할 수 있습니다. BQM은 가시성 확보에 필수적인 도구입니다. 시장 데이터 및 거래 환경에서 대량의 데이터 이동을 경험하는 복잡한 인프라에서 세분화 된 엔드 투 엔드 대기 시간 측정을 제공합니다. 밀리 세컨드 수준의 마이크로 버스트를 효과적으로 감지하고 특정 이벤트에 대한 전문가 분석을받는 것은 거래 층 설계자에게 매우 중요합니다. 스마트 대역폭 변동성있는 시장 상황에 대응할 수있는 더 큰 민첩성 제공 사이징 및 가상 분석 (what-if analysis)과 같은 프로비저닝 권장 사항은 변동성이 큰 시장 상황에 대응할 수 있도록 해줍니다. 알고리즘 트레이딩의 폭발적 증가와 메시지 속도의 증가로 BQM은 QoS 도구와 결합하여 QoS 정책을 구현할 수 있습니다. 중요한 거래 어플리케이션 보호. 시스코 파이낸셜 서비스 대기 시간 모니터링 솔루션. Cisco 및 Trading Metrics는 FIX 주문 흐름 및 시장 데이터 모니터링을위한 지연 모니터링 솔루션과 협력 해 왔습니다. Cisco AON 기술은 지능형 네트워크를 애플리케이션 인프라와 병합하는 데 도움이되는 새로운 수준의 네트워크 임베디드 제품 및 솔루션의 기초입니다. 서비스 지향 아키텍처 또는 전통적인 아키텍처 중 하나 Trading Metrics는 네트워크 인프라 및 애플리케이션 지연 모니터링을위한 분석 소프트웨어의 선도적 인 제공 업체입니다. Cisco AON Financial Services 대기 모니터링 솔루션 FSMS는 관찰 시점에서 두 가지 유형의 이벤트를 연관 시켰습니다. 네트워크 이벤트는 일치하는 응용 프로그램 메시지 처리와 직접 관련되어 있습니다. 무역 주문 흐름 및 일치하는 시장 업데이트 이벤트. 네트워크 캡처 시점에서 주장 된 타임 스탬프를 사용하여 이러한 상호 연관된 데이터 스트림의 실시간 분석을 통해 무역이 실행되거나 시장 데이터가 존재하는 동안 인프라 전반에서 병목 현상을 정확하게 식별 할 수 있습니다. 분산주기 초반에 대기 시간을 모니터링하고 측정함으로써 금융 회사는 거래 주문 라우팅을 위해 선택할 네트워크 서비스 및 중개자, 시장 또는 상대방에 대해 더 나은 결정을 내릴 수 있습니다. 마찬가지로이 지식은 업데이트 된 시장 데이터 주식 시세, 경제 뉴스 등을 포함 할 수 있습니다. 이는 시장 기회를 시작, 철수 또는 추구하기위한 중요한 기초입니다. 솔루션의 구성 요소는 다음과 같습니다. 3 가지 폼 팩터의 AON 하드웨어. Cisco 2600 2800 3700 3800 라우터 용 AON 네트워크 모듈. Cisco Catalyst 6500 시리즈 용 AON 블레이드. AON 8340 기기. 모니터링 및 경고 애플리케이션을 제공하는 Trading Metrics MA 2 0 소프트웨어는 대시 보드에 대기 시간 그래프를 표시하고 속도 저하가 발생하면 경고를 표시합니다. 그림 10 AON 기반 FIX 지연 모니터링. Cisco IP SLA. Cisco IP SLA는 임베디드 네트워크 관리입니다 라우터 및 스위치가 대기 시간, 지터, 패킷 손실 및 기타 기준에 대해 측정 할 수있는 인위적 트래픽 스트림을 생성 할 수있게 해주는 Cisco IOS의 도구입니다. 핵심 두 가지 개념은 생성 된 트래픽의 소스 및 대상입니다. 둘 다 IP SLA 응답 트래픽은 RTL 측정을 위해 대상에 의해 소싱되어 반환되기 전에 제어 트래픽을 타임 스탬프 할 책임이 있습니다. IP SLA 내에서 다양한 트래픽 유형을 소싱 할 수 있으며 다양한 메트릭을 목표로하고 다양한 서비스 및 응용 프로그램을 대상으로합니다. UDP 지터 작업은 단방향 및 왕복 지연을 측정하고 변동을보고하는 데 사용됩니다. 트래픽이 resp를 사용하여 송신 및 대상 장치에 시간을 기록하므로 onder 기능을 사용하면 라운드 트립 지연은 두 개의 타임 스탬프 간의 델타로 표시됩니다. 새 기능은 타임 스탬프를 마이크로 초 단위의 해상도로 표시 할 수있는 IOS 12 3 14 T, IP SLA Sub Millisecond Reporting에서 도입되었으므로 이전에는 사용할 수 없었던 세분화 수준이 새로운 기능으로 인해 네트워크 대기 시간이 일반적으로 300-800 마이크로 초 범위 인 캠퍼스 네트워크와 관련된 IP SLA가 만들어졌으며 추세와 스파이크를 감지하는 기능은 마이크로 세컨드 세분성 카운터에 기반한 간단한 추세가 필요합니다 이는 시간에 민감한 전자 거래 환경에 종사하는 고객을위한 것입니다. 결과적으로 IP SLA는 많은 금융 기관에 의해 요구 사항에 직면 해 있습니다. 사용자에게 기본 대기 시간을보고합니다. 시간 경과에 따른 경향 기준선 대기 시간. 보고 된 대기 시간의 변화를 유발하는 트래픽 급증에 신속하게 대응하십시오. 여러 캠퍼스와 백본이 현재 여러 스위치 홉에 걸친 대기 시간 중 두 번째에 도달하기 때문에이 고객에게는 밀리 초 단위의보고가 필요합니다. 전자 거래 환경은 일반적으로 모든 장치 및 네트워크 지연 시간을 단축하여 비즈니스에 신속한 주문 처리 실현 네트워크 응답 시간이 1 밀리 초 미만이라는보고는 더 이상 충분하지 않으며 네트워크 세그먼트 또는 백본에서보고 된 대기 시간 측정의 세분성은 300-800 마이크로 - seconds with a degree of resolution of 100 seconds. IP SLA recently added support for IP multicast test streams, which can measure market data latency. A typical network topology is shown in Figure 11 with the IP SLA shadow routers, sources, and responders. Figure 11 IP SLA Deploymentputing Servicesputing services cover a wide range of technologies with the goal of elim inating memory and CPU bottlenecks created by the processing of network packets Trading applications consume high volumes of market data and the servers have to dedicate resources to processing network traffic instead of application processing. Transport processing At high speeds, network packet processing can consume a significant amount of server CPU cycles and memory An established rule of thumb states that 1Gbps of network bandwidth requires 1 GHz of processor capacity source Intel white paper on I O acceleration. Intermediate buffer copying In a conventional network stack implementation, data needs to be copied by the CPU between network buffers and application buffers This overhead is worsened by the fact that memory speeds have not kept up with increases in CPU speeds For example, processors like the Intel Xeon are approaching 4 GHz, while RAM chips hover around 400MHz for DDR 3200 memory source Intel. Context switching Every time an individual packet needs to be processed, the CPU performs a context switch from application context to network traffic context This overhead could be reduced if the switch would occur only when the whole application buffer is complete. Figure 12 Sources of Overhead in Data Center Servers. TCP Offload Engine TOE Offloads transport processor cycles to the NIC Moves TCP IP protocol stack buffer copies from system memory to NIC memory. Remote Direct Memory Access RDMA Enables a network adapter to transfer data directly from application to application without involving the operating system Eliminates intermediate and application buffer copies memory bandwidth consumption. Kernel bypass Direct user-level access to hardware Dramatically reduces application context switches. Figure 13 RDMA and Kernel Bypass. InfiniBand is a point-to-point switched fabric bidirectional serial communication link which implements RDMA, among other features Cisco offers an InfiniBand switch, the Server Fabric Switch SFS. Figure 14 Typical SFS Deployment. Trading applications benefit from the reduction in latency and latency variability, as proved by a test performed with the Cisco SFS and Wombat Feed Handlers by Stac Research. Application Virtualization Service. De-coupling the application from the underlying OS and server hardware enables them to run as network services One application can be run in parallel on multiple servers, or multiple applications can be run on the same server, as the best resource allocation dictates This decoupling enables better load balancing and disaster recovery for business continuance strategies The process of re-allocating computing resources to an a pplication is dynamic Using an application virtualization system like Data Synapse s GridServer, applications can migrate, using pre-configured policies, to under-utilized servers in a supply-matches-demand process. There are many business advantages for financial firms who adopt application virtualization. Faster time to market for new products and services. Faster integration of firms following merger and acquisition activity. Increased application availability. Better workload distribution, which creates more head room for processing spikes in trading volume. Operational efficiency and control. Reduction in IT complexity. Currently, application virtualization is not used in the trading front-office One use-case is risk modeling, like Monte Carlo simulations As the technology evolves, it is conceivable that some the trading platforms will adopt it. Data Virtualization Service. To effectively share resources across distributed enterprise applications, firms must be able to leverage data across multiple sources in real-time while ensuring data integrity With solutions from data virtualization software vendors such as Gemstone or Tangosol now Oracle , financial firms can access heterogeneous sources of data as a single system image that enables connectivity between business processes and unrestrained application access to distributed caching The net result is that all users have instant access to these data resources across a distributed network. This is called a data grid and is the first step in the process of creating what Gartner calls Extreme Transaction Processing XTP id 500947 Technologies such as data and applications virtualization enable financial firms to perform real-time complex analytics, event-driven applications, and dynamic resource allocation. One example of data virtualization in action is a global order book application An order book is the repository of active orders that is published by the exchange or other market makers A global order book aggregates orders from around the world from markets that operate independently The biggest challenge for the application is scalability over WAN connectivity because it has to maintain state Today s data grids are localized in data centers connected by Metro Area Networks MAN This is mainly because the applications themselves have limits they have been developed without the WAN in mind. Figure 15 GemStone GemFire Distributed Caching. Before data virtualization, applications used database clustering for failover and scalability This solution is limited by the performance of the underlying database Failover i s slower because the data is committed to disc With data grids, the data which is part of the active state is cached in memory, which reduces drastically the failover time Scaling the data grid means just adding more distributed resources, providing a more deterministic performance compared to a database cluster. Multicast Service. Market data delivery is a perfect example of an application that needs to deliver the same data stream to hundreds and potentially thousands of end users Market data services have been implemented with TCP or UDP broadcast as the network layer, but those implementations have limited scalability Using TCP requires a separate socket and sliding window on the server for each recipient UDP broadcast requires a separate copy of the stream for each destination subnet Both of these methods exhaust the resources of the servers and the network The server side must transmit and service each of the streams individually, which requires larger and larger server farms On th e network side, the required bandwidth for the application increases in a linear fashion For example, to send a 1 Mbps stream to 1000recipients using TCP requires 1 Gbps of bandwidth. IP multicast is the only way to scale market data delivery To deliver a 1 Mbps stream to 1000 recipients, IP multicast would require 1 Mbps The stream can be delivered by as few as two servers one primary and one backup for redundancy. There are two main phases of market data delivery to the end user In the first phase, the data stream must be brought from the exchange into the brokerage s network Typically the feeds are terminated in a data center on the customer premise The feeds are then processed by a feed handler, which may normalize the data stream into a common format and then republish into the application messaging servers in the data center. The second phase involves injecting the data stream into the application messaging bus which feeds the core infrastructure of the trading applications The larg e brokerage houses have thousands of applications that use the market data streams for various purposes, such as live trades, long term trending, arbitrage, etc Many of these applications listen to the feeds and then republish their own analytical and derivative information For example, a brokerage may compare the prices of CSCO to the option prices of CSCO on another exchange and then publish ratings which a different application may monitor to determine how much they are out of synchronization. Figure 16 Market Data Distribution Players. The delivery of these data streams is typically over a reliable multicast transport protocol, traditionally Tibco Rendezvous Tibco RV operates in a publish and subscribe environment Each financial instrument is given a subject name, such as Each application server can request the individual instruments of interest by their subject name and receive just a that subset of the information This is called subject-based forwarding or filtering Subject-based f iltering is patented by Tibco. A distinction should be made between the first and second phases of market data delivery The delivery of market data from the exchange to the brokerage is mostly a one-to-many application The only exception to the unidirectional nature of market data may be retransmission requests, which are usually sent using unicast The trading applications, however, are definitely many-to-many applications and may interact with the exchanges to place orders. Figure 17 Market Data Architecture. Design Issues. Number of Groups Channels to Use. Many application developers consider using thousand of multicast groups to give them the ability to divide up products or instruments into small buckets Normally these applications send many small messages as part of their information bus Usually several messages are sent in each packet that are received by many users Sending fewer messages in each packet increases the overhead necessary for each message. In the extreme case, sending onl y one message in each packet quickly reaches the point of diminishing returns there is more overhead sent than actual data Application developers must find a reasonable compromise between the number of groups and breaking up their products into logical buckets. Consider, for example, the Nasdaq Quotation Dissemination Service NQDS The instruments are broken up alphabetically. This approach allows for straight forward network application management, but does not necessarily allow for optimized bandwidth utilization for most users A user of NQDS that is interested in technology stocks, and would like to subscribe to just CSCO and INTL, would have to pull down all the data for the first two groups of NQDS Understanding the way users pull down the data and then organize it into appropriate logical groups optimizes the bandwidth for each user. In many market data applications, optimizing the data organization would be of limited value Typically customers bring in all data into a few machines a nd filter the instruments Using more groups is just more overhead for the stack and does not help the customers conserve bandwidth Another approach might be to keep the groups down to a minimum level and use UDP port numbers to further differentiate if necessary The other extreme would be to use just one multicast group for the entire application and then have the end user filter the data In some situations this may be sufficient. Intermittent Sources. A common issue with market data applications are servers that send data to a multicast group and then go silent for more than 3 5 minutes These intermittent sources may cause trashing of state on the network and can introduce packet loss during the window of time when soft state and then hardware shorts are being created. PIM-Bidir or PIM-SSM. The first and best solution for intermittent sources is to use PIM-Bidir for many-to-many applications and PIM-SSM for one-to-many applications. Both of these optimizations of the PIM protocol do not ha ve any data-driven events in creating forwarding state That means that as long as the receivers are subscribed to the streams, the network has the forwarding state created in the hardware switching path. Intermittent sources are not an issue with PIM-Bidir and PIM-SSM. Null Packets. In PIM-SM environments a common method to make sure forwarding state is created is to send a burst of null packets to the multicast group before the actual data stream The application must efficiently ignore these null data packets to ensure it does not affect performance The sources must only send the burst of packets if they have been silent for more than 3 minutes A good practice is to send the burst if the source is silent for more than a minute Many financials send out an initial burst of traffic in the morning and then all well-behaved sources do not have problems. Periodic Keepalives or Heartbeats. An alternative approach for PIM-SM environments is for sources to send periodic heartbeat messages to the mu lticast groups This is a similar approach to the null packets, but the packets can be sent on a regular timer so that the forwarding state never expires. S,G Expiry Timer. Finally, Cisco has made a modification to the operation of the S, G expiry timer in IOS There is now a CLI knob to allow the state for a S, G to stay alive for hours without any traffic being sent The S, G expiry timer is configurable This approach should be considered a workaround until PIM-Bidir or PIM-SSM is deployed or the application is fixed. RTCP Feedback. A common issue with real time voice and video applications that use RTP is the use of RTCP feedback traffic Unnecessary use of the feedback option can create excessive multicast state in the network If the RTCP traffic is not required by the application it should be avoided. Fast Producers and Slow Consumers. Today many servers providing market data are attached at Gigabit speeds, while the receivers are attached at different speeds, usually 100Mbps This creates the potential for receivers to drop packets and request re-transmissions, which creates more traffic that the slowest consumers cannot handle, continuing the vicious circle. The solution needs to be some type of access control in the application that limits the amount of data that one host can request QoS and other network functions can mitigate the problem, but ultimately the subscriptions need to be managed in the application. Tibco Heartbeats. TibcoRV has had the ability to use IP multicast for the heartbeat between the TICs for many years However, there are some brokerage houses that are still using very old versions of TibcoRV that use UDP broadcast support for the resiliency This limitation is often cited as a reason to maintain a Layer 2 infrastructure between TICs located in different data centers These older versions of TibcoRV should be phased out in favor of the IP multicast supported versions. Multicast Forwarding Options. PIM Sparse Mode. The standard IP multicast forwarding protoco l used today for market data delivery is PIM Sparse Mode It is supported on all Cisco routers and switches and is well understood PIM-SM can be used in all the network components from the exchange, FSP, and brokerage. There are, however, some long-standing issues and unnecessary complexity associated with a PIM-SM deployment that could be avoided by using PIM-Bidir and PIM-SSM These are covered in the next sections. The main components of the PIM-SM implementation are. PIM Sparse Mode v2. Shared Tree spt-threshold infinity. A design option in the brokerage or in the exchange.