카프카 알아보기 (1)
1-1. 잘란도와 트위터의 카프카 도입 사례
1-1-1. 잘란도의 도입 사례
•
2020년 기준 현황
◦
실사용자 3,100만
◦
연간 주문수: 1억 4,500만건
◦
상품 판매 건수: 50만건
◦
연 평균 성장률: 24%
◦
거래액: 약 10조원
•
도입 배경
◦
점차 회사의 규모가 커지고 사업도 다각화되면서 내부적으로 데이터에 대한 온갖 요구사항이 불거짐
◦
데이터의 변화가 스트림으로 컨슈머 측에 전달되는 이벤트 드리븐 시스템으로의 전환을 결정함
◦
EDA 도입을 통해 데이터를 소비하는 컨슈머들은 자신의 요구사항에 따라 데이터를 처리하거나 구독할 수 있게됨
•
초기 방식
◦
초기에는 데이터의 오차를 줄이려는 목적으로 API 와 PostgreSQL 로 연결하는 CRUD 타입으로 구성
◦
데이터베이스가 업데이트가 완료된 후에는 Outbound 이벤트가 생성되도록 구성
◦
한계점
▪
여러 네트워크를 이용하는 환경에서 모든 데이터 변경에 대한 올바른 전달 보장 문제
▪
동일한 데이터를 동시에 수정하면서 정확하게 순서를 보장해야 하는 문제
•
수정된 이벤트들을 정확한 순서대로 Outbound 전송하는 문제
▪
다양한 클라이언트들의 요구사항을 효율적으로 지원하기 어려운 문제
▪
빠른 전송을 위한 클라이언트 또는 대량의 배치 전송을 위한 클라이언트를 지원하기 어려운 문제
•
비동기 방식의 스트리밍 플랫폼, 카프카 도입
◦
카프카를 선택한 이유
▪
빠른 데이터 수집이 가능한 높은 처리량
•
HTTP 대신 카프카로 처리되는 응답 시간이 한자릿수의 ms 단위로 처리됨
▪
순서 보장
•
이벤트 처리 순서가 보장되면서 엔티티 간의 유효성 검사나 동시 수정 같은 무수한 복잡성들이 제거되면서 구조가 간결해짐
▪
최소 한번 전달 방식
•
분산된 여러 네트워크 환경에서의 데이터 처리에서 중요한 모범 사례는 멱등성(idempotent) 이다
◦
멱등성이란 동일한 작업을 여러번 수행하더라도 결과가 달라지지 않는것을 의미
•
최소 한번 전달 방식은 간혹 이벤트들이 중복 발생할 수 있으나, 누락 없는 재 전송이 가능하므로 메시지 손실에 대한 걱정이 사라짐
◦
중복 메시지를 처리할 수 있는 구조로 개발한다면 복잡한 트랜잭션 처리가 필요하지 않음
▪
자연스러운 백프레셔 핸들링
•
카프카의 클라이언트는 풀(Pull) 방식으로 동작함
◦
풀 방식은 자기 자신의 속도로 데이터를 처리할 수 있음
◦
브로커 속도에 의존적이지 않음
•
복잡한 피드백이나 제한의 요구사항이 사라져 매우 간단하고 편리하게 클라이언트를 구현할 수 있음
▪
강력한 파티셔닝
•
논리적으로 토픽을 여러 개로 나눌 수 있음
•
파티션에 적절한 키를 할당하기 위한 여러 고려사항은 있지만, 각 파티션들을 다른 파티션들과 관계없이 처리할 수 있으므로 효과적인 수평 확장이 가능함
▪
그 외 여러가지 기능
•
로그 컴팩션 기능을 통해 스냅샷 역할이 가능
◦
새로운 애플리케이션이 나중에 메시지를 읽어가는 방식도 가능
•
컨슈머와 프로듀서가 명확하게 분리되어 있으므로 애플리케이션의 병목 현상을 정확하게 파악할 수 있음
◦
모니터링을 통해 지연에 대한 문제를 빠르게 해결할 수 있음
◦
카프카 스트림 (Kafka Streams) 도입
▪
카프카 스트림은 MapReduce 스타일 연산에 필요한 기본 요소를 갖췄으며, 시릿간 처리가 가능하고 다른 애플리케이션과 잘 맞아떨어지는 등 장점이 많음
◦
결론
▪
내부의 데이터 처리를 간소화함
▪
높은 처리량을 바탕으로 스트림 데이터 처리의 확장성을 높임
▪
단순히 실시간 데이터를 수집하고 공유하는 역할뿐만 아니라 주요 비즈니스 영역의 중요한 문제들을 해결하는 목적으로 활용함
1-1-2. 트위터의 카프카 활용 사례
•
도입 배경
◦
비용 절감 효과
▪
현재 구축되어 있는 이벤트 버스에서 실행되는 워크로드와 일부 장애 시나리오를 이용해 카프카 성능 테스트를 진행함
•
성능적인 측면에서 메시지가 처리되는 양과 관계없이 이벤트 버스에 비해 카프카의 응답 속도가 빠름
▪
성능 차이가 발생하는 이유
•
이벤트 버스는 서빙 레이어와 스토리지 레이어가 분리되어 있어 추가적인 홉이 필요하지만, 카프카는 하나의 프로세스에서 스토리지와 요청을 모두 처리함
•
이벤트 버스는 fsync() 를 하는 동안 블로킹을 하지만, 카프카는 OS 에 의존해 백그라운드로 fsync() 를 처리하고 Zero-Copy 를 사용함
▪
카프카를 도입함으로써 60~70% 리소스 절감 효과를 누리게 되어 하드웨어 운영 유지 비용은 물론이고, 기타 부대 비용까지 절감하는 효과를 얻음
◦
강력한 커뮤니티
▪
카프카는 이미 많은 기업에서 채택됐으며 수 많은 사람들이 버그를 수정하고 새로운 기능을 개발하고 있었음 (수백명에 이르는 엔지니어)
•
하지만, 트위터 내부에서 이벤트 버스를 담당하고 기능을 개선하는 엔지니어는 8명정도밖에 없었음
▪
트위터 내에서 이벤트 버스에 필요로 하는 기능들 (HDFS 파이프라인, 정확히 한 번 전송 등) 은 이미 카프카에 구현되어 있었음
▪
클라이언트나 브로커에 문제가 발생한 경우 다양한 사용자들의 경험담이 웹에 공유되어 있기 때문에 해결 방법을 찾기 수월했음
•
초기 방식
◦
Kafka 0.7 버전을 사용하고 있었으나 많은 I/O 오퍼레이션에서의 문제 발생, 내구성 및 레플리케이션의 미구현 등으로 인한 불안정성 때문에 카프카를 포기하고 인하우스에서 개발한 메시지 시스템 (Event Bus) 를 구축함
•
결론
◦
트위터의 카프카 채택 사례는 단지 기술적인 성능 이슈뿐만 아니라, 비용 절감 효과와 인력 충원 등 기술 외적인 기업의 변화상을 보여줌
1-2. 국내외 카프카 이용 현황
해외 카프카 이용 현황
•
라인
◦
내부의 50여 개 서비스들이 카프카를 이용하고 있음
◦
하루에 2,500억 건이 넘는 메시지를 처리함
◦
하루 약 210TB 의 데이터가 카프카로 인입됨
•
뉴욕타임스
◦
카프카와 스트림즈 API 를 이용해 시릿간으로 콘텐츠를 배포하고 있음
•
아디다스
◦
데이터 소스 시스템을 통합하고, 모니터링과 분석 등의 작업을 실시간으로 처리함
•
데이터독
◦
각종 메트릭과 이벤트 통합 파이프라인으로 카프카를 사용함
•
스포티파이
◦
로그 전송 시스템으로 카프카를 사용함
•
특정 산업 분야 뿐만 아니라 여행, 글로벌 뱅크, 보험, 통신 등 여러 분야에 걸쳐 다양한 목적으로 카프카를 이용하고 있음
•
2020년 기준으로 포춘 100대 기업 중 약 80% 이상이 카프카를 사용하고 있음
국내 카프카 이용 현황
•
카카오
◦
총 7대의 클러스터를 보유
◦
하루에 2,600억 개의 메시지를 처리
◦
하루 약 240TB 의 데이터가 카프카로 인입됨
1-3. 카프카 주요 특징
높은 처리량과 낮은 지연시간
•
처리량이 가장 높은 것은 카프카이며, 응답 속도가 가장 빠른 것은 RabbitMQ 이다
◦
처리량과 응답 속도를 같이 비교했을 때는 카프카가 단연 독보적이다
•
높은 처리량을 바탕으로 다양한 기업들의 요구사항을 만족시켜줄 뿐만 아니라, 낮은 지연시간까지 제공한다
높은 확장성
•
카프카는 손쉬운 확장이 가능하도록 잘 설계된 애플리케이션이다
◦
링크드인은 내부적으로 ActiveMQ 를 사용하고 있었으나, 확장이 어려움을 겪었기에 이러한 불편사항을 개선하고자 새로이 개발한 카프카는 애초부터 확장 가능할 수 있도록 설계를 했다
고가용성
•
카프카 초기 버전에서는 메시지를 빠르게 처리하는것이 목표였으나, 시간이 지나면서 고가용성 측면을 중요하게 여기게됨
•
2013년에 클러스터 내 레플리케이션 기능을 추가하게됨
내구성
•
프로듀서는 카프카로 메시지를 전송할 때, acks 라는 옵션을 조정하여 메시지의 내구성을 강화할 수 있음
•
전통적인 메시징 시스템의 경우, 컨슈머가 메시지를 가져감과 동시에 저장소에서 메시지가 삭제됨
•
카프카는 컨슈머가 메시지를 가져가더라도 삭제하지 않고 지정된 설정 시간 또는 로그의 크기만큼 디스크에 저장됨
◦
코드의 버그나 장애가 발생하더라도 과거의 메시지들을 불러와서 재처리할 수 있음
•
메시즈들을 브로커 한 대에만 저장하는 것이 아니라, 2~3대 이상의 브로커에 저장되므로 브로커가 종료되더라도 다른 브로커에서 데이터를 가져와 복구할 수 있음
개발 편의성
•
카프카는 프로듀서와 컨슈머가 완벽히 분리되어 동작하기 때문에 서로 영향을 받지 않는다
•
프로듀서와 컨슈머를 동시에 사용할 때는 워크로드 또는 구현하고자 하는 요구사항에 따라 프로듀서와 커늇머에서 제공하는 옵션을 잘 활용해야 함
•
개발 편의성을 위해 Kafka Connect, Schema Registry 를
◦
Schema Registry 는 데이터를 파싱하는 데 많은 시간을 소모하는 비효율적인 구조를 개선하고자 스키마를 정의해서 사용할 수 있도록 개발된 애플리케이션
◦
Kafka Connect 는 Producer 와 Consumer 를 따로 개발하지 않고도 카프카와 연동해 손쉽게 Source 와 Sink 로 데이터를 보내고 받을 수 있는 애플리케이션
▪
ElasticSearch, HDFS, RDB, S3 등 다양한 소스와 싱크를 제공함
운영 및 관리 편의성
•
성능 확장을 위한 증설 작업이 쉽고 간단
•
최신 버전이 릴리즈 되는 경우 무중단으로 버전 업그레이드 가능
•
카프카의 운영 및 관리 편의성, 안정적인 운영을 위한 모니터링이 가능
1-4. 카프카의 성장
•
주요 서비스 출시일
◦
2012.01: 카프카 v0.7 버전 출시
◦
2013.12: 카프카 v0.8 버전 출시
◦
2015.02: 카프카 v0.8.2 버전 출시 (Schema Registry)
◦
2015.11: 카프카 v0.9 버전 출시 (Kafka Connect)
◦
2016.05: 카프카 v0.10 버전 출시 (Kafka Streams)
◦
2017.08: ksql 출시
◦
2018.07: 카프카 v2.0 출시
◦
2021.09: 카프카 v3.0 출시
카프카 v0.8 버전 출시
•
레플리케이션 기능을 추가
•
클러스터에서 브로커의 장애가 발생해도 레플리케이션 기능으로 인해 데이터 유실 없이 안정적으로 사용할 수 있음
카프카 v0.8.2 버전 출시 (Schema Registry)
•
카프카의 데이터 흐름은 대부분 브로드캐스트 방식이라 컨슈머 입장에서는 데이터를 전송하는 프로듀서를 일방적으로 신뢰할 수 밖에 없는 구조임
◦
이러한 구조로 인해 데이터를 분석하거나 비정형 데이털르 파싱하는데 시간을 많이 사용함
•
프로듀서와 컨슈머 간에 서로 데이터 구조를 설명할 수 있는 스키마를 등록 지정해 사용하는 스키마 레지스트리가 발표됨
카프카 v0.9 버전 출시 (Kafka Connect)
•
기업들이 카프카를 활용해 데이터를 통합하거나 데이터 허브로 이용하는 경우가 많아지면서 연결된느 시스템도 점점 더 다양해짐
•
시스템과 카프카를 하나하나 연동하는 클라이언트를 개발하고 유지보수하는 일은 점점 더 과중해지기 때문에 이를 손쉽게 해결할 수 있는 카프카 커넥트를 발표함
◦
카프카 커넥트를 이용해 별도의 코드 작성 없이도 다양한 프로토콜과 카프카를 연동할 수 있게됨
카프카 v0.10 버전 출시 (Kafka Streams)
•
많은 기업에서의 실시간 처리에 대한 니즈가 높아지고 있는 니즈를 충족하고나 카프카 스트림즈를 발표함
•
간단하고 가벼운 클라이언트를 이용해 많은 개발자나 기업에서의 실시간 분석, 처리 등이 가능해짐
ksql 출시
•
개발자들이 별도의 코드를 작성하지 않고도 SQL 기반의 실시간 처리가 가능한 KSQL 을 발표함
•
KSQL 을 이용하면 스트림 처리뿐만 아니라 배치 처리도 가능하며, 익숙한 SQL 언어로 처리할 수 있다는 점이 굉장히 큰 장점임
카프카 v3.0 출시
•
카프카의 토픽, 브로커 등을 관리하는 목적으로 분산 코디네티어 시스템인 주키퍼(Zookeeper) 를 사용해왔음
◦
주키퍼는 카프카가 높은 성능을 갖는데 장벽이 되어있음
•
주키퍼 의존성 제거하기 위한 노력으 일환으로 20221년 4월 2.8 버전 발표와 함께 주키퍼 없이 동작 가능한 카프카를 발표함
•
2021년 09월 21일 카프카 3.0이 릴리스 되면서 주키퍼 의존성이 제거된 정식 카프카 버전에 근접했으나, 아직 프로덕션 워크로드에는 도입하는것을 추천하지 않음
◦
카프카의 메시지 포맷 v0, v1 지원 종료
◦
자바 8, 스칼라 2.12 지원 종료
◦
주키퍼 의존성을 제거하기 위해 새로 도입된 분산 합의 프로코톨 KRaft 를 전반적으로 적용하려는 양상
◦
프로듀서의 전송 보장에 대해 중복 없는 전송 (idempoency) 방식을 기본으로 채택
◦
1-5. 다양한 카프카의 사용 사례
데이터 파이프라인: 넷플릭스
•
사용자의 넷플릭스 비디오 시청 활동, 유저 인터페이스 사용 빈도, 에러 로그 등의 모든 이벤트는 데이터 파이프라인을 통해 흐르므로, 이 내용들을 분석해 사용자의 경험을 예측해 능동적으로 대응할 수 있으며, 오류 발생 시에도 실시간으로 대응이 가능하다
데이터 통합: 우버
•
데이터 엔지니어는 하나의 데이터 파이프라인을 추가할 때 마다 이기종 간의 호환성 확인, 데이터 정합성 등으로 매우 번거로운 작업을 수행해야 했음
•
카프카를 도입한 이후부터는 안정적이고 손쉽게 데이터 파이프라인의 추가가 가능해져 조금씩 카프카 중심으로 데이터 파이프라인이 생겨나고, 결과적으로 모든 데이터가 카프카를 통해 오가는 구조가 만들어짐
머신러닝 분야 활용 사례
•
데이터 전송과 파이프라인을 위해 카프카 커넥트를, 모델 생성 또는 상용 머신러닝 앱의 실사근 처리를 위해서는 카프카 스트림즈를 사용함
•
스키마 정의를 위한 스키마 레지스트리, SQL 기반 쿼리를 위한 KSQL 등 카프카의 연계 시스템들이 종합적으로 활용됨
스마트 시티 분야 활용 사례
•
카프카와 카프카 사이의 안정적인 데이터 전송을 위해서는 카프카 커넥트가 활용되며, 사전에 정의된 스키마를 이용해 데이터 변화 등에 유연하게 대응하기 위해서는 스키마 레지스트리를 활용함
