조금씩 스터디 및 프로젝트를 진행하면서, 아주 많이는 하지는 못하지만, 오픈소스를 사용할 때 고려했던 점들이 있다. 이벤트 발생 상황이나 서버를 여러 개 두었을 때라던지 여러 가지 고려 사항이 생기기 시작했다. 솔직하게 객관적으로 말하자면, 작은 토이 프로젝트에 오픈소스를 여러 개 쓰는 것조차도 사실 부담이 됐었고, 클라우드 서비스에 어떻게 배포를 해야할 지도 머리가 아플 지경이였다. (비용이 사실 제일 큰 문제였다.)
그래서 프로젝트 진행 중, 서버에서 이벤트 추적에 대한 혹은 이벤트 로직을 기능 구현 중 생각 했던 것이 토이프로젝트지만, 이벤트 서버라도 분리를 해보자 현재 메인 서버에 대해 이벤트 로직까지 구현하게 되면 백엔드를 하는 입장에서 소스코드를 뜯어보기도 부담스럽기도 했다. 너무 과투자가 아닌가? 혹은 폴더 구조 자체도 유지보수가 힘든게 아닐까 라는 생각을 했지만, 작은 토이 프로젝트에도 최소한 만큼의 서버분리를 해서 유지보수에 편리성을 높이자라는 생각을 해보게 되었다. 이게 맞는 것인지는 모르겠지만, 확실히 도전해볼만한 가치가 있다고 느꼈다.
그러던 중 이벤트 서버에 대한 분리를 해보자라는 것이 주 목적이였고, 실시간성 데이터나 혹은 사용자 행위 추적에 대한 로직이 필요했다.
현재 사용해본 pub/sub 기능에서는 총 3가지였다.
- rabbitMQ
- redis pub/sub
- mosquitto
안그래도 기존 사용하던 것에 레디스를 사용하기도 했고 처음에는 레디스를 선택하고 기능을 만들면서 최초에는 레디스 PUB/SUB 기능을 사용하고 있었다.
사실 개인적인 욕심이지만 카프카나 다른 메시지큐를 학습해보고 싶기도 했고, 프로젝트 진행 중 개인적인 욕심으로 레디스 PUB/SUB을 빼고 다른 걸 끼워보고 싶은 생각이 들기도해서 카프카나 다른 메시지큐에 대한 자료를 찾아보기 시작했다.
Nats의 선택이유
그렇다면 왜 nats를 선택하게 되었나? 첫 이유는 간단했다. 사실 go 백엔드를 구현하고 있으니 go를 사용하는 오픈소스가 어떤가라는 생각으로 찾았는데 nats가 그 대상이였다. 그렇다면 요즘 많이 사용하는 카프카를 고려를 안한건 아니다. 그래서 더 많은 이유를 찾았다. (사실 nats를 사용해야할 이유를 찾기였다.)
아 추가적으로 생각해야할 것들은 있었다. 그래도 오픈소스를 또 추가로 하는건데 리소스는 얼마나 먹는지, 큰기능을 쓸건아니니까 사실 그러한 것도 고려대상이였다. aws에 배포하는 것도 문제긴 했으니까 그런 비용적인 문제도 컸다.
그렇다면 카프카랑 비슷하다고 하면 NATS JetStream이였고, 그에 대한 비교 및 분석이 필요했다.
Nat JetStream
- 메시지 영구저장 기능을 제공하고 이전 메시지를 다시 조회할 수 있다
- 특정 메시지를 가져올 수 있다.
- zookeeper같은 것이 없고 단순함
- 클러스터링 및 확장이 쉬워서 쿠버네티스 환경에도 나쁘지 않다.
- 필요한 메시지만 저장을 할 수 있다.
- 토픽을 구분할 때 계층적 구조를 가진다.
데이터를 저장 혹은 메시지를 저장한다는 것이 카프카를 사람들이 선택했던 이유고 단순히 PUB/SUB 기능은 메시지 유실가능성이 있기 때문에 영속성에 대한 문제도 생각하지 않을 수 없다.
단순히 내 토이프로젝트에서는 그러한 문제까지 담기에는 너무 작은 프로젝트기때문에 제트스트림까진 아니지만 그래도 확인 과정이 필요했다.
KAFKA
- 로그기반 시스템이기때문에 대량의 디스크 I/O가 발생하기도 한다.(물론 그정도의 데이터를 쌓진 않겠지만 그만큼 운영비용이 더 들어간다.), 데이터 유실에 대한 문제는 없다.
- 운영이 어렵다 , ZOOKEEPER관리와 여러개의 브로커 관리가 필요하다. 신경써야할 부분이 더 많다. 이에 대한 부분은 클러스터링 관리 또한 어렵다는 것이다.
- 로그기반에 대한 얘기가 다시나오는데 로그기반이기 때문에 좀 더 LATENCY가 길어진다.
사실 기술적인 부분들은 추가적으로 검증이 더 필요할 것 같다. 사용하고 있는 나 자신도 아직 확신이 들지 않은 상태에서 토픽을 계층적으로 구분하는 것은 기존에 업무로 사용해봤던, mosuquitto와 비슷하기도 하고, 나중에 aws에 설치할때도 가볍기 때문에 돈이 들지 않을거 같아서 간단하게 설치하기 좋기도하고, 추가적으로 k8s에서 운영할 때도 부담이 없다는 얘기에도 NATS를 생각하게 된 계기가 있었다.
📌 NATS JetStream vs Apache Kafka 비교표
| 항목 | NATS JetStream 🚀 | Apache Kafka 🏢 |
|---|---|---|
| 설치 및 운영 | 단일 바이너리로 간단한 배포 | Zookeeper 필요, 복잡한 설정 |
| 지연 시간 (Latency) | 낮음 (μs 단위) | 높음 (ms 단위) |
| 메시지 저장 | 필요할 때만 저장 (최적화) | 전체 로그 저장 (비효율적) |
| 확장성 | 간편한 확장 (클러스터 지원) | 브로커 & 파티션 확장 필요 |
| 메시지 보장 | At-Least-Once, Exactly-Once 없음 | At-Least-Once, Exactly-Once 지원 |
| 메시징 모델 | Pub/Sub, Queue 방식 (Push & Pull 지원) | Topic-Partition 방식 (Pull 기반) |
| 운영 비용 | 상대적으로 낮음 (리소스 효율적) | 디스크 및 네트워크 비용 높음 |
| 적합한 사용 사례 | 실시간 메시징, IoT, 마이크로서비스 | 빅데이터 분석, 로그 저장, 이벤트 스트리밍 |
- 추가적인 비교내용은 아래 참고자료 유튜브에서 확인했었다.
참고 자료
