Aeron: HFT 업계 절반을 움직이는 메시징 시스템의 내부 구조

Aeron: Media Driver, 공유 메모리, 트리플 버퍼 로그 — 저지연 메시징의 표준을 세운 아키텍처.

고빈도 트레이딩의 메시징 시스템을 이야기할 때 빠지지 않는 이름이 있다 — Aeron. Martin Thompson과 Real Logic 팀(이후 Adaptive Financial Consulting)이 개발한 Aeron은 마이크로초가 모든 것을 결정하는 세계에서 데이터 전송의 사실상 표준이 되었다.

이 글에서는 Aeron의 구성 요소를 하나씩 분석한다: Transport, Archive, Cluster, Sequencer. 내부 구조, 강점, 그리고 문제가 시작되는 지점을 살펴본다.

요약

• Aeron — 저지연 애플리케이션을 위한 오픈소스(Apache 2.0) 메시징 시스템
• IPC 지연 시간: 공유 메모리를 통한 약 250ns 왕복
• 처리량: 초당 2,000만+ 메시지
• 4가지 제품: Transport(코어), Archive(기록/리플레이), Cluster(Raft), Sequencer(전체 순서)
• 언어: Java(메인) + C 클라이언트(기능 제한)
• 사용자: 수십 개의 HFT 기업, 마켓메이커, 거래소

파트 1: Aeron Transport — 모든 것의 핵심

아키텍처: Media Driver

Aeron의 핵심 컴포넌트는 Media Driver이다. 독립 프로세스(또는 임베디드 라이브러리)로 동작하며 모든 데이터 전송을 관리한다. 애플리케이션은 공유 메모리(/dev/shm의 mmap 파일)를 통해 Media Driver와 통신한다.

┌──────────┐                    ┌──────────────┐                    ┌──────────┐
│ Publisher │ ── shm commands ─→│ Media Driver  │←─ shm commands ── │Subscriber│
│   (App)   │ ←─ shm responses─│  (process)    │─→ shm responses  │  (App)   │
└──────────┘                    │              │                    └──────────┘
                                │ Log Buffers  │
                                │ (data path)  │
                                └──────┬───────┘
                                       │
                                    Network
                                  (UDP/IPC)

핵심 데이터 구조:

• ManyToOneRingBuffer(MPSC) — 클라이언트에서 Media Driver로의 명령
• BroadcastTransmitter/Receiver — Media Driver에서 클라이언트로의 응답
• Log Buffers — 데이터용 트리플 버퍼 추가 전용 로그
• Position Counters — 위치 조정을 위한 원자적 카운터

Log Buffers: 트리플 버퍼링

Aeron의 데이터는 Log Buffers를 통해 전송된다 — 3개의 term buffer가 교대로 사용된다. 하나가 가득 차면 다음으로 전환된다(term rotation). 이를 통해 publisher가 하나의 버퍼에 쓰는 동안 subscriber가 다른 버퍼에서 읽을 수 있다.

각 term buffer의 크기는 64 KB에서 1 GB까지이며, Publication 생성 시 고정된다.

프로토콜

Aeron은 UDP 위에 자체 wire protocol을 사용한다:

• Data frames — 헤더가 포함된 실제 데이터(stream ID, session ID, term ID, offset)
• Status Messages — 흐름 제어(receiver가 자신의 위치를 보고)
• NAK — 재전송 요청(receiver 주도)
• Setup — 연결 설정
• Heartbeat — 활성 확인

성능

공식 성능 지표:

이 수치는 인상적이다. 다만 주의할 점이 있다 — Java에서 측정된 것으로 JVM 관련 요인의 영향을 받는다.

파트 2: Aeron Archive — 기록과 재생

Archive는 메시지를 디스크에 저장하고 임의의 위치에서 리플레이할 수 있는 기능을 제공한다.

작동 원리

1. Archive 프로세스가 Aeron Transport를 통해 스트림을 구독
2. 모든 메시지가 세그먼트 파일로 디스크에 기록
3. 필요시 리플레이: Archive가 기록된 데이터로부터 새로운 Publication 생성
4. 클라이언트가 리플레이 스트림을 구독하여 과거 메시지 수신

활용 사례

• 감사 — 규제 기관이 모든 메시지 보존을 요구
• 장애 복구 — 새 노드가 리플레이를 통해 리더를 "따라잡음"
• 분석 — 전략 백테스트를 위한 스트림 리플레이
• 디버깅 — 정확한 이벤트 시퀀스 재현

파트 3: Aeron Cluster — Raft 합의

Cluster는 Raft 합의 기반의 장애 허용 복제 상태 머신이다. 메시지 손실이 허용되지 않는 미션 크리티컬 시스템(매칭 엔진, 주문 관리)에서 사용된다.

작동 원리

1. Leader가 모든 수신 명령을 처리
2. Aeron Transport를 통해 각 레코드를 followers에 복제
3. 과반수 확인 후 — 레코드가 committed 처리
4. committed된 레코드가 상태 머신에 적용

특성

• 자동 리더 선출 및 페일오버(1초 미만)
• 강한 일관성(리더를 통한 선형화 가능 읽기)
• 핫 시스템 업그레이드
• 처리량: Raft 합의 하에서 초당 수백만 메시지

파트 4: Aeron Sequencer — 통합 이벤트 순서

Sequencer는 자본 시장에 최적화된 신규 제품(2025년)이다.

과제

마켓메이킹과 거래소에서는 모든 참가자가 동일한 이벤트 순서를 보는 것이 매우 중요하다. Sequencer는 전체 순서(total ordering) — 모든 메시지에 대한 통합된 글로벌 시퀀스를 보장한다.

아키텍처

• Aeron Cluster 위에 구축
• 여러 머신에 복제되는 분산 로그
• 다중 리더 — 여러 애플리케이션이 하나의 로그를 읽음
• 팀 분리 — 통합된 순서 프레임워크 내에서 팀이 독립적으로 작업

제약 사항

Sequencer는 Adaptive Financial Consulting의 상용 제품이다. 클로즈드 소스. Cluster의 모든 약점을 계승한다.

Aeron의 약점

많은 장점에도 불구하고 Aeron에는 근본적인 한계가 있다:

1. JVM 의존성

off-heap 메모리를 사용하더라도 JVM safepoint는 모든 스레드를 중단시킨다. GuaranteedSafepointInterval=300000은 임시방편일 뿐 근본적인 해결책이 아니다. JIT 워밍업으로 시작 후 처음 몇 분간 예측 불가능성이 증가한다.

C 클라이언트가 존재하지만 기능이 불완전하다 — Archive도 Cluster도 없다.

2. Media Driver 오버헤드

별도 프로세스는 공유 메모리를 통한 추가 홉을 의미한다. 임베디드 모드는 JVM에 종속된다. 어느 쪽이든 추가적인 불확실성이 발생한다.

3. 고정된 Log Buffers

3개의 term buffer가 생성 시 크기가 고정된다. 적응형 메모리 관리가 없다. 너무 크면 RAM 낭비, 너무 작으면 잦은 term rotation이 발생한다.

4. 네이티브 커널 바이패스 부재

네트워크는 UDP만 지원한다. io_uring, DPDK, AF_XDP는 지원하지 않는다. Aeron Premium이 커널 바이패스를 추가하지만 클로즈드 소스 유료 제품이다.

5. SBE — 별도 의존성

XML 스키마, Java 코드 생성기, 별도의 빌드 단계. 언어 내 통합이 없다.

6. 제로카피 네트워킹 부재

데이터가 소켓에서 log buffer로 복사된다. Linux 6.0+에서 io_uring은 제로카피 송수신을 지원하지만 Aeron은 이를 활용하지 않는다.

대안

Marketmaker.cc에서는 ZigBolt를 개발했다 — Zig 언어로 만든 오픈소스 Aeron 대안. JVM 없음, GC 없음, comptime 코덱과 20ns SPSC 지연 시간. 자세한 내용은 ZigBolt 관련 글을 참고하라.

결론

Aeron은 저지연 메시징의 표준을 세운 뛰어난 엔지니어링 프로젝트이다. 그 아키텍처적 결정(트리플 버퍼 로그, NAK 기반 신뢰성, Raft 클러스터)은 업계의 모범이 되었다.

하지만 세상은 계속 앞으로 나아간다. Zig와 Rust 같은 언어는 JVM 오버헤드 없이 동일한(또는 더 나은) 결과를 달성할 수 있다. io_uring과 DPDK를 통한 커널 바이패스는 순수 UDP로는 불가능한 가능성을 열어준다. comptime 코드 생성은 별도의 XML 스키마와 Java 코드 생성기를 과거의 산물로 만들고 있다.

Aeron은 수십 개 기업의 프로덕션 환경에서 앞으로도 수년간 운영될 것이다. 하지만 새로운 프로젝트라면 대안을 검토할 가치가 있다 — ZigBolt를 포함해서.

참고 링크:

• Aeron GitHub: github.com/real-logic/aeron
• Aeron Wiki: github.com/real-logic/aeron/wiki
• Martin Thompson(개발자): mechanical-sympathy.blogspot.com
• ZigBolt(우리의 대안): 글 | 사이트
• Marketmaker.cc: marketmaker.cc

인용

@article{soloviov2026aeron,
  author = {Soloviov, Eugen},
  title = {Aeron: HFT 업계 절반을 움직이는 메시징 시스템의 내부 구조},
  year = {2026},
  url = {https://marketmaker.cc/ko/blog/post/aeron-messaging-overview},
  description = {Aeron 아키텍처 분석 — Transport, Archive, Cluster, Sequencer. 강점과 약점.}
}