기업에서 데이터는 핵심 비즈니스와 직결되는 중요한 부분이다. 이런 데이터를 빠르고 더 적은 노력으로 다룰 수 있게 된다면 더욱 핵심 비즈니스에 집중할 수 있게 될 것이다.
서버 간 데이터 이동을 위해 간단한 메시지 큐나 프로세스 간 통신 채널을 놓음
서비스가 많아질수록 발행자/구독자의 관계가 복잡해지고 기술 부채가 심해짐
중간에서 개별 메시지 큐를 통해 관리하여 발행자/구독자의 관계를 명확하게 해줄 수 있지만, 다른 유형의 데이터를 서빙하려면 메시지 큐 자체가 늘어나게 되어 다시 복잡해짐
위와 같은 문제점들을 해결하기 위해 고안된 메시지 발행/구독 시스템이다.
'분산 커밋 로그', '분산 스트리밍 플랫폼' 이라고 불리기도 한다. 데이터베이스에서의 커밋 로그처럼 데이터를 순서를 유지한 채 지속성있게 보관되며 결정적(deterministic)으로 읽을 수 있다.
확장 시 데이터를 분산 저장하여 성능을 높이고 HA를 구축할 수 있다.
일정 기간 또는 일정 양의 데이터를 지속성있게 보관할 수 있으며, 토픽에는 로그 압착 기능을 통해 필요한 데이터만 저장하여 저장 효율을 높일 수 있다.
메시지
데이터의 기본 단위
데이터베이스의 row, record 와 비슷하게 볼 수 있음.
단순한 바이트 배열이며, key 라고 불리는 메타데이터 바이트 배열을 추가로 가져, 분산 처리를 할 때 어느 파티션에 들어갈 지를 정하는 용도로 사용할 수 있음.
배치
메시지를 저장하는 단위
단건으로 메시지를 쓰게되면 네트워크 비용이 발생하므로 배치 단위로 데이터를 묶어 한 번에 처리해 효율을 높임
전체적인 메시지 처리량을 향상시킬 수 있으나, 이로 인해 단건으로 메시지를 처리하는 것 보다 평균적인 지연 시간은 길어질 수 있음
효율적인 전송과 저장을 위해 배치는 압축되는 경우가 많음
스키마
카프카 입장에서 메시지는 단순한 바이트 배열이지만, 사용하는 입장에서 이해하기 쉽도록 일정한 구조(스키마)를 부여하는 것이 권장됨
JSON, XML 과 같은 많이 사용하는 스키마를 사용하면 좋겠지만, 타입 처리 기능이나 스키마 버전 간 호환성 문제 때문에 많은 아파치 카프카 개발자들은 아파치 에이브로(Avro)를 선호함. 아파치 에이브로는 메시지 본체와 스키마를 분리하여 스카마 변경에 대응하기 쉬우며, 강력한 데이터 타이핑, 스키마 상위호환, 조밀한 직렬화 제어 방식 제공 등 다양한 장점이 있음.
토픽
카프카의 메시지를 분류하는 단위
데이터베이스의 테이블, 파일시스템의 폴더와 유사함
토픽은 다시 여러 개의 파티션으로 나누어짐
토픽 내 메시지의 전체적인 순서는 보장되지 않음
파티션
파티션은 커밋 로그 관점에서 하나의 로그에 해당함
메시지가 쓰여질 때 추가만 가능한 형태
파티션 내 메시지의 순서는 보장됨
파티션은 하나의 토픽 내에서 분산되어 다른 서버에 저장될 수 있기 때문에 수평적 확장에 용이하며 HA로 구축할 수 있음
스트림
하나의 토픽에 저장된 데이터로 간주되며, 프로듀서로부터 컨슈머로의 하나의 데이터 흐름을 나타냄
프로듀서
메시지를 생성하는 클라이언트
다른 발행/구독 시스템에서는 발행자(publisher), 작성자(writer)라고도 부름
기본적으로 토픽을 지정하여 메시지를 생성함
특정 파티션으로만 메시지를 쓰기 위해 파티셔너(키와 키값으로 해시를 통해 파티션을 특정)를 사용하기도 함
컨슈머
메시지를 읽는 클라이언트
다른 발행/구독 시스템에서는 구독자(subscriber), 독자(reader)라고도 부름
1개 이상의 토픽을 읽어와 각 파티션에 쓰여진 순서대로 메시지를 읽어옴
읽은 메시지의 오프셋(파티션의 메시지별로 갖는 고유한 값)을 기록(대체로 카프카 자체에 저장)하여 어느 메시지까지 읽었는지 유지하며, 이를 통해 읽기 작업을 정지했다가 다시 시작하더라도 마지막으로 읽었던 메시지의 바로 다음 메시지부터 읽을 수 있음
컨슈머 그룹
컨슈머는 컨슈머 그룹의 일원으로서 작동함
각 파티션이 하나의 컨슈머에 의해서만 읽히도록 함
컨슈머와 파티션의 대응 관계를 소유권(ownership)이라고도 부름
컨슈머를 수평 확장하기에 용이하며, 장애가 발생한 컨슈머가 읽고 있던 파티션을 다른 컨슈머가 이어서 데이터를 읽을 수도 있음
브로커
하나의 카프카 서버를 지칭하는 말
프로듀서의 메시지를 받아 오프셋을 할당해 디스크에 저장하고, 컨슈머의 읽기 요청도 처리하여 메시지를 발행함
하나의 브로커가 초당 수천 개의 파티션과 수백만 개의 메시지를 쉽게 처리할 수 있음
클러스터
브로커가 클러스터의 일부로 동작함
여러 개의 브로커가 하나의 클러스터로 동작할 수 있으며, 그 중 하나의 브로커가 클러스터 컨트롤러의 역할을 하게 됨
컨트롤러는 파티션을 브로커에 할당하거나 장애가 발생한 브로커를 모니터링하는 등의 관리 기능을 담당
파티션은 클러스터 안의 브로커 중 하나가 담당하며 그 브로커를 파티션 리더라고 부르며, 파티션을 복제하여 다른 여러 브로커에 할당될 수도 있는데 해당 브로커를 팔로워라고 부름
파티션 리더에 프로듀서가 메시지를 생성해야 클러스터 내 브로커들에서 메시지를 읽을 수 있음
파티션 리더에 장애가 발생 시 팔로워가 리더 브로커의 역할을 이어 받음
다중 클러스터
카프카 시스템이 확장됨에 따라 클러스터를 다수로 운용하는 것이 나은 경우가 있음
데이터를 유형별로 분리할 때
보안 요구사항을 충족시키기 위해
재해 복구를 위한 다중 데이터 센터
다중 데이터 센터를 운영할 경우 각 데이터 센터에서 동일한 데이터를 읽어올 수 있어야 하므로 카프카 프로젝트는 데이터를 다른 클러스터로 복제하는 미러메이커라는 툴을 포함함
발행/구독 시스템은 이미 여러 가지가 사용되고 있었다. 카프카만의 장점을 알아보자.
다중 프로듀서
여러 프로듀서 클라이언트가 하나의 토픽이든 여러 개의 토픽이든 자연스럽게 사용할 수 있도록 설계됨
데이터를 분석할 때 여러 개로 나누어진 MSA 환경에서 다양한 데이터를 수집하기 용이함
다중 컨슈머
하나의 메시지를 하나의 클라이언트에서 소비하는 다른 큐 구조 시스템들과는 달리 어떠한 메시지 스트림이든 많은 컨슈머가 상호 간섭없이 읽을 수 있음
디스크 기반 보존
메시지를 지속성있게 보관하여 일시적인 트래픽 폭주, 느린 처리 속도 등으로 메시지가 쌓여도 데이터 유실의 걱정이 없음. 컨슈머를 늘리거나 컨슈머를 재시작하더라도 카프카가 메시지를 보관하고, 해당 지점부터 읽어올 수 있기 때문
확장성
사용성 검증을 위해 설계한 3개의 브로커를 가진 개발용 클러스터에서 수백 개의 브로커로 구성된 대규모 클러스터가 되기 까지 유연하게 확장할 수 있음
카프카 클러스터는 전체의 가용성에 영향을 주지 않으면서 확장이 가능함
고성능
지금까지 설명한 특징들 때문에 큰 메시지 스트림도 쉽게 다룰 수 있고 높은 성능을 보임
플랫폼 기능
카프카 커넥트, 카프카 스트림즈 등 카프카에서 자주 반복되는 작업을 쉽게 할 수 있도록 도와주는 API, 라이브러리를 사용할 수 있음