항해+ 백엔드 코드 9주차 회고 : Kafka 메세지 큐

항해 20만원 할인 추천인코드: NYFKU8 

 

이번 주 과제는 기존에 구현된 이벤트 기반 로직을 Kafka 메세지 큐를 활용하여 리팩토링 하는 과제였습니다.

 

Kafka는 대규모 실시간 데이터 스트리밍을 위한 분산 메시징 시스템으로, 높은 처리량과 안정성을 제공하는 것이 특징입니다. 특히 이벤트 기반 아키텍처에서 서비스 간 결합도를 낮추고, 장애가 발생했을 때에도 메시지를 안정적으로 처리할 수 있도록 설계되어 있습니다

 

Kafka Overview

• Producer & Consumer
  • Producer는 메시지를 Kafka 브로커에 발행하는 주체입니다.
  • Consumer는 브로커에 적재된 메시지를 읽어오는 서비스입니다.
  • Consumer는 메시지의 처리 위치를 추적하기 위해 offset을 사용하며, 이를 커밋하여 재처리나 누락을 방지합니다.
• Broker
  • Kafka 서버의 단위로, Producer의 메시지를 받아 디스크에 저장하고 Consumer 요청에 따라 전달합니다.
  • 클러스터 내부에서는 Controller(장애 브로커 감지 및 리더 파티션 재분배), Coordinator(컨슈머 그룹 모니터링 및 파티션 재할당) 같은 역할을 수행합니다.
• Topic & Partition

  

  • 메시지는 토픽 단위로 분류되고, 각 토픽은 여러 개의 파티션으로 나뉩니다.
  • 파티션을 활용하면 병렬 처리가 가능해 대용량 트래픽을 빠르게 처리할 수 있으며, 같은 파티션 내에서는 순차성이 보장됩니다.
  • 메시지 키를 활용하면 특정 자원(ID 등)에 대해 순서가 중요한 이벤트는 순차성을 보장할 수 있습니다.
• Consumer Group

  

  • 하나의 토픽을 여러 서비스가 구독할 수 있도록 그룹화한 개념입니다.
  • 같은 토픽의 메시지를 결제 서비스, 상품 서비스 등 여러 애플리케이션이 동시에 처리할 수 있으며, 그룹 내에서 파티션은 컨슈머에게 분배됩니다.
• Rebalancing
  • 새로운 Consumer가 추가되거나 장애가 발생했을 때 파티션의 소유권을 재분배하는 과정입니다.
  • 단, 리밸런싱이 일어나는 동안에는 메시지 처리가 중단되므로 주의가 필요합니다.
• Cluster & Replication
  • Kafka는 고가용성을 위해 여러 Broker를 묶어 클러스터를 구성합니다.
  • 각 파티션은 리더(Leader) Replica와 팔로워(Follower) Replica를 두어 장애 시에도 안정성을 확보합니다.

 

STEP 17 카프카 기초 학습 및 활용

• 실시간 주문정보(이커머스) & 예약정보(콘서트)를 카프카 메시지로 발행하도록 변경합니다.
  • 카프카에 대한 기초 개념을 학습하고 문서로 작성합니다.
    • 로컬에서 카프카를 설치하고 기본적인 기능을 수행해봅니다.
    • 어플리케이션에서 카프카를 연결하여 Producer & Consumer를 동작시켜봅니다.

STEP 18 카프카를 활용하여 비즈니스 프로세스 개선

• 각 프로젝트의 대용량 트래픽 프로세스를 카프카를 활용하도록 변경해봅니다.
• 개선한 내용에 대한 설계 문서(비즈니스 시퀀스 다이어그램, 카프카 구성 등)를 작성합니다.

 

• Step17 PR
• Step18 PR

Step18 by seuthootDev · Pull Request #19 · seuthootDev/hanghae-plus-backend

 

Step17 by seuthootDev · Pull Request #18 · seuthootDev/hanghae-plus-backend

회고

Kafka를 적용하면서 단순한 메시지 큐를 넘어 대용량 트래픽 처리와 서비스 간 책임 분리에 강점이 있다는 걸 느꼈습니다. 파티션과 Consumer Group 설계가 성능과 직결된다는 점이 인상 깊었고, 리밸런싱과 같은 운영 이슈도 고민할 필요가 있다는 걸 배웠습니다.