Artemis가 HornetQ를 흡수한 기술적 이유는?

🚀 Apache ActiveMQ Artemis: HornetQ를 흡수하고 '차세대'가 된 기술적 필연성

메시지 브로킹의 세계에서 ActiveMQ 5.x는 오랫동안 군림해온 제왕이었습니다. 하지만 클라우드 네이티브 환경과 초고속 데이터 처리가 요구되면서 5.x 버전의 아키텍처는 한계에 부딪혔죠. 이때 구원투수로 등장한 것이 바로 HornetQ였고, 이것이 Apache 재단에 기증되면서 Artemis라는 이름의 괴물이 탄생했습니다. 왜 그래야만 했을까요?

---

1. 아키텍처의 패러다임 시프트: OIO에서 NIO(Netty)로

ActiveMQ 5.x의 가장 큰 발목을 잡았던 것은 전통적인 Blocking I/O (OIO) 기반의 통신 모델이었습니다. 스레드 하나가 연결 하나를 담당하는 구조는 동시 접속자가 늘어날수록 컨텍스트 스위칭 비용으로 인해 성능이 급격히 저하되었죠.

HornetQ의 혁신: Non-blocking I/O (Netty)

HornetQ는 애초에 Netty를 기반으로 설계된 초고성능 메시징 엔진이었습니다. 이벤트 루프 기반의 NIO를 사용하여 적은 수의 스레드로도 수만 개의 커넥션을 처리할 수 있었죠.

• 기술적 이점: 커넥션 오버헤드 최소화 및 처리량(Throughput) 극대화.
• Artemis의 선택: Artemis는 이 HornetQ의 코어를 그대로 계승하여, 메시지 처리 성능을 수 배 이상 끌어올렸습니다.

---

2. 저널링 시스템과 파일 입출력의 극한 성능 (Libaio)

메시지 브로커에서 가장 중요한 것은 지속성(Persistence)입니다. 메시지를 디스크에 안전하게 기록하면서도 성능을 놓치지 않아야 하죠.

HornetQ의 전매특허: 자바 기반의 비동기 IO (Libaio)

HornetQ는 리눅스 커널의 Libaio(Linux Asynchronous IO)를 직접 호출하는 네이티브 저널 라이브러리를 사용했습니다. 일반적인 자바의 FileChannel보다 훨씬 빠르고 효율적인 디스크 쓰기가 가능했죠.

 

---

3. Zero-Copy 메시지 처리와 메모리 관리

HornetQ가 Artemis로 흡수된 결정적인 이유 중 하나는 메모리 효율성입니다.

• Zero-Copy: 메시지가 네트워크 카드(NIC)에서 커널 공간을 거쳐 사용자 공간으로 복사되는 횟수를 최소화합니다.
• Paging 시스템: 메모리가 부족할 때 메시지를 효율적으로 디스크로 스왑(Swap)했다가 다시 불러오는 알고리즘이 HornetQ에서 매우 정교하게 구현되어 있었습니다. 이는 대규모 트래픽 상황에서 OutOfMemory(OOM) 장애를 방지하는 핵심 기술이었습니다.

---

4. 멀티 프로토콜 지원의 유연성 (The Polyglot Broker)

ActiveMQ 5.x는 다양한 프로토콜을 지원했지만, 각 프로토콜을 처리하는 방식이 파편화되어 있었습니다. 반면, HornetQ의 코어는 프로토콜 불가지론(Protocol Agnostic)적인 설계를 가지고 있었습니다.

Artemis는 이 코어를 바탕으로 다음 프로토콜들을 단일 엔진에서 완벽하게 지원합니다:

1. AMQP: 표준 클라우드 메시징 프로토콜.
2. MQTT: IoT 환경의 표준.
3. STOMP: 단순한 텍스트 기반 프로토콜.
4. OpenWire: 기존 ActiveMQ 5.x 클라이언트 호환성.
5. CORE: HornetQ 고유의 초고속 프로토콜.

이러한 유연한 레이어링 덕분에 개발자는 클라이언트 언어나 환경에 구애받지 않고 고성능 엔진의 혜택을 누릴 수 있게 된 것입니다.

---

5. 고가용성(HA)과 클러스터링 전략

HornetQ는 Shared-nothing 복제 모델을 아주 강력하게 지원했습니다. 주 노드(Live)와 보조 노드(Backup) 간의 실시간 데이터 복제를 통해, 주 노드가 죽더라도 데이터 유실 없이 즉시 페일오버(Failover)가 가능한 구조였습니다.

Artemis는 이를 계승하여 Quorum 기반의 투표 시스템을 도입, 소위 말하는 'Split-brain' 현상을 방지하고 엔터프라이즈 급의 신뢰성을 확보했습니다.