(*)아래글을 읽는 분들은 꼭 댓글을 읽으시길 바랍니다. 이것을 작성할 때 RoCE를 오해했습니다. 댓글을 보고 이해했습니다.
1.
2010년 금융위원회가 ‘ELW 추가건전화방안’과 함께 DMA가이드라인을 발표했을 때 새로운 환경하에서 레이턴시 경쟁력을 높이는 방안을 살펴본 적이 있습니다.
이후 금융위원회부터 한국거래소까지 주문수탁과 관련된 제도적 틀거리를 완성하였습니다.
주문속도와 관련한 한국거래소 업무규정 개정
주문속도와 관련한 금융투자업 규정 개정
이제 한국형 시장접속규정(Korean Market Access Rule)에 따라 Low Latency환경을 구축할 수 있는 방법을 알아보도록 하겠습니다. 물론 그동안 해왔던 이야기입니다. 또한 이미 증권IT를 하는 분들도 익수한 이야기입니다만 정리하는 취지로 이해바랍니다.
최근 기회가 있어 몇 증권사를 방문한 적이 있었습니다. 어느 경우나 네트워크와 관련된 환경을 개선할 계획을 가지고 있더군요. 이와 관련하여 대다수 관심사는 10G환경인 듯 합니다. 10G환경을 구축하여야 하는 이유 그리고 가능하면 좋은 네트워크카드를 사용하여야 하는 이유는 정리한 글들입니다.
만원짜리 네트워크 카드를 사용하세요?
10G 이야기
10G 이야기 둘
10G 환경을 구축할 때 두가지 영역을 검토합니다. 10G 스위치와 10G용 Ethernet Card입니다. 이미 많은 증권사들이 스위치와 이더넷카드 도입을 위한 BMT를 실시하였습니다. 다양한 자료들이 축적되어 있고 경험들이 있습니다. ?두루 살피면 가격과 성능을 조화롭게 고려한 솔류션을 찾을 수 있습니다.
또다른 영역은 방화벽입니다. 최근에 자주 이야기한 부분입니다. ASIC방식이든 NP방식이든 혹은 FPGA방식이든 Low Latency를 위한 제품들이 있습니다. 역시나 BMT를 하시면 비교평가가 가능합니다. 최근 확인한 자료에 따르면 NP를 이용할 경우 대략 5 마이크로초전후한 지연을 보이고 있고 FPGA를 사용할 경우 1 마이크로초도 가능하다고 합니다. 방화벽일 경우 가장 중요한 쟁점은 공동평가기준인 CC인증을 받은 제품인가 아닌가 일 듯 합니다. BMT를 하실 때 Fortinet 제품인 Fortigate도 해보시길 바랍니다.
2.
이제 어플리케이션과 관련된 영역입니다. 대부분의 증권사들이 공통으로 검토하는 부분이 있습니다.
첫째는 RDMA기술을 적용하고자 합니다. RDMA기술을 적용하려고 하는 구간은 전략서버(주문서버) – 방화벽 – 미니원장(FEP) 입니다. RDMA를 통하여 지연을 줄여보자는 취지입니다. RDMA는 특정한 기술을 이야기하는 것은 아닙니다. 네트워크 환경에서 Low Latency를 줄일 수 있는 여러가지 기술들을 총칭하는 개념입니다. 어떤 글은 이렇렇게 설명합니다.
RDMA has its roots in Virtual Interface Architecture, which was essentially developed to support user-level, fast, low-latency zero-copy networks.
RDMA라는 개념을 구체화한 기술은 여러가지가 있습니다. Ethernet환경에서 가능하도록 한 기술이 iWARP과 RoCE(Cisco의 Roland는 RoCE가 불명확한 개념이라고 하여 IBoE=Infiniband Over Ethernet이라고 함)입니다. iWARP은 TCP/IP환경이고 RoCE는 Infiniband입니다. 반면 다른 접근도 있습니다. IPoIB와 Infiniband입니다. 이들은 IB를 기반으로 합니다.
앞서 적용하려고 하는 업무흐름을 보면 방화벽이 놓여져 있기때문에 Infiniband를 기반으로 한 환경은 적용할 수 없습니다. 같은 이유로 RoCE도 적용할 수 있는 기술이 아닙니다.
이제 선택할 수 있는 경우는 두가지입니다. RDMA기술인 iWARP과 TOE기술입니다. iWARP을 지원하는 대부분의 RNiC은 TOE를 지원하기 때문에 대립하는 개념이 아닙니다. TOE=Hardware Accelation은 네트워크카드를 구매하여 드라이버를 교체하면 어플리케이션의 수정없이 그대로 적용할 수 있습니다. 가장 빠른 시간내에 Low Latency환경을 구축할 수 있는 방안입니다. 반면 누구나 할 수 있는 방안입니다.
iWARP을 이용한 어플리케이션을 구현하는 것은 어렵다고 할 수 없지만 그렇다고 쉬운 일도 아닙니다. Verb를 이용하여 업무환경에 맞는 API를 구축하는 일부터 시작해야 하기때문입니다. 그러면 iWARP을 쉽게 이해하는 방법은 무엇일까요? 보통 iWARP과 같은RDMA는 하드웨어적으로 구현되어 있습니다. 그래서 별도의 구현이 필요하지 않고 Verb를 통하여 인터페이스합니다. 개발자들이 영어문서를 보면서 iWARP등을 이해하려면 시간이 많이 걸립니다. 개발환경 구현도 힘듭니다. 그래서 탄생한 것이 SoftiWARP입니다. 소스를 보시면 프로토콜이 어떤 기능을 하는지 짐작할 수 있습니다. 아래의 자료들은 리눅스에서 개발환경을 구축하는 방안을 소개하고 있습니다. 참고로 2월중으로 iWARP을 지원하는 ZeroM을 내놓을 계획입니다. 가상화환경의 IPC도 지원하는 것을 포함한 기능개선입니다.(^^)
Setting up SoftiWARP in Debian 6.0 from scratch
다음으로 넘어갑니다. 둘째는 미니원장과 FEP와 관련된 영역입니다. 여기서 몇가지 이슈를 도출할 수 있습니다.
첫째는 가장 근본적으로 미니원장과 FEP를 물리적으로 분리할 것인가, 아니면 물리적으로 통합할 것인가 입니다. 현재 몇 증권사는 미니원장과 FEP를 통합한 시스템을 운영하고 있습니다. 한국거래소가 내놓은 주문수탁제도는 “미니원장과 FEP를 분리하여 운영하라”는 규정이 없습니다. 결국 하나의 서버를 이용하여 통합서비스를 제공하는 방향으로 가지 않을까 합니다.
둘째는 “미니원장 프로세스와 FEP프로세스를 어떻게 통합할 것인가”입니다. TCP/IP로 인터페이스하던 프로세스를 하나의 서버로 통합하면 도메인 소켓이나 IPC등이 선택가능한 프로토콜일 듯 합니다. 그렇지만 좀 더 넓게 생각하면 멀티코어환경에 특화된 IPC방식을 이용한 메시징제품들을 이용하는 것이 가장 좋은 방법이라는 생각을 합니다. ?예를 들면 이렇습니다.CME가 표준메시징제품으로 Tibco FTL를 선정했다는 소식을 전한 뉴스중 한 부분입니다. ZeroM도 비슷한 목표로 IPC를 구현했지만 아직 갈 길이 먼 듯 합니다.(^^)
TIBCO FTL was developed in close collaboration with Intel to take full advantage of Intel’s multi-core server processors. TIBCO’s software also supports other leading-edge technologies, from shared-memory architectures to InfiniBand to 10 Gigabit Ethernet.
셋째는 미니원장 프로세스의 데이타관리입니다. 지금까지 가원장 혹은 미니원장 프로세스가 데이타를 관리할 때 선택은 MMDBMS이었습니다. 그렇지만 ELW 서비스를 거치면서 많은 경우 Hash Algorithm을 이용한 Shared Memory로 변환하였습니다. 여기가 출발일 듯 합니다. 메인메모리DB보다는 가볍고 더 빠르게 메모리로 데이타를 관리할 수 있는 방법을 찾는 경쟁이 있을 듯 합니다. Exture+를 도입하기 이전 코스콤이 수행하였던 파일럿프로젝트는 Tokyo Cabinet이라는 제품을 벤치마킹하였습니다. 참고로 ZeroAOS는 나름 빠른 Hash Algorithm을 구현한 ZeroTable을 만들어 사용하고 있습니다.
넷째는 미니원장의 역할에 관한 부분입니다. 미니원장을 정의할 때 ‘특정한 고객들을 위한 빠른 원장서비스’라고 할 수 있습니다. 그런데 만약 미니원장을 여러명이 아니라 한명의 고객만을 위한 서비스라고 하면 어떤 모양일까요? 미니원장을 개인원장으로 정의하여 서비스하자는 취지입니다. Thread든 Process든 개인원장을 CPU Affinity와 결합하여 서비스하면 좀더 빠른 속도를 얻을 수 있지않을까 합니다.
다섯째는 FEP의 경우 MPMC(Multi Producers/Consumers)와 같은 병렬구조를 도입할지 여부입니다. Lock Free Algorithm을 적용한 MPMC모델을 적용할 경우 속도 개선이 가능할지 검토할 필요가 있을 듯 합니다. 나아가 Async환경으로 전환될 Exture+의 시대에는 더욱 의미가 있지않을까 합니다. 하나더 덧붙이자면 Exture+의 경우 암호화와 관련하여 제품이 아니라 알고리즘을 표준으로 제시했으면 합니다. 그것이 경쟁의 원리에 부합합니다.
마지막으로 HA를 고려할 경우 Hardware Paritioning기술과 Reliable UDP의 적용입니다. 이런 환경을 도입하여 성공한 경우가 TSE의 Arrowhead입니다.
3.
이런 생각도 해보았습니다.
All In One
하나의 서버에 주문-방화벽-미니원장-FEP를 구성할 수 있는 방안이 있으면 어떨까? 역시나 방화벽의 인증이 걸림돌이더군요. ?이런 이야기를 덧붙이는 이유는 간단합니다. 나름 상상력이 필요합니다. 레이턴시경쟁에서 최종 목표는 없습니다. 경쟁자보다 “더 적게 더 빨리”가 중요합니다. 그러기 위해선 여러가지 시도가 필요하기때문입니다. 혹 Low Latency에 대한 일반론을 알고 싶으시면 @dolppi님이 번역할 글을 꼭 참고하시길 바랍니다.
변화한 환경에 맞는 기술적 대응을 위한 시론입니다. 꼭 정답은 아니고 ZeroAOS를 구성하면서 했던 생각들을 다시금 정리해보았습니다.
smalllake님께서 잘못 아시는 거 같아서 reply 남깁니다.
RoCE는 TCP/IP 기반의 Ethernet 위에서 작동하기 때문에
위의 Hammer님 의견에서 방화벽에 사용 못한다 하셨는데
사용 가능합니다. 한국 증권 시스템에서는 방화벽이 RoCE 사용의 주 목적일 것 같습니다.
즉 Subnet이 다른 곳에 위치하고 중간에 방화벽이 위치할 경우
두 Subnet의 통신은 RoCE로 하고 Subnet 안에서는 IB로 통신하는 형태로 보시면 되겠습니다.
iWARP는 RoCE에 비하여 느리기도 하지요
요즘 RoCE등에 관심이 없어서 기억이 가물합니다.
RoCE=RDMA Over Converged Ethernet의 약자로 기억합니다. . 위키페이디아를 보면 “RoCE is a link layer protocol and hence allows communication between any two hosts in the same Ethernet broadcast domain”라고 하네요. 결과적으로 InfiniBand RDMA로 데이타통신이 일어납니다.
아마 위의 글을 쓸 때 infiniband를 지원하는 Firewall 없어서 불가능하다고 쓴 듯합니다. 위의 글을 쓸 때 Roce를 적용할지 말지를 놓고 몇 곳에서 이야기가 있었습니다. 즉,
DMA서버 – TCP/IP – 방화벽 – TCP/IP – FEP 말고 DMA서버 – RoCE – 방화벽 – RoCE – FEP가 가능한지를 검토했었죠. 만약 RoCE 혹은 InfiniBand를 지원하는 방화벽이 있으면 가능하겠지만 없다고 해서 쓴 글입니다.
그런데 있나요? 있다면 가격은?
RoCE는 단순히 InfiniBand Subnet에서 Ethernet(TCP/IP)으로 나갈때 사용되는 protocol(정확히 애기해서는 driver)입니다.
즉 InfiniBand Fabric -> TCP/IP Network , Outbound일때 쓰는 것이며
IPoIB는 TCP/IP Network -> InfiniBand Fabric, Inbound일떄 쓰는 것입니다.
그러므로 RoCE로 Firewall을 통할떄는 따로 지원하는 Firewall이 필요한 것이 아니라
TCP/IP가 되는 모든 Firewall에서 정상적으로 작동합니다. (iWARP처럼요)
말씀하신 것으로 보면 iWARP과 RoCE가 같은 Ethernet에서 RDMA를 지원하는 다른 방식이네요. Checlsio는 iWARP, Mellanox는 RoCE를 만든듯 합니다.제가 잘못 이해했습니다.
그러면 RoCE에서 가장 궁금했던 점을 여쭈어볼께요. Convergerd Ethernet입니다. RoE라고 하지 않고 CE라고 한 이유가 항상 궁금했습니다. Chelsio의 자료를 보면 CE=Lossless Ethernet이라고 했고요. 이말이 무슨 뜻인지요? 일반 증권사나 금융회사의 Ethernet이 그대로 Convergered, Loss Network인가요?
RoCE가 iWARP이 더 성능이 좋다는 보고서는 본 적이 많습니다. 다만 Convergered Ethenrnet의 현실적인 의미가 무엇인지에 따라 의미가 달라질 듯 합니다.
아.. 참고로 Firewall하고는 Switch가 연결되겠죠.
RoCE 지원하는 스위치는 많습니다. 대표적으로 Mellanox 제품군이 있겠네요
말 그대로 RoCE는 Converged Ethernet이기 때문입니다.
Converged Etherent은 PFC, DCB, PBPS를 support합니다.
좀 더 쉽게 말씀드리자면 Converged ethernet은 IEEE802.1 standard라고 보시면 되며
현재 증권사에서 사용하는 NIC(랜카드) 전체가 이 standard를 따른 다 보시면 되겠습니다.
다시 말씀드리면 일반 증권사나 금융회사에서 쓰고 있는 Ethernet은 다 CE라고 보시면 되겠습니다.
물론 TCP/UDP 중 어느 것을 쓰냐에 따라 data loss가 일어날 수도 안 날수도 있겠지요.
제가 network guy가 아니고 programmer 이기 때문에 정확한 info를 전달하는데 한계가 있지만
위처럼 이해하시면 될 것 같습니다.
제가 잘못 알고 있었던 점을 고쳐주셔서 감사합니다. 다만 iWARP이나 RoCE나 같은 문제가 있네요.Mellanox에서 RoCE와 PFC를 찾아보았습니다. 소프트웨어 구현입니다.
위의 문구가 들어가 아래자료를 읽어보니까 PFC를 하기 위해서 어플리케이션에서 해야할 일이 많네요.Tradeoff관계입니다.
RoCE with Priority Flow Control Application Guide
아주 개인적인 의견을 덧붙이면 iWARP이든 RoCE든 TCP/IP 어플리케이션의 대체제(Alternative)가 되려면 더 많은 시간이 필요할 듯 합니다.(^^)
네.. 덕분에 많은 것을 보게 되네요.
PFC는 application level에서 이루어지는 것이 아니라
hardware level에서 이루어 집니다. 지금 현재 대부분의 LAN card(NIC)가 802.1Q vlan을 support
하고 있기 때문에 TCP/IP 대체의 걸림돌은 Ethernet카드나 어플 문제는 아니라고 생각됩니다.
단지 현재 모든 infra가 HPC에 맞게 형성이 안되어 있고 이런 환경들이 set-up되는 데 오랜 시간이
걸린다는 점이 걸림돌이라고 생각합니다.
제가 알기론 KRX의 차세대인 엑스츄어도 10Gbit Ethernet카드에 Linux RDMA를 사용하는 것으로 알고 있습니다.
이 부분은 pure RDMA보다는 당연히 속도가 느리지요. 아마도 다음 차세대때는 FIX protocol과 함께 진정한 RDMA technology(RoCE, iWARP, InfiniBand)가 사용될 것으로 보여집니다.
저도 이 분야를 접한지 얼마 안됐지만 운좋게 테스트 환경이 갖추어져서 열심히 학습중입니다.
개인적으로는 LLT 세미나를 크게 기대했었는데 안타깝습니다.
앞으로 많은 부분을 공유하고 토론했으면 좋겠네요. 토론 즐거웠습니다.(^^)
아 혹시 보실지 모르지만 참고가 될만한 링크 하나 남깁니다.
http://www.itc23.com/fileadmin/ITC23_files/slides/WDC_3_RoCE-DC-CaVeS-9Sep2011-nb.pdf
LLC는 계속합니다. 다만 방식을 바꿀 뿐입니다. 오랜만에 즐거운 댓글이야기를 해서 즐거웠습니다. 프로그램을 하지 않으니까 문서를 대략 읽습니다. 읽으면서 생겼던 오해네요. 감사합니다.
첨부하신 링크는 댓글토론을 하면서 검색해서 대략 읽은 글입니다. 저는 위에 제가 링크를 걸어 놓은 Application Guide가 더 도움이 되었습니다. 하여튼 고맙습니다.
나중에 따로 한번 정리해보겠습니다. 오늘 말씀하신 것을 포함해서..