1.
IT기술이 하루가 다르게 바뀌고 있습니다. 지난 몇 년을 되돌아보면 변화의 속도가 무척 빠릅니다. 뒷쫓아 가기가 무척이나 힘듭니다. 그러다가 결국은 손을 놓습니다. 처음 고속 네트워킹에 관심을 가진 때는 HFT입니다. 지금부터 십 몇 년전입니다. 고속매매시스템이 처음 등장했을 때 고속보다는 고빈도에 방점을 찍힌 채 세상에 나왔습니다.High Frequency라고 작명을 하였죠. 시간이 지나면서 빈도보다는 속도를 더 강조합니다. High Frequency 보다는 Low Latency가 더 주목을 받습니다. TCP Acceleration 기술이 큰 관심을 끌었습니다. 지금도 한국에서 힘을 쓰고 있는 OpenOnload입니다. 저는 OpenOnlaod보다 Chelsio를 더 많이 사용하였습니다. 관심도 많았고.. 최근에서 libvma을 주로 사용합니다.
고속매매시스템의 네트워킹을 다룰 때 TCP가속기술이 가장 중요하지만 같은 기술도 OS 및 매매프로세스와 어떤 조건에서 동작하느냐에 따라 결과가 달라집니다. 튜닝을 할 때 제가 하는 일입니다. 이와 관련하여 무척 재미있는 논문을 보았습니다.
The Anatomy of Networking in High Frequency Trading
제목만 보면 특별하지 않습니다. 특별한 것은 발표자의 소속입니다. Jump Trading의 엔지니어이기 때문입니다. Jump Trading은 유명한 HFT회사이고 한국에서도 거래를 하고 있습니다. LinkedIn을 보니까 A Capital Markets Professional와 같은 분이 부산에서 일하고 있네요..고빈도매매 회사 Jump Crypto와 테라,루나에서도 다루었던 회사이기도 합니다. 논문이 다루는 주제는 네트워킹에서 CPU affinity, Interrupt affinity, CPU isolation 및 Polling의 중요성을 시험으로 제시합니다. 여기에 더하여 AF_XDP, RDMA도 다룹니다. 자세한 내용은 논문을 참고하시길 바랍니다.
개인적으로 저자가 논문에서 주장하는 핵심요지가 Predictable Latency라고 생각합니다. 제가 생각하는 예측가능하다는 말을 Jitter의 최소화로 이해합니다.Jitter를 최소화하려면 Network Path를 단순화하여야 합니다. 리눅스내에서 패킷이 어떤 경로로 전달하거나 받는지를 그림으로 표시하면 아래와 같습니다. Path of a packet in the Linux Kernel Stack에서 가져온 도표입니다.
이상과 같이 복잡한 경로를 최소화하는 기술이 Kernel Bypass입니다. 옛날에는 TCP Offload라고 한 부분입니다. 다만 네트워킹과 관련한 다양한 기술이 등장하면 TCP에 국한한 단어대신에 Kernel Bypass라는 표현을 더 선호하는 듯 합니다. 그리고 TCP Acceleration기술보다는 Kernel-bypass-with-the-kernel에 의한 방법이 예측가능성을 높힌다고 주장합니다. 참고로 libvma는 RDMA기술을 기반으로 합니다. Kernel 기반입니다.(^^)
참고로 Networking and high-frequency trading은 위 논문을 설명합니다.
Predictable latency is also important on the analysis side of the network, and RDMA works well for that, but there are some things that he thinks could be done better. For one, io_uring is showing great promise; it has expanded quite a ways from its initial genesis as a replacement for the libaio asynchronous I/O library. It is no longer only for I/O, as Josh Triplett’s io_uring_spawn talk at LPC shows, Waskiewicz said. It would be interesting to see if the networking-hardware ring buffers could be used directly as buffers for io_uring operations so that data can get to and from the hardware using that mechanism; that would allow the HPC side to use something “much more kernel-standardized that would be able to replace RDMA”.
But, for now at least, RDMA is the king in HPC networks; no mention of RDMA is complete without mention of RDMA over Converged Ethernet (RoCE), though, he said. Infiniband, which is the fabric used for these RDMA networks, is expensive, but that is not necessarily a problem in the HFT world as the industry is willing to spend money that allows it to make more money. Infiniband is something of a niche technology, though, which makes it hard to find technical people that can manage the network and keep it up and running.
RoCE (along with iWARP) allow the use of Ethernet equipment and management skills, but they come with challenges of their own. Converged networks still have jitter problems because they are not a dedicated fabric. That leads to a need for additional equipment and configuration to reduce that.
He said that he already had planned to talk about Homa for HPC before the John Ousterhout’s keynote the previous day (which we covered: part 1 and part 2). Waskiewicz sees the remote-procedure-call-based approach of Homa as being similar to the RDMA Verbs API. Having Homa available both in user space and the kernel would allow for more flexibility. Being able to use standard Ethernet equipment throughout the network would be worthwhile from a maintenance and cost standpoint as well.
2.
앞서 저자를 소개했습니다. 혹시나 해서 어떤 사람인지 찾아보니까 아래 논문을 쓴 분입니다.
Wire-Speed Hardware-Assisted Traffic Filtering with Mainstream Network Adapters
이 때 저자의 직장을 보니까 IBM 연구소입니다.
