사이드 프로젝트로 STOMP 기반 채팅 시스템을 개발했다.
먼저 메인 서버와 채팅 서버를 분리하여 구축했는데, 실제 운영 환경에서 채팅 서버를 스케일 아웃(Scale Out)해야 할 경우에도 메시지가 실시간으로 전달되는지 궁금했다.
테스트해 본 결과, 분산된 채팅 서버 간에는 메시지 동기화가 이루어지지 않아 다른 사용자에게 채팅이 표시되지 않는 문제가 발생했다.

그 이유는 인메모리(Simple) 브로커 사용했기 때문이다.
Spring WebSocket의 기본 STOMP 브로커(enableSimpleBroker)는 서버 인스턴스 내 메모리 위에서만 동작한다. 따라서 한 노드에서 받은 메시지는 그 노드의 메모리 구독자에게만 전달되고 다른 노드에 연결된 클라이언트는 전혀 모르게 된다.

따라서 외부 브로커를 사용해야했는데 나는 Kafka를 도입해보기로 마음 먹었다.

채팅 시스템에서 Kafka를 선택한 이유

Kafka, RabbitMQ, Redis Pub/Sub 중에 진짜 오랜시간 고민을 했었다. 처음에는 RabbitMQ를 사용하려고 했지만 시간이 지날수록 Kafka를 사용하기로 마음 먹었다. 처음에 RabbitMQ를 사용하려고 한 목적은 낮은 처리량과 짧은 지연시간이라는 장점을 가지고 있었기 때문이다.

Redis Pub/Sub는 메모리 기반으로 빠른 성능을 제공하지만, 메시지 유실 가능성이 너무 컸기 때문에 처음부터 후보에서 제외했다. 이는 화상 회의나 스트리밍 같은 용도에는 적합하겠지만, Slack이나 카카오톡 같은 채팅 시스템에서는 사용자가 잠시라도 연결이 끊겼을 때 놓친 메시지를 복구할 수 없는 치명적인 단점이 존재했다.

RabbitMQ는 설정이 간편하고 AMQP 프로토콜 덕분에 빠르게 시작할 수 있으며, 디스크 쓰기 없이 메모리만으로 메시지를 주고받을 때 지연시간이 매우 짧다는 장점이 있었다. 사이드 프로젝트라 유저가 몇백 명 수준일 것이라 예상해 “과도한 트래픽이나 복잡한 파티셔닝 없이도 충분히 커버할 수 있겠다”고 판단했지만, 실제로 대용량 메시지 처리 시 처리량의 한계가 명확하다는 것을 알게되었다. k6로 부하를 걸어보면 장애가 발생할 것이 분명했고, 메시지가 과도하게 쌓일 경우 메모리 부족으로 시스템 전체 안정성이 위협받는 문제도 우려되었다.

따라서 높은 처리량, 메시지 유실 방지, 안정적인 스케일 아웃을 모두 충족하는 Kafka를 도입하게 되었다.

📌 카프카(Kafka)

카프카(Kafka)는 분산 스트리밍 플랫폼으로, 대량의 데이터를 처리하고 실시간으로 전송하는 데 사용된다. 모든 데이터는 로그 형식으로 파일 시스템에 기록된다. 여기서 말하는 로그는 추가만 가능하며, 시간순으로 완전히 정렬된 데이터의 흐름(레코드 시퀀스)을 의미한다. 로그를 한곳에 모아 처리할 수 있도록 중앙집중화되어 있으며, 대용량 데이터를 수집하고 실시간 스트리밍으로 소비가 가능하다.

우선 메세지/이벤트 브로커와 메세지 큐를 아는게 더 좋다고 판단해서 정리 할려고 한다.

메세지 큐 (Message Queue, MQ)

메시지 큐(MQ)는 메시지 지향 미들웨어(MOM : Message Oriented Middleware)를 구현한 시스템으로 프로그램(프로세스) 간의 데이터를 교환할 때 사용하는 기술을 의미한다.

• Producer: 메시지를 보내는 주체

• Consumer: 메시지를 받는 주체

• Queue: 메시지를 차례로 보관했다가 전달하는 대기줄

🤔 메세지 지향 미들웨어(MOM)??

• 응용 소프트웨어 간의 비동기적 데이터 통신을 위한 소프트웨어
• 생산자(producer)는 메시지를 보내고, 소비자(consumer)는 필요할 때 꺼내 처리
• 즉, 비동기적(Asynchronous) 방식을 이용해서 프로세스간의 데이터를 주고 받는 기능을 위한 시스템

메세지 브로커(Message Broker) / 이벤트 브로커(Event Broker)

메시지 브로커(Message Broker)

애플리케이션 간에 “메시지”를 안전하게 전달해 주는 중개자
메세지 지향 미들워어(Message-Oriented Middleware)를 구현하는데 사용되는 시스템

• 생산자(producer)가 보낸 메시지를 받아서
• 큐(Queue)나 토픽(Topic)에 저장해 두었다가
• 소비자(consumer)에게 전달해 준다.
  → 주로 비동기 작업 분산, 장애나 트래픽 급증 시에도 신뢰성 있게 처리할 때 사용한다.
  -> 이러한 구조를 보통 pub/sub구조라고 하며 대표적으로는 Redis, RabbitMQ가 있다.

이벤트 브로커(Event Broker)

시스템에서 발생한 “이벤트(사건)”를 발행(publish)하고,
관심 있는 소비자(Subscriber)에게 실시간으로 전파해 주는 중개자

• 이벤트는 과거 히스토리를 로그로 남겨 재생(replay)도 가능
• 이벤트 스트리밍(Event Streaming) 플랫폼(예: Kafka, Pulsar) 형태로 많이 구현
  → 마이크로서비스나 이벤트 기반 아키텍처에서 서비스 간 느슨한 결합과 실시간 반응을 위해 사용한다.

메시지 브로커는 이벤트 브로커가 될 수 없지만, 이벤트 브로커는 메시지 브로커 역할을 할 수 있다.

특성	메시지 브로커	이벤트 브로커
데이터 처리	메시지 처리 후 삭제	이벤트 영구 저장 가능
재처리	제한적	이벤트 재생 가능
확장성	상대적으로 제한적	높은 확장성
용도	비동기 작업 처리	실시간 스트림 처리
결합도	상대적으로 높음	낮은 결합도

Pub/Sub 구조

1. 이벤트(메시지)를 발행하는 Publisher가 존재하며, Publisher는 특정 Channel(혹은 Topic)에 이벤트를 전송한다.
2. 특정 Channel(혹은 Topic)을 구독하는 Subscriber가 존재하며, Publisher에 관계없이 발행된 이벤트를 받을 수 있다.

카프카를 구성하는 주요 요소

• 이벤트(Event) : Kafka 을 통해 Producer 와 Consumer 가 데이터를 주고받는 단위, 메세지

• 카프카 클러스터(Kafka Cluster): Kafka Broker 들의 모임, Kafka 는 확장성과 고가용성을 위하여 Broker 들이 클러스터로 구성
  -> 여러개의 Kafka Broker 로 운영을 하면 동시에 더 많은 데이터를 처리할 수 있으며, 필요에 따라 Broker 을 추가 가능
  -> 클러스터 내 한 Broker에 장애가 발생해도 다른 Broker가 파티션 리더를 자동으로 승격해 무중단 운영이 가능

• 브로커(Broker) : 각각의 Kafka 서버, 동일 노드에 여러 브로커 가능
  -> 실행된 Kafka 서버를 말하며, Kafka 그 자체

• 프로듀서(Producer): Kafka에 이벤트(메시지)를 발행(Publish)하는 역할을 하는 클라이언트

• 컨슈머(Consumer): 특정 토픽(Topic)을 구독(Subscribe)하고, 그 안에 담긴 이벤트를 받아 처리하는 클라이언트

• 토픽(Topic) : Kafka에서 메시지를 분류하고 저장하는 논리적인 공간, 파일시스템의 폴더와 유사

• 파티션(Partition) : Topic은 여러 Broker에 분산되어 저장되며, 이렇게 분산된 topic을 partition이라고 함
  -> 토픽을 여러 개로 나눈 작은 단위

• 오프셋(offset) : 컨슈머에서 메세지를 어디까지 읽었는지 저장하는 값
  -> 컨슈머 그룹의 컨슈머들은 각각의 파티션에 자신이 가져간 메시지의 위치 정보(offset) 을 기록
  -> 컨슈머 장애 발생 후 다시 살아나도, 전에 마지막으로 읽었던 위치에서부터 다시 읽기 가능

쉽게 정리하기

이벤트(Event) = 우편물(편지·소포)

• Kafka에서는 “이벤트”가 데이터를 담은 최소 단위
• “우편물(편지·소포)”에 해당
• 보낼 사람(Producer)이 내용을 담아 발송하고, 받을 사람(Consumer)이 열어보는 단위

토픽(Topic) = 우체통

• Kafka에서 메시지를 분류·저장하는 논리적인 공간
• “우체통”에 해당
• 프로듀서가 이벤트를 넣고, 컨슈머가 구독해 꺼내 읽음
• 예를 들어, chat-messages는 채팅 전용 우체통, order-events는 주문 전용 우체통이라고 생각

파티션(Partition) = 우체통 속 번호 붙은 칸

• 하나의 토픽을 여러 개의 작은 단위로 나눈 것
• “우체통 속 번호 붙은 칸”에 해당
• 하나의 우체통(Topic)은 여러 칸(Partition)으로 나뉘어 있고,
• 같은 roomId(키)를 가진 이벤트는 항상 같은 칸에 들어가 순서 보장
• 칸마다 번호(Partition 0,1,2…)가 붙어 있고, 같은 우편번호(roomId) 로 보낸 편지는 언제나 같은 칸에 들어가도록 설계
• 그래서 그 칸 안에서는 들어온 순서대로 편지가 보관되어 순서가 보장

브로커(Broker) = 우체국 지점

• Kafka 서버 하나를 가리키는 용어
• “우체국 지점” 과 같음
• 클러스터 내에서 파티션 리더 역할을 수행

클러스터(Cluster) = 우체국 지점들이 모인 전국망

• 여러 브로커가 모여 구성된 집합
• “전국 우체국 네트워크”에 해당
• 한 지점(브로커) 장애 시에도 다른 지점이 대신 처리

프로듀서(Producer) = 편지 부치는 사람

• Kafka에 이벤트를 발행(Publish)하는 클라이언트
• “편지 부치는 사람” 역할
• 토픽과 키(roomId)를 지정해 메시지 전송

컨슈머(Consumer) = 우체통에서 편지 꺼내 읽는 사람

• 특정 토픽을 구독(Subscribe)하고 이벤트를 처리하는 클라이언트
• “우체통에서 편지 꺼내 읽는 사람” 역할
• 같은 컨슈머 그룹 내에서 파티션을 나눠 읽어 병렬 처리

카프카 Pub/Sub 구조

위에서 작성한 Pub/Sub 구조랑 매우 유사하게 작동한다. Producer는 Topic에 이벤트를 보내고, 이 이벤트는 Topic의 각 Partition에 분산되어 저장된다. 특정 Topic을 구독하고 있는 Consumer Group내의 Consumer는 각각 1개 이상의 Partition 으로 부터 이벤트를 가져온다. 만약 Partition 갯수보다 Consumer가 많다면, 아무것도 안하는 Consumer가 많아질 가능성이 존재하기 때문에 항상 Partition 수를 Consumer보다 같거나 크게 해주는 것이 좋다.

Topic의 Partition

왜 Topic은 여러개의 Partition 으로 나눌까?
카프카의 토픽에 메세지가 쓰여지는 것도 어느정도 시간이 소비되는데 만약 몇 천건의 메세지가 동시에 카프카에 write 되면 병목현상이 발생할 것이다. 따라서 여러개의 Partition으로 나누어 처리하면 장점이 많다.

나 같은 경우 단일 토픽에 5개의 파티션을 두었다.

roomId	hash(roomId) % 5	파티션	설명
101	1	1	101 해시 결과가 1 → 파티션 1에 저장
202	2	2	202 해시 결과가 2 → 파티션 2에 저장
303	3	3	303 해시 결과가 3 → 파티션 3에 저장
404	4	4	404 해시 결과가 4 → 파티션 4에 저장
505	0	0	505 해시 결과가 0 → 파티션 0에 저장
606	1	1	606 해시 결과가 1 → 파티션 1에 저장

• 처리량 확장(Scalability): 하나의 파티션만 쓰면 처리 용량이 제한되지만, 5개의 파티션으로 나누면 동시에 5개 쓰기·읽기 작업을 병렬로 할 수 있다.
• 병렬 소비(Parallelism): 컨슈머 그룹에서 각 파티션을 다른 컨슈머가 맡아 읽기 때문에 처리 속도가 빨라진다.
• 순서 보장(Ordering): 같은 roomId 같은 파티션(예: 해시 결과로 파티션 1)에 모아 순차적으로 처리가 가능하다.
• 장애 격리(Fault Isolation): 특정 파티션이 있는 브로커가 장애 나도, 나머지 파티션은 계속 동작해 전체 서비스 가용성을 높일 수 있다.

Kafka 프로듀서는 기본적으로 키(key)가 없는 메시지를 보낼 때, 설정된 파티션 수를 기준으로 라운드 로빈(Round‑Robin) 방식으로 순차 할당한다. 따라서 하나의 파티션 내에서는 메세지 순서가 보장되지만, 파티션이 여러개일 경우에는 순서가 보장않는다.

나는 키(key) 기반 파티셔닝을 사용하면, 프로듀서가 메시지를 보낼 때 roomId를 키로 지정한다.
즉, “키를 roomId로 설정했다”는 건, 동일한 방의 메시지끼리 전용 파티션에 모아 순서를 보장하라는 뜻이다.

하지만 다만, 한번 늘린 파티션은 절대 줄일 수 없기 때문에 처음에 많은 고민을 하고 설계를 해야한다.

컨슈머 그룹(Consumer Group)

• 카프카의 개별 Consumer 인스턴스를 하나로 묶는 논리적 그룹 단위
• 만약 Consumer1 에 장애가 발생하더라도 동일 Consumer Group에 있는 Consumer 들이 처리 가능하게 함

Partition	할당된 Consumer
0	Consumer 1
1	Consumer 2
2	Consumer 3
3	Consumer 4
4	Consumer 5

• 각 파티션은 Consumer Group 내 하나의 Consumer에게만 할당됨 → 병렬 처리가 가능. 처리 속도 향상

• 같은 Consumer Group에 속한 컨슈머들은 중복 없이 데이터 소비

• 만약 Consumer 수 > Partition 수면, 일부 Consumer는 놀게 됨

• Consumer Group이 다르면 모든 그룹이 독립적으로 동일 데이터 소비 가능

• 한 개의 Consumer는 여러 개의 토픽을 처리 가능

STOMP + Kafka

이번 프로젝트에서 나는 실시간으로 채팅 할 수있는 시스템을 만들어볼려고 했다. 따라서 아직 개념은 부족하지만 그래도 성공(?)은 했으니 기록해볼려고 한다. 아마 잘못된 부분도 많아서 차후에 수정을 해야할 것 같다.

WebSocket/STOMP

@Configuration
@RequiredArgsConstructor
@EnableWebSocketMessageBroker
public class WebSocketConfig implements WebSocketMessageBrokerConfigurer {

  private final StompHandler stompHandler;

  @Override
  public void configureMessageBroker(MessageBrokerRegistry registry) {
    registry.setApplicationDestinationPrefixes("/send");
  }

  @Override
  public void registerStompEndpoints(StompEndpointRegistry registry) {
    registry
        .addEndpoint("/ws-stomp")
        .setAllowedOriginPatterns("http://localhost:3000")
        .withSockJS();
  }

  @Override
  public void configureClientInboundChannel(ChannelRegistration registration) {
    registration.interceptors(stompHandler);
  }
}

스프링 내장 메모리 브로커인 simpleBroker("/topic") 설정은 제거하였다. 이제 메시지 브로커로서 스프링의 기본 Simple Broker 대신 Kafka를 사용하기 때문이다. Kafka를 통해 메시지를 발행(Publish)하고 구독(Subscribe)하는 구조로 전환함에 따라, 더 이상 enableSimpleBroker() 설정이 필요하지 않다.

• 클라이언트가 SockJS(STOMP)로 /ws-stomp 엔드포인트에 연결하도록 설정
• 클라이언트가 서버로 메시지를 보낼 때 URL 앞에 /send를 붙이도록 지정

KafkaProducerConfig

@Configuration
public class KafkaProducerConfig {

  @Value("${spring.kafka.bootstrap-servers}")
  private String bootstrapServers;

  public Map<String, Object> producerConfig() {
    Map<String, Object> props = new HashMap<>();
    props.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, bootstrapServers);
    props.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class);
    props.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, JsonSerializer.class);
    return props;
  }

  @Bean
  public ProducerFactory<String, ChatRequest> chatRequestProducerFactory() {
    return new DefaultKafkaProducerFactory<>(
        producerConfig(),
        new StringSerializer(),
        new JsonSerializer<ChatRequest>()
    );
  }

  @Bean
  public KafkaTemplate<String, ChatRequest> chatRequestKafkaTemplate(
      ProducerFactory<String, ChatRequest> chatRequestProducerFactory) {
    return new KafkaTemplate<>(chatRequestProducerFactory);
  }
}

• bootstrapServers(application.yml의 spring.kafka.bootstrap-servers)를 통해 Kafka 클러스터 주소를 지정
• 메시지 키는 문자열(StringSerializer), 값은 JSON 형태(JsonSerializer)로 직렬화
• ChatRequest 객체를 value로 보내기 위한 ProducerFactory와 KafkaTemplate 생성
• 내부적으로 JsonSerializer가 DTO를 JSON으로 변환하며, StringSerializer가 키(roomId)를 직렬화

KafkaProducer

@Component
@RequiredArgsConstructor
public class KafkaProducer {

  private final KafkaTemplate<String, ChatRequest> chatRequestKafkaTemplate;

  public void send(String topic, String roomId, ChatRequest message) {
    chatRequestKafkaTemplate.send(topic, roomId, message);
  }
}

• Kafka 메시지를 한 곳에서 보낼 수 있도록 설계된 래퍼

ChatController

@Controller
@RequiredArgsConstructor
public class ChatController {

  private final KafkaProducer kafkaProducer;

  @MessageMapping("/chat/{roomId}")
  public void sendChat(
      ChatRequest incoming,
      @DestinationVariable("roomId") Long roomId,
      Principal principal
  ) {
    ChatMemberDetails userDetails = getUserDetails(
        (UsernamePasswordAuthenticationToken) principal);
    Long memberId = userDetails.getMemberId();
    String userName = userDetails.getNickName();

    ChatRequest enriched = createChatRequest(incoming, memberId, userName);

    kafkaProducer.send(
        "chat-messages",
        roomId.toString(),
        enriched
    );
  }

1. 클라이언트 → WebSocket 전송

• 프론트엔드에서 /send/chat/{roomId}로 STOMP 메시지를 보낸다.
• 메시지는 WebSocket을 통해 @MessageMapping("/chat/{roomId}")에 도달한다.
• @DestinationVariable("roomId") Long roomId : 경로의 {roomId} 값을 추출하여 채팅방 식별자로 사용

2. Spring Controller 수신

• Kafka로 비동기 전송
• kafkaTemplate.send("chat-messages", roomId, enriched) 호출
• “chat-messages” 토픽에 키를 방번호(roomId)로 지정 보낸다.
• 다른 서버나 서비스(또는 같은 어플리케이션 내 Kafka 리스너)가 이 메시지를 받아 실제 DB 저장, WebSocket 브로드캐스트 등을 처리하게 된다.

KafkaConsumerConfig

@Configuration
public class KafkaConsumerConfig {

@Value("${spring.kafka.bootstrap-servers}")
private String bootstrapServers;

public Map<String, Object> consumerConfig(String groupId) {
  Map<String, Object> props = new HashMap<>();
  props.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, bootstrapServers);
  props.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class);
  props.put(ConsumerConfig.AUTO_OFFSET_RESET_CONFIG, "latest");
  props.put(ConsumerConfig.GROUP_ID_CONFIG, groupId);
  return props;
}

@Bean
public ConsumerFactory<String, ChatRequest> chatRequestConsumerFactory() {
  JsonDeserializer<ChatRequest> deserializer = new JsonDeserializer<>(ChatRequest.class);
  deserializer.addTrustedPackages("yuhan.pro.chatserver.domain.dto");
  String chatGroup = "${spring.application.name}-${random.uuid}";
  return new DefaultKafkaConsumerFactory<>(
      consumerConfig(chatGroup),
      new StringDeserializer(),
      deserializer
  );
}

@Bean(name = "chatMessageFactory")
public KafkaListenerContainerFactory<ConcurrentMessageListenerContainer<String, ChatRequest>> factory(
    ConsumerFactory<String, ChatRequest> chatRequestConsumerFactory) {
  ConcurrentKafkaListenerContainerFactory<String, ChatRequest> factory =
      new ConcurrentKafkaListenerContainerFactory<>();
  factory.setConsumerFactory(chatRequestConsumerFactory);
  factory.setConcurrency(5);
  return factory;
}

• bootstrapServers: application.yml 등에 정의된 Kafka 클러스터 주소

• 키 역직렬화: 메시지 키를 StringDeserializer로

• 오프셋 리셋: 컨슈머 시작 시에 latest로 설정해, 가장 마지막(최신) 메시지부터 읽기
  -> earliest는
  컨슈머가 처음 합류하거나 유효한 오프셋이 없을 때, 토픽의 가장 처음부터(가장 오래된 메시지) 읽기 시작

  상황	권장 설정
  실시간 데이터 처리만 중요하고 과거 이력은 필요 없을 때	latest
  서비스 초기화 시 토픽 전체 이력을 로드하면서 상태를 구축할 때	earliest
  이미 처리된 메시지가 다시 재처리되는 것을 피하고 싶을 때	latest
  재시작 시에도 과거 처리하지 못한 메시지부터 이어서 처리하고 싶을 때	earliest

• 그룹 아이디: 파라미터로 받은 groupId를 사용해, 컨슈머 그룹을 동적 생성

• JsonDeserializer: JSON으로 직렬화된 ChatRequest 메시지를 DTO로 역직렬화

• addTrustedPackages: 역직렬화 가능한 패키지 범위를 지정해 보안 강화
• 동적 그룹 ID: ${spring.application.name}에 랜덤 UUID를 붙여 컨슈머 그룹을 고유하게 생성
  -> 각 애플리케이션 인스턴스가 토픽의 모든 메시지를 빠짐없이 받아야하기 때문에 서버마다 고유하게 컨슈머 그룹을 생성하게 했다.

• DefaultKafkaConsumerFactory: 위 프로퍼티와 키/값 역직렬화기를 조합해 팩토리 객체 생성

KafkaListeners

@Slf4j
@Component
@RequiredArgsConstructor
public class KafkaListeners {

private final SimpMessageSendingOperations messagingTemplate;
private final ChatService chatService;

@KafkaListener(
    topics = "chat-messages",
    groupId = "${spring.application.name}-${random.uuid}",
    containerFactory = "chatMessageFactory"
)
public void handleChatMessage(
    ChatRequest message,
    @Header(KafkaHeaders.RECEIVED_PARTITION) int partition,
    @Header(KafkaHeaders.RECEIVED_KEY) String roomId
) {
  try {
    log.info("Kafka 수신 - roomId: {}, partition: {}, message: {}", roomId, partition, message);
    messagingTemplate.convertAndSend("/topic/rooms/" + roomId, message);
    chatService.saveChat(message, Long.valueOf(roomId));
  } catch (Exception e) {
    log.error("Kafka 메시지 처리 오류", e);
  }
}

• topics = "chat-messages"
  → 이 리스너 메서드는 chat-messages 토픽에 발행된 모든 메시지를 구독

• groupId = "${spring.application.name}-${random.uuid}"
  → 인스턴스별(혹은 세션별)로 고유한 컨슈머 그룹을 만들어, 각 애플리케이션 인스턴스가 모든 메시지를 독립적으로 받아 처리하도록 보장

• containerFactory = "chatMessageFactory"
  → KafkaConsumerConfig에서 설정한 ConcurrentKafkaListenerContainerFactory<String, ChatRequest> 빈을 사용해, JSON → ChatRequest 역직렬화와 병렬성 설정(Concurrency = 5)을 적용

• @Header(KafkaHeaders.RECEIVED_KEY) String roomId

  kafkaProducer.send("chat-messages", roomId.toString(), enriched);

  -> 이 값은 프로듀서(여기서는 kafkaProducer.send(…, roomId, enriched))에서 메시지를 보낼 때 지정한 키(key) 와 동일

• @Header(KafkaHeaders.RECEIVED_PARTITION) int partition
  -> 키 기반 파티셔너를 쓰고 있다면(기본 파티셔너는 키의 해시값을 사용) 같은 키(roomId)에 대해 항상 동일한 파티션을 선택

• WebSocket 브로드캐스트
  messagingTemplate.convertAndSend("/topic/rooms/" + roomId, message)
  → STOMP 구독 경로 /topic/rooms/{roomId}로 들어와 있는 모든 WebSocket 클라이언트에게 ChatRequest를 전송

  현재 나는 단일 브로커(브로커 1개)를 사용 중이지만 만약 단일 브로커가 다운되면 클러스터 전체가 마비된다. 따라서 보통 브로커 수를 늘려 3대 정도로 운영하는 것이 일반적이다. 하지만 이 프로젝트는 사이드 프로젝트로 개발 단계에 있어, 편의상 Kafka 브로커를 단일 인스턴스(복제 팩터=1)로만 운영하고 있다.

  

참고:

• Message Brokers: Publish Subscribe Communication for Systems Design
• 우리 팀은 카프카를 어떻게 사용하고 있을까
• what-is-message-queuing
• [서버] Kafka 에 대해서
• PUB/SUB, 잘 알고 쓰자!
• What is a consumer group in Kafka?
• Topics, Partitions, and Offsets in Apache Kafka