알고 쓰기 위한 블로그

개요이번에는 카프카 내부 동작 원리로 브로커의 파티션들이 장애 복구를 하는 과정에 대해 정리해보겠다. 리더 에포크(Leader Epoch)리더 에포크는 Kafka에서 파티션 리더가 변경될 때마다 증가하는 번호로, 리더 변경 히스토리를 기록하며 데이터 동기화와 복구 동작에 활용된다. 이는 팔로워가 부족한 데이터를 동기화할 범위를 결정하고, 메시지의 순서와 일관성을 유지하기 위해 사용된다. 리더 에포크가 없는 장애 복구 과정의 문제점브로커가 복구 동작을 하는데 왜 리더 에포크가 필요한지 알기 위해서는 먼저 리더 에포크가 없을 때 발생하는 문제점에 대해서 알아봐야한다. peter-test01 토픽의 파티션 수는 1, 리플리케이션 팩터 수는 2, min.insync.replicas는 1인 상황이다. 리더 에포..

개요과거 프로젝트 진행했을 때 카프카를 단일 브로커를 사용해서 구축하였다. 이는 카프카가 제공하는 고가용성의 장점을 충분히 활용하지 못한 사례로, 단일 브로커에 장애가 발생할 경우 전체 서비스에 심각한 영향을 미칠수 있는 구조였다. 이러한 문제를 개선하기 위해 이번에는 과거 kafka설정을 기반으로 재구성하여 kafka클러스터를 단일 브로커가 아닌 다중 브로커(3개) 환경으로 구축하여 리플리케이션이 가능하도록 구축해보겠다. docker-compose.ymlversion: '3.8'services: zookeeper: image: confluentinc/cp-zookeeper:latest container_name: zookeeper ports: - "2181:2181" e..

개요이전 포스트에서는 카프카를 구성 요소를 중심으로 리플리케이션과 파티션의 역할, 그리고 이를 활용한 고가용성과 병렬 처리의 장점에 대해 알아보았다. 고가용성 분산 스트리밍 플랫폼인 카프카는 무수히 많은 데이터 파이프라인의 정중앙에 위치하는 메인 허브 역할을 한다. 이러한 메인 허브 역할을 하는 카프카가 정상 동작하지 못하면 연결된 전체 데이터 파이프라인에 영향을 주게 될 것이다. 따라서 카프카 초기 설계 단계부터 브로커 한두 대에서 장애가 발생하더라도 중앙 데이터 허브로서 안정적으로 서비스를 운영될 수 있게 리플리케이션이라는 동작을 한다. 지금부터 카프카의 매우 중요한 리플리케이션 동작 원리에 대해 파헤쳐보자 리더와 팔로워의 역할카프카는 내부적으로 모두 동일한 리플리케이션들을 리더와 팔로워로 구분하고..

개요MSA 프로젝트에서 kafka를 다양한 곳에 활용 했었다. 예를 들어 대규모 쿠폰 발급 처리에 Insert DB부하를 방지하기 위해 비동기 처리를 위해 사용 했었고, 채팅 서비스의 수평적 확장을 위해 메시지 브로커로 사용했었다. 지금 생각 해보면 잘못된 설계라는게 머리에 스쳐가기도 한다. 현재 쿠폰 발급 구조는 쿠폰 서비스에 이벤트를 발행하고 카프카에서 받아 다시 쿠폰 서비스에서 소비하는 구조(순환 호출 문제)쿠폰 서비스 (이벤트 발행) --> Kafka --> 쿠폰 서비스 (이벤트 소비 후 DB insert)물론 이벤트를 발행 후 사용자에게 바로 '발행완료' API 응답하고, DB insert작업은 비동기로 처리하므로 API 응답 시간이 빨라지고 트래픽 증가에 더 잘 대처할 수 있게 되었지만 쿠폰 ..