[Kafka] 개요, 사용 목적, 특징, 구성

개요

• 아파치에서 스칼라로 개발한 오픈소스 메세지 브로커
• 링크드인에서 최초 개발
• 2011년 오픈소스화
• 링크드인에서는 백엔드 데이터 흐름 처리 위한 목적
  • 스트리밍 데이터 원할한 처리
• 정적인 데이터 저장이 아닌 동적인 데이터 처리 주 목적
  • 계속적으로 변하는 스트리밍 데이터
    ⇒ 현대의 기업은 정적인 DB로는 관리할 수 없는 복잡성, 다양성을 띈 데이터 처리할 수 있는 시스템 요구
  • ex) 배민 라이더 위치 추적, 지하철 칸별 혼잡도
• RDBMS의 트랜잭션 로그 마이너 기술 영향을 받아서 만들어졌음
  • 데이터가 생성, 변경될 때 마다 로그를 기록

목표

• 고성능
• 이벤트
• 분산
• 스트리밍
  • 카프카 스트림이라는 별도의 기술(api) 사용
  • 스트리밍 프로세스에 최적화된 방법 제공

사용 목적

• 시스템 또는 애플리케이션 간에 실시간 데이터 파이프라인 만들 때 사용
• 대용량 실시간 로그 처리에 특화되어 있는 솔루션
• 데이터를 유실 없이 안전하게 전달하는 것이 주 목적인 메세지 시스템활용 사례
• 초기에는 ETL과 메세지 교환 등 정적 메세지 처리 용도
  현재에는
• 이벤트 주도 마이크로서비스 환경에서 각 서비스 이벤트를 연동할 때
• 실시간 스트림 처리
• IoT - 센서, 자율 주행
• 머신 러닝 파이프라인
• 실시간 게임 플레이 데이터
• 실시간 위치 추적
• 대용량 스트리밍 서비스
  • 넷플릭스

특징

• 다중 producer, consumer 지원
• 파일 시스템 기반
• 확장성
• 고가용성
• 고성능
• pull 방식 (Consumer 입장)
• 파일 시스템 기반, pull 방식이 다른 메세지 브로커와의 큰 차이

파일 시스템 기반

• 전통적인 메세징 시스템
  • ActiveMQ, RabbitMQ
  • 전송한 메세지를 메모리 유지
  • 정적 성격 데이터 아니다 하고 생각하고 설계
  • 빠르게 소비되어야 하는 메모리 상의 데이터
  • 메모리 데이터
• 카프카
  • 프로듀서가 생성한 메세지를 파일 시스템에 저장
  • 메세지 보존 기간 내에는 언제든지 읽어갈 수 있음
  • 풀 방식 가능해지는 특징
• 유일하지는 않는데 카프카가 대표적인 기술
• 프로듀서와 컨슈머의 속도(성능) 차이가 있을 때 유용
• 컨슈머가 데이터 소비하는 것이 아니라 모았다가 처리하는 배치 처리 가능하게 함
• 컨슈머 쪽에서 에러가 생겼을 때 이전에 읽었던 데이터를 다시 가져갈 수 있게 해준다
• 최소한 한 번의 메세지 전송 보장 (신뢰성)

Pull 방식 (Consumer의 메세지 수신 방식)

일반적인 메세지 브로커와 반대
consumer에게 push하지 않음

• pull 방식 채택
  • 가져가는 쪽에서 필요한 만큼
• 컨슈머의 처리량을 브로커가 고려하지 않아도 됨
• 컨슈머는 자기가 처리할 수 잇는 메세지만 폴링
  • 메세지 처리 성능 최적화
• 프로듀서의 성능보다 일반적으로 컨슈머의 처리 속도가 느림
  • 그럴 때 컨슈머 추가해서 처리량 늘릴 수 있다
• Consumer가 주기적으로 Polling을 해서 메세지를 읽음

다중 producer, consumer

• 여러 프로듀서가 동시 메세지 발행 가능
• 여러 컨슈머가 읽을 수 있음
• 토픽 방식
  • 큐 방식, 토픽 방식 중
    ⇒ 하나의 카프카 시스템을 통해 다양한 애플리케이션이 데이터를 주고받을 수 있음

확장성

• 여러 마이크로서비스 기술 가지고 있는 특징
• 기본적으로 클러스터 구성
• 서비스 중단 없이 확장 용이하도록 설계
• 토픽, 파티션 구성도 운영 중 추가 가능
• 토픽의 데이터는 내부의 파티션 세분화된 단위로 저장
• Consumer 는 Consumer Group으로 묶이며, 필요 시 컨슈머 그룹에 추가 가능
  • 컨슈머 그룹에 컨슈머가 추가되면 컨슈머의 파티션 소유권이 재분배되는 리밸런스 과정 수행
    • 리밸런스 부하 많이 줘서 일반적으로는 일어나지 않도록 설계함
  • 리밸런스 과정 후 컨슈머 그룹에 속한 컨슈머가 고르게 할당

고가용성

• 파티션 데이터의 복사본(replication)을 가지고 있음
• 데이터의 중요성에 따라 Replication factor 설정

고성능

• 기본적으로 성능이 좋다
• 높은 처리량
• 이를 위해 일반적인 범용 메시징 시스템이 지원하는 몇 가지를 포기
  • 메세지 처리를 위한 복잡한 승인 프로토콜
  • 복잡한 메세지 라우팅 및 필터링 기능
  • 메세지 우선 순위, 순차적 전달 보장
    • 설정은 가능하나 일반적으로는 offset
    • 단순한 메세지 처리 방식으로 설계
    • 순위, 순차 보장 필수는 아님

Broker 클러스터 구성

• 클러스터
  • 여러 서버를 묶어서 하나의 시스템으로 작동하게 하는 것
  • 내부적으로는 분산된 여러 시스템
  • 고가용성 서비스 제공
• 클러스터 구성 및 관리를 위한 Zookeeper가 필요
  • Zookeeper(사육사)
    • 브로커 노드들 관리 담당
    • 메타 정보 관리
    • 카프카에만 쓰이는 것은 아니다
    • 여러 노드로 구성하는 마이크로서비스 노드 상태 관리에도 zookeeper 사용
    • 분산 시스템 마스터 역할 선출
• 주키퍼 클러스터 + 브로커 클러스터
  • 브로커가 3개면 주키퍼도 3개 클러스터
• 일반적 최소 사양
  • 주키퍼 3EA, 카프카 3EA
  • 기본 구성
  • 왜 3개가 필요한가?
    • 다수결의 방식으로 리더 선정하는 포럼 기반
    • 최소 3개 필요
    • 마스터 선출되려면 2개 이상의 노드 동의
    • 앙상블. 합의에 도달하고 과반수 포럼 기반 작동
    • 마스터 선출
    • 마스터 문제되면 후보

Controller: 다른 브로커를 지휘하는 브로커

• 브로커 상태 체크
  • 특정 브로커가 컨트롤러 역할
• 셧다운, 정상 작동 못 하는 경우 새로운 리더(또 다른 브로커) 선출
• 다른 브로커 생존 여부 모니터링
  • 토픽은 파티션에 들어가기 때문에 리더 파티션
  • 리더 파티션 가지는 브로커 문제 생기면 탈락. 다른 팔로워
• 컨트롤러가 중단된 경우
  • 주키퍼가 감지하여 새로운 컨트롤러 선출
• 브로커가 종료될 때, 컨트롤러를 통한 복제 파티션의 리더 재선출 과정 발생
  • 컨트롤러가 리더 파티션 정보 가지고 있음
  • 파티션 정보 바꾸고 주키퍼에게 알려줌
  • 리더 바꿈

메세지 저장 성능 극대화: log append-only

• 브로커는 파일 시스템 기반
• 로그 자료구조 형태로 디스크에 저장
  • RDBMS의 트랜잭션 로그 마이너 영향
  • 로그 형태로 디스크 저장
• 로그는 새로운 쓰기 작업이 중간에 삽입되지 않고 오로지 끝에서만 추가되는 append-only 특징
  • 쓰기 성능 극대화
• 메세지들은 파티션별로 세그먼트 단위의 파일로 저장
• ⇒ 파티션으로 발행되는 메세지를 세그먼트 파일에 쓰고, 컨슈머는 이 파일을 읽어가서 메세지를 구독*

메세지 레코드의 구조

• 헤더
  • 토픽
  • 파티션
  • 메세지 생성 시간
• 메세지 키
• 메세지 값

토픽

• ex) ORDER_APPROVED: 주문 확정 메세지

키

• 메세지 유니크한 키값
  • DB의 PK와 비슷한 개념
• Optional
• 순차 메세지 보장하지 않음
• 정렬하지 않음

파티션

• Consumer가 메세지를 처리하는 단위
• Consumer:Partition은 1:N 관계를 맺고 있다
  • One consumer hasMany partitions
  • Consumer는 Partition을 중첩 없이 소유한다
• 지정하지 않으면 라운드 로빈 방식으로 자동 할당
• 파티션을 설계할 때 특정 파티션에 메세지가 몰리지 않도록 유의해야 한다
  • 리밸런싱이 부하가 크기 때문이다
  • 리밸런싱: 컨슈머 추가, 이탈 시 파티션 소유권을 재조정하는 작업
  • 리밸런싱을 최소화해야 한다
  • 리밸런싱이 일어나지 않게 파티션 용량을 여유롭게 설정하는 것도 하나의 방법

Consumer Group

• 주로 마이크로서비스가 scale-out됐을 때 같은 종류의 노드를 묶을 때 쓴다
  • ex) 주문 마이크로서비스 그룹
• 분할된 파티션을 병렬 처리하여 성능 극대화
  • 같은 토픽의 메세지를 여러 컨슈머가 나눠서 처리한다Auto Commit
• 컨슈머 오프셋을 자동으로 업데이트할 지 여부
• false일 경우, 커밋 코드를 직접 작성해야 함
  • 데이터를 처리한 후 커밋을 한다
• 일부 데이터가 중복, 유실되어도 상관없는 환경에서 사용
  • 센서, GPS 등
• 중복, 유실 허용하지 않는 곳에서는 수동 커밋
  • 은행, 카드사

출처

• 제로베이스 EDA 특강 3주차 - EDA 대표 기술: Kafka 개요, 장용규님