[Kafka Study] 01. 카프카 특징과 이용 사례 w/실전 카프카 개발부터 운영까지

"카프카를 공부할 거야"라고 했더니 "갑자기 프란츠 카프카는 왜?"라는 말을 들었다. 그 카프카가 아니라 다른 카프카라고 설명하려는데 말문이 막혔다. 대용량 데이터를 처리할 때 쓰는 건데, 그러니까... 이제부터 공부하려고! 라고 얼버무리고 보니 이 정도로 아는 게 없다는 게 부끄러웠다. 그래서 카프카 스터디를 시작하기에 앞서 카프카가 왜 중요한지 알아보았다. 스터디는 책만 출판사의 <실전 카프카 개발부터 운영까지>를 기반으로 진행하고, 공부하면서 참고한 자료는 하단에 첨부해놓았다.

카프카 Kafka

아파치 카프카는 정말 프란츠 카프카Franz Kafka에서 따온 이름이라고 한다. 아파치 카프카를 만든 제이 크렙스Jay Kreps가 평소에 프란츠 카프카를 존경했다고.. 아무튼, 카프카 소개를 찾아보면 이 세 가지 키워드가 눈에 띈다.

1. 이벤트 기반 Event Driven
2. 대규모 데이터
3. 스트리밍 또는 실시간 처리

이게 왜 그렇게 특별할까?

 

1. 이벤트 기반 Event-Driven

카프카가 표준화가 되는 과정의 시작점에는 기업들이 이벤트 기반 시스템(EDA)으로 전환하려는 움직임이 있다. 데이터의 절대량이 증가하는 것과 동시에 실시간 데이터 활용에 대한 수요와 데이터에 대한 다양한 요구사항이 증가하면서 많은 기업은 이벤트 기반 시스템으로 전환하고자 했다. 그 과정에서 기업들이 당면한 문제를 해결할 수 있는 답으로 카프카만 한 것이 없었다. 

 

2. 대규모 데이터

카프카는 여러 개의 메시지 큐를 기반으로 한 분산 시스템이다. 또한, 카프카는 배치Batch 전송이 가능하다. 이 두 가지 특성을 모두 가졌기 때문에 카프카는 대규모 데이터를 빠르면서도 안정적으로 처리할 수 있다. 시간이 갈수록 기업에서 하루에 감당해야 하는 데이터는 상상을 초월하는 규모로 커지고 있다. 이를 제시간에 올바르게 처리하려면 기존의 데이터 파이프라인으로는 한계가 많았고, 카프카가 그 대안이 되어주고 있다. 그래서 카프카는 엔터프라이즈급 아키텍처에서 거의 필수 요소로 꼽힌다. 이런 특성을 만들어낸 카프카의 구성 요소(파티션, 세그먼트 등)나 프로듀서Producer와 컨슈머Consumer, 브로커Broker 등의 자세한 구조는 3장에서 설명하고 있어서 3장을 공부할 때 더 자세히 정리해보겠다.

 

3. 스트리밍 또는 실시간 처리

카프카에는 '실시간 이벤트 데이터 전달', '실시간 스트리밍 데이터 처리' 등 여러 수식어를 붙인다. 표현은 다 달라도 하고자 하는 말은 하나다. 아파치 카프카는 서버 내에서 요청을 실시간으로 빠르게 처리하는 데에 탁월하다는 것이다. 시간이 갈수록 하루에 처리해야 하는 요청이 기하급수적으로 증가하는 상황에서 이러한 실시간 처리 성능이 꼭 필요하기 때문에 카프카는 점점 없어서는 안 되는 서비스로 자리매김하고 있다. 이와 유사한 특성을 가진 서비스에는 Apache Spark, RabbitMQ, AWS Kinesis 등 몇 가지가 더 있다고 하는데(참고), 카프카를 공부한 후에 이들 간에 어떤 차이가 있고, 언제 무엇을 어떻게 써야 할지 알아보아야겠다.

 

 

카프카의 탄생

전공 서적을 볼 때면 어떤 것을 공부하든 왜 항상 역사를 제일 먼저 알려주는지 궁금했었다. 'C언어는 1972년 벨 연구소의 데니스 리치가 만들었다'라는 설명과 printf("Hello World!");를 실행하는 것은 전혀 관련이 없어 보였기 때문이다.

이 생각이 바뀐 건 Airflow나 카프카같은 비교적 최근에 등장한 서비스를 찾아보면서부터다. 카프카를 들어본 사람은 대부분 카프카가 링크드인에서 만들었다는 걸 알고 있다. 정확하게는 링크드인에서 근무하던 제이 크렙스Jay Kreps와 준 라오Jun Rao, 네하 나크헤데Neha Narkhede가 데이터 파이프라인 구축/운영의 여러 문제점을 해결하기 위해 카프카를 만들었다고 한다. 예전과 다르게 역사 이야기가 흥미로운 이유는 링크드인은 지금까지도 많은 사람이 사용하고 있는 플랫폼이고, 또 수많은 기업에서 유사한 문제가 일어나기 시작하면서 카프카에 더 많은 관심을 쏟고 있기 때문이다.

좀 더 알아보자면 이 세 창시자는 카프카를 2011년에 아파치 오픈소스로 공개했고, 링크드인에서 이룩한 성공을 발판 삼아 2014년에 Confluent라는 회사를 설립하여 카프카를 발전시키고 있다고 한다. 그래서 현재 카프카는 Apache Kafka와 Confluent Kafka 둘로 나뉘어있으며, 일반적으로 말하는 '카프카'는 아파치 카프카를 의미한다고 한다. 이 두 카프카의 차이점은 '한국 카프카 사용자 그룹'에서 개최한 2021년 제1회 온라인 밋업 'Apache Kafka &  Confluent Platform의 새로운 기능 및 로드맵' 발표 영상에서 참고할 수 있다.

 

 

사용 사례와 주요 특징

위에서 카프카는 링크드인에서 데이터 파이프라인 구축/운영 중 발생한 문제를 해결하기 위해 만들었다고 했다. 그 문제에는 데이터 파이프라인 확장의 어려움, 이기종간의 호환성, 고성능 시간의 실시간 데이터 처리의 어려움 등이 있는데, 현재까지도 여러 기업에서 유사한 문제를 해결하기 위해 카프카를 사용하고 있다.

유럽의 온라인 쇼핑몰 잘란도Zalando는 2015년부터 연평균 24%의 성장률을 보이며 2020년 기준 실 사용자 3,100만 명, 연간 주문 수 1억 4,500만 건을 기록하였다. 이 과정에서 내부적으로 데이터에 대한 수많은 요구사항과 문제에 대한 해결 방안이 필요했다. 잘란도는 기존 시스템을 데이터의 변화가 스트림으로 컨슈머 측에 전달되는 이벤트 드리븐 시스템으로 전환하기로 했고, 그 과정에서 몇 가지 핵심 과제를 중점적으로 고민했다고 한다.

먼저 인바운드 데이터와 아웃바운드 데이터가 일치해야 한다는 점에 주목했다. 그리고 CRUD 타입 통신 시 발생하는 데이터 정합성 문제와 데이터 수정 순서를 보장해야 하는 문제, 대량 배치 전송을 빠르게 처리하기 어려운 점 등에서 한계를 느끼고 있기도 했다. 잘란도는 카프카 기반의 느슨하게 결합된 이벤트 드리븐 시스템과 애플리케이션을 구축하여 비동기 방식으로 데이터를 처리하였고, 카프카 스트림즈Kafka Streams를 이용해 실시간 도메인 랭킹 시스템을 구축하기도 했다.

성공적으로 카프카를 적용했던 잘란도와 달리 트위터Twitter는 과거에 카프카를 적용했다가 I/O 오퍼레이션 문제와 기능의 불안정성으로 카프카를 포기하고 인하우스 메시지 시스템(이벤트 버스)을 구축했었다고 한다. 하지만 그 이후로 카프카는 고가용성과 높은 처리량, 빠른 응답 시간을 안정적으로 확보하였고, 카프카가 Pub/Sub 모델을 지원하여 수평 확장이 용이해졌다. 그리고 많은 기업에서 카프카를 사용하면서 강력한 커뮤니티가 생성되자 트위터는 2018년 경 내부적으로 카프카 성능 테스트를 수행했고, 카프카의 성능이 이벤트 버스 성능을 넘어서는 것을 확인하였다. 이를 기점으로 트위터는 고객 데이터를 다시 카프카로 옮겼다.

https://blog.twitter.com/engineering/en_us/topics/insights/2018/twitters-kafka-adoption-story

그 외에도 다양한 분야의 수많은 기업에서 이벤트 기반 시스템으로 전환하면서 카프카를 선택했다. 넷플릭스Netflix는 전 세계 규모의 네트워크 환경에서 데이터를 수집, 통계, 처리, 적재하기 위한 파이프라인을 연결해주는 역할로 카프카를 사용하고 있다. 또 우버Uber는 탑승자와 운전자의 모바일 앱, GPS, 지도 서비스 등의 데이터 프로듀서로부터 이벤트 데이터를 수집하기 위해 카프카를 사용하였다. 머신러닝 분야에서도 모델과 상용 앱에 피처Feature 데이터를 전송하는 플랫폼으로 카프카를 사용하는 사례가 있다. 또 스마트 시티의 IoT 기기들이 이벤트 기반 시스템에서 안정적으로 구동할 수 있도록 카프카를 사용하기도 한다.

https://www.slideshare.net/ConfluentInc/benefits-of-stream-processing-and-apache-kafka-use-cases

 

이렇게 많은 기업들이 카프카를 선택한 이유를 보면 몇 가지로 축약된다.

1. 높은 처리량과 낮은 지연시간
2. 높은 확장성
3. 고가용성과 내구성(또는 영속성)
4. 개발·운영·관리 편의성

 

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

카프카는 전통적인 메시징 큐 시스템인 RabbitMQ에 비해 End-to-End 응답 속도는 느리지만, 처리량에서는 몇 배의 성능을 보여준다. 즉, 대용량 데이터를 실시간으로 처리해야 하는 시스템에서는 카프카가 훨씬 나은 선택이다. 아래는 Confluent에서 측정한 카프카와 Pulsar, RabbitMQ의 처리량과 응답 지연 시간 비교 결과이다. 더 자세한 성능 비교 분석 결과는 여기에서 확인할 수 있다.

https://www.confluent.io/blog/kafka-fastest-messaging-system/

 

2. 높은 확장성

링크드인에서 기존에 사용하던 ActiveMQ는 확장성이 낮아서 링크드인 비즈니스 성장에 따라 급격히 증가하는 스트림 데이터에 대응하기 어려웠다고 한다. 그래서 카프카 개발 초기부터 손쉽게 scale-in, scale-out 할 수 있는 구조로 설계했다고 전해진다. 이 과정은 무중단으로 적용이 가능하다는 장점이 있지만 그만큼 카프카의 여러 옵션에 대해 잘 알아야 하고, 또 더 많은 장애에 대응해야 해서 점점 더 까다로워진다고 한다. 이에 대해서는 8장에서 다룬다고 하니 그때 더 자세히 알아보아야겠다.

 

3. 고가용성과 내구성(또는 영속성)

대규모 데이터 처리를 실시간으로 운영하는 데에 있어서 고가용성을 갖추는 것은 아주 중요하고, 또 어려운 일이다. 카프카는 클러스터 내에 리플리케이션replication, 즉 복제 기능을 추가하면서 높은 가용성을 확보했다고 한다. 프로듀서로 전달받은 데이터를 여러 브로커 중 한 대에서만 가지고 있지 않고 다른 브로커에도 복제하여 장애 발생 시에도 지속적으로 데이터 처리가 가능하도록 한 것이다.

그리고 카프카에서는 프로듀서의 acks 옵션을 사용하여 카프카로 전송되는 모든 메시지를 로컬 디스크에 안전하게 저장할 수 있다. 이를 통해 컨슈머가 메시지를 가져감과 동시에 메시지가 삭제되었던 기존의 메시징 시스템과 달리 과거의 메시지를 다시 불러올 수 있어 장애나 버그 발생 시 문제가 발생했던 요청들을 복구 및 재처리할 수 있다. 이러한 특징에 대해서는 4장에서 더 자세히 다룬다고 한다.

 

4. 개발·운영·관리 편의성

카프카는 프로듀서와 컨슈머가 서로 완벽히 분리되어 동작하므로 각각 개발 및 운영이 용이하다고 한다. 또, 카프카 커넥트Kafka Connect와 스키마 레지스트리Schema Registry라는 애플리케이션을 제공하여 개발 편의성을 높여준다고 한다. 카프카 커넥트는 프로듀서와 컨슈머를 따로 개발하는 대신 소스 커넥트Source Connect와 싱크 커넥트Sink Connect를 통해 메시지를 보내고 받을 수 있도록 하는 애플리케이션이고, 스키마 레지스트리는 스키마를 미리 정의하여 데이터 파싱 리소스를 줄일 수 있도록 도와주는 애플리케이션이라고 한다. 자세한 내용은 5,6, 그리고 8장에서 상세하게 다룬다고 한다.

 

 

 

---

 

책에서는 2장에서 실습 환경을 구축한다. 그런데 그보다 먼저 기본 용어와 구조를 알아보려고 한다. 그 다음 환경을 구성하고, 실습을 진행할 것이다.

 

※ Kafka Study 순서 ※

01. 카프카 특징과 이용 사례
02. 카프카 기본 개념과 구조
03. 카프카 실습 환경 구성 및 프로듀서와 컨슈머 기본동작과 예제
04. 카프카의 내부 동작 원리와 구현
05. 프로듀서의 내부 동작 원리와 구현
06. 컨슈머의 내부 동작 원리와 구현
07. 카프카 운영과 모니터링
08. 카프카 버전 업그레이드와 확장
09. 카프카 보안
10. 스키마 레지스트리
11. 카프카 커넥트
12. 엔터프라이즈 카프카 아키텍처 구성 사례
13. 카프카의 발전과 미래

 

※ 참고 자료와 이미지 출처 ※

[1] 링크드인은 왜 카프카를 만들었나, https://www.hanbit.co.kr/channel/category/category_view.html?cms_code=CMS9400468504
[2] Top 15 Kafka Alternatives Popular In 2021, https://www.spec-india.com/blog/kafka-alternatives
[3] 아파치 카프카 애플리케이션 프로그래밍 with 자바, http://www.kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&ejkGb=KOR&barcode=9791165920548
[4] Apache Kafka & Confluent Platform의 새로운 기능 및 로드맵, https://www.youtube.com/watch?v=_Kk1r_qFbMQ
[5] Benfits of Stream Processing and Apache Kafka Use Cases, https://www.confluent.io/online-talks/benefits-of-stream-processing-and-apache-kafka-use-cases-on-demand/​
[6] Benchmarking Apache Kafka, Apache Pulsar, and RabbitMQ: Which is the Fastest?, https://www.confluent.io/blog/kafka-fastest-messaging-system/
[7] Twitter's Kafka adoption story, https://blog.twitter.com/engineering/en_us/topics/insights/2018/twitters-kafka-adoption-story