AutoMQ

이것저것 검색해보다가 카프카 관련 오픈소스가 신기한게 검색되어서 남겨본다.

Apache Kafka 완전 호환 오픈소스 메시징 플랫폼

• Apache License 2.0 기반 → 상용 환경에서도 자유롭게 사용 가능
• 기존 Kafka의 한계(로컬 디스크 기반 스토리지, 리밸런싱 비용)를 극복하기 위해
  클라우드 네이티브 아키텍처로 재설계됨

주요 특징

• 스토리지와 컴퓨트(브로커) 분리
• 오브젝트 스토리지(S3, MinIO 등) 활용
• 서버리스/탄력 확장 지향
• Kafka API와 100% 호환

아키텍처 특징

• 데이터 저장 위치: 브로커 로컬 디스크 대신 오브젝트 스토리지 사용
• 브로커 역할 단순화: 데이터 저장 책임이 없어지고, 처리(네트워킹·메타데이터)만 담당
• 확장성: 브로커 수를 자유롭게 늘리고 줄일 수 있으며, 데이터 재분배 비용 최소화
• 운영 효율성: 객체 스토리지 비용·운영 효율을 그대로 활용 가능

Kafka vs AutoMQ 비교

항목	Apache Kafka (로컬 디스크 기반)	AutoMQ (오브젝트 스토리지 기반)
데이터 저장 위치	브로커 로컬 디스크	외부 오브젝트 스토리지 (S3/MinIO 등)
브로커 역할	저장 + 처리	처리 전용 (저장은 분리)
브로커 증설 (Scale-out)	새 브로커에 파티션 이동 필요 → 대량 데이터 리밸런스	새 브로커가 메타데이터만 읽고 바로 참여 → 데이터 이동 없음 수준
브로커 축소 (Scale-in)	파티션을 다른 브로커로 옮겨야 함 → 비용/시간 큼	브로커 제거 시 데이터는 스토리지에 남음 → 영향 최소화
데이터 내구성	브로커 간 복제 필요	오브젝트 스토리지가 분산 복제/내구성 제공
확장 탄력성	제한적 (자동 축소 어려움)	매우 높음 (실시간 오토스케일링 가능)
운영 비용	고성능 디스크 필요, 관리 복잡	오브젝트 스토리지 활용 → 비용 절감, 운영 단순화
리스크	브로커 장애 시 데이터 복구·재동기화 필요	브로커 장애 시 다른 브로커로 즉시 대체 가능

장점

• 클라우드 친화적: Kubernetes·클라우드 환경에서 탄력적 확장/축소 용이
• 비용 효율적: SSD·HDD 확장 대신 저렴한 오브젝트 스토리지 사용
• 운영 단순화: 리밸런스/재분배 부담 감소
• Kafka 완전 호환: 기존 Kafka 클라이언트/코드 그대로 사용 가능

단점

• 성숙도 부족 : Kafka에 비해 신생 프로젝트 → 운영 사례와 커뮤니티 지원이 제한적

• 네트워크/스토리지 의존: 모든 로그를 오브젝트 스토리지에 저장 → 네트워크 지연·대역폭에 민감

• 비용 구조 리스크: 오브젝트 스토리지 API 호출·egress 비용 → 경우에 따라 Kafka보다 더 비쌀 수 있음

• 운영 생태계 미성숙: Kafka Streams, Connect 등 일부 에코시스템 호환성·운영 툴링은 아직 제한적