카프카는 실시간 데이터 스트리밍 및 데이터 파이프라인으로 주로 많이 쓰인다고 한다.
카프카가 데이터 파이프라인으로 적합하기 때문인데 그 이유가 무엇일까?
프로듀서가 브로커로 데이터를 보낼 때와
컨슈머가 브로커로 데이터를 받을 때 모두 데이터를 묶어서 전송한다.
많은 양의 데이터를 송수신한다면, 네트워크 비용은 무시할 수 없다.
이럴 경우, 네트워크 통신 횟수를 최소한으로 줄여 동일 시간 내에 더 많은 데이터를 전송하는 방법이 있다.
카프카는 많은 양의 데이터를 배치로 묶어 빠르게 처리할 수 있어 대용량 실시간 로그데이터를 처리하는 데에 적합하다.
파티션 단위를 통해 동일 목적의 데이터를 여러 파티션에 분배하고 데이터를 병렬 처리할 수 있다. 그리고 파티션의 개수만큼 컨슈머 개수를 늘려서 동일 시간당 데이터 처리량을 늘릴 수 있다. (Scale-out)
데이터 파이프라인에서 데이터를 모을 때 데이터가 얼마나 들어올 지 예측하기 어렵다.
카프카는 가변적인 환경에서 안정적으로 확장이 가능하도록 설계되어 있다.
데이터가 많아지면 브로커의 수를 자연스럽게 늘려 Scale-Out 할 수 있다.
반대로, 데이터 개수가 적어져 추가 서버들이 더 필요하지 않다면,
브로커의 개수를 줄여 Scale-In 할 수 있다.
Scale-Out과 Scale-In을 한다면 이를 위해 잠시 중단되는 경우가 있지 않을까? 생각해보았지만 카프카는 무중단 운영을 지원한다.
그래서 365일 24시간 데이터를 처리해야하는 커머스나 은행과 같은
비즈니스 모델에서도 안정적으로 운영할 수 있다.
카프카 클러스터 & 브로커
카프카 클러스터는 여러 개의 브로커로 이루어져 있다.
프로듀서가 데이터를 저장한다면 클러스터의 브로커들에게 메시지들이 각각 저장된다.
브로커가 처리할 수 있는 데이터의 량은 한계가 있으며,
이를 해결하려고 한다면 브로커를 추가로 붙이는 방법이 있다.
영속성은 데이터를 생성한 프로그램이 종료되더라도 사라지지 않는 데이터의 특성을 의미한다.
카프카는 전송받은 데이터를 메모리가 아닌 파일 시스템에 저장한다.
→ 그렇다면 속도가 느리지 않나?
카프카는 운영체제 레벨에서 파일 시스템을 최대한으로 활용하는 방법을 적용하여 속도가 느리지 않다.
운영체제에서는 파일 I/O 성능 향상을 위해 페이지 캐시(page cache) 영역을 메모리에 따로 생성하여 사용한다.
페이지 캐시 메모리 영역을 사용하여 한 번 읽은 파일 내용은
메모리에 저장하여 다시 사용하는 방식이다.
또한, 디스크 기반의 파일 시스템을 활용하여 브로커 애플리케이션에
장애가 발생하더라도 프로세스를 재시작하여 안전하게 데이터를 다시 처리할 수 있다.
3개 이상의 서버로 운영되는 카프카 클러스터는 일부 서버에 장애가 발생하더라도 무중단으로 안전하고 지속적으로 데이터를 처리할 수 있다.
프로듀서가 카프카 클러스터에 데이터를 보낼 경우,
메시지는 한 개의 프로세스(브로커)에만 저장되는 것이 아닌 복제가 되어서 다른 프로세스에서도 저장이 된다.
이처럼 여러 브로커에 저장함으로써 한 개의 브로커에 장애가 발생하더라도 다른 브로커에 저장되어 있는 데이터를 바탕으로 지속적으로 처리가 가능하다.
적재된 데이터를 바탕으로 컨슈머는 여러 개의 브로커가 갖고 있는 복제된 데이터를 사용함으로써, 프로듀서가 데이터를 보내고 컨슈머가 데이터를 가져가는 흐름이 끊김이 없이 계속될 수 있다.
추가적으로 서버를 직접 운영하는 온프레미스(on-promise) 환경의 서버 렉 또는 퍼블릭 클라우드의 리전 단위 장애에도 데이터를 안전하게 복제할 수 있는 브로커 옵션들이 준비되어 있다. 덕분에 여러 환경에서 안전하게 운영할 수 있다.