[실전 카프카 개발부터 운영까지] 1장. 카프카 개요

[kmg28801]

개요

• 이벤트 드리븐 시스템 구성에서 가장 중요한 사항은 바로 인바운드 데이터와 아웃바운드 데이터가 동일해야 한다
• 카프카가 잘란도의 대안으로 부상한 이유는 아래와 같다.
  • 높은 처리량
  • 순서 보장
  • 적어도 한 번 전송 방식
  • 강력한 파티셔닝
  • 자연스러운 백프레셔 핸들링
  • 로그 컴팩션

카프카의 특징

• 순서 보장

  • 이벤트 처리 순서가 보장되면서, 엔티티 간의 유효성 검사나 동시 수정 같은 무수한 복잡성들이 제거됨으로써 구조 또한 매우 간결

• 적어도 한 번 전송 방식

  • 분산된 여러 네트워크 환경에서의 데이터 처리에서 중요한 모범 사례는 멱등성
  • 멱등성 : 동일한 작업을 여러 번 수행하더라도 결과가 달라지지 않는 것을 의미
  • 프로듀서가 재전송을 하더라도 데이터 변화는 일어나지 않음
  • 이벤트들이 중복 발행할 수는 있으나 누락 없는 재전송이 가능하므로 메시지 손실에 대한 걱정이 사라짐

• 자연스러운 백프레셔 핸들링

  • 카프카의 클라이언트는 풀(pull) 방식으로 동작
  • 풀 방식의 장점으로는 자기 자신의 속도로 데이터를 처리할 수 있다는 점
  • 반면 푸쉬 방식은 브로커가 보내주는 속도에 의존하는 한계
  • 성능과 편리함에 집중하고자 풀 방식을 채택한 카프카 클라이언트는 복잡한 피드백이나 제한의 요구사항이 사라져 매우 간단하고 편리하게 클라이언트 구현 가능

• 강력한 파티셔닝

  • 카프카의 파티셔닝 기능을 이용하면, 논리적으로 토픽을 여러 개로 나눌 수 있다.
  • 파티션에 적절한 키를 할당하기 위한 여러 고려사항은 있"지만, 각 파티션들을 다른 파티션들과 관계없이 처리할 수 있으므로 효과적인 수평 확장이 가능

• 카프카 스트림즈 : 맵리듀스 스타일 연산에 필요한 기본 요소를 갖췄으며, 실시간 처리도 가능

• 이벤트 버스는 서빙 레이어와 스토리지 레이어가 분리되어 있어 추가적인 홉이 필요하지만, 카프카는 하나의 프로세스에서 스토리지와 요청을 모두 처리한다는 장점이 있음

• 이벤트 버스는 fsync()를 하는 동안 블로킹을 하는 반면, 카프카는 OS에 의존해 백그랑룬드로 fsync()를 처리하고 제로카피를 사용

• 고가용성 : 카프카는 2013년에 클러스터 내 리플리케이션 기능을 추가했고, 이를 통해 카프카 클러스터의 고가용성이 확보

• 내구성 : 프로듀서는 카프카로 메시지를 전송할 때, 프로듀서의 acks라는 옵션을 조정하여 메시지의 내구성을 강화

  • 강력한 메시지의 내구성을 원한다면 옵션을 acks=all로 사용
  • 프로듀서에 의해 카프카로 전송되는 모든 메시지는 안전한 저장소인 카프카의 로컬 디스크에 저장
  • 전통적인 메시징 시스템의 경우, 컨슈머가 메시지를 가져감과 동시에 저장소에서 메시지가 삭제되지만, 카프카는 컨슈머가 메시지를 가져가더라도 메시지는 삭제되지 않고 지정된 설정 시간 또는 로그의 크기만큼 로컬 디스크에 보관되므로, 코드의 버그나 장애가 발생하더라도 과거의 메시지들을 불러와 재처리 가능
  • 메시지들은 브로커 한 대에만 저장되는 것이 아니라 두 대 또는 세 대의 브로커에 저장되므로, 브로커 중 한 대가 종료되더라도 다른 브로커의 로컬 디스크에 저장된 내용을 바탕으로 복구 가능

• 개발 편의성 : 카프카는 메시지를 전송하는 역할을 하는 프로듀서와 메시지를 가져오는 역할을 하는 컨슈머가 완벽하게 분리되어 동작하고 서로 영향을 주지도 받지도 않는다.

  • 카프카 커넥트와 스키마 레지스트리를 제공

카프카의 성장

• 리플리케이션 기능 추가 (v0.8)

  • 카프카는 2013년 12월 버전 0.8을 세상에 공개하면서, 카프카에 리플리케이션 기능을 추가
  • 0.8 버전부터 내부 카프카 클러스터에서 브로커의 장애가 발생해도 리플리케이션 기능으로 인해 데이터 유실 없이 안정적으로 사용 가능

• 스키마 레지스트리 공개 (v0.8.2)

  • 카프카의 데이터 흐름은 대부분 브로드캐스트 방식이라 컨슈머 입장에서는 데이터를 전송하는 프로듀서를 일방적으로 신뢰할 수 밖에 없는 구조
  • 프로듀서와 컨슈머 간 서로 데이터 구조를 설명할 수 있는 스키마를 등록 지정해, 사용하는 스키마 레지스트리가 2015년 2월 카프카 0.8.2 버전이 발표되면서 공개
  • 프로듀서와 컨슈머는 이 스키마 레지스트리를 이용해 스키마를 등록할 수 있고, 이를 통해 스키마에 정의된 데이터만 주고 받는다.

• 카프카 커넥트 공개 (v0.9)

  • 카프카를 사용하려면 카프카 클라이언트인 프로듀서 API, 컨슈머 API 이용이 필요
  • 카프카 커넥트를 이용해 별도의 코드 작성 없이도 다양한 프로토콜과 카프카를 연동 가능

• 카프카 스트림즈 공개 (v0.10)

  • 카프카에서는 실시간 처리에 대한 니즈를 충족시키고자 카프카 스트림즈를 공개

• KSQL 공개 : 2017년 8월

• 주키퍼 의존성에서 해방 (v3.0)

  • 아직은 운영 환경에서 사용하는 것을 추천하지 않음
  • 주키퍼의 의존성을 제거하면서 새롭게 도입된 합의 프로토콜인 크래프트를 카프카 전반에 적용하려는 양상이 두드러짐
  • 프로듀서의 전송 보장에 대해 중복 없는 전송 방식을 기본값으로 채택
  • 컨슈머의 session.timeout.ms 기본값을 늘려 컨슈머의 안정성을 높임

아키텍처

• 데이터 처리 아키텍처 중 배치 파이프라인과 실시간 파이프라인이 있는 것을 람다 아키텍처라고 한다.
• 람다 아키텍처는 배치와 스트림 처리의 장점
• 람다 아키텍처는 일반적으로 배치 처리를 위한 배치 레이어, 실시간 처리를 위한 스피드 레이어, 배치와 스트림 처리의 아웃풋 을 담당하는 서빙 레이어로 구성됨