오늘은 개인 프로젝트를 위해 카프카에 대해서 공부를 좀 해봤다. 물론 쓰면서 익히는게 맞겠지만 일단 한번 알아보기로 했다.
분산 이벤트 스트리밍 플랫폼으로, 대용량의 데이터를 안정적으로 처리하고 전송하는 데 사용된다. 주로 대량의 데이터를 실시간으로 수집, 저장, 처리하고, 다양한 시스템 간에 데이터를 안전하게 전송하는 데에 사용된다.
처음에는 소스 -> 타겟의 단방향 통신을 수행했다.
하지만 시간이 지나며 소스와 타겟 어플리케이션이 많아지며 데이터 전송 라인이 복잡해졌다.
데이터 전송 라인이 많아지면서 배포와 장애에 대한 대응이 힘들어졌다.
프로토콜과 포맷의 파편화도 심해지며 유지보수가 힘들어졌다.
아파치 카프카는 이러한 복잡함을 소스와 타겟 간 커플링을 약하게 함으로써 해결해준다. 링크드인에서 내부에서 개발하여 현재는 오픈소스로 제공하고있다.
프로듀서(Producer)
카프카 토픽으로 데이터를 전송하는 주체.
여러 응용프로그램에서 생성된 데이터를 토픽에 쓰는(Write) 역할을 한다.
데이터를 특정 파티션에 전송하는데, 이때 특정한 로드 밸런싱 알고리즘을 사용해 파티션에 고르게 데이터를 분배한다.
브로커(Broker)
카프카 클러스터를 구성하는 각각의 서버.
데이터를 관리하고 클러스터 내에서 역할을 분담한다.
데이터를 읽고 쓰는 기능을 수행하면서 하나 이상의 파티션에 대한 리더 or 팔로워 역할을 맡는다.
프로듀서가 전송한 데이터를 받아 해당 토픽의 파티션 중 하나에 저장한다.
컨슈머(Consumer)
특정 토픽에서 데이터를 읽어오는 역할.
여러 컨슈머가 동시에 동일한 토픽의 다른 파티션에서 데이터를 소비할 수 있다.(데이터 처리의 병렬화) 그리고, 컨슈머 그룹을 통해 여러 컨슈머가 하나의 토픽을 공유해 처리할 수 있다.
토픽(Topic)
데이터 스트림을 논리적으로 구분하는 단위
프로듀서는 데이터를 특정 토픽으로 전송하며, 컨슈머는 해당 토픽에서 데이터를 읽어온다.
토픽은 여러 파티션으로 나눠져 있다.
파티션(Partition)
토픽은 하나 이상의 파티션으로 나눠진다. 각 파티션은 독립적인 로그 파일을 가지고 있고, 메시지의 순서를 보장하기 위해 사용된다. 여러 브로커에 데이터를 분산 저장하고, 복제를 통해 데이터의 안정성을 보장한다.
주키퍼(Zookeeper)
카프카 클러스터의 구성정보를 관리하고, 브로커들 간 조율을 담당한다.
분산 환경에서 안정적인 동기화와 리더 선출을 지원해 카프카의 안정성에 기여한다.
위와 같은 구성요소들로 카프카는 대규모 실시간 데이터 처리 및 전송을 위한 강력한 플랫폼을 제공한다. 카프카에서는 기본적으로 카프카 서버가 브로커 역할을 하며, 프로듀서와 컨슈머는 카프카에서 제공하는 API로 구현된 애플리케이션을 의미한다.
여러 프로듀서가 동시에 메시지를 전송할 수 있고, 여러 컨슈머가 동시에 메시지를 읽을 수 있다.
빠른 속도로 대용량의 데이터를 처리하기 쉽고, 낮은 지연시간으로 메시지를 빠르게 처리한다.
지속성 (Durability) : 프로듀서가 전달한 메시지는 브로커에 의해 영속적인 형태로 저장된다. 메모리에만 처리되는게 아니라 디스크에 파일로 저장된다. 따라서 브로커에서 메시지를 영구적으로 저장하고 관리하므로 메시지는 중간에 손실되지 않고 안전하게 보관된다.
고가용성(High Availability) + 확장성 : 클러스터는 복수의 브로커로 구성된다. 각 브로커가 특정 토픽의 일부 파티션을 관리하고 있기 때문에, 하나의 브로커에 장애가 발생해도 다른 브로커가 역할을 대신할 수 있다. 브로커간 데이터 복제로 장애에 대비하고, 새로운 브로커 추가로 시스템을 쉽게 확장할 수 있다.
다양한 언어로 작성된 클라이언트 라이브러리를 제공해 프로듀서와 컨슈머를 쉽게 개발할 수 있다.
컨슈머가 프로듀서의 생성속도를 따라잡지 못하면 컨슈머를 그룹으로 묶어 양쪽 속도간 균형을 맞출 수 있다.
모니터링이나 관리 도구가 불편하고, 메시지 조정이 필요한 경우 카프카의 성능이 크게 저하된다는 단점이 있다. 그리고 클러스터 대기열 수가 증가하면 느리게 동작하는 경우가 있다.