MessageQueue를 써야하는 이유 (+카프카 사용후기)

데이터 통신은 왜 안전하지 않을 수 있는가?

전통적인 데이터 통신방식은 동기적이다. 요청 - 응답 프로세스만 봐도 동기적인 것을 알 수 있다.
다만 이 방식에는 위험이 따른다.

왜? 수신부에서 서버가 트래픽을 대응하지 못하면 송신중이던 송신을 마저하는 데이터들은 유실될 수밖에 없다.

---

그럼 이것을 어떻게 해결할 수 있지?

Message Queue (MQ) 시스템을 이용하는 것이다.
MQ 시스템은 이러한 문제를 중간완충지대 개념으로 해결한다.
메시지를 서버간 바로 하지않고 중간지대를 통해 주고받는다.

이는 시스템의 결합성을 낮추고 통신을 비동기적으로 할 수 있게 한다.

---

동작원리

대표적으로
"생산자" -> "큐시스템" -> "소비자" 방식으로 동작한다.
이때 큐시스템이 위에 설명한 중간완충지대 라고 생각하면 된다.

핵심메커니즘

1. Queue (대기열): 메시지가 소비되기 전까지 안전하게 보관되는 저장소
2. Point-to-Point: 가장 기본적인 형태로, 하나의 메시지는 하나의 소비자에게만 전달됩니다.
   1. 다만 카프카의 경우 "어디까지 읽었어" 라는 오프셋 개념이 컨슈머별로 존재할 수 있다.
      따라서 하나의 토픽(큐시스템) 을 여러 목적으로 사용이가능하다.
   2. 예를 들면 소켓서버가 실시간으로 전달하면서 저장서버가 데이터를 저장하는?
   3. 다른 큐 시스템도 가능할수도
3. Publish/Subscribe (Pub/Sub): 생산자가 '주제(Topic)'에 메시지를 발행하면, 해당 주제를 구독하고 있는 모든 소비자에게 메시지가 전달됨. (카프카가 주로 사용하는 방식.)
4. Acknowledgment (Ack): 소비자가 메시지를 성공적으로 처리했다고 브로커에게 알리는 신호. 이 신호가 없으면 큐시스템은 유실하지 않고, 다시 보냄.

---

관련기술

기술	특징	주요 용도
RabbitMQ	전통적인 메시지 브로커. 복잡한 라우팅 지원이 강력함.	실시간 응답이 중요하고 복잡한 전달 로직이 필요한 경우
Redis (Pub/Sub)	인메모리 기반으로 속도가 매우 빠름.	데이터 휘발성이 있어도 괜찮은 가벼운 알림, 채팅
Amazon SQS	AWS에서 제공하는 관리형 서비스. 운영 부담이 적음.	클라우드 네이티브 환경의 단순 비동기 처리
Apache Kafka	대용량 데이터 스트리밍에 최적화. 디스크에 메시지를 저장함.	로그 수집, 실시간 분석, 대규모 트래픽 처리 (이 글의 최종 목적지)

Redis는 인메모리 방식이라 극강의 빠름

Apache Kafka 는 디스크 저장(다만 순차적으로저장해서 속도는 빠름) + 분산처리방식으로 대용량을 안정적으로 처리가 가능함.

---

그래서 대표적으로 대강 무엇을 사용해야할까?

레디스

실시간 채팅 알림, 가벼운 작업 큐, 메시지가 좀 유실되어도 서비스에 큰 타격이 없는 경우, 인프라 비용을 아끼고 싶은 경우.

카프카

결제 로그, 사용자 행동 분석 등 데이터 유실이 절대 안 되는 경우, 하루 수억 건 이상의 초고대용량 데이터가 발생하는 경우.

---

왜 많은기업이 카프카를 선택하는가?

• 압도적인 처리량 (Throughput): 카프카는 메모리가 아닌 디스크에 데이터를 순차적으로 기록합니다. 이 덕분에 초당 수백만 건의 데이터를 처리할 수 있습니다.
• 데이터의 영속성 (Persistence): 일반적인 MQ는 소비자가 가져가면 메시지를 삭제하지만, 카프카는 설정한 기간만큼 데이터를 보관합니다. 장애 발생 시 과거 데이터를 다시 불러와 복구(Replay)할 수 있다는 엄청난 장점이 있습니다.
• 분산 아키텍처: 여러 대의 서버(Broker)로 클러스터를 구성하여 확장성(Scalability)과 고가용성(Availability)을 보장합니다.

1. 압도적인 처리량 - 디스크에 데이터를 순차적으로 기록함.
2. 영속성 - 카프카는 소비됐다고 사라지지 않음. 장애 발생 시 다시 읽는게 가능하다.
3. 분산아키텍처 - 여러 대의 서버로 클러스트럴 구성하여 확장성, 고가용성을 챙긴다.

---

MQ를 사용하면서 멱등성을 더 고려해야 하는 이유

메시지 큐를 왜 이용하느냐? 하면 유실도 하기싫고, 장애시 재전송하고.. 이런 이유
하지만 이래서 메시지가 두번가기도 한다.
카카오톡을 예로들면 "언제와?" 가 두번가는 느낌?

이런 경우에는 멱등성 처리를 개발자가 해줘야하는데 그 중 한가지 방법은
message_id 같은 항목을 같이보내서 중복처리를 하는 방법이 있다.

---

프로젝트 카프카 사용후기

결론은 매우 비싸고🥰, 매우 좋다🥰

 

마지막 프로젝트에서 대용량 로그처리를 위해 카프카를 사용했었는데
사실.. 고민이 많이 필요한 트러블이 없었다.

그저 토픽설계 잘하고, 배치처리만 해준다면 적어도 카프카가 데이터를 처리할때 문제가 되진 않았다.

 

그래서 프로젝트 마무리하고 따로 MQ를 공부하는 과정에서
너무 황금칼을 쥐고 한 것 같아 아쉽다.

 

그때의 판단기준은 "인프라 구성과 대용량처리가 2주안에 가능한가" 였고,
일단 해놓고 보자 라는 마음에 황금칼을 선택한 것 같다.

 

지나고보면 RabbitMQ나 서버를 띄워 다른 큐시스템을 구축해볼수도 있었고,
그런과정들을 통해 Kafka가 장점을 더 체감할 수 있었다고 생각한다.

 

돈낭비를 한 가장 큰 이유는 테스팅환경을 고려안한 점이다.
배포도 안한시점에서 End to End 를 할 때는 유실을 고려안해도되기 때문에 그냥 바로 보냈어도 됐었고, 혹은다른 큐시스템을 써도되고..
대용량 테스트 할 때만 켜놔도 됐는데 그런지점을 고민안한 것이 돈낭비에 가장 큰 원인이 됐다.

 

앞으로 이 부분에 더 깊이 파볼 기회가 있다면
AWS에서 제공하는 카프카 말고, 직접 카프카 시스템을 구축해보고 싶다.

 

그래도 AWS 140만원 가량 크레딧을 제공해주고,
이런 경험을 하게 해준 정글에 감사함을 느낀다.