Last Updated on 5월 1, 2023 by Jade(정현호)
안녕하세요.
이번 포스팅은 아파치 카프카에 대한 글로 실전 카프카 개발부터 운영까지 책을 정리한 글 입니다.
Contents
카프카의 역사
오늘날 카프카가 없는 데이터 처리 아키텍처를 상상해보기란 어려울 것입니다. 그만큼 데이터가 비지니스의 핵심이 된 오늘날 현실 속에서 만약 카프카가 없었다면 급속도로 변화하는 다양한 비즈니스의 요구사항들을 충족시키기란 매우 어렵고 고된 일이 될 것 입니다.
오늘날 데이터 처리에서 중요한 핵심 역할을 하는 카프카는 미국의 대표적인 비지니스 인맥 소셜 네트워크 서비스인 링크드인(LinkedIn) 에서 근무하던 제이 크렙스, 준 라오, 네하 나크헤데가 링크드인 서비스 내에서 발생하고 있는 이슈들을 해결하기 위해서 만들었습니다.
데이터 파이프라인 확장의 어려움, 이기종 간의 호환성, 고성능 기반의 실시간 데이터 처리의 어려움 등의 문제를 해결 하기 위해 2010년 개발된 카프카는 일년 뒤인 2011년 아파치(Apache) 오픈소스로 세상에 처음 공개가 되었습니다.
링크드인이 자사에서 직접 개발한 카프카를 첫 도입하면서 링크드인 고객의 서비스 만족도가 높아지는 긍정적인 효과를 이끌어냈습니다.
링크드인 서비스를 사용하는 고객이 직장(JOB)을 변경하면 해당 변경 내용이 링크드인을 사용하는 지인들에게 곧바로 업데이트 되고 링크드인 내부 서비스에도 즉시 반영되어 추천 로직을 거쳐 실시간으로 직장 추천도 가능하게 되었습니다.
카프카의 창시자인 제이 크렙스는 공동 창시자인 준 라오, 네하 나크헤데와 함께 링크드인에서 독립하여 2014년에 컨플루언트(www.confluent.io) 라는 회사를 설립 하였으며, 현재까지 카프카를 계속해서 발전 시키면서 프로젝트를 리드해가고 있습니다.
카프카가 굉장히 안정적인 애플리케이션이며 사용자들의 요구에 맞춰 크고 작은 신기능들이 발 빠르게 추가되면서 고객을 끊임없이 만족시켜줬기 때문에 이와 같은 이유로 실시간 스트리밍 플렛폼이 필요한 곳에서 대부분 카프카를 필수 요소로 채택하여 많은 곳에서 사용되고 있습니다.
카프카 개요
아파치 카프카는 실시간으로 레코드의 스트림을 게시, 구독, 저장, 처리할 수 있는 분산 데이터 스트리밍 플랫폼입니다.
다양한 소스에서 데이터 스트림을 처리하고 여러 컨슈머에게 전달하기 위해 설계되었습니다.
간단히 말해서, 카프카는 단순히 A지점에서 B지점으로 데이터를 이동시키는 것뿐 아니라 A지점에서 Z지점과 필요한 모든 곳으로 동시에 대규모 데이터를 이동시킬수 있습니다.
아파치 카프카는 전통적인 엔터프라이즈 메시징 시스템의 대안이며, 이제는 다양한 엔터프라이즈 요구 사항에 적용 가능한 오픈 소스 데이터 스트리밍 솔루션으로 사용 되고 있습니다.
스트리밍 데이터
스트리밍 데이터는 실시간 정보의 지속적인 흐름이자 이벤트 기반 아키텍처(event driven architecture) 소프트웨어 모델의 기반입니다.
현대적인 애플리케이션은 스트리밍 데이터를 사용하여 데이터를 처리, 저장, 분석합니다.
스트리밍 데이터는 데이터 세트에 발생한 변경 사항이나 이벤트의 실행 로그(대개 매우 빠른 속도로 변경됨)라고 볼 수도 있습니다.
빠르게 이동하는 대규모 데이터 세트로서 스트리밍 데이터의 소스일 수 있는 경우는 금융 거래, 사물 인터넷(IoT) 센서 데이터, 물류 운영, 소매 주문 또는 병원 환자 모니터링 등 다양합니다. 차세대 메시징처럼 데이터 스트리밍은 이벤트에 대한 실시간 응답이 필요한 상황에 적합하다고 할 수 있습니다.
Kafka를 통한 비동기식 통합
마이크로서비스(Microservices)는 개발 환경을 바꾸어 놓았습니다.
공유 데이터베이스 계층과 같은 종속성을 줄여 개발자들이 더욱 민첩하게 작업을 수행하도록 해줍니다.
그러나 개발자가 구축 중인 분산형 애플리케이션이 데이터를 공유 하려면 특정한 유형의 통합 환경이 필요합니다.
널리 사용되는 통합 옵션으로 동기식 방법이 있는데, 이는 서로 다른 사용자 간 데이터를 공유하는 데 애플리케이션 프로그래밍 인터페이스(API)를 활용합니다.
또 다른 통합 옵션으로는 중간 데이터 스토어에 데이터를 복제하는 비동기식 방법이 있습니다.
Apache Kafka는 바로 이런 맥락에 등장하는 솔루션으로, 다른 개발팀의 데이터를 스트리밍하여 데이터 스토어를 채우면 해당 데이터를 여러 팀과 이들의 애플리케이션 간에 공유할 수 있게 됩니다.
해외 도입 사례
카프카는 공개 된지 10년이 넘는 지금의 시대에서는 카프카는 정말 많은 곳에서 사용 되고 있으며, 많은 곳에서 알려진 유명한 도입 사례에 대해서 확인 해보도록 하겠습니다.
잘란도(zalando.com)
신발과 의류 등 온라인 패션몰로 유명세를 떨치고 있는 잘란도(zalando.com) 는 2008년 독일에서 설립되어 처음에는 신발 판매 온라인몰로 출발했습니다. 신발 판매에 주력하던 잘란도는 사업을 확장하기 위해서 2010년 네델란드와 프랑스에 자사 서비스를 출시하며 의류 판매를 추가 하였으며, 이후 조금씩 비즈니스를 확장해서 2013년 유럽의 대표 디지털 플랫폼으로 변화하기 시작한 잘란도는 현재 유럽전역에 걸쳐 대표적인 온라인 쇼핑 사이트로 자리 매김하였습니다.
잘란도는 5년간 연 평균 성장율 24%, 2020년 거래액 10조원 규모를 달성할 만큼 매우 빠른 속도로 큰 성장을 하였습니다.
이런 성장하는 비즈니스 속에서 잘란도는 데이터의 변화가 스트림으로 컨슈머 측에 전달되는 이벤트 트리븐 시스템으로 전환을 결정하게 되었습니다.
이벤트 드리븐 시스템 구성으로 모든 것이 해결될 수 있는 것은 아니며, 가장 중요한 사항은 바로 인바운드 데이터와 아웃바운드 데이터가 동일 해야 한다는 점 이었습니다. 데이터가 누락된다면 데이터의 신뢰성을 잃게 되고 결국 쓸모 없는 데이터가 될수 있습니다.
이러한 현상을 방지하기 위해서 데이터 일치를 검증해야하고 데이터 파이프라인이 추가되고 다시 데이터 검증에 대한 피로도 역시 높아지고 하는 상황이 지속될 수도 있습니다.
그 다음으로 통신 방법에 대한 선택을 해야 할 것 입니다. 가장 널리 사용되면서 매우 간편한 REST API 기반의 통신을 고려 해볼 수 있습니다.
초기에는 데이터의 오차를 줄이려는 목적으로 API 와 PostgreSQL 로 연결하는 CRUD 타입으로 구성하고 DB 가 완료된 후에 아웃바운드 이벤트가 생성되도록 구현 하여 사용하였으나 여러 문제점이 불거졌습니다.
위에서 대략적으로 설명한 여러가지의 동기(Sync) 방식의 한계점을 느끼게 되고 비동기 방식으로의 전환을 고려한 잘란도는 비동기 방식의 대표 스트리밍 플랫폰인 카프카를 선택하게 되었습니다.
카프카를 선택한 이유로는 높은 처리량, 순서 보장, 적어도 한번(at least once) 전송 방식, 강력한 파티셔닝, 자연스러운 백프레셔 핸들링, 로그 컴팩션 과 같은 훌륭한 기능들이 있었기 때문 입니다.
트위터
두번째의 해외 사례로는 SNS 절대 강자 트위터의 활용 사례를 들 수 있습니다.
대표적은 소셜 네트워크 서비스인 트위터는 사용자가 글을 작성하면 그 사용자를 팔로워하는 다른 사용자들에게 메세지가 즉시 전달 되게 됩니다.
이처럼 대표적인 실시간 서비스인 트위터에서의 실시간 요구사항드로 인해 데이터 엔지니어링 팀은 여러 어려운 문제를 맞닥뜨리게 되었습니다. 빠르게 노출이 되고 해야하는 서비스를 그전까지 이벤트 버스 시스템을 구축하여 운영 하였지만 향후에 카프카로 전환하게 됩니다.
결국 카프카를 선택한 트위터는 두가지 측면이 고려가 되었다고 합니다. 비용 절검과 커뮤니티 였습니다.
비용절감은 카프카 도입에 따른 60~70% 가량의 시스템 리스소를 절감하는 효과를 누리게 되어 하드웨어 운영 유지 비용과 기타 부대 비용을 절감하는 부수적인 효과를 얻을 수 있게 되었으며, 기존에 사용한 이벤트 버스에 비해서 카프카의 처리량이 월등이 좋았습니다.
그리고 또하나의 이유로 강력한 커뮤니티 였습니다. 카프카는 이미 많은 기업에서 사용되며, 카프카를 향상하고 버그를 수정하며 새로운 기능을 개발하고 하는 오픈소스 기여 엔지니어들이 전 세계 걸쳐서 수백 명에 이기 때문 입니다. 이러한 커뮤니티의 활발함은 카프카의 문제가 있을 경우 다양한 사용자들의 경험이 담긴 웹에 공유가 되고 있으며 검색을 통해서 해결 방법을 빠르게 찾을 수 있다는 장점이 있게 됩니다. 또한 대중화된 카프카는 그 만큼 카프카 전문 운영자나 엔지니어의 채용 면에서도 쉽다는 장점도 있게 됩니다.
이와 같이 카프카 고유의 장점 과 기능으로 도입 과 사용 되는 사례도 있으나 트위터처럼 다른 측면에서의 이유로 카프카의 도입을 할 수 있음을 보여주는 사례 입니다.
카프카의 주요 특징
카프카 도입을 거의 확정 했거나 이미 사용 중인 기업들은 대부분 카프카가 지닌 좋은 기능에 매료 되었으며, 이러한 기능을 충족시켜주는 대체재가 아직은 없다는 사실을 잘 알고 있을 것 입니다.
이러한 좋은 장점으로는 아래와 같은 기능들이 있습니다.
높은 처리량과 낮은 지연시간
카프카를 선택하는 가장 큰 이유 일 것 입니다. 앞에 사례에서도 그렇고 카프카는 매우 높은 처리량과 낮은 지연시간(latency) 을 자랑 힙니다.
컨플루언트의 블로그에는 메세지 시스템 간의 성능을 비교한 자료가 공개 되어 있습니다.
[confluent.io/kafka-fastest-messaging-system]
위의 이미지에서 아파치 카프카, 북키퍼(BookKeeper) 기반의 스토리지를 이용한 펄사(Pulsar), 전통적인 메세지 큐 시스템인 래빗MQ(RabbitMQ), 총 세가지 메세징 시스템의 비교한 내용을 확인 할 수 있습니다.
위의 벤치마크의 결과에서 확인 할 수 있듯이 처리량과 응답속도를 같이 비교하면 카프카가 다연 독보적으로 좋다고 할 수 있습니다.
높은 확장성
처리량이 높은 시스템이라도 그 한계 또는 끝은 존재하기 마련 입니다. 이러한 문제를 해결할 수 있는 가장 쉬운 방법은 확장을 하는 것이라고 생각 합니다.
카프카는 손쉬운 확장이 가능하고 잘 설계된 애플리케이션 입니다.
링크드인이 비즈니스 적으로 급성장 하면서 애플리케이션 확장의 필요성을 느끼게 되었습니다. 확장하기 어려운 애플리케이션에서 어려움을 겪으면서 이러한 문제점을 개선하고자 카프카 초기부터 확장이 가능하도록 설계를 하게 되었습니다.
고가용성
카프카 초기버전에서는 무엇보다 메세지를 빠르게 처리하는 것이 목표였지만, 점차 시간이 지나면서 고가용성 측면도 중요하게 생각하게 되었습니다. 카프카는 2013년 에 클러스터 내 레플리케이션 기능을 추가 하였습니다.
고가용성(High Availability) 라는 개념은 간단해 보이지만, 내부 레플리케이션에 대한 로직은 매우 어렵고 복잡합니다. 이러한 복잡하지만 좋은 기능은 고가용성 기능을 카프카는 지원하고 있습니다.
내구성
프로듀서는 카프카로 메세지를 전송할 때, 프로듀서의 acks 라는옵션을 조정하여 메세지의 내구성을 강화할 수 있습니다.
강력한 메세지의 내구성을 원한다면 옵션에서 acks=all 로 사용할 수 도 있습니다.
이렇게 프로듀서에 의해 카프카로 전송되는 모든 메세지는 안전한 저장소인 카프카 로컬 디스크에 저장되게 됩니다.
카프카의 경우에는 컨슈머가 메세지를 가져가더라도 메세지는 삭제되지 않고 지정한 설정 시간 또는 로그의 크기 만큼 로컬 디스크에 보관되므로 코드의 버그나 장애가 발생하더라도 과거의 메세지들을 불러와 재처리 할 수 있습니다.
개발 편의성
카프카는 메세지를 전송하는 역할을 하는 프로듀서 와 메세지를 가져오는 역할을 하는 컨슈머가 완벽하게 분리 되어 동작하고 서로 영향을 주지도 받지도 않습니다.
따라서 프로듀싱을 원하는 개발자는 프로듀싱만 보면 되고, 컨슈밍을 원하는 개발자는 컨슈머만 보면 됩니다.
또한 개발 편의성을 제공하기 위해 카프카에서는 카프카 커넥트(Kafka Connect) 와 스키마 레지스트리 를 제공 하고 있습니다.
운영 및 관리 편의성
카프카는 앞서 언급한 여러 장점으로 인해 중앙 메인 데이터 파이프라인 역할을 하게 되는데, 운영이나 관리의 편의성이 떨어진다면 그와 같은 주요 역할을 맡기가 부담스러울수도 있습니다.
중요한 역할을 하는 애플리케이션이라면 성능 확장을 위한 증설 작업이 쉽고 간단해야 하며, 최신 버전이 릴리즈되는 경우 무중단으로 버전 업그레이도 가능해야 하고 , 버전 업그레이드 작업 역시 단순 해야 합니다.
이런 측면에서는 카프카는 다양한 기능과 3rd Party 를 통해 관리 편의성을 높일수 있는 부분이 있습니다.
다양한 카프카의 사용 사례
추가적으로 실제로 적용하고 사용한 사례 몇가지를 살펴보려고 합니다.
카프카와 에코시스템의 공개로 인해 많은 기업 들에서는 이제 단순하게 카프카를 펍/섭 모델로만 사용하는데 그치지 않고, 데이터 통합, 메세지 버스, 실시간 데이터 처리,실시간 데이터 분석 등 여러 용도로 활용하고 있습니다.
어떤 다양한 측면으로 사용이 되는지를 살펴보도록 하겠습니다.
데이터 파이프라인 : 넷플릭스 사례
넷플릭스는 데이터 기반 회사로서 풍부한 데이터 분석을 통해 비지니스와 제품에 대한 의사결정을 내립니다.
전 세계에 걸쳐 커다란 규모로 데이터를 수집,통계, 처리 , 적재 하기 위한 파이프라인들이 연결되어 있어 이러한 파이프라인을 연결해주는 역할로 카프카를 사용하고 있습니다.
[netflixtechblog/netflix-data-pipeline]
위의 이미지는 넷플릭스 블로그에서 공개한 카프카로 구성한 데이터 파이프라인 사례 입니다.
넷플릭스 사용자의 시청 활동, 유저 인터페이스 사용 빈도, 에러 로그 등의 모든 이벤트는 데이터 파이프라인을 통해 흐르게 되고 넷플릭스는 이러한 내용을 분석하여 사용자의 경험을 예측해 능동적으로 대응할 수 있게 됩니다.
스마트 시티 분야 활용 사례
스마트 시티는 다양한 형태의 IOT(사물 인터넷) 데이터를 수집하여 정보를 얻고 이를 바탕으로 자산, 리소스, 서비스 의 운용 효율을 높입니다. 스마트 시티에서는 데이터 수집이 좀 더 광범위하게 이루어지며, 대중교통, 쓰레기 관리, 범죄 감지, 학교, 도서관 , 병원 등 다양한 커뮤니티 서비스가 포함 됩니다.
[kai-waehner.de/building-smart-city-kafka]
위의 이미지는 스마트 시티에서 데이터 수집 ,분석, 활용하는 예를 보여주고 있습니다. 스마트 시티는 일반 기업에서의 서비스 같은 일부 특정 서비스가 아닌 도시 규모로 발생되는 모든 데이터를 수집하고 분석을 하고 있습니다.
이렇게 많은 양의 데이터를 처리하기 위해서 카프카가 사용 되고 있습니다. 여러 도시에서 수집된 데이터를 분석하기 위해서 중앙에 위치한 카프카로 데이터가 전송 되며 이때 카프카와 카프카 사이에 안정적인 데이터 전송을 위해서 카프카 커넥터가 활용 됩니다.
해당 포스팅은 실전 카프카 개발부터 운영까지 책의 많은 내용 중에서 일부분의 내용만 함축적으로 정리한 것으로 모든 내용 확인 및 이해를 위해서 직접 책을 통해 모든 내용을 확인하시는 것을 권해 드립니다.
다음 이어지는 글
Reference
Reference Book
• 실전 카프카 개발부터 운영까지
연관된 다른 글
Principal DBA(MySQL, AWS Aurora, Oracle)
핀테크 서비스인 핀다에서 데이터베이스를 운영하고 있어요(at finda.co.kr)
Previous - 당근마켓, 위메프, Oracle Korea ACS / Fedora Kor UserGroup 운영중
Database 외에도 NoSQL , Linux , Python, Cloud, Http/PHP CGI 등에도 관심이 있습니다
purityboy83@gmail.com / admin@hoing.io
