카프카 Apache Kafka
또 아파치다. 비영리 소프트웨어 재단이라고 하는 아파치 대체 뭐길래 매번 등장하는거야. 하둡이랑 XML, 엘라스틱서치(정확히는 루신) 얘기에 모두 빠지지 않았는데 언젠가는 이 재단이 어떻게 유지되는건지에 대해서도 알아볼 날이 있으려나.
아파치 카프카는 오픈 소스 분산 이벤트 스트리밍 플랫폼으로서, 고성능의 데이터 파이프라인, 스트리밍 분석, 데이터 통합, 그리고 미션 크리티컬한 - 오차가 있으면 안 되는 항공우주나 은행 등 - 어플리케이션에서 사용될 수 있다. 아래의 세 가지 주요 기능을 포괄한다.
- 연속된 이벤트를 읽고 read 쓸 write 수 있으며, 이는 다른 시스템의 데이터를 import / 다른 시스템으로의 export를 포괄한다.
- 지속적이고 신뢰 가능하게 연속된 이벤트를 저장 store 할 수 있다.
- 이벤트를 실시간 혹은 사후적으로 처리 process 할 수 있다.
여튼 핵심은, 카프카가 오류로부터 안전한 실시간 이벤트(무엇이/언제) 의 파이프라인 및 저장소라는 것.
특징
오픈 소스이고, 쉽게 확장 가능함. 특히 라이센스 피가 전무하다고 한다. 커스텀화를 위한 수정 배포 역시 자유. 쉽게 확장 가능한 점은 분산 플랫폼의 이점 덕분이다.
이벤트 스트리밍
데이터를 지속적으로 흐르게 하고, 또 설명 가능하게 해서 right place, right time에 서빙할 수 있도록 하는 아래의 활동들을 포괄한다.
- 데이터베이스, 센서, 모바일 기기, 클라우드 서비스, 소프트웨어 어플리케이션 등 이벤트가 발생하는 소스로부터 "연속된 이벤트"의 데이터를 실시간으로 확보하는 것
- 이러한 이벤트를 이후의 사용을 위해 저장하는 것
- 이벤트 스트림을 실시간 혹은 사후적으로 조작/처리/대응하는 것
- 이벤트 스트림을 다른 용도에 사용하는 것
예를 들어, 주식거래소나 은행 등에서 발생하는 거래나 결제를 실시간으로 처리할 수도 있고, 회사의 여러 부서에서 발생하는 데이터를 상호 연결하고, 저장하고, 활용할 수 있는 형태로 만들 수도 있다.
이벤트
이벤트에 대한 정의는 너무 당연하게도, "어떤 일이 일어났"는지이다. 이벤트는 대체로 키, 값, 타임스탬프, 그리고 헤더에의 메타데이터(optional) 로 이루어져있다. 이를테면 아래처럼.
- Event key: "Alice"
- Event value: "Made a payment of $200 to Bob"
- Event timestamp: "Jun. 25, 2020 at 2:06 p.m."
카프카가 작동하는 방식
생산자 Producer 는 카프카로 이벤트를 발행 write 하는 클라이언트 어플리케이션이고, 소비자 Consumer 는 이 이벤트를 읽고 read 처리 process 한다. 카프카는 높은 확장성 scalability 을 달성하기 위해 생산자와 소비자가 철저히 분리되어 있다. 예를 들어, 생산자는 이벤트의 발행을 위해 소비자의 처리를 기다릴 필요가 없다. 카프카는 각 이벤트가 "단 한 번" 기록되고 전달되어 (Exactly once—each message is delivered once and only once.) 누락되거나 중복되지 않는다.
이벤트는 정돈되어 토픽 topics 의 형태로 저장된다. 토픽은 파일시스템으로 치면 "폴더"와 유사하고, 이벤트들은 이 폴더 안에 있는 파일에 해당한다. 카프카의 토픽은 항상 0~복수의 생산자와 소비자를 가질 수 있다. 이벤트는 몇 번이고 소비 read 될 수 있으며, 소비된 이후에도 사전에 지정한 조건이 도래하기 전까지는 삭제되지 않는다. 카프카의 성능은 데이터 사이즈에 구애받지 않기 때문에 장기간의 데이터를 보관하는 것에 문제는 없다.
토픽
토픽은 기본적으로 파티션화되어 있다. 말인 즉슨, 토픽은 다른 카프카 "브로커"에 위치한 몇 개의 "버킷"에 퍼져 있다. 이렇게 데이터가 분산되어 있다는 것은 확장성에 매우 중요한데, 여러 명의 브로커에게, 혹은 브로커로부터 클라이언트 어플리케이션이 데이터를 동시에 읽고 쓸 수 있게 해주기 때문이다.
하나의 이벤트가 발생하면 토픽 중 하나의 파티션에 추가된다. 같은 키(customer나 vehicle ID 같은) 를 가진 데이터는 같은 파티션에 쓰여지는데, 어떤 경우에도 데이터를 읽을 때에는 데이터가 쓰여진 순서대로 제공된다.
데이터의 내결함성 fault-tolerant 과 고가용성 highly-available 을 위해 모든 토픽은 복제되며 다른 데이터센터에 보관되기도 한다. 대체로 3부 정도의 복제본을 가지고 있다.
카프카 사용 예시 1
"유사한 제품들"을 추천해주는 사이트이다. 고객의 클릭 등 액션이 카프카를 통해 로깅되고 카프카로 전달된다. 몇 가지의 추천 관련 어플리케이션이 이런 메시지를 소비하고, 고객의 클릭 이벤트가 발생한 제품과 유사한 제품을 실시간으로 분석해 유저 프론트로 전달한다. 한편, 이러한 추천 이력 데이터 역시 모두 저장되므로, 추천 이력을 일배치로 돌려서 고객에게 푸시 메일을 보낼 수도 있다.
카프카 사용 예시 2
시스템 실패를 감지하기 위한 모니터링 앱에 카프카 스트림을 사용할 수 있다. 서버로부터 실시간으로 syslog를 받아오는 카프카 스트림 앱을 활용해, 이를 모니터링 앱에 피딩하고 평소와 다른 트래픽 등을 감지할 수 있다.
"쿠버네티스에 카프카를 올린다" 에 대해
쿠버네티스와 같은 컨테이너 오케스트레이션 플랫폼에서 Apache Kafka를 배포하면 이벤트 기반 애플리케이션을 어디서나 자동화, 확장, 배포할 수 있습니다. 간단히 말하자면 쿠버네티스 Apache Kafka에 빌드된 애플리케이션의 내재적 유연성을 증폭시킵니다.
원래 이 글은 저 위의 문장을 이해하기 위해 시작했지만, 카프카 하나만으로도 너무 벅찬 주제라... 쉽게 말해 쿠버네티스 플랫폼이 카프카를 운용하기에 여러모로 장점이 있다는 건데, 실제 쿠버네티스 위에 카프카를 올린 라인 쇼핑의 사례가 있어 링크를 걸어두었다.
카프카 사용 예시 3 - 라인 쇼핑의 사례
오늘의 메인 주제인 카프카에 한정해 위 사례를 정리해보자면, 기존 Oracle RDB 상에서는 배치를 통해 상품 업데이트를 반영했는데, 몇 천만 개의 상품에는 가능하지만 몇 억개의 상품에 대해서는 상품 변경(판매자의 상품명 수정이라든가) 을 "처리의 앞부분에 있는 데이터가 뒷부분에 있는 데이터의 처리를 기다려야 해서" 빠르게 반영할 수 없었다는 것. 상품 변경이라는 event가 중심이 되는 EDA (Event Driven Architecture) 로 전환하고, 이 때 데이터 브로커로서 Kafka를 사용하기로 했다는 이야기.
마치며
쿠버네티스와의 관계도 물론 궁금하긴 했는데, 대체 "원래 있던 카프카 스트림으로 드릴게요" 라는 게 무슨 말인지도 궁금했었다. 여태까지의 내용을 종합해서 이해해보자면, "변경이 발생한 이벤트들에 대해 배치batch 기다리지 말고 실시간 스트리밍 방식으로 내놔라" 였던 것으로. 저 위의 라인 쇼핑의 사례는 지금 하고 있는 다른 일과도 연관이 깊어서... 따로 파보면 좋을 것 같다.
참고
https://kafka.apache.org/intro
https://www.cloudkarafka.com/blog/part1-kafka-for-beginners-what-is-apache-kafka.html
https://engineering.linecorp.com/ko/blog/line-shopping-platform-kafka-mongodb-kubernetes/
https://www.redhat.com/ko/topics/integration/why-run-apache-kafka-on-kubernetes
https://engineering.linecorp.com/ko/blog/line-shopping-platform-kafka-mongodb-kubernetes/
'Data' 카테고리의 다른 글
| OLAP과 OLTP (0) | 2022.02.09 |
|---|---|
| xml과 json (4) | 2022.02.01 |
| Apache Hadoop 하둡 (1) | 2022.01.31 |
