회사에서 공통 코드 테이블을 사용하면서 한 가지 불편함을 느꼈습니다. 성별, 상태값, 카테고리 같은 코드성 데이터를 조회하는 로직이 API마다 반복되고 있었습니다.

상품 조회 API에서도 코드를 조회하고, 사용자 정보 API에서도 같은 코드를 조회하고, 목록 API에서도 또 조회합니다. 쿼리를 살펴보니 코드 테이블을 JOIN하거나 서브쿼리로 가져오는 중복 코드가 여러 Repository에 흩어져 있었습니다.

[상품 조회 API] → SELECT ... JOIN code_table → 상태 코드 조회
[사용자 API]   → SELECT ... JOIN code_table → 성별 코드 조회
[목록 API]     → SELECT ... JOIN code_table → 카테고리 코드 조회

매 요청마다 거의 변하지 않는 같은 데이터를 DB에서 반복 조회하고, 그 조회 로직이 여기저기 중복되어 있는 상황이었습니다.

코드 테이블의 특성을 다시 생각해보면 이건 불필요한 낭비입니다.

• 데이터가 거의 변하지 않는다 — 운영자가 수동으로 변경할 때만 바뀜
• 데이터 양이 적다 — 수백 건 이내
• 조회 빈도가 매우 높다 — 거의 모든 API에서 사용
• 중복 쿼리가 발생한다 — 여러 Repository에 코드 조회 로직이 산재

캐시에 올려두고 한 곳에서 관리하면 DB 부하도 줄이고, 중복 코드도 제거할 수 있겠다고 판단했습니다.

개발 제약 사항: Redis 없이 여러 서버의 캐시 동기화

우리 서비스 구조에서 가장 큰 제약은 Front Office(사용자 서비스)와 Back Office(관리자)가 별도 서버로 운영되고, 각각 여러 인스턴스가 떠 있다는 점이었습니다.

[Front Office 서버 1] ──┐
[Front Office 서버 2] ──┤
[Back Office  서버 1] ──┼── 모두 같은 코드 테이블을 사용
[Back Office  서버 2] ──┘

일반적으로 이런 환경에서는 Redis 같은 중앙 캐시 서버를 두고 모든 서버가 같은 캐시를 바라보게 합니다. 하지만 우리는 Redis를 사용하지 않는 환경이었습니다.

그렇다면 로컬 캐시를 선택할 수밖에 없는데, 데이터 동기화를 어떻게 할 것인가? 이것이 가장 핵심적인 문제였습니다. Back Office에서 관리자가 코드를 변경하면, Front Office 서버들의 로컬 캐시에도 반영이 되어야 합니다. 서버마다 독립적인 캐시를 갖고 있으니, 아무런 장치 없이는 변경 사항이 전파되지 않습니다.

이 문제의 해결 방향은 뒤에서 다루겠지만, 결론부터 말하면 주기적 Warm-Up(3분 간격)으로 모든 서버가 DB를 기준으로 캐시를 갱신하는 방식을 택했습니다. 실시간 동기화 대신 “최대 3분 내 반영”이라는 트레이드오프를 받아들인 것입니다. 코드 테이블은 관리자가 수동으로 변경하는 데이터이기 때문에, 이 정도의 지연은 충분히 허용 가능했습니다.

왜 로컬 캐시인가?

Redis를 사용하지 않는 환경이라는 제약도 있었지만, 코드 테이블의 특성을 따져보면 오히려 로컬 캐시가 더 나은 선택이었습니다.

코드 테이블은 변경 빈도가 낮고, 데이터 크기가 작으며, 읽기 비율이 압도적입니다. Redis를 도입하면 인프라 관리 비용이 추가되는 반면, 로컬 캐시는 네트워크 홉 없이 JVM 메모리에서 바로 읽으므로 성능상으로도 유리합니다. 동기화 지연이라는 단점은 주기적 갱신으로 충분히 커버할 수 있었습니다.

왜 Caffeine인가?

Java 진영의 로컬 캐시 라이브러리 중 Caffeine을 선택한 이유는 다음과 같습니다.

• 성능: Window TinyLFU 알고리즘 기반으로 Guava Cache 대비 높은 히트율
• 자동 로딩: LoadingCache를 제공하여 캐시 미스 시 자동으로 데이터를 로딩
• Spring 공식 지원: spring-boot-starter-cache에서 Caffeine을 공식 CacheManager로 지원
• 풍부한 설정: 만료 정책, 최대 크기, 통계 수집 등을 세밀하게 제어 가능

구현하기

의존성 추가

// build.gradle
implementation 'com.github.ben-manes.caffeine:caffeine:3.1.8'

캐시 설정 정의

캐시 타입별로 설정값을 관리하면 여러 종류의 캐시를 일관되게 다룰 수 있습니다.

@Getter
public enum CacheType {
    CODE(500, Duration.ofHours(24));

    private final int maxSize;
    private final Duration refreshDuration;

    CacheType(int maxSize, Duration refreshDuration) {
        this.maxSize = maxSize;
        this.refreshDuration = refreshDuration;
    }

    public <K, V> LoadingCache<K, V> createLoadingCache(
            CacheLoader<K, V> loader) {
        return Caffeine.newBuilder()
                .maximumSize(maxSize)
                .refreshAfterWrite(refreshDuration)
                .recordStats()
                .build(loader);
    }
}

CacheType을 enum으로 정의하면 캐시가 추가될 때마다 상수만 추가하면 됩니다. recordStats()를 넣어두면 히트율, 미스율 등을 모니터링할 수 있습니다.

캐시 Repository 구현

@Slf4j
@Component
@RequiredArgsConstructor
public class CachedCodeRepository {

    private final CodeRepository codeRepository;
    private LoadingCache<String, Code> cache;

    @PostConstruct
    public void init() {
        this.cache = CacheType.CODE.createLoadingCache(key -> {
            String[] parts = key.split("::", 2);
            if (parts.length != 2) return null;
            return codeRepository
                    .findByGroupNameAndCodeName(parts[0], parts[1])
                    .map(CodeEntity::toDomain)
                    .orElse(null);
        });

        warmUp();
        log.info("Code cache initialized - maxSize: {}, refresh: {}m",
                CacheType.CODE.getMaxSize(),
                CacheType.CODE.getRefreshDuration().toMinutes());
    }

    public Code findByGroupAndName(String groupName, String codeName) {
        if (codeName == null || codeName.isBlank()) return null;
        String key = groupName + "::" + codeName;
        return cache.get(key);
    }
}

핵심 포인트를 살펴보겠습니다.

키 설계: 그룹명::코드명 형태의 복합 키를 사용합니다. 예를 들어 GENDER::MALE 처럼 하나의 문자열로 코드를 식별합니다.

LoadingCache: 캐시 미스가 발생하면 CacheLoader를 호출하여 자동으로 DB에서 로딩합니다. 같은 키에 대해 동시에 여러 요청이 들어와도 한 번만 로딩됩니다(thundering herd 방지).

왜 AsyncLoadingCache가 아닌가?: Caffeine은 AsyncLoadingCache도 제공하지만, 이 케이스에서는 동기 LoadingCache로 충분합니다. warm-up으로 미리 전체 데이터를 적재하기 때문에 실제 운영 중 캐시 미스가 거의 발생하지 않고, Spring MVC 기반이라 CompletableFuture를 리액티브하게 활용할 일도 없습니다. AsyncLoadingCache는 WebFlux 같은 리액티브 스택에서 non-blocking 파이프라인에 태울 때 더 적합합니다.

Warm-Up: 애플리케이션 시작 시 캐시 채우기

public void warmUp() {
    Map<String, Code> newEntries = new HashMap<>();

    List<String> groupNames = codeRepository.findAllGroupNames();
    for (String groupName : groupNames) {
        List<CodeEntity> codes = codeRepository.findByGroupName(groupName);
        for (CodeEntity entity : codes) {
            String key = groupName + "::" + entity.getCodeName();
            newEntries.put(key, entity.toDomain());
        }
    }

    // 삭제된 코드는 캐시에서 제거
    Set<String> currentKeys = cache.asMap().keySet();
    Set<String> newKeys = newEntries.keySet();
    currentKeys.stream()
            .filter(key -> !newKeys.contains(key))
            .forEach(cache::invalidate);

    // 새로운 데이터로 캐시 갱신
    cache.putAll(newEntries);
    log.debug("Code cache warmed up: {} items", cache.estimatedSize());
}

Warm-Up은 두 가지 역할을 합니다.

1. 애플리케이션 시작 시 모든 코드를 미리 로딩하여 첫 요청부터 캐시 히트가 되도록 합니다
2. 주기적 갱신 시 DB에서 삭제된 코드는 캐시에서도 제거하여 데이터 정합성을 유지합니다

단순히 putAll만 하면 DB에서 삭제된 코드가 캐시에 남아있게 됩니다. currentKeys와 newKeys를 비교하여 차집합을 invalidate하는 부분이 중요합니다.

주기적 캐시 갱신 (TTL 3분)

@Slf4j
@Component
@RequiredArgsConstructor
public class CacheRefreshScheduler {

    private final CachedCodeRepository cachedCodeRepository;

    @Scheduled(fixedRate = 180_000) // 3분
    public void refreshCaches() {
        try {
            cachedCodeRepository.warmUp();
        } catch (Exception e) {
            log.error("Failed to refresh Code cache", e);
        }
    }
}

refreshAfterWrite만으로는 요청이 들어와야 갱신이 트리거됩니다. 스케줄러로 3분마다 warmUp()을 호출하면 요청 유무와 관계없이 캐시가 최신 상태를 유지합니다.

갱신 주기를 3분으로 잡은 이유는 코드 테이블의 변경이 운영자의 수동 작업으로만 발생하기 때문입니다. 실시간 반영이 아닌 “수 분 내 반영”이면 충분하고, 너무 짧으면 불필요한 DB 부하가 발생합니다.

각 캐시의 warmUp()을 try-catch로 감싸는 것이 중요합니다. 하나의 캐시 갱신이 실패해도 다른 캐시에 영향을 주지 않도록 격리합니다.

전체 흐름

[애플리케이션 시작]
    └─ @PostConstruct → warmUp() → DB 전체 조회 → 캐시 적재

[API 요청]
    └─ findByGroupAndName("GENDER", "MALE")
        └─ cache hit → 즉시 반환 (ns 단위)
        └─ cache miss → CacheLoader → DB 조회 → 캐시 적재 → 반환

[3분마다]
    └─ @Scheduled → warmUp()
        └─ DB 전체 조회 → 신규 코드 추가, 삭제된 코드 제거

주의할 점

1. 메모리 사용량 관리

로컬 캐시는 JVM 힙 메모리를 사용합니다. maximumSize를 반드시 설정하고, 코드 테이블의 예상 크기를 고려해야 합니다. 설정하지 않으면 메모리 누수로 이어질 수 있습니다.

2. 다중 인스턴스 환경

서버가 여러 대라면 각 인스턴스가 독립적인 캐시를 갖게 됩니다. 코드 변경 후 최대 3분간 서버마다 다른 데이터를 반환할 수 있습니다. 코드 테이블의 특성상 이 정도는 허용 가능하지만, 실시간 일관성이 필요한 데이터라면 로컬 캐시는 적합하지 않습니다.

3. Cache Stampede 방지

LoadingCache는 같은 키에 대한 동시 요청을 하나로 합쳐줍니다. 하지만 warmUp() 시 대량 DB 조회가 발생하므로, 코드 데이터가 매우 많다면 warm-up 자체의 부하도 고려해야 합니다.

4. null 처리

존재하지 않는 코드를 조회하면 null이 캐시에 저장될 수 있습니다. Caffeine은 기본적으로 null value를 허용하지 않으므로 CacheLoader에서 null을 반환하면 해당 키는 캐시되지 않습니다. 매번 DB를 조회하는 negative lookup이 발생할 수 있으니, 의도적으로 빈 객체를 반환하는 것도 고려해볼 수 있습니다.

5. 갱신 실패 시 기존 캐시 유지

warmUp() 내부에서 DB 조회가 실패하면 Exception이 발생하고, try-catch에 의해 기존 캐시가 그대로 유지됩니다. 이는 의도된 동작으로, 일시적인 DB 장애가 서비스 장애로 이어지지 않도록 합니다.

마무리

코드 테이블처럼 변경이 적고, 크기가 작고, 조회가 잦은 데이터에는 로컬 캐시가 효과적입니다. Caffeine의 LoadingCache와 주기적 warm-up을 조합하면, 거의 제로에 가까운 지연시간으로 코드를 조회하면서도 데이터 정합성을 유지할 수 있습니다.

핵심을 정리하면 다음과 같습니다.

• 코드 테이블은 로컬 캐시가 적합하다 (네트워크 비용 제거)
• Caffeine은 높은 히트율과 비동기 로딩을 지원한다
• Warm-Up으로 콜드 스타트를 방지하고, 스케줄러로 주기적 갱신한다
• 삭제된 데이터의 캐시 무효화를 잊지 말자
• 다중 인스턴스 환경에서의 일시적 불일치를 허용할 수 있는 데이터에만 적용하자

포스팅 예약 시스템에서 @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)를 사용해 DB 커밋 이후 Kafka로 이벤트를 발행하고 있었습니다. 평소에는 문제없이 동작했지만, Kafka 브로커 장애 상황에서 치명적인 버그가 드러났습니다.

1. 애플리케이션 → DB 커밋 완료 ✅
2. TransactionalEventListener → 이벤트 위임
3. Kafka 전송 시도 → 브로커 장애 ❌
4. 메시지 유실 → 포스팅이 WORKING 상태에서 영원히 멈춤

DB에는 정상적으로 저장됐지만 Kafka 메시지가 유실되면서, 예약된 포스팅이 발행되지 않는 상태가 되었습니다. DB 트랜잭션과 메시지 발행 사이의 원자성이 보장되지 않는 전형적인 분산 시스템 문제였습니다.

해결 방법 후보: Two-Phase Commit vs Outbox Pattern

Two-Phase Commit (2PC)

분산 시스템에서 원자성을 보장하는 전통적인 방법입니다.

“모두 성공하거나 모두 실패”라는 강력한 일관성을 제공하지만, 실제 운영 환경에서는 몇 가지 단점이 있습니다.

• 성능 저하 — 모든 참여자가 응답할 때까지 락을 잡고 대기해야 합니다
• 단일 장애점 — 코디네이터가 다운되면 참여자들이 불확실한 상태로 남습니다
• Kafka는 XA 트랜잭션을 지원하지 않음 — 사실상 DB + Kafka 조합에서 2PC 적용이 불가능합니다

Transactional Outbox Pattern

이벤트를 외부 시스템에 직접 전송하지 않고, Outbox 테이블에 먼저 저장한 후 별도 프로세스가 읽어서 외부 시스템으로 전송하는 패턴입니다.

[비즈니스 로직]
    │
    ├─ 도메인 데이터 저장  ──┐
    │                        ├── 같은 DB 트랜잭션
    └─ Outbox 테이블 저장  ──┘

[Message Relay (별도 스케줄러)]
    │
    ├─ Outbox에서 PENDING 이벤트 조회
    ├─ Kafka로 전송
    └─ 전송 결과에 따라 상태 업데이트 (SUCCESS / FAIL)

핵심은 도메인 데이터와 이벤트를 같은 DB 트랜잭션으로 묶는 것입니다. DB 트랜잭션의 원자성을 활용하기 때문에 “데이터는 저장됐는데 이벤트는 없다”는 상황이 원천적으로 발생하지 않습니다.

왜 Outbox Pattern을 선택했는가

특히 기존 시스템에서 메시지 발행 상황에 대한 로깅이 부족했기 때문에, Outbox 테이블이 자연스럽게 이벤트 이력 역할까지 하는 점이 큰 장점이었습니다.

Outbox 테이블 설계

CREATE TABLE outbox (
    id          BIGINT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    event_type  ENUM('POSTING_EVENT', 'POSTING_RESERVATION_EVENT') NOT NULL,
    payload     JSON,
    created     DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
    status      ENUM('PENDING', 'SUCCESS', 'FAIL', 'RETRY'),
    retry_count BIGINT NOT NULL DEFAULT 0
);

CREATE INDEX idx_outbox_status_created_id ON outbox (status, created, id);

인덱스 설계 의도

(status, created, id) 복합 인덱스를 사용한 이유는 Message Relay의 조회 쿼리 패턴 때문입니다.

-- Message Relay가 실행하는 쿼리
SELECT * FROM outbox
WHERE status = 'PENDING'
ORDER BY created, id
LIMIT 100;

• status = 'PENDING' — 인덱스 선두 컬럼으로 빠르게 필터링
• ORDER BY created, id — 인덱스 순서와 일치하여 filesort 없이 정렬 가능
• LIMIT 100 — 인덱스 스캔을 100건에서 조기 종료

이 인덱스가 없으면 Outbox 테이블이 커질수록 전체 테이블 스캔이 발생해 성능이 급격히 저하됩니다.

Message Relay 구현

@Scheduled(fixedDelay = 5_000)
@Transactional
public void publishPendingPostingEvents() {
    List<Outbox> retryableEvents =
        outBoxRepository.findTop100PendingOrderByCreatedAndId();

    retryableEvents.forEach(outbox -> {
        try {
            PostingEventPayload payload =
                DataSerializer.deserialize(outbox.getPayload(),
                    PostingEventPayload.class);
            String postId = String.valueOf(payload.getPostId());

            kafkaTemplate.send(kafkaTopicConfig.getTopicName(),
                postId, postId).get();

            outbox.markSent();
            log.info("Kafka 전송 성공: postId={}", postId);

        } catch (Exception e) {
            outbox.markFailed();
            log.error("Kafka 전송 실패: outboxId={}, retryCount={}",
                outbox.getId(), outbox.getRetryCount(), e);
        }
    });

    outBoxRepository.saveAll(retryableEvents);
}

전체 흐름 정리

[사용자 포스팅 예약 요청]
    │
    ▼
[예약 스케줄러 - 1분 주기]
    ├─ 5분 전 예약 데이터 조회
    ├─ WORKING 상태로 마킹
    └─ Outbox 테이블에 이벤트 저장  ← 같은 트랜잭션
    │
    ▼
[Message Relay - 5초 주기]
    ├─ PENDING 상태 이벤트 100건 조회
    ├─ Kafka로 전송 시도
    ├─ 성공 → SUCCESS로 마킹
    └─ 실패 → FAIL로 마킹, retry_count 증가
         └─ 최대 3회 재시도 후 수동 처리 대상으로 분류

구현에서 주의한 점

1. 동기 전송 사용 (kafkaTemplate.send().get())

KafkaTemplate.send()는 기본적으로 비동기입니다. .get()을 호출해 동기로 전환한 이유는, 전송 성공/실패를 확실히 확인한 후 Outbox 상태를 업데이트해야 하기 때문입니다. 비동기로 처리하면 전송 결과를 모르는 채로 상태를 변경할 위험이 있습니다.

2. 배치 조회 + 개별 전송

100건을 한 번에 조회하되 개별 건마다 try-catch로 감싸서, 한 건의 실패가 나머지 건의 전송을 막지 않도록 했습니다.

3. 재시도 횟수 제한

무한 재시도는 장애 상황에서 시스템 부하를 가중시킵니다. 최대 3회로 제한하고, 그 이후에는 운영자가 직접 확인할 수 있도록 별도 상태로 분류합니다.

적용 결과

Outbox 패턴은 추가 테이블과 스케줄러라는 복잡성이 생기지만, 메시지 유실 방지, 운영 가시성 확보, 시스템 간 결합도 감소라는 이점이 그 비용을 충분히 상쇄했습니다. 복잡성과 운영 효율성, 확장성을 고려했을 때 현재 서비스 환경에 가장 적합한 선택이었습니다.

이 글은 “카프카 핵심 가이드(Kafka: The Definitive Guide)”를 읽고 Chapter 1의 내용을 정리한 것입니다. 단순 요약이 아니라, 각 개념이 왜 그렇게 설계되었는지에 초점을 맞춰 정리했습니다.

Kafka는 LinkedIn에서 시작된 프로젝트로, 대규모 실시간 데이터 파이프라인과 스트리밍 처리를 위해 설계되었습니다. 현재는 Apache 재단의 최상위 프로젝트로, 분산 메시징 시스템의 사실상 표준(de facto standard)이 되었습니다.

메시지(Message) — Kafka의 데이터 단위

Kafka에서 데이터의 최소 단위는 메시지입니다. 데이터베이스의 row, 테이블의 record에 대응하는 개념입니다.

메시지는 선택적으로 key라는 메타데이터를 포함할 수 있습니다. key는 단순한 식별자가 아니라 파티션 배치 전략에 직접적으로 관여합니다.

파티션 결정 방식:
hash(key) % partition_count = 저장될 파티션 번호

이 설계 덕분에 동일한 key를 가진 메시지는 항상 같은 파티션에 저장됩니다. 예를 들어, 주문 ID를 key로 사용하면 같은 주문의 모든 이벤트가 하나의 파티션에 순서대로 쌓이게 됩니다.

배치(Batch) — 처리량과 지연의 트레이드오프

Kafka는 메시지를 하나씩 전송하지 않고 배치 단위로 모아서 전송합니다.

배치 크기를 키우면 네트워크 왕복 횟수가 줄어 전체 처리량이 증가하지만, 개별 메시지 입장에서는 배치가 채워질 때까지 기다려야 하므로 지연이 늘어납니다. 실시간성이 중요한 서비스에서는 이 트레이드오프를 신중하게 조정해야 합니다.

토픽(Topic)과 파티션(Partition)

토픽은 메시지를 논리적으로 분류하는 단위이고, 파티션은 토픽을 물리적으로 분할하는 단위입니다.

Topic: order-events
├── Partition 0: [msg1] [msg3] [msg5] → append-only
├── Partition 1: [msg2] [msg6]        → append-only
└── Partition 2: [msg4] [msg7]        → append-only

파티션의 핵심 특성

1. Append-Only 구조

메시지는 파티션 끝에만 추가됩니다. 수정이나 삽입이 없기 때문에 디스크 순차 쓰기(sequential write)가 가능하고, 이것이 Kafka의 높은 처리량의 기반입니다.

2. 순서 보장 범위

• 단일 파티션 내에서는 메시지 순서가 보장됩니다
• 파티션 간에는 순서가 보장되지 않습니다

이 때문에 순서가 중요한 메시지는 같은 key를 사용해 같은 파티션으로 보내야 합니다.

3. 복제(Replication)

각 파티션은 여러 브로커에 복제되어 저장됩니다. 하나의 브로커가 다운되더라도 다른 브로커에 복제본이 있으므로 데이터 유실 없이 서비스를 지속할 수 있습니다.

프로듀서(Producer)와 컨슈머(Consumer)

프로듀서 — 메시지를 만드는 쪽

프로듀서는 메시지를 생성하여 토픽에 전송합니다.

• key가 없으면 — 라운드 로빈으로 파티션에 균등 분배
• key가 있으면 — 파티셔너(Partitioner)가 hash 기반으로 파티션 결정

// key 없이 전송 → 라운드 로빈
producer.send(new ProducerRecord<>("order-events", orderJson));

// key 지정 전송 → 같은 orderId는 항상 같은 파티션
producer.send(new ProducerRecord<>("order-events", orderId, orderJson));

컨슈머 — 메시지를 읽는 쪽

컨슈머는 하나 이상의 토픽을 구독하고 메시지를 읽습니다. 핵심 개념은 오프셋(offset)입니다.

Partition 0: [0] [1] [2] [3] [4] [5] [6]
                          ↑
                   현재 오프셋 = 3
                   (여기까지 읽었음)

오프셋은 파티션 내에서 메시지의 위치를 나타내는 순차적인 번호입니다. 컨슈머는 자신이 어디까지 읽었는지를 오프셋으로 관리하기 때문에, 장애 후 재시작해도 마지막으로 읽은 위치부터 이어서 처리할 수 있습니다.

컨슈머 그룹(Consumer Group) — 수평 확장의 핵심

컨슈머 그룹은 Kafka가 수평 확장을 지원하는 핵심 메커니즘입니다.

Consumer Group: order-service
├── Consumer A → Partition 0, Partition 1
├── Consumer B → Partition 2, Partition 3
└── Consumer C → Partition 4

규칙: 하나의 파티션은 그룹 내 오직 하나의 컨슈머에만 할당

왜 이렇게 설계했을까?

하나의 파티션을 여러 컨슈머가 동시에 읽으면 메시지 처리 순서를 보장할 수 없고, 중복 처리 가능성도 생깁니다. “하나의 파티션 = 하나의 컨슈머” 규칙 덕분에 순서 보장과 정확히 한 번 처리가 가능해집니다.

장애 시 자동 리밸런싱

컨슈머 하나가 다운되면 해당 컨슈머가 담당하던 파티션이 나머지 컨슈머에게 자동으로 재할당됩니다. 별도의 수동 작업 없이 장애 복구가 이루어집니다.

주의: 컨슈머 수가 파티션 수보다 많으면 초과된 컨슈머는 유휴 상태가 됩니다. 따라서 파티션 수를 설계할 때 예상되는 최대 컨슈머 수를 고려해야 합니다.

브로커(Broker)와 클러스터

브로커는 Kafka 서버의 단일 인스턴스입니다. 프로듀서로부터 메시지를 수신하고, 오프셋을 할당한 뒤, 디스크에 저장하는 역할을 합니다.

Kafka 클러스터
├── Broker 0 (Leader: P0, P3)   (Follower: P1, P4)
├── Broker 1 (Leader: P1, P4)   (Follower: P2, P0)
└── Broker 2 (Leader: P2)       (Follower: P3)

리더와 팔로워

• 리더(Leader) — 해당 파티션의 모든 읽기/쓰기를 처리합니다
• 팔로워(Follower) — 리더의 데이터를 복제합니다. 리더가 다운되면 팔로워 중 하나가 새로운 리더로 승격됩니다

이 구조 덕분에 브로커 하나가 장애를 겪어도 클러스터 전체는 정상 운영됩니다.

Kafka의 네 가지 설계 철학

1. 다중 프로듀서 지원

여러 프로듀서가 동일한 토픽에 동시에 메시지를 보낼 수 있습니다. 서로 다른 마이크로서비스에서 발생하는 이벤트를 하나의 토픽으로 모을 수 있어, 이벤트 통합이 자연스럽습니다.

2. 다중 컨슈머 그룹 지원

같은 토픽을 여러 컨슈머 그룹이 독립적으로 읽을 수 있습니다. 주문 이벤트를 결제 서비스, 알림 서비스, 분석 서비스가 각각 독립적으로 소비할 수 있습니다. 한 그룹이 느려지더라도 다른 그룹에 영향을 주지 않습니다.

3. 디스크 기반 저장

메시지를 메모리가 아닌 디스크에 저장합니다. 브로커가 재시작되어도 데이터가 유지되고, 보존 기간(retention period) 동안 메시지를 재소비할 수 있습니다. 장애 복구나 데이터 재처리 시나리오에서 큰 장점입니다.

4. 고성능

순차 쓰기, 배치 처리, zero-copy 전송 등의 기법으로 높은 처리량을 달성합니다. 디스크 기반임에도 메모리 기반 시스템에 준하는 성능을 보여줍니다.

마치며

Chapter 1을 읽으며 느낀 점은, Kafka의 각 구성 요소가 독립적으로 존재하는 것이 아니라 서로 맞물려 동작하도록 설계되었다는 것입니다.

• key → 파티션 결정 → 순서 보장
• 파티션 → 컨슈머 그룹 → 수평 확장
• 복제 → 리더/팔로워 → 고가용성

단순히 “메시지를 보내고 받는 시스템”으로 이해하면 Kafka의 절반만 아는 것입니다. 다음 장에서는 프로듀서의 내부 동작과 설정 옵션에 대해 정리해 보겠습니다.