1장 카프카 개요

JIN·2023년 4월 21일

실전 카프카 개발부터 운영까지 책을 정리한 내용입니다.

카프카란? 이벤트 스트리밍 플랫폼 / 실시간 스트리밍 플랫폼이다.

동기/ 비동기 데이터 전송에 대한 고민이 있는가?
실시간 데이터 처리에 대한 고민이 있는가?
현재의 데이터 처리에 한계를 느끼는가?
새로운 데이터 파이프라인이 복잡하다고 느끼는가?
데이터 처리의 비용 절감을 고려하고 있는가?

→ 카프카를 사용하자!

배경) 링크드인에서 데이터 처리를 담당하던 제이 크렙스, 준 라오, 네하 나크헤데가 개발

문제 ) 당시 링크드인 내부에서는 서로 데이터를 연동하거나 데이터를 처리하는 시스템들이 다양해지면서 데이터 파이프 라인이 생겨남. 하지만 시간이 지날 수록 데이터 처리의 포맷이나 처리 방법 등이 다른 문제로 인해 데이터 파이프 라인을 유지하거나 확장하는데 어려움을 겪음. 데이터의 정합성을 확인해야 하는 문제까지 발생

해결) 2010년 개발된 카프카는 일 년 뒤인 2011년 아파치 오픈소스로 공개. 데이터 파이프라인 확장의 어려움, 이기종 간의 호환성, 고 성능 기반의 실시간 데이터 처리 문제 해결

1.1 잘란도와 트위터의 카프카 도입 사례

잘란도는 유럽 에서 유명세를 떨치고 있는 온라인 패션몰임

2020년에 이미 실사용자 수가 3100만명, 연간 주문 수 1억 4500만 건, 상품 판매 건수 50만건, 2020년 거래액 약 10조원

1.1.1 잘란도에서 카프카를 도입한 배경

회사의 규모가 커지고 사업도 다각화되면서 내부적으로 데이터에 대한 온갖 요구사항이 불거지자, 잘란도에서는 데이터 요구사항을 근본적으로 해결하기 위한 대책을 강구. 그 방법으로 데이터의 변화가 스트림으로 컨슈머 측에 전달되는 이벤트 드리븐 시스템으로의 전환을 결정

그러나 이 방식에 존재하는 문제

문제 1. 인바운드 아웃바운드 데이터의 정합성을 검증해야 함

문제 2. 통신 방법 문제 - 간단한 REST API 기반의 통신 고려

처음엔 데이터의 오차를 줄이려는 목적으로 API와 PostgreSQL로 연결하는 CRUD 타입으로 구성하고, 데이터베이스 업데이트가 완료된 후에는 아웃바운드 이벤트가 생성되도록 구성. 이를 통해 데이터의 오차는 줄일 수 있지만 동기화 문제 발생

여러 네트워크를 이용하는 환경에서 모든 데이터 변경에 대한 올바른 전달 보장 문제
동일한 데이터를 동시에 수정하면서 정확하게 순서를 보장해야 하는 문제, 그리고 수정된 이벤트들을 정확한 순서대로 아웃바운드 전송하는 문제
다양한 클라이언트들의 요구사항을 효율적으로 지원하기 어려운 문제
빠른 전송을 위한 클라이언트 또는 대량의 배치 전송을 위한 클라이언트를 지원하기 어려운 문제

비동기 방식의 대표 스트리밍 플랫폼, 카프카 도입

카프카의 장점: 높은 처리량, 순서 보장, 적어도 한번 전송 방식, 강력한 파티셔닝, 자연스러운 백프레셔 핸들링, 로그 컴팩션

장점

빠른 데이터 수집이 가능한 높은 처리량: HTTP 기반으로 전달되는 이벤트일지라도 이벤트가 카프카로 처리되는 응답시간을 불과 한자릿수의 밀리초(ms) 단위로 처리됨.
순서 보장: 이벤트 처리 순서가 보장되면서, 엔티티 간의 유효성 검사나 동시 수정같은 무수한 복잡성들이 제거됨으로써 구조 또한 매우 간결해짐
적어도 한 번 전송 방식: 분산된 여러 네트워크 환경에서의 데이터 처리에서 중요한 모범 사례는 “멱등성” 멱등성이란, 동일한 작업을 여러 번 수행하더라도 결과가 달라지지 않는 것을 의미함. 차선책인 “적어도 한 번” 전송방식은 간혹 이벤트들이 중복 발생할 수 있으나 누락 없는 재전송이 가능하므로 메시지 손실에 대한 걱정이 사라짐. 또한 백엔드 시스템들이 중복 메시지 처리가 가능하도록 허용된다면 복잡한 트랜잭션 처리 또한 필요하지 않게 됨. 이로 인해 아키텍처는 더욱 단순해지고 처리량 또한 더욱 높아짐
자연스러운 백프레셔 핸들링: 카프카의 클라이언트는 pull 방식으로 동작. 장점으로는 자기 자신의 속도로 데이터를 처리할 수 있음. 반면 push 방식은 브로커가 보내주는 속도에 의존해야 함.
강력한 파티셔닝: 논리적으로 토픽을 여러 개로 나눌 수 있다. 또한 파티션에 적절한 키를 할당하기 위한 여러 고려사항은 있지만, 각 파티션들을 다른 파티션들과 관계없이 처리할 수 있으므로 효과적인 수평확장이 가능해진다.
그 외 여러가지 기능: 로그 컴팩션 기능을 통한 스냅샷, 비동기식 방식을 사영함에 따라 애플리케이션의 병목현상 파악 가능

카프카로 도약의 기회를 얻은 잘란도

카프카 기반의 느슨하게 결합된 이벤트 드리븐 시스템과 애플리케이션들을 구축한 잘란도는 이벤트 스트림을 통해 모든 데이터를 비동기 방식으로 처리 .

잘란도는 패션과 관련된 사이트들로부터 지속적으로 데이터를 수집하고 미래의 베스트 사이트를 찾고자 노력, 자동화된 데이터 중심의 방법론이 필요

→ 카프카 스트림즈 : 맵리듀스 스타일 연산에 필요한 기본 요소를 갖췄으며, 실시간 처리가 가능 기존 앱들과도 잘 어우러짐

1.1.2 트위터의 카프카 활용 사례

사용자가 글을 적으면 그 사용자를 팔로우하는 다른 사용자들에게 메시지가 즉시 전달됨. 이처럼 실시간 서비스인 트위터에서의 실시간 요구사항들로 인해 데이터 엔지니어링 팀은 항상 독특하고 어려운 문제에 맞닥뜨림.

트위터에서는 이러한 워크로드를 처리할 수 있는 시스템으로 그간 이벤트 버스를 구축했으나 이후 카프카로 전환

카프카로 유턴한 트위터

카프카 0.7 버전을 사용하던 10년전에는 많은 I/O 오퍼레이션에서의 문제 발생, 그리고 내구성 및 리플리케이션의 미구현으로 인한 불안정성으로 트위터는 인하우스 메시지 시스템(이벤트버스)를 구축

이벤트 버스와 카프카의 성능 차이를 보면 BPS와 상관 없이 지연이 거의 발생하지 않음 .

트위터에서 측정한 이벤트 버스와 카프카의 성능 비교 

출처: [https://teki.tistory.com/65?category=542226](https://teki.tistory.com/65?category=542226)

이러한 성능 차이의 이유
- 이벤트 버스는 서빙 레이어와 스토리지 레이어가 분리되어 있어 추가적인 홉이 필요, 그러나 카프카는 하나의 프로세스에서 스토리지와 요청을 모두 처리
- 이벤트 버스는 fsync()를 하는 동안 블로킹을 하는 반면, 카프카는 OS에 의존해 백그라운드로 fsync()를 처리하고 제로카피를 사용.
- 결과적으로 리소스 절감과 하드웨어 운영 유지 비용 절감, 기타 부대 비용 절감

1.2 국내외 카프카 이용 현황

라인: 약 50여개 서비스들이 카프카 이용, 하루에 2500억건이 넘는 메시지 처리, 약 210TB의 데이터가 카프카로 인입.(약 2년전)
뉴욕 타임즈: 카프카와 스트림즈 API를 이용해 실시간으로 콘텐츠 배포
아디다스: 데이터 스트리밍 플랫폼으로 카프카 이용, 모니터링 분석 등의 작업을 실시간 처리
데이터독: 메트릭과 이벤트 통합 파이프라인으로 카프카 사용
스포티파이: 로그 전송 시스템
이 외에도 페이팔, 넷플릭스, 아우디, 우버 등

1.3 카프카의 주요 특징

높은 처리량과 낮은 지연시간

카프카, 펄사, 래빗MQ 성능 비교

출처 : [https://www.confluent.io/blog/kafka-fastest-messaging-system/](https://www.confluent.io/blog/kafka-fastest-messaging-system/)

- 북키퍼 기반의 펄사 메시징 시스템, 전통적인 메시징 큐 시스템인 래빗 MQ와 비교했을 때 처리량과 응답속도를 같이 고려하면 카프카가 가장 적합

높은 확장성
- 손쉬운 확장이 가능한 애플리케이션
고가용성
- 클러스터 내 리플리케이션 추가
내구성
- 프로듀서는 카프카로 메시지를 전송할 때 , 프로듀서의 acks라는 옵션을 조정하여 메시지의 내구성을 강화할 수 있다. 강력한 메시지의 내구성을 원한다면 옵션을 acks = all로 사용할 수 있다.
- 이렇게 프로듀서에 의해 카프카로 전송되는 모든 메시지는 안전한 저장소인 카프카의 로컬 디스크에 저장됨. 전통적인 메시징 시스템의 경우 컨슈머가 메시지를 가져감과 동시에 저장소에서 메시지가 삭제됨. 그러나 카프카는 컨슈머가 메시지를 가져가더라도, 메시지는 삭제되지 않고 지정된 설정 시간 또는 로그의 크기만큼 로컬 디스크에 보관되므로, 재처리 할 수 있음
- 메시지들은 브로커 한 대에만 저장되는 것이 아니라 두 대 또는 세 대의 브로커에 저장되므로 복구할 수 있다.
개발 편의성
- 카프카는 메시지를 전송하는 역할을 하는 프로듀서와 메시지를 가져오는 역할을 하는 컨슈머가 완벽하게 분리되어 동작하고 서로 영향을 주지도 받지도 않음
- 개발 편의성을 제공하기 위해 카프카 커넥트와 스키마 레지스트리를 제공
  - 카프카 커넥트: 프로듀서와 컨슈머를 따로 개발하지 않고도 카프카와 연동해 손쉽게 소스와 싱크로 데이터를 보내고 받을 수 있는 애플리케이션.
    - 엘라스틱 서치, HDFS등 다양한 소스와 싱크를 제공하므로 개발 편의성을 높임
  - 스키마 레지스트리: 데이터 파싱하는데 소요되는 시간을 줄이기 위해 스키마를 정의해서 사용
- 운영 및 관리 편의성

1.4 카프카의 성장

리플리케이션 기능 추가 (v0.8)
스키마 레지스트리 공개 (v0.8.2)
- 카프카의 데이터 흐름은 대부분 브로드캐스트방식이라 컨슈머 입장에서는 데이터를 전송하는 프로듀서를 일방적으로 신뢰할 수 밖에 없는 구조. 그래서 비정형 데이터를 파싱하는 데 많은 시간을 소모하고 있었기에 이런 문제를 해결하고자 프로듀서와 컨슈머간의 서로 데이터 구조를 설명할 수 있는 스키마를 등록 지정해
- 스키마에 정의된 데이터만 주고받게 됨
카프카 커넥트 공개(v 0.9)
- 카프카와 연결되는 시스템도 점점 다양해짐. 데이터베이스의 경우 MySQL, SQL, PostgreSQL, MongoDB/ 프로토콜: FTP, HDFS, 아마존 S3, 액티브 MQ
- 별도의 코드 작성 없이도 다양한 프로토콜과 카프카를 연동할 수 있게 됨
카프카 스트림즈 공개 (v 0.10)
- 실시간 분석 처리 가능
KSQL 공개
- SQL 기반으로 실시간 처리 가능 / 스트림 처리 뿐만 아니라 배치 처리도 가능하며 SQL 언어로 처리할 수 있다.
주키퍼 의존성에서 해방(v3.0)
- 대부분 지금까지는 카프카의 토픽, 브로커 등을 관리하는 목적으로 분산 코디네이터 시스템인 주키퍼를 사용했으나 주키퍼는 그간 카프가가 높은 성능을 갖는 데 장벽이 되었음.
- 주키퍼 없이 동작 가능한 카프카 공개(실제 운영환경에서는 추천 하지 않음)
- 새롭게 도입된 프로토콜: 크래프트
- 멱등성 방식을 기본값으로 채택, 컨슈머의 session.tiumeout.ms 기본값을 늘려 컨슈머의 안정성을 높임

1.5 다양한 카프카의 사용 사례

카프카의 에코 시스템의 공개로 많은 기업에서는 단순하게 카프카를 펍/섭 모델로만 활용하는 데 그치지 않고, 데이터 통합, 메시지 버스, 실시간 데이터 처리, 실시간 데이터 분석 등 여러 용도로 카프카와 카프카 커넥트, 스키마 레지트리 등을 활용하고 있다.

1.5.1 데이터 파이프라인 : 넷플릭스

데이터를 수집, 통계, 처리, 적재하기 위해 파이프라인들이 연결되어 있어 이러한 파이프라인을 연결해주는 역할로 카프카 사용
사용자의 넷플릭스 비디오 시청활동, 유저 인터페이스 사용 빈도, 에러 로그 등의 모든 이벤트는 데이터 파이프라인을 통해 흐르므로, 넷플릭스는 이런 내용을 분석해 사용자의 경험을 예측해 능동적으로 대응