Apache Kafka ‐ A to Z - dnwls16071/Backend_Summary GitHub Wiki

📚 Kafka 도입 후의 아키텍처 다이어그램

데이터 흐름

  • 주문 서비스가 주문 이벤트를 order-events 토픽에 발행
  • 중앙 데이터 버스(=kafka)가 이벤트를 저장하고 배포
  • 독립 소비자 시스템(=consumer)가 각자 필요한 이벤트를 구독

아키텍처 특징

  • EDA : 이벤트 발생 → 비동기 처리
  • Loose Coupling : 서비스 간 직접 의존성 없이 Kafka를 통한 간접 통신
  • 확장성 : 새로운 소비자 서비스 추가가 용이
  • 장애 격리 : 한 서비스 장애가 다른 서비스에 직접적으로 영향을 주지 않음

📚 Kafka 내부 아키텍처⭐

Core Kafka 컴포넌트

  • Kafka Cluster : 여러 브로커로 구성된 분산 메시징 시스템
  • Broker : 메시지를 저장하고 처리하는 서버 노드
  • Topic : 메시지가 저장되는 논리적 채널
  • Partition: Topic 내에서 데이터를 분산 저장하는 물리적 단위
  • Leader/Follower : 파티션의 읽기/쓰기 담당과 복제본
  • Producer : 메시지를 Topic에 발행
  • Consumer : Topic으로부터 메시지를 구독
  • Consumer Groups : 메시지를 분산 처리하는 Consumer들의 그룹

Schema Registry 컴포넌트

  • Schema Registry : 스키마 저장 및 버전 관리 서비스
  • Schema : 데이터 구조 정의
  • Subject : 스키마 진화 범위를 정의하는 논리적 그룹
  • Compatibility Type : 스키마 호환성 검사 규칙
  • Serializer/Deserializer : 데이터 직렬화/역직렬화

확장

  • Kakfa Connect : 외부 시스템과의 데이터 파이프라인 구축 도구
  • Kafka Streams : 실시간 스트림 처리 라이브러리
  • ZooKeeper/Kraft : 클러스터 메타데이터 및 코디네이션 관리

📚 세그먼트 단위 저장 시스템⭐

저장 시스템 특징

  • 카프카는 효율적인 저장 및 관리를 위해 파티션 데이터를 세그먼트로 구성한다.
  • 활성 세그먼트(Active Segment) : 현재 새로운 메시지가 쓰여지고 있는 세그먼트
  • 일반 세그먼트(Segment) : 이미 닫힌 세그먼트로 더 이상 쓰기가 발생하지 않는다.

동작 원리

  • 프로듀서가 메시지를 보내면 활성 세그먼트에 순차적으로 추가된다.
  • 세그먼트가 설정된 크기나 시간 제한에 도달하면 새로운 활성 세그먼트가 생성된다.
  • 각 세그먼트는 연속된 오프셋 범위를 가지며 파일명에 시작 오프셋이 표시된다.

세그먼트의 내부 구조

  1. .log : 실제 메시지 데이터
  • 실제 메시지 내용이 저장되는 핵심 파일
  • 각 오프셋에 해당하는 메시지 데이터가 순차적으로 저장
  • 메시지는 바이트 스트림 형태로 연속해서 저장
  1. .index : 오프셋 인덱스
  • 물리적 위치 매핑 정보를 저장
  • 특정 오프셋 메시지를 빠르게 찾기 위한 색인 역할
  1. .timeindex : 타임스탬프 인덱스
  • 오프셋 매핑 정보를 저장
  • 특정 시간대의 메시지를 찾기 위한 시간 기반 색인 역할

동작 원리

  • 메시지 저장은 .log 파일에 순차적으로 저장
  • .index 파일을 통해 오프셋 기반으로 빠르게 접근
  • .timeindex 파일을 통해 시간대별 메시지를 조회

📚 장애 극복 시스템 브로커, 클러스터, 주키퍼

장애 복구

  • 브로커에서 장애가 발생하면 컨트롤러 브로커에게 알려 새로운 리더를 선출한다.
  • 브로커의 장애 시에도 무중단 서비스를 제공하며 자동으로 새로운 리더를 선출해 HA를 보장한다.

복제 구조

  • 리더는 읽기/쓰기를 처리하고 팔로워는 리더로부터 데이터를 복제(ISR_
  • 각 파티션은 여러 브로커에 복제되어 저장

📚 Kafka 프로듀서 심화 - 멱등성, 트랜잭션, 최적화⭐

멱등성(Idempotent)

  • 프로듀서 → 각 프로듀서는 고유한 Producer ID(PID)를 가진다.
  • 시퀀스 번호(Seq) → 각 메시지마다 순차적인 번호를 부여

중복 방지 메커니즘

  • 브로커가 PID와 Seq를 확인하고 이미 처리된 메시지인지를 확인해 폐기한다.
  • 이로 인해 정확히 한 번(Exactly Once) 전송을 보장한다.
  • 네트워크 장애 상황에서도 메시지 중복을 방지한다.
  • 프로듀서의 안정성과 데이터 일관성을 향상시킬 수 있다.

트랜잭션 프로듀서

  • init : 트랜잭션 초기화
  • begin : 트랜잭션 시작
  • send(TopicA, msg1) : TopicA에 msg1 전송
  • send(TopicB, msg2) : TopicB에 msg2 전송
  • commit or abort : 커밋 또는 롤백

Commit 경우

  • 두 토픽의 모든 메시지가 컨슈머에게 가시화
  • 원자성(Atomicity) 보장 → 모든 메시지가 성공적으로 처리

Abort 경우

  • 두 토픽의 모든 메시지가 영구 폐기
  • 일관성(Consistency) 보장 → 부분 실패 방지

📚 Kafka 컨슈머 심화 - 리밸런싱, 오프셋, 커밋⭐

장애 감지 방식

  • Heartbeat 기반 모니터링
  • Consumer → Group Coordinator로 주기적 하트비트 전송
  • heartbeat.interval.ms 간격으로 생존 신호를 확인

장애 판단 조건

  • session.timout.ms 시간 동안 하트비트가 없는 경우
  • poll() 간격이 max.poll.interval.ms 초과하는 경우

장애 처리 프로세스

  • Rebalancing(리밸런싱) : 파티션 재할당을 통한 자동 복구

Auto Commit

  • 시간 기반 커밋
  • 메시지 손실 우려
  • 성능 Good(비동기)
  • enable.auto.commit=true

Manual Commit

  • 처리 완료 후 커밋
  • 메시지 안전 보장
  • 성능 Bad(동기)
  • enable.auto.commit=false