[KOSTA] Kafka with Spring Boot - 1편

 

 

※ 보편적으로 많이 사용했던 버전을 기준으로 작성 됨. 최신 버전은 구조가 바뀌어 있을 수 있다. ※ 

- 내용이 많아서 1편과 2편으로 나눴습니다. -

 

 

아파치 카프카 개요

• Apache Kafka(아파치 카프카)는 LinkedIn에서 개발된 분산 메시징 시스템으로써 2011년에 오픈소스로 공개되었음
• 카프카는실시간으로기록스트림을 게시,구독,저장및처리할수있는분산데이터 스트리밍 플랫폼
  • 게시: 아파트 벽보와 같이 게시를 하는데, 포스트를 하는 사람은 포스트만 하면 됨
  • 구독: 아파트 벽보에 있는 게시글을 읽는 행위.
  • 저장 및 처리: 이전 게시판에 있던 게시글(메세지)를 저장하고 처리할 수 있어야 한다.
• 대용량의 실시간 로그처리에 특화된 아키텍처 설계를 통하여 기존 메시징 시스템보다 우수한 TPS를 보여주고 있음
• 어떤 특정 디바이스를 대상으로 통신을 보내지 않는다.
  • 데이터들이 범용성(데이터 구조 표준이 있음.)을 나타내게 된다

 

• 카프카는 대량의 데이터를 높은 처리량과 실시간으로 취급하기 위한 제품으로 다음 4 가지를 실현할 수 있다.
  ※ 고가용성(高可用性, 영어: high availability, HA)은 서버, 네트워크, 프로그램 등의 정보 시스템이 상당히 오랜 기간 동안 지속적으로 정상 운영이 가능한 성질
  
  • 확장성:여러서버로확장(scaleout)구성할수있기때문에데이터양에따라시스템확장 이 가능함
  • 영속성:수신한데이터를디스크에유지할수있기때문에언제라도데이터를읽을수있음
  • 유연성:연계할수있는제품이많기때문에제품이나시스템을연결하는허브역할
  • 신뢰성:‘메시지전달보증’을하므로데이터분실을걱정하지않아도됨
    → 어느 정도의 신뢰성을 부여할지 조절할 수 있다.

 

카프카 탄생 배경

• 카프카는 2011년 미국 링크드인에서 출발함
• 카프카는 링크드인 웹사이트에서 생성되는 로그를 처리하여 웹사이트 활동을 추적하는 것을 목적으로 개발 되었음
• 웹 사이트에서의 활동은 사용자가 페이지뷰와 검색시 키워드 광고의 이용 상황도 포함
• 웹에서 생성되는 대량의 로그를 분석하여 사용자가 웹에서하는 활동을 모니터링하고 서비스 개선에 활용하는 것

 

• 링크드인의 시스템 요구사항 목표
  • 높은 처리량으로 실시간 처리한다
  • 임의의 타이밍에서 데이터를 읽는다
  • 다양한 제품과 시스템에 쉽게 연동한다
  • 메시지를 잃지 않는다

 

 

 

버퍼 역할은 중간에 잠시 쉬었다가는 역할을 한다.

• 카프카 이전 제품
  • 메시지 큐
  • 한 건의 레코드 단위로 실시간 처리를 할때 가장 먼저 떠오르는 것이 메시지큐
  • 메시지 큐 제품으로는 IBM의 WebSphere MQ와 JMS(java Messaging System) 사양을 따르는 아파치 ActiveMQ, 그 외 RabbitMQ가 있음

• 메시지 큐의 한계

  • 강력한 전달 보증이 오버 스펙
  • 스케일 아웃(확장성)이 용이한 제품이 아님
  • 메시지가 대량으로 쌓이는 것을 예상하지 않았다

 

• 로그수집시스템
  • 특징 
    • 실시간으로 데이터를 수집한다는 관점에서 생각할 수 있는 것은 로그 수집을 위한 미들웨어
    • 주로 웹서버 등의 프론트 엔드 서버의 로그를 수집하기 위한 것
    • 당시 이 카테고리의 제품으로 존재하고 있던 것은 페이스북이 개발한 Scribe와 미국 클라우데라가 개발한 Flume
  • 단점
    • HDFS로 데이터 축적과 배치 처리만 고려했다
    • 알기 쉬운 API가 없다
    • 수신하는 쪽이 임의로 메시지를 수신하기 어렵다
       

 

• ETL(extract,transform,load)도구
  • 컴퓨팅에서 데이터베이스 이용의 한 과정으로 특히 데이터 웨어하우스에서 다음을 아우른다
  • 동일 기종 또는 타기종의 데이터 소스로부터 데이터를 추출한다.
  • 조회 또는 분석을 목적으로 적절한 포맷이나 구조로 데이터를 저장하기 위해 데이터를 변환한다.
  • 최종 대상(데이터베이스, 특히 운영 데이터 스토어, 데이터 마트, 데이터 웨어하우스)으로 변환

 

 

카프카로 링크드인 요구 사항 실현하기

• 요구사항
  • 높은 처리량으로 실시간 처리한다
  • 임의의 타이밍에 데이터를 읽는다
  • 다양한 제품과 시스템에 쉽게 연동한다
  • 메시지를 잃지 않는다
• 실현수단
  • 메시징 모델과 스케일 아웃형 아키텍처
  • 디스크로의 데이터 영속화
  • 이해하기 쉬운 API제공
  • 전달 보증 

 

• 메세징 모델은 세 가지고 요소로 구성됨
  • Producer : 메시지생산자
  • Broker : 메시지 수집/전달 역할
  • Consumer : 메시지 소비자

 

큐잉 모델

• 큐에서 추출된 메세지는 컨슈머에 도달하면 사라진다.

 

Publish/Subscribe(펍/섭) 메시징 모델

• 특징
  • 서브 스크라이버는 여러 개 존재하는 토픽 중 하나를 선택하여 메시지를 받음
  • 여러 서브 스크라이버가 동일한 토픽을 구독하기로 결정한다면, 이 여러 서브 스크라이버는 동일한 메시지를 받음
  • 또한 다른 토픽에서는 다른 메시지를 받을 수 있음

 

 

 

 

• 컨슈머 그룹

 

 

 

 

• 디스크로의 데이터 영속화
  • 임의의타이밍에데이터를읽는다.
  • 메시지를잃지않는다.
    (단, 고장에 의한 최근 메시지 손실 회피 목적은 아님)
  • 카프카는 디스크에 영속화 함에도 불구하고 높은 처리량을 제공한다

 

• 이해하기 쉬운 API

 

• 전달 보증
  • 메시지 생산자 입장에서 매우 당연한 요구인 메시지를 잃지 않고 전달하는데 있어 카프카는 전달 보증 기능을 제공
  • 'At Most Once', 'At Least Once', 'Exactly Once' 세 가지 수준으로 전달을 보증

 

 

• Ack
  • 브로커가 메시지를 수신했을 때 프로듀서에게 수신을 완료했다는 응답을 뜻함
  • 프로듀서가 Ack를 받지 못한 경우에 재전송해야 한다고 판단할 수있음

• 오프셋 커밋

 

 

카프카 기초

메세지 송수신 기본

 

카프카의 주요 구성 요소 5가지

• 브로커
  • 데이터를 수신, 전달하는 서비스
• 메시지
  • 카프카에서 다루는 데이터의 최소 단위.
  • 카프카가 중계하는 로그의 한 줄 한 줄과 센서데 이터 등이 이에 해당.
  • 메시지는 Key와 Value를 갖게 되며 메시지 전송할 때 파티셔닝에 이용
• 프로듀서
  • 데이터의 생산자이며 브로커에 메시지를 보내는 애플리케이션
• 컨슈머
  • 브로커에서 메시자를 취득하는 애플리케이션
• 토픽
  • 메시지를 종류(토픽)별로 관리하는 스토리지 브로커에 배치되어 관리
  • 프로듀서와 컨슈머는 특정 토픽을 지정하여 메시지를 송수신함으로써 단일 카프카 클러스터에서 여 러 종류의 메시지를 중계함

 

 

시스템 구성

• 보러커

 

 

 

병렬처리를 위한 구조가 아니기 때문에 컨슈머 그룹 안의 컨슈머에게 나눠 주기 위해서 파티션이 필요하다.

토픽 안에 파티션의 수와 컨슈머 그룹 안의 컨슈머 수가 같거나 파티션의 수가 더 많아야 한다.

처음에는 파티션을 하나로 시작하고, 조금씩 늘려나가도록 한다(규모 확장).

파티션을 늘릴 수는 있지만 줄이거나 또는 합칠 수는 없다.

 

카프카 상태에서 따라서 어떻게 될지 모르기 때문에. 오래된 데이터는 Dupm를 만들어서 저장한다.

 

• 프로듀서 API / 컨슈머 API

 

• 프로듀서

 

• 주키퍼
  • 카프카의브로커에있어분산처리를위한관리도구로아파치주키퍼ApacheZooKeeper( 이하 주키퍼)가 필요
  • 하둡등병렬분산처리용OSS에있어서설정관리,이름관리,동기화를위한잠금관리를 하는 구조로 자주 사용
  • 카프카에 있어서는 분산 메시징의 메타 데이터(토픽과파티션등)를관리하기위한구성요 소로 기능함
  • 주키퍼 클러스터(주키퍼앙상블이라고도한다)의구조상3,5처럼홀수로구성하는것이일 반적임

 

• 파티션
  • 토픽에대한대량의메시지입출력을지원하기위해,브로커상의데이터를읽고쓰는것은 파티션(Partition)이라는 단위로 분할됨
  • 토픽을구성하는파티션은브로커클러스터안에분산배치되어프로듀서에서의메시지수 신, 컨슈머로의 배달을 분산해서 실시함으로써 하나의 토픽에 대한 대규모 데이터 수신과 전 달을 지원함
  • 각파티션을브로커에어떻게배치하는가에대한정보는브로커측에유지
  • 프로듀서API/컨슈머API가파티션들을은폐해서통신하기때문에프로듀서/컨슈머에서는 토픽만을 지정하고, 구현 시에 송신처 파티션을 의식할 필요가 없음

 

• 오프셋
  • Log-End-Offset(LEO) : 파티션 데이터의 끝을 나타낸다.
  • Current Offset : 컨슈머가 어디까지 메시지를 읽었는가를 나타낸다.
  • Commit Offset : 컨슈머가 어디까지 커밋했는지룰 나타낸다.각 파티션에서 수신한 메시지에는 각각 일련번호가 부여되어 있어 파티션 단위로 메시지 위치를 나타내는 오프셋(Offset)이라는 관리 정보를 이용해 컨슈머가 취득하는 메시지의 범위 및 재시도를 제어함

 

• 컨슈머의 메세지 취득
  • 메세지의 유입 빈도가 동일한 경우, 컨슈머의 브로커 요청 간격이 길수록 모인 메시지가 많아짐

 

브로커에서 프로듀서로 메세지가 송신된 것을 어느 타이밍에 송신할 것인지를 제어하는 것.

프로듀서는 타임아웃 설정으로 ACK가 돌아오지 않고 타임아웃 된 Send처리를 송신 실패로 감지함

 

 

 

카프카의 대표적 기능

• 데이터 허브
  • 여러 시스템 사이에서 데이터를 상호 교환
• 로그 수집
• 웹 활동분석
• 사물 인터넷
  • 센서 등 다양한 디바이스에서 보낸 데이터를 수신해서 처리한 후 디바이스에 송신
• 이벤트 소싱
  • 데이터에 대한 일련의 순차적으로 기록하고 CQRS 방식으로 대량의 이벤트를 유연하게 처리