C로 구현된 HTTP 기반 이벤트 로그, 'curl'로 손쉽게 사용!
C로 작성된 HTTP 기반의 이벤트 로그 시스템(Event Log System) 'Ayder'가 출시되었으며, 'curl'을 클라이언트로 사용
3-노드 Raft 클러스터 환경에서 50K msg/s의 처리량(Throughput)과 3.46ms의 P99 응답 시간을 기록
SIGKILL을 통한 의도적인 크래시(Crash) 후에도 데이터 복구 및 오프셋 검증을 시연하여 내구성을 강조
Kafka, Redis Streams 등 기존 시스템과의 트레이드오프(Trade-offs) 및 향후 이벤트 로그 표준화에 대한 논의가 진행됨
Ayder의 아키텍처 및 성능 분석
Ayder는 C 언어로 구현되어 단일 바이너리(Single Binary)로 배포되며, HTTP를 네이티브 프로토콜로 사용한다. 3-노드 Raft 클러스터 환경에서 동기식 쓰기(Sync-majority writes)를 지원하며, 64B 페이로드(Payload) 기준으로 초당 50,000개의 메시지를 처리한다. SIGKILL 시뮬레이션(Simulation)을 통해 데이터 손실 없이 복구되는 모습을 시연하여 내구성을 강조한다. 이는 데이터 격리 아키텍처(Data Isolation Architecture)를 통해 구현된 것으로 보인다.
Kafka, Redis Streams와의 트레이드오프
Ayder는 Kafka 및 Redis Streams와 비교하여 단순성(Simplicity)을 강조한다. 특히, 'curl'을 클라이언트로 사용함으로써 별도의 클라이언트 라이브러리 의존성을 제거했다. 하지만, Raft 합의 알고리즘(Consensus Algorithm)을 사용함에 따라, TigerBeetle의 VSR(Versatile State Replication)과 같은 다른 합의 알고리즘과의 트레이드오프를 고려해야 한다. 또한, Kafka와 같은 성숙한 시스템에 비해 기능의 제한(Feature Limitation)이 있을 수 있다.
이벤트 로그 표준화에 대한 논의
커뮤니티에서는 이벤트 로그 소비를 위한 표준 프로토콜(Standard Protocol)의 부재에 대한 아쉬움을 표하며, 다양한 서버에서 사용할 수 있는 클라이언트 측 도구의 필요성을 제기한다. Vipps의 feedapi-spec과 같은 표준 제안(Standard Proposal)이 존재하지만, 널리 사용되지 못하고 있다. 이러한 표준화 노력은 이벤트 스트리밍(Event Streaming) 생태계의 확장을 촉진하고, 개발자들의 선택의 폭(Choice)을 넓힐 수 있다.
C 언어 선택 및 개발 철학
Ayder는 C 언어를 사용하여 낮은 수준의 제어(Low-level Control)와 최적화된 성능(Optimized Performance)을 추구한다. 이는 JVM이나 두꺼운 클라이언트 라이브러리 없이도 높은 처리량을 달성하기 위한 선택으로 보인다. 또한, Makefile을 사용하여 빌드 과정을 관리하는 등, 단순하고 직관적인 개발 방식(Simple and Intuitive Development)을 선호하는 개발 철학을 엿볼 수 있다. 이는 최신 기술 트렌드와는 다른, 독자적인 접근 방식(Unique Approach)을 보여준다.