MSA/Event Driven Architecture

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

개발자 이우진 2024. 7. 14. 00:59

개요

  • 아파치에서 스칼라로 개발한 오픈소스 메세지 브로커
  • 링크드인에서 최초 개발
  • 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 개요, 장용규님
저작자표시 (새창열림)