[Disruptor] 1. 왜 LMAX는 Queue를 버렸는가?

프롤로그: 호기심의 시작, 그리고 뼈아픈 교훈

본격적인 아키텍처 분석에 앞서, 왜 하필 지금 Disruptor를 다시 파고들게 되었는지 이야기해 보려 한다.

 

나는 평소 블록체인 생태계와 암호화폐, 그리고 그 기저에 흐르는 경제 시스템에 관심이 많다.

6년 차 개발자이다 보니 단순히 투자의 대상을 넘어, "저 거대한 자본이 실시간으로 오가는 시스템은 도대체 어떻게 굴러가는 걸까?"라는 엔지니어링 관점의 호기심이 발동하는 건 어쩔 수 없나 보다.

특히 암호화폐 거래소가 그 엄청난 트래픽과 초단타 매매를 어떻게 감당해내는지 늘 궁금했다.

 

이 궁금증을 해소하기 위해 리서치를 하던 2021년 무렵, 영국 거래소 LMAX에서 만든 Disruptor라는 라이브러리를 처음 접하게 되었다.

쓱 훑어보니 Hardware Sympathy(기계적 공감)라는, 백엔드 개발자의 심장을 뛰게 하는 키워드들이 가득했다. 

당시에는 이직 준비 등 현실적인 이유로 깊게 파고들지 못하고 마음 한구석에 미뤄두었으나, 최근 기술적 갈증을 해소하고자 다시 문서를 펼치게 되었다.

 

사실, 이 주제에 집착하게 된 데에는 뼈아픈 개인적인 경험도 한몫했다.

코인 광풍이 불던 21년도, 막 상장한 코인을 업비트에서 매수했던 적이 있다.

폭등하는 차트를 보며 매도 버튼을 연타했지만, 돌아온 건 요청이 너무 많다는 차가운 에러 로그뿐이었다.

그 찰나의 지연 시간 동안 내 수익률은 곤두박질쳤고, 결국 꽤 큰 손실을 입었다.

 

그 정도로 트래픽이 폭주하는 곳이 거래소인데, 놀랍게도 LMAX는 C++나 Rust 같은 시스템 프로그래밍 언어가 아닌 Java를 사용하여 이 시스템을 구축했다고 한다.

밀리세컨드(ms)를 넘어 나노세컨드(ns) 단위의 경쟁을 해야 하는 거래소 엔진을 Java로?

GC(Garbage Collection)로 인한 'Stop-the-world' 현상은 어떻게 해결했을까?

멀티 스레드 환경의 고질적인 문제인 Lock 경합과 Context Switching 비용은 또 어쩌고?

의구심과 경이로움이 동시에 들었다.

도대체 그들은 어떻게 Java의 태생적 한계를 극복했을지 궁금하였다.

 

 

Disruptor란 무엇인가?

LMAX Disruptor 공식 홈페이지에 접속하면 그들의 당찬 포부가 첫 줄부터 반긴다.

 

LMAX aims to be the fastest trading platform in the world.
Clearly, in order to achieve this we needed to do something special to achieve very low-latency and high-throughput with our Java platform.

LMAX는 세상에서 가장 빠른 트레이딩 플랫폼을 목표로 한다.
이를 위해 우리는 Java 플랫폼 위에서 초저지연(Low-Latency)과 높은 처리량(High-Throughput)을 달성할 '무언가 특별한 것'이 필요했다.

 

 

핵심은 명확했다.

그들은 단순히 '빠른' 시스템이 아니라, 극한의 트래픽 상황에서도 예측 가능한 레이턴시(Latency)를 보장하는 시스템이 필요했던 것이다.

일반적인 웹 애플리케이션이라면 적당한 성능 타협이 가능하겠지만, 금융 거래소는 다르다.

내가 겪었던 주문 실패 경험처럼, 0.1초의 지연이 수십, 수백억 원의 가치를 바꿀 수 있기 때문이다.

 

LMAX 엔지니어들이 주목한 문제의 본질은 동시성 처리 방식에 있었다.

전통적인 방식, 즉 여러 스레드가 데이터를 공유할 때 발생하는 오버헤드를 어떻게 하면 획기적으로 줄일 수 있을까?

Disruptor는 바로 이 질문에 대한 LMAX의 대답이다.

 

이어지는 글에서는 LMAX가 어떻게 하드웨어의 성능을 극한까지 끌어올렸는지 그 설계의 심연을 들여다보려 한다.

전통적인 Queue를 대체한 Ring Buffer의 구조적 미학부터, CPU 캐시 효율을 위해 False Sharing과 Cache Line을 어떻게 제어했는지,

그리고 Memory Barrier를 통해 어떻게 Lock 없는 동기화를 이뤄냈는지 코드로 확인해 볼 것이다.

마지막으로, 이 강력한 도구가 만능열쇠가 되지 않도록 언제, 어떻게 적재적소에 활용해야 하는지에 대한 실무적 고찰로 여정을 마무리하겠다.