서문

이 책은 NATS의 기초를 다루는 입문서가 아닙니다. 이미 기본적인 Pub/Sub 큐(Kafka, RabbitMQ, SQS 등) 시스템을 써봤거나, NATS를 실무에 도입해 '아키텍처 고도화'를 고민하는 2~5년 차 백엔드 엔지니어를 위한 '실무 패턴 가이드'입니다.

특히, pub/sub 모델의 기본을 알고 있다고 가정하고 설명하고 있습니다. kafka와 같은 메세지 브로커를 이전에 다뤄보았지만 nats가 처음이시라면 아래 3가지만 기억하고 본문으로 넘어가주세요! (더 상세한 개념 설명은 공식 문서의 기본 튜토리얼을 참고하시는 것을 권장합니다.)

• Subject (주제): 메세지가 전달되는 '단체 채팅방 이름'입니다. (Kafka의 Topic과 같습니다.)
• JetStream (제트스트림): 원래 NATS는 메세지를 던지고 잊어버리는 휘발성(In-memory)이지만, JetStream을 켜면 메세지를 하드디스크에 기록해 줍니다. (Kafka처럼 '영속성'을 가지게 해주는 저장소 엔진입니다.)
• Consumer (소비자) & Queue Group: 단톡방에 올라온 일을 처리하는 '일꾼'입니다. 인스턴스가 3대 떠 있을 때 셋 다 똑같은 알림을 보내면 안 되겠죠? 큐 그룹으로 묶어두면 3명 중 딱 1명만 메세지를 가져가서 처리합니다. (RabbitMQ의 Worker Queue, Kafka의 Consumer Group과 동일한 역할입니다.)

1. 들어가며: 우리는 왜 Redis를 포기했는가?

메신저나 알림 서비스를 개발할 때 '30분 뒤 알림 발송' 같은 예약 기능은 필수적입니다.

당시 NATS 기반의 메신저 서비스를 개발하고 있던 저에게, 이 기능을 구현하기 위한 가장 직관적이고 흔한 선택지는 단연 Redis였습니다. Redis의 ZSET(Sorted Set) 데이터 구조를 사용하면 예약 시각을 기준으로 데이터를 오름차순 정렬하여 아주 쉽게 예약 발송 시스템을 구축할 수 있으니까요.

하지만 문제는 '운영 비용'이었습니다.

새로운 인프라가 추가된다는 것은 곧 인프라 팀의 관리 포인트가 늘어난다는 것을 의미했습니다. 특히 장애 상황을 대비해 Redis의 데이터 보존 및 복구 전략(RDB/AOF 등)까지 새롭게 수립해야 하는 점은 큰 부담으로 다가왔습니다.

"그럼 그냥 쓰던 데이터베이스(MySQL)를 쓰면 안 되나?"

물론 DB에 저장해두고 Polling(주기적 조회) 방식으로 가져올 수도 있습니다. 하지만 트래픽이 몰리는 메신저 서비스 특성상, 1초마다 DB에 쿼리를 날리는 것은 DB 부하를 급격히 높이는 최악의 선택이었습니다.