Skip to content

Kafka

아파치 카프카는 아파치 소프트웨어 재단이 스칼라로 개발한 오픈 소스 메시지 브로커 프로젝트이다. 이 프로젝트는 실시간 데이터 피드를 관리하기 위해 통일된, 높은 처리량, 낮은 지연시간을 지닌 플랫폼을 제공하는 것이 목표이다.

Categories

  • ktea - Kafka 터미널 클라이언트

목적

카프카가 링크드인 요구 사항을 어떤 수단으로 실현했는지 살펴보자.

요구 사항

  • 높은 처리량으로 실시간 처리한다.
  • 임의의 타이밍에 데이터를 읽는다.
  • 다양한 제품과 시스템에 쉽게 연동한다.
  • 메시지를 잃지 않는다.

실현 수단

  • 메시징 모델과 스케일 아웃형 아키텍처
  • 디스크로의 데이터 영속화
  • 이해하기 쉬운 API 제공
  • 전달 보증

Message Queues

kafka는 왜 빠를까?

  • kafka는 왜 빠를까? | GeekNews
    • [원문] (java) 카프카는 왜 빠를까? | frogred8
      • (@vwjdalsgkv 주석) 본문상 내용중 nio를 살짝 헷갈리신것같은데 nio는 non blocking io가 아니라 new io입니다. block이랑 non block 모두 지원해요
  • 카프카가 빠른 일반적 이유
    • 저지연 I/O 사용 (ram)
    • 순차적 I/O 자료구조 사용 (log)
    • zero-copy 적용
    • 수평 확장 시스템
    • 데이터 압축 및 일괄 처리
  • zero-copy란?
    • file을 socket으로 복사할 때 발생하는 부하를 개선한 os 지원 인터페이스
    • linux에서는 sendfile 명령
  • 그래서 kafka는 어떻게 zero-copy로 인해 빨라졌는가?
    • java에서 nio패키지에 transferTo 함수가 추가됨
    • 이를 사용하여 kafka는 메시지를 유저 영역으로 가져오지 않고, 커널 영역에서 네트워크로 바로 전송하여 속도에 많은 이점을 가짐
    • 기존 방식과 transferTo를 사용한 방식의 성능 측정 시 후자가 65% 더 빠른 결과를 보여줌

Kafka를 처음부터 다시 만들 수 있다면

  • Kafka를 처음부터 다시 만들 수 있다면 어떨까? | GeekNews
  • KIP-1150(디스크 없는 Kafka)과 AutoMQ의 Kafka 포크 프로젝트를 통해 클라우드 최적화 Kafka 논의가 활발해짐
  • Kafka를 다시 만든다면 기존 파티션 구조를 제거하고 키 중심 접근을 제안
  • 동시성 제어와 브로커 사이드드 스키마 지원 기능이 필요한 상황임
  • 확장성, 스냅샷, 멀티 테넌시 같은 최신 시스템 특징을 통합할 필요성도 강조
  • Kafka를 기반으로, 기존 Kafka의 한계를 넘어서는 진정한 클라우드 네이티브 이벤트 로그 시스템에 대한 상상

Kafka를 다시 만든다면?

  • 최근 KIP-1150(디스크 없는 Kafka)과 AutoMQ의 Kafka 포크가 발표되었고, 이는 S3와 같은 객체 스토리지와 Kafka를 통합하여 클라우드 환경에서 탄력성 개선과 비용 절감을 목표로 함
  • 기존 Kafka의 한계를 넘어서는 클라우드 네이티브 이벤트 로그 시스템을 상상하며 다양한 개선 사항을 제안함

파티션 없는 구조 제안

  • 클라우드 객체 스토리지가 무한대 스토리지처럼 동작하기 때문에 토픽 파티션의 필요성이 감소함
  • 글로벌 메시지 순서 또는 동일 키를 가진 메시지 순서만 중요한 경우가 많음
  • 사용자에게 파티션 개념을 숨기고 단순화된 사용성을 제공할 수 있음

키 중심 접근

  • 파티션 스캔이 아니라 특정 키의 모든 메시지에 빠르게 접근하고 재생할 수 있도록 설계 제안
  • 수백만 개의 엔터티 수준 스트림을 지원해 수요에 따라 소비자 수를 유동적으로 조정할 수 있음
  • 실패가 키 단위로 격리되므로 시스템 전체의 처리 효율성이 증가함
  • 이벤트 소싱이나 액터 모델 시스템에 이상적인 구조임

토픽 계층 구조 지원

  • Solace와 같은 시스템처럼 메시지 페이로드 일부를 구조화된 경로 형태의 토픽 식별자로 승격시켜 패턴 기반 구독을 가능하게 해야 함
  • 브로커가 전체 메시지를 파싱하지 않고도 효율적으로 구독 필터링을 지원할 수 있음

동시성 제어 기능

  • 현재 Kafka는 기록 시 동시성 충돌을 방지할 방법이 없음
  • 키별로 낙관적 락(optimistic locking)을 지원하면, 메시지가 최신 상태를 본 후 기록되었는지 검증할 수 있음
  • 업데이트 손실 문제를 방지할 수 있음

브로커 사이드드 스키마 지원

  • Kafka는 현재 메시지를 단순 바이트 배열로 취급해 외부 스키마 레지스트리에 의존함
  • 스키마 일관성 확보를 위해 브로커 차원에서 AsyncAPI 메타데이터 같은 스키마 정보를 기본 지원할 필요성 제안
  • 이를 통해 Apache Iceberg 같은 오픈 테이블 포맷에도 쉽게 연동할 수 있음

확장성과 플러그인 구조

  • Postgres, Kubernetes처럼 확장성과 플러그인 가능성을 갖춘 구조를 제안
  • 프로토콜 인식 프록시(Kroxylicious 등)가 없이 브로커 단 필터나 변환을 쉽게 구현할 수 있어야 함
  • 속도 제한, 토픽 암호화, Iceberg 테이블 기반 백엔드 지원 등이 플러그인으로 구현 가능해야 함

동기적 커밋 콜백

  • 현재 Kafka는 최종 일관성만 보장함
  • 프로듀서가 메시지를 전송한 후, 해당 파생 데이터가 업데이트되었는지 즉시 확인 가능한 구조 필요성 제안
  • 자기 쓰기 읽기 보장(read-your-own-writes) 를 지원해 Kafka를 진정한 데이터베이스 로그로 사용할 수 있게 함

스냅샷 기능

  • Kafka의 현재 압축(compaction)은 마지막 메시지만 남기는데, 이는 전체 상태를 포함하는 경우에만 유효함
  • 변경 사항만 기록하는 경우에는 키별로 이벤트를 모두 재생해야 하므로 시간이 증가함
  • 키 단위로 이벤트를 스냅샷으로 요약하는 논리적 압축 기능이 필요함

멀티 테넌시 기본 지원

  • 모든 현대적 데이터 시스템은 멀티 테넌시를 기본으로 고려해야 함
  • 신규 테넌트 환경을 저렴하고 즉시 생성 가능하게 하고, 자원, 보안, 접근 제어를 철저히 분리해야 함

기타 참고사항

  • 일부 기능은 S2(고카디널리티 스트림), Waltz(낙관적 락), Apache Pulsar(멀티 테넌시) 같은 시스템에서 이미 지원되고 있음
  • 하지만 제안된 모든 기능을 동시에 지원하는 오픈소스 시스템은 존재하지 않음
  • 이 글은 Confluent 소속 저자의 개인적 견해이며 공식 입장은 아님
  • 이론적으로는 LSM 트리 기반 아키텍처가 유력한 선택이 될 것이라고 언급함

See also

Favorite site