Apache Kafka와 이벤트 기반 아키텍처

앞 글에서는 NestJS와 gRPC로 서비스 사이의 동기 통신을 구현했습니다. 이 글에서는 비동기 통신과 이벤트 기반 아키텍처(EDA)의 핵심 요소인 Apache Kafka를 NestJS에 적용합니다.

동기 통신은 요청-응답 패턴에 잘 맞지만, 서비스 사이의 결합을 강하게 만들고 한 서비스의 장애가 다른 서비스로 번질 위험이 있습니다. 대량의 이벤트를 처리하거나 실시간 데이터 파이프라인을 만들 때도 효율이 떨어집니다.

Apache Kafka는 이벤트를 파티션 로그에 보관하고, 이벤트를 만드는 쪽과 읽는 쪽의 처리 시점을 떼어 놓는 분산 스트리밍 플랫폼입니다. 실제 처리량과 장애를 견디는 범위는 파티션 수, 복제, 승인 설정, 보관 정책과 실행 환경에 따라 달라집니다.

이벤트 기반 아키텍처와 Kafka

이벤트 기반 아키텍처(EDA, Event-Driven Architecture)는 구성 요소들이 서로를 직접 호출하는 대신, 이벤트를 발행하고 구독하는 방식으로 상호작용하는 아키텍처 스타일입니다. 각 서비스는 관심 있는 이벤트를 구독하고, 그 이벤트가 발생하면 필요한 작업을 수행합니다.

• 느슨한 결합(loose coupling): 서비스들이 서로를 직접 호출하지 않으므로 한 서비스의 변경이 다른 서비스에 미치는 영향이 줄어듭니다.
• 확장성: 이벤트를 만드는 쪽과 읽는 쪽을 각각 독립적으로 확장할 수 있습니다.
• 복원력(resilience): 이벤트가 브로커에 기록되고 보관 기간 안에 남아 있다면, 소비자가 잠시 멈췄다가 다시 읽어 처리할 수 있습니다.
• 비동기 통신: 응답을 바로 기다리지 않으므로 오래 걸리는 작업이나 백그라운드 작업에 잘 맞습니다.
• 낮은 지연 처리: 데이터 변경 이벤트를 계속 흘려보낼 수 있지만, 실제 지연은 생산자·브로커·소비자 설정과 부하에 따라 달라집니다.

Apache Kafka는 이런 구조를 구현할 때 가장 널리 쓰이는 플랫폼 가운데 하나입니다. Kafka는 분산 커밋 로그(commit log)나 분산 메시지 브로커로 볼 수 있으며, 다음과 같은 특징이 있습니다.

• 처리량 확장: 토픽을 여러 파티션으로 나누고 생산자와 소비자를 늘릴 수 있습니다. 얻을 수 있는 처리량은 작업 특성과 클러스터 구성에 달려 있습니다.
• 장애 허용: 파티션 복제와 ISR(in-sync replicas), 생산자의 acks 설정을 조합해 장애를 견디는 범위를 정합니다. 복제만으로 모든 장애에서 데이터 손실이 없다고 보장되지는 않습니다.
• 수평 확장: 브로커를 늘려 데이터 양이 많아져도 대응할 수 있습니다.
• 영속성: 브로커가 승인한 이벤트는 디스크 로그에 기록되며, 소비자가 다시 읽을 수 있는 범위는 토픽의 cleanup·retention 정책에 따라 달라집니다.
• 다중 소비자: 서로 다른 consumer group은 같은 이벤트 스트림을 각자 독립적으로 읽고, 같은 group 안의 인스턴스들은 파티션을 나누어 처리합니다.

Kafka의 핵심 개념은 다음과 같습니다.

• Producer(생산자): Kafka 토픽에 이벤트를 발행하는 애플리케이션입니다.
• Consumer(소비자): Kafka 토픽의 이벤트를 구독하고 처리하는 애플리케이션입니다.
• Topic(토픽): 이벤트가 발행되고 소비되는 논리적인 분류입니다.
• Partition(파티션): 토픽 로그를 나누는 단위입니다. 레코드의 순서는 파티션 안에서만 정해지므로, 같은 업무 키의 순서가 필요하다면 그 키가 항상 같은 파티션으로 가도록 설계해야 합니다.
• Broker(브로커): 파티션 로그를 저장하고 생산·소비 요청을 처리하는 Kafka 서버입니다. 여러 브로커에 걸친 복제와 배치가 장애를 견디는 범위를 결정합니다.
• KRaft controller: 메타데이터 요청과 로그를 관리하는 서버 역할입니다. 여러 controller가 Raft 기반의 메타데이터 quorum을 구성하며, Kafka 4.x는 ZooKeeper 없이 KRaft 모드만 지원합니다.

Kafka 이벤트는 단순한 메시지가 아니라 재처리, 순서, 소비자 확장까지 함께 정해야 하는 운영상의 약속입니다. 토픽을 만들기 전에 아래 그림의 기준으로 이벤트의 범위를 먼저 잡아 두면 구현과 확인이 쉬워집니다.

위 그림은 사용자를 메모리에 저장한 뒤 Kafka 생산을 시작하고, 브로커가 생산을 승인하면 HTTP 응답이 나가는 흐름과, 이와 따로 진행되는 소비 흐름을 보여 줍니다. HTTP 성공이 소비 완료를 기다린다는 화살표가 없다는 점이 핵심입니다. 왼쪽의 별도 실패선은 emit() 생산 자체가 실패한 경우인데, 지금 코드에는 이미 메모리에 넣은 사용자를 자동으로 취소하는 경로가 없습니다. 아래쪽 표는 이벤트가 어디서 멈췄는지를 브로커, 생산자, 토픽·그룹, handler 순서로 좁혀 가는 방법을 정리합니다.

NestJS에서 Kafka 설정과 구현

NestJS는 @nestjs/microservices 패키지로 Kafka 전송 계층을 지원합니다. 시나리오는 다음과 같습니다. Users 서비스에서 새 사용자가 생성되면 Kafka에 이벤트를 발행하고, Notifications 서비스가 이 이벤트를 구독해 사용자에게 환영 메일을 보냅니다.

먼저 로컬에서 Kafka 브로커를 실행해야 합니다. Docker Compose 파일을 다음과 같이 만듭니다.

# 로컬 학습용 단일 KRaft broker
services:
  kafka:
    image: apache/kafka:4.4.0
    ports:
      - "9092:9092"

공식 이미지의 기본 단일 노드 KRaft 구성은 로컬 학습용입니다. 이미지 태그와 시작 방법은 Apache Kafka 공식 Quickstart에서 확인할 수 있으며, 현재 Quickstart도 apache/kafka:4.4.0을 사용합니다. 운영 환경에서는 controller와 broker 역할, 복제 계수, ISR, 인증, 보관 정책을 따로 설계해야 합니다.

Kafka 사용자 이벤트 서비스 만들기

새 사용자가 생성될 때 Kafka에 이벤트를 발행하는 서비스입니다. 이번에는 같은 users-service를 gRPC 서버에서 HTTP 생산자로 바꿉니다. 앞 글의 Users gRPC 프로세스와 Orders HTTP 프로세스를 종료하고 설정을 바꿉니다. 이 글에서는 Users가 HTTP 3000번을 쓰므로 Orders를 같은 포트로 함께 실행하지 않습니다. Kafka 브로커, Users HTTP 생산자, Notifications 소비자는 각각 다른 실행 단위입니다.

users-service 프로젝트에 Kafka 드라이버를 설치합니다.

npm install kafkajs

NestJS의 Kafka transporter는 실행 중에 kafkajs 드라이버를 쓰므로, 공식 문서대로 애플리케이션 의존성으로 함께 설치합니다. 현재 버전은 2.2입니다. @nestjs/microservices는 7장 첫 글에서 이미 설치했고, HTTP 서버에 필요한 @nestjs/platform-express와 @types/express는 새 프로젝트에 처음부터 들어 있습니다. 설치한 뒤 npm ls @nestjs/core @nestjs/microservices kafkajs와 lockfile로 실제 조합을 확인합니다.

사용자 서비스는 클라이언트의 HTTP 요청을 받아 사용자를 만든 뒤 Kafka 이벤트를 발행하므로, main.ts는 HTTP 서버로 되돌립니다.

import { NestFactory } from '@nestjs/core';
import { AppModule } from './app.module';

async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  // 이 장의 다른 예제와 맞춰 HTTP 3000번 포트를 사용합니다.
  await app.listen(3000);
  console.log('Users Service (HTTP Server) is listening on port 3000');
}

void bootstrap();

main.ts가 다시 NestFactory.create()를 쓰므로 Users는 HTTP 요청을 받는 일반 서버가 되고, Kafka와는 아래에서 등록할 클라이언트로만 통신합니다. 즉 Users는 Kafka 메시지를 받지 않고 보내기만 합니다. ClientsModule로 Kafka 클라이언트를 등록하고, 이를 UsersController에 주입해 이벤트를 발행합니다.

import { Module } from '@nestjs/common';
import { ClientsModule, Transport } from '@nestjs/microservices';
import { UsersController } from './users.controller';
import { UsersService } from './users.service';

@Module({
  imports: [
    ClientsModule.register([
      {
        name: 'KAFKA_SERVICE', // Kafka 클라이언트 토큰
        transport: Transport.KAFKA, // Kafka 전송 방식 사용
        options: {
          client: {
            clientId: 'user-producer', // 클라이언트 ID
            brokers: ['localhost:9092'], // Kafka 브로커 주소
          },
          producer: {
            allowAutoTopicCreation: true, // 토픽이 없으면 자동으로 생성
          },
          producerOnlyMode: true, // 이벤트 발행 전용 클라이언트
        },
      },
    ]),
  ],
  controllers: [UsersController],
  providers: [UsersService],
})
export class UsersModule {}

• name: 'KAFKA_SERVICE': 이 클라이언트 프록시를 의존성 주입으로 참조할 token입니다.
• transport: Transport.KAFKA: Kafka 전송 방식을 씁니다.
• options.client: Kafka 클라이언트 설정으로, 클라이언트를 식별하는 clientId와 처음 연결할 브로커 목록 brokers를 지정합니다.
• options.producer: Kafka 생산자 설정입니다. 예제는 allowAutoTopicCreation으로 토픽이 없으면 자동으로 만들게 합니다.
• producerOnlyMode: 이벤트를 발행하기만 하는 클라이언트이므로 consumer group에 참여하지 않게 합니다.

사용자를 만들 때 Kafka의 emit()으로 이벤트를 발행합니다.

import { Body, Controller, Get, Inject, OnModuleInit, Param, Post } from '@nestjs/common';
import type { ClientKafkaProxy } from '@nestjs/microservices';
import { UsersService } from './users.service';
import { lastValueFrom } from 'rxjs';

interface User {
  id: number;
  name: string;
  email: string;
}

@Controller('users') // HTTP 엔드포인트
export class UsersController implements OnModuleInit {
  constructor(
    private readonly usersService: UsersService,
    @Inject('KAFKA_SERVICE') private readonly client: ClientKafkaProxy,
  ) {}

  async onModuleInit() {
    await this.client.connect();
  }

  @Post()
  async createUser(@Body() userDto: { name: string; email: string }): Promise<User> {
    const newUser = this.usersService.create(userDto);
    console.log(`Users Service: New user created: ${JSON.stringify(newUser)}`);

    // emit()은 reply topic을 만들지 않는 이벤트 발행입니다.
    // 같은 사용자의 이벤트가 같은 파티션으로 가도록 key를 함께 보냅니다.
    await lastValueFrom(
      this.client.emit('user_created', {
        key: String(newUser.id),
        value: newUser,
      }),
    );

    return newUser;
  }

  // 기존 사용자 조회 엔드포인트 (HTTP)
  @Get(':id')
  getUserById(@Param('id') id: string): User | null {
    const userId = parseInt(id, 10);
    return this.usersService.findOne(userId);
  }
}

• ClientKafkaProxy: Kafka 전송 방식에서는 ClientProxy 대신 이 타입을 씁니다. 앞 글의 ClientGrpc처럼 인터페이스이므로, 데코레이터가 붙은 생성자에서 쓰려면 import type으로 가져와야 컴파일 오류가 나지 않습니다.
• onModuleInit(): client.connect()를 호출해, 애플리케이션이 시작할 때 브로커 연결 실패가 바로 드러나게 합니다.
• emit(): 이벤트 발행용 hot Observable을 반환합니다. lastValueFrom()으로 완료를 기다리면 이 요청 안에서 생산자 오류를 확인할 수 있지만, 소비자의 업무 처리 결과까지 기다리는 것은 아닙니다.
• subscribeToResponseOf(): send()와 @MessagePattern()을 쓰는 요청-응답 방식에서 응답 토픽을 구독할 때만 필요합니다. emit()과 @EventPattern()에는 쓰지 않습니다.

위 예제는 생산자의 승인을 확인하지만, 사용자 저장과 Kafka 기록을 하나의 원자적 트랜잭션으로 묶지는 않습니다. 사용자를 저장했다면 이벤트 발행도 반드시 이어져야 하는 업무라면, 같은 데이터베이스 트랜잭션에 outbox 레코드를 남기고 별도 relay가 Kafka에 발행하도록 설계합니다.

users.service.ts와 AppModule은 앞 글과 같습니다.

알림 서비스 만들기

user_created 이벤트를 구독해 처리하는 서비스입니다. 공통 상위 폴더에서 새 프로젝트를 만듭니다.

npx @nestjs/cli@12 new notifications-service --no-observe
cd notifications-service
npm install @nestjs/microservices@12 kafkajs

CLI 질문에서는 앞의 두 프로젝트와 같이 CommonJS와 npm을 고릅니다. main.ts를 Kafka 마이크로서비스 서버로 설정합니다.

import { NestFactory } from '@nestjs/core';
import { MicroserviceOptions, Transport } from '@nestjs/microservices';
import { AppModule } from './app.module';

async function bootstrap() {
  const app = await NestFactory.createMicroservice<MicroserviceOptions>(AppModule, {
    transport: Transport.KAFKA, // Kafka 전송 방식 사용
    options: {
      client: {
        clientId: 'notification-consumer', // 실제 값: notification-consumer-server
        brokers: ['localhost:9092'], // Kafka 브로커 주소
      },
      consumer: {
        groupId: 'notification-group', // 실제 값: notification-group-server
      },
    },
  });
  await app.listen();
  console.log('Notifications Microservice (Kafka Consumer) is listening.');
}

void bootstrap();

• transport: Transport.KAFKA: Kafka 전송 방식을 씁니다.
• options.client: Kafka 클라이언트 설정입니다.
• options.consumer.groupId: 생략하면 Nest가 기본값을 주므로 문법상 필수는 아닙니다. 하지만 @EventPattern()으로 토픽을 구독하는 운영 서비스는 목적별로 안정된 ID를 명시해야, 배포한 뒤에도 같은 offset과 파티션 배분 단위를 유지합니다. 같은 group ID를 쓰는 인스턴스들은 파티션을 나누어 소비합니다.
• 공식 문서에 따르면 Nest는 클라이언트와 서버의 이름이 겹치지 않도록 clientId와 groupId 뒤에 역할을 붙입니다. 서버 쪽은 기본적으로 -server를 붙이므로 Kafka에 실제로 등록되는 그룹 이름은 notification-group-server입니다. 접미사를 바꾸려면 postfixId 옵션을 씁니다.

@EventPattern() 데코레이터로 특정 Kafka 토픽의 이벤트를 처리합니다.

import { Controller } from '@nestjs/common';
import { EventPattern, Payload } from '@nestjs/microservices'; // EventPattern, Payload 임포트
import { NotificationsService } from './notifications.service';

interface UserCreatedEvent { // user_created 이벤트의 페이로드 구조 정의
  id: number;
  name: string;
  email: string;
}

@Controller()
export class NotificationsController {
  constructor(private readonly notificationsService: NotificationsService) {}

  // 'user_created' 토픽의 이벤트를 처리하는 핸들러
  @EventPattern('user_created')
  async handleUserCreated(@Payload() data: UserCreatedEvent) {
    console.log(`Notifications Service: Received 'user_created' event for user: ${JSON.stringify(data)}`);
    // 여기에서 실제 알림 로직 (예: 이메일 전송)을 구현합니다.
    await this.notificationsService.sendWelcomeEmail(data.email, data.name);
  }
}

• @EventPattern('topic_name'): 특정 Kafka 토픽에 발행된 이벤트를 구독해 처리합니다. send()와 달리 응답을 돌려줄 필요가 없습니다.
• @Payload(): 이벤트 메시지의 값(value)을 꺼내 메서드 인자로 넣어 줍니다.

알림 서비스는 메일 발송을 흉내만 냅니다.

import { Injectable } from '@nestjs/common';

@Injectable()
export class NotificationsService {
  async sendWelcomeEmail(email: string, name: string): Promise<void> {
    console.log(`Sending welcome email to ${name} (${email})...`);
    // 실제 이메일 전송 로직 (예: Nodemailer, SendGrid 등 사용)
    await new Promise(resolve => setTimeout(resolve, 1000)); // 1초 지연 시뮬레이션
    console.log(`Welcome email sent to ${name}!`);
  }
}

sendWelcomeEmail()은 시작 로그를 남기고 1초를 기다린 뒤 완료 로그를 남기므로, 소비자 콘솔에는 두 줄이 약 1초 간격으로 찍힙니다. handler가 이 메서드를 await하므로 두 번째 로그가 찍혀야 handler 실행도 끝납니다. NotificationsModule과 AppModule을 구성합니다. 알림 서비스에는 HTTP 경로가 없고, NotificationsController의 @EventPattern() handler만 Kafka 서버에 등록됩니다.

import { Module } from '@nestjs/common';
import { NotificationsController } from './notifications.controller';
import { NotificationsService } from './notifications.service';

@Module({
  controllers: [NotificationsController],
  providers: [NotificationsService],
})
export class NotificationsModule {}

import { Module } from '@nestjs/common';
import { NotificationsModule } from './notifications/notifications.module';

@Module({
  imports: [NotificationsModule],
  controllers: [],
  providers: [],
})
export class AppModule {}

더 깊이: 키 없이 보낸 이벤트는 어느 파티션으로 갈까

Nest의 Kafka 클라이언트는 실제 생산을 KafkaJS 생산자에 맡기므로, 레코드가 들어갈 파티션도 KafkaJS의 파티셔너가 정합니다. KafkaJS 생산 문서에 따르면 메시지에 파티션을 직접 적었다면 그 파티션을 쓰고, 파티션 없이 키가 있으면 키의 murmur2 해시로 파티션을 고르며, 둘 다 없으면 라운드 로빈으로 돌아가며 고릅니다. 이 글의 emit()은 Nest 문서가 안내하는 대로 key와 value를 가진 객체를 보내고 사용자 ID를 key로 쓰므로, 같은 사용자의 이벤트는 같은 파티션으로 갑니다. 키 없이 사용자 객체만 보냈다면 토픽의 파티션이 여러 개일 때 같은 사용자에 대한 이벤트도 서로 다른 파티션에 들어갈 수 있고, 파티션 안에서만 순서가 정해지므로 사용자별 순서를 기대할 수 없게 됩니다.

키에서 파티션을 고르는 방식은 KafkaJS 2.0.0에서 바뀌었습니다. 그 전의 기본값이던 방식은 이제 LegacyPartitioner라는 이름으로 남았고, 지금의 기본 파티셔너는 Java Kafka 클라이언트의 기본 파티셔너와 호환되도록 만들어졌습니다. 그래서 다른 언어로 만든 생산자와 같은 키를 쓰면 같은 파티션에 모이므로, 키가 같은 두 토픽을 함께 처리하는 소비자가 파티션 배치를 맞출 수 있습니다. KafkaJS 1.x에서 올린 생산자는 같은 키라도 다른 파티션으로 갈 수 있으므로, 키별 순서에 기대는 소비자가 있다면 전환 시점을 따로 계획합니다.

실행하며 이벤트 흐름 확인하기

아래 순서는 브로커에 실제로 기록되었는지와 소비자 handler가 실행되었는지를 구분해서 확인하는 실습입니다. 알림 예제는 잠시 기다린 뒤 로그를 출력하는 모의 메일 처리이며, SMTP나 메일 서비스의 실제 발송 결과를 확인하는 코드는 없습니다.

1. Docker Compose 파일이 있는 폴더에서 docker compose up -d로 Kafka 브로커를 실행하고, docker compose ps로 컨테이너가 떠 있는지 확인합니다.
2. notifications-service에서 npm run start:dev를 실행하고, 콘솔에 Notifications Microservice (Kafka Consumer) is listening.이 찍히는지 확인합니다.
3. users-service에서 npm run start:dev를 실행하고, 콘솔에 Users Service (HTTP Server) is listening on port 3000이 찍히는지 확인합니다.
4. POST http://localhost:3000/users에 Content-Type: application/json 헤더와 다음 본문을 보내 사용자를 만듭니다.

{
  "name": "David",
  "email": "[email protected]"
}

사용자 서비스 콘솔에는 곧바로 Users Service: New user created: {"id":3,"name":"David","email":"[email protected]"}가 찍힙니다. 잠시 뒤 Kafka 브로커를 거쳐 메시지가 전달되면, 알림 서비스 콘솔에 Notifications Service: Received 'user_created' event for user: {"id":3,"name":"David","email":"[email protected]"}와 Sending welcome email to David ([email protected])..., Welcome email sent to David!가 차례로 찍힙니다.

이 과정으로 Users 서비스가 Notifications 서비스를 직접 호출하지 않고도, Kafka를 거쳐 이벤트가 비동기로 전달되고 처리되는 것을 확인했습니다. Kafka에서는 API 응답보다 이벤트가 브로커를 지나 소비자까지 도착했는지가 더 중요합니다.

Kafka 기반 설계에서는 연결 자체보다, 실패한 뒤에도 같은 상태로 수렴하는지가 더 중요합니다. 아래 그림은 토픽 설계, 소비자 처리, 재시도와 DLQ(dead letter queue)를 하나의 흐름으로 묶어 점검하는 기준입니다.

위 그림은 지금의 모의 코드에 더할 확장 설계입니다. 위쪽 흐름에서는 사용자와 outbox를 같은 데이터베이스 커밋으로 확정하고, relay가 같은 event ID로 Kafka에 발행하며, 소비자는 inbox 기록과 업무 상태를 함께 확정한 뒤에 offset을 커밋합니다. handler가 실패하면 원인과 시도 횟수로 분류해, 일시적인 실패는 제한적으로 재시도하고 영구적인 실패나 횟수를 다 쓴 경우는 DLQ로 보내 운영자가 다시 재생합니다. 아래쪽 칸들은 공식 문서의 설명처럼 Nest Kafka handler에서 처리되지 않은 예외가 KafkaJS로 전달되면 offset이 커밋되지 않아 같은 레코드가 다시 전달될 수 있다는 점, 그리고 업무 목적마다 별도의 consumer group을 두는 이유를 정리합니다.

Kafka 기반 아키텍처는 서비스 사이의 동기 호출을 줄이고 이벤트 스트림을 중심으로 비동기 흐름을 구성합니다. 구현할 때는 토픽 설계, 파티션 키, consumer group, 재시도, DLQ, 중복 처리 기준을 함께 정하고, 같은 이벤트가 다시 전달되어도 안전하게 같은 상태로 수렴하는지 확인해야 합니다.

정리

• 이벤트 기반 아키텍처에서는 서비스가 서로를 직접 호출하지 않고 이벤트를 발행·구독하며, Kafka는 이벤트를 파티션 로그에 보관해 생산과 소비의 시점을 떼어 놓습니다.
• 레코드 순서는 파티션 안에서만 정해지므로, 같은 업무 키는 같은 파티션으로 가도록 key를 함께 보냅니다.
• NestJS는 Kafka 드라이버로 kafkajs를 쓰며, 생산자는 ClientKafkaProxy.emit()으로, 소비자는 @EventPattern()으로 이벤트를 다룹니다.
• Nest는 clientId와 groupId 뒤에 -server나 -client를 붙이므로, Kafka에서 실제 그룹 이름을 확인할 때 이 접미사를 고려합니다.
• 생산 승인은 소비 완료나 메일 발송을 뜻하지 않으므로, 저장과 발행은 outbox로, 재전달은 event ID 기반 멱등 처리로 대비합니다.

연습 문제

1. 생산 승인과 메일 완료는 같은가

새 사용자 POST에서 createUser()가 메모리 배열에 사용자를 넣었고, 이어서 emit()의 생산이 성공해 HTTP 응답도 성공했습니다. 그런데 Notifications 소비자가 처리하던 중 종료되었습니다. 사용자 생성, 브로커 기록, 메일 발송 가운데 확정할 수 있는 결과는 무엇일까요? 생산 단계 자체가 실패했다면, 이미 저장한 사용자가 이 코드에서 자동으로 취소될까요?

2. 그룹을 찾을 수 없다

운영자가 Kafka의 consumer group 목록에서 notification-group을 찾았지만 보이지 않았습니다. 알림 서비스는 정상적으로 이벤트를 처리하고 있습니다. 왜 그럴까요?

3. 인스턴스를 늘렸는데 하나만 일한다

user_created 토픽은 자동 생성되어 파티션이 하나입니다. 처리량을 높이려고 알림 서비스 인스턴스를 두 개로 늘렸는데, 한 인스턴스만 이벤트를 받습니다. 또 분석 서비스를 새로 만들어 같은 토픽을 analytics-group으로 구독하게 했다면, 사용자 하나가 생성될 때 이벤트는 어디로 전달될까요?

다음 글 API 게이트웨이 패턴 구현에서는 지금까지 만든 여러 서비스 앞에 하나의 진입점을 두고, 라우팅·인증·응답 집계를 맡기는 방법을 다룹니다.