1.
한동안 리눅스는 소수의 전유물인 적이 있었습니다. 그렇지만 조금씩 이용자를 넓혀 왔습니다. 개발자뿐 아니라 기업으로까지 발을 넓혔습니다. 낮은 비용뿐 아니라 높은 성능으로 인하여 금융산업의 중심인 월스트리트까지 확대하였습니다. 그리고 자본시장에서 가장 중요한 시스템인 매매체결시스템까지 장악하였습니다. 한마디로 리눅스가 대세인 세상입니다.(^^)
위의 기사중 언급이 되었지만 금년도 LinuxCon 행사중 주요한 발표중 하나가 Linux: How it Runs the World of Finance입니다. 그만큼 리눅스와 자본시장을 밀월의 시대에 접어들었습니다.
그렇지만 한가지 의문이 생깁니다. 월스트리트의 대형IB들은 OS로서 Linux을 어떻게 사용하는지가 궁금하였습니다. 그냥 Redhat과 같은 회사들의 제품을 사서 설치하고 운영하는 수준인지 아니면 다르지를 알아보고 싶었습니다.
이와 관련한 단서를 보여주는 발표가 2010년에 있었습니다. Nasdaq OMX의 CIO인 Bob Evans가 Linux Foundation’s invitation-only End User Summit 행사에서 Linux at NASDAQ: What Works and What Would Really Work라는 주제로 발표한 기사입니다.
현재 전세계 거래소는 Low Latency 경쟁을 하고 있습니다. 나스닥도 예외는 아닙니다. 이런 경쟁에서 이기기 위한 선택이 리눅스이었다고 합니다.
To meet these requirements, NASDAQ OMX runs large clusters of thousands of machines. These clusters can process hundreds of millions of orders per day – up to one million orders per second – with 250μs latency.
그러면서 진화하고 있는 리눅스커널이 제공하는 여러가지 기능으로 인하여 시스템 성능을 향상시킬 수 있었다고 합니다.
According to Bob, Linux has incorporated some useful technologies in recent years. The NAPI interrupt mitigation technique for network drivers has, on its own, freed up about 1/3 of the available CPU time for other work. The epoll system call cuts out much of the per-call overhead, taking 33μs off of the latency in one benchmark. Handling clock_gettime() in user space via the VDSO page cuts almost another 60ns. Bob was also quite pleased with how the Linux page cache works; it is effective enough, he says, to eliminate the need to use asynchronous I/O, simplifying the code considerably.On the other hand, there are some things which have not worked out as well for them. These include I/O signals; they are complex to program with and, if things get busy, the signal queue can overflow. The user-space libaio asynchronous I/O (AIO) implementation is thread-based; it scales poorly, he says, and does not integrate well with epoll. Kernel-based asynchronous I/O, instead, lacks proper socket support. He also mentioned the recvmsg() system call, which requires a call into the kernel for every incoming packet.
There is some new stuff coming along which shows some promise. The new recvmmsg() system call can receive multiple packets with a single call. For now, though, it is just a wrapper around the internal recvmsg() implementation and does not hold the socket lock across the entire operation. But, he said, recvmmsg() is a good example of how the ability to add new APIs to Linux is a good thing. He also likes the combination of kernel-based AIO and the eventfd() system call; that makes it possible to integrate file-based AIO into an applications normal event-processing loop. There is also some potential in syslets, which he sees as a way of delivering cheap notifications to user space; it’s not clear whether syslets will scale usefully, though.
What NASDAQ OMX would really like to see in Linux now is good socket-based AIO. That would make it possible to replace epoll/recvmsg/sendmsg sequences with fewer system calls. Even better would be if the kernel could provide notifications for multiple events at a time. Best would be if the interface to this functionality were completely based on sockets. He described a vision of an “epoll-like kernel object” which would handle in-kernel network traffic processing. The application could post asynchronous send and receive requests to the queue, and receive notifications when they have been executed. He would like to see multiple sockets attached to a single object, and a file descriptor suitable for passing to poll() for notifications. With a setup like that, it should be possible to push more network traffic through the kernel with lower latencies.
In summary, NASDAQ OMX seems to be happy with its use of Linux. They also seem to like to go with current software – the exchange is currently rolling out 2.6.35.3 kernels. “Emerging APIs” are helping operations like NASDAQ OMX realize real-world performance gains in areas that matter. Linux, Bob says, is one of the few systems that are willing to introduce new APIs just for performance reasons. That is an interesting point of view to contrast with Linus Torvalds’s often-stated claim that nobody uses Linux-specific APIs; it seems that there are users, they just tend to be relatively well hidden.
아주 오래전 소켓기반의 서버구조를 살펴볼 때 보았던 epoll이라는 단어는 눈에 들어옵니다. 만약 이 글을 읽고 있는 분이 개발자라고 하면 느낌이 오실 듯 합니다.
2.
이상을 소개한 이유는 KRX가 리눅스를 기반으로 Exture+를 개발하겠다고 했기때문입니다. 만약 KRX의 Exture+가 성공하면 한국자본시장에서 리눅스는 확고히 자리를 잡을 수 있을 듯 합니다. 때문에 Exture+는 성공하여야 하는 프로젝트입니다. KRX만을 위해서가 아니라 자본시장내의 생태계변화를 위해서도 그렇습니다.
성공을 위한 조건은 무엇일까요? 앞서 어떻게 사용하는지 궁금하였다고 하였습니다. Linux를 어떤 수준에서 사용하는지가 매우 중요하다는 생각입니다.? 앞서 소개한 기사의 댓글을 살펴보았습니다 .눈에 들어오는 문장이 있습니다.
The important information missing IMHO is: how many Kernel hackers are employed by NASDAQ?
Nasdaq과 KRX가 똑같이 Redhat를 기본OS로 해서 시스템을 개발한다고 하더라 똑같은 지원을 받을 수 없습니다. 최소한 미국 나스닥은 레드햇본사 연구소의 개발자들이 커널과 관련된 다양한 지원 및 개발을 하지 않을까 합니다. 반면 KRX의 경우 아무리 레드햇 코리아에서 지원을 한다고 하더라도 아주 제한적이고 기술적 수준이 낮을 듯 합니다. 저의 예상입니다. 이럴 경우 나노초 혹은 마이크로초를 다투는 시스템은 커다란 차이를 보입니다. Exture+는 두자리의 마이크로초를 목표로 합니다. System Call을 잘못 사용하면 그 순간 세자리가 되고 한 자리 밀리초가 됩니다.
Exture+를 담당하고 있는 코스콤이 얼마나 많은 리눅스 커널전문가를 가지고 있는지 모릅니다. 제가 알기론 거의 없다고 합니다. 이런 상태에서 원하는 성능을 가진 Exture+가 나올까요? AIX와 같은 유닉스와 비교하여 Linux가 가진 강점은 오픈소스로 끊임없이 진화하고 있는 OS라는 점입니다. 강점을 계속 받아드리려면 Linux만을 위해 자신의 모든 것을 쏫아 붙는 누군가가 있어야 합니다.
리눅스로 선택한 순간 리눅스커널 전문가를 널리 구해야 합니다.
