핵심 요약
피크 8만 RPS Kafka 클러스터(9노드, Zookeeper 3, Schema Registry 2)를 NATS JetStream(3노드)으로 1년에 걸쳐 이관. 운영 인력 시간이 월 120h -> 36h로 70% 감소, 인프라 비용 53% 감소. 단, 분석 파이프라인(Flink·Spark) 호환과 초당 50만 메시지 이상 워크로드는 여전히 Kafka가 유리.
1. 왜 NATS인가
| 측면 | Kafka | NATS JetStream |
|---|
| 바이너리 | JVM+Zookeeper/KRaft | 단일 Go 바이너리(18MB) |
| 최소 노드 | 3+3 | 3 |
| 지연(p99) | 5~15ms | 0.8~3ms |
| 처리량 한계 | 매우 높음 | 중상 |
| KV·OBJECT | 별도 솔루션 | 내장 |
2. Stream과 Consumer 모델
nats stream add ORDERS \
--subjects "orders.>" \
--storage file \
--replicas 3 \
--retention limits \
--max-age 168h
nats consumer add ORDERS billing \
--filter "orders.paid.>" \
--ack explicit \
--max-deliver 5
3. 마이그레이션 전략
| 단계 | 방식 | 기간 |
|---|
| 1. 미러링 | kafka-to-nats bridge로 양쪽 동시 발행 | 2주 |
| 2. 컨슈머 이전 | 서비스별로 NATS 구독으로 교체 | 4개월 |
| 3. 프로듀서 이전 | 발행 측 교체, Kafka 폐기 | 3개월 |
4. KV 스토어
// Go
kv, _ := js.CreateKeyValue(ctx, jetstream.KeyValueConfig{
Bucket: "sessions",
TTL: 30 * time.Minute,
History: 5,
})
kv.Put(ctx, "user:42", []byte("token"))
watcher, _ := kv.Watch(ctx, "user:>")
for entry := range watcher.Updates() {
log.Println(entry.Key(), entry.Value())
}
5. 처리량 실측
| 시나리오 | JetStream | Kafka 9노드 |
|---|
| 단일 stream 발행 | 185K msg/s | 720K msg/s |
| p99 발행 지연 | 2.4ms | 11ms |
| p99 e2e | 3.8ms | 14ms |
| 월 인프라 비용 | $840 | $1,790 |
6. 운영 시간이 줄어든 진짜 이유
| 작업 | Kafka 월 시간 | NATS 월 시간 |
|---|
| 브로커 리밸런싱 | 14h | 0h |
| Zookeeper/KRaft 운영 | 22h | 0h |
| 토픽 파티션 설계 | 18h | 4h |
| 모니터링·알람 튜닝 | 12h | 6h |
| 스키마 호환성 | 20h | 8h |
7. 한계
1) Flink·Spark Streaming 네이티브 connector가 빈약. 2) Schema Registry 같은 정식 스키마 거버넌스 부재. 3) 처리량 한계 — 50만 msg/s 넘어가면 Kafka가 답. 4) Confluent급 매니지드 생태계 부재.
8. 적합·부적합 정리
| 워크로드 | 추천 |
|---|
| 마이크로서비스 이벤트 버스 | NATS |
| CDC + 데이터 레이크 | Kafka(Connect) |
| 로그 집계 100K+/s | Kafka |
| 엣지·IoT 다중 사이트 | NATS(leafnode) |
참고
- nats.io
- docs.nats.io/jetstream
- github.com/nats-io/nats-server
댓글 0