아파치 카프카는 메시지 발행/구독 시스템이다. '분산 커밋 로그' 혹은 '분산 스트리밍 플랫폼'이라고 불리기도 한다.
파일시스템이나 데이터베이스 커밋 로그는 모든 트랜잭션 기록을 지속성 있게 보존함으로써 시스템의 상태를 일관성 있게 복구할 수 있도록 고안되었다. 이와 유사하게, 카프카에 저장된 데이터는 순서를 유지한 채로 지속성 있게 보관되면 결정적으로 읽을 수 있다. 또한, 확장시 성능을 향상시키고 실패가 발생하더라도 데이터 사용에 문제가 없도록 시스템 안에서 데이터를 분산시켜 저장할 수 있다.
1. 메시지와 배치
카프카에서 데이터의 기본 단위는 메시지 이다. 메시지는 키(key)라 불리는 메타데이터를 포함할 수 있다. 키는 메시지를 저장할 파티션을 결정하기 위해 사용된다. 가장 간단한 방법은 키값에서 일정한 해시값을 생성한 뒤 이 값을 토픽의 파티션 수로 나눴을 때 나오는 나머지 값에 해당하는 파티션에 메시지를 저장하는 것이다. 이렇게 하면 같은 키값을 가진 메시지는 항상 같은 파티션에 저장된다.
카프카는 효율성을 위해 메시지를 배치 단위로 저장한다. 배치는 그저 같은 토픽의 파티션에 쓰여지는 메시지들의 집합일 뿐이다. 메시지를 쓸 때마다 네트워크를 통하여 신호가 오가는 것은 막대한 비용이 발생하는데, 메시지를 배치 단위로 모아서 쓰면 이것을 줄일 수 있다. 물론 이것은 레이턴시와 처리량 사이에 트레이드 오프를 발생시킨다. 즉, 배치 크기가 커질수록 시간당 처리되는 메시지의 수는 늘어나지만, 각각의 메시지가 전달되는 데 걸리는 시간은 늘어나는 것이다. 배치는 효율적인 데이터 전송과 저장을 위해 압축될 수 있다.
2. 스키마
카프카 입장에서 메시지는 단순한 바이트 배열일 뿐이지만, 내용을 이해하기 쉽도록 일정한 구조(스키마)를 부여하는 것이 권장된다. 가장 간단하고 많이 사용하는 형태는 JSON 이나 XML 이 있다.
카프카에서는 메시지 쓰기와 읽기 작업을 분리할 수 있도록 해주기 때문에 일관적인 데이터 형식이 중요하다. 잘 정의된 스키마를 공유 저장소에 저장함으로써 카프카는 두 버전 형식을 동시에 지원하는 작업 없이도 메시지를 처리할 수 있다.
3. 토픽과 파티션
카프가에 저장되는 메시지는 토픽 단위로 분류된다. 토픽과 가장 비슷한 개념으로는 데이터베이스의 테이블이나 파일시스템의 폴더가 있을 것이다. 토픽은 다시 여러개의 파티션으로 나뉘어 진다. 커밋 로그의 관점에서, 파티션은 하나의 로그에 해당한다. 파티션에 메시지가 쓰여질 때는 추가만 가능(append-only)한 형태로 쓰여지며, 읽을 때는 맨 앞부터 제일 끝까지의 순서로 읽힌다. 대개 토픽에 여러 개의 파티션이 있는 만큼 토픽 안의 메시지 전체에 대한 순서는 보장되지 않으며, 단일 파티션 안에서만 순서가 보장될 뿐이다.
카프카와 같은 시스템을 이야기할 때면 스트림(stream) 이라는 용어가 자주 사용된다. 대부분의 경우 스트림은 (파티션의 개수와 상관없이) 하나의 토픽에 저장된 데이터로 간주되면, 프로듀서로부터 컨슈머로의 하나의 데이터 흐름을 나타낸다.
4. 프로듀서와 컨슈머
카프카의 클라이언트는 시스템의 사용자이며, 기본적으로 프로듀서와 컨슈머 두 종류가 있다.
프로듀서는 새로운 메시지를 생성한다. 다른 발행/구독 시스템에서는 퍼블리셔(publisher) 혹은 작성자(writer) 라고도 부른다. 메시지는 특정한 토픽에 쓰여진다. 기본적으로 프로듀서는 메시지를 쓸 때 토픽에 속한 파티션들 사이에 고르게 나눠서 쓰도록 되어 있다. 하지만 어떠한 경우에는, 프로듀서가 특정한 파티션을 지정해서 메시지를 쓰기도 한다.
컨슈머는 메시지를 읽는다. 다른 발행/구독 시스템에서는 구독자(subscriber) 혹은 독자(reader) 라고도 부른다. 컨슈머는 1개 이상의 토픽을 구독하여 여기에 저장된 메시지들을 각 파티션에 쓰여진 순서대로 읽어온다. 컨슈머는 메시지의 오프셋을 기록함으로써 어느 메시지까지 읽었는지를 유지한다.
컨슈머는 컨슈머 그룹의 일원으로서 작동한다. 컨슈머 그룹은 토픽에 저장된 데이터를 읽어오기 위해 협업하는 하나 이상의 컨슈머로 이루어진다. 컨슈머 그룹은 각 파티션이 하나의 컨슈머에 의해서만 읽히도록 한다. 컨슈머에서 파티션으로의 대응 관계는 컨슈머의 파티션 소유권(ownership) 이라고도 부른다.
이 방법을 사용함으로써 대량의 메시지를 갖는 토픽들을 읽기 위해 컨슈머들을 수평 확장할 수 있다. 또한, 컨슈머 중 하나에 장애가 발생하더라도, 그룹 안의 다른 컨슈머들이 장애가 발생한 컨슈머가 읽고 있던 파티션을 재할당받은 뒤 이어서 데이터를 읽어올 수 있다.
5. 브로커와 클러스터
하나의 카프카 서버를 브로커라고 부른다. 브로커는 프로듀서로부터 메시지를 전달받아 오프셋을 할당한 뒤 디스크 저장소에 쓴다. 브로커는 컨슈머의 파티션 읽기(fetch) 요청 역시 처리하고 발행된 메시지를 보내준다. 시스템 하드웨어의 성능에 따라 다르겠지만, 하나의 브로커는 초당 수천 개의 파티션과 수백만 개의 메시지를 쉽게 처리할 수 있다.
카프카 브로커는 클러스터의 일부로서 작동하도록 설계되었다. 하나의 클러스터 안에 여러 개의 브로커가 포함될 수 있으며, 그중 하나의 브로커가 클러스터 컨트롤러의 역할을 하게 된다. (컨트롤러는 클러스터 안의 현재 작동 중인 브로커 중 하나가 자동으로 선정된다.) 컨트롤러는 파티션을 브로커에 할당해주거나 장애가 발생한 브로커를 모니터링하는 등의 관리 기능을 담당한다. 파티션은 클러스터 안의 브로커 중 하나가 담당하며, 그 브로커를 파티션 리더(partition leader)라고 부른다. 복제된 파티션이 여러 브로커에 할당될 수 있는데 이것들은 파티션의 팔로워(partition follower) 라고 부른다.
카프카의 핵심 기능 중 일정 기간 동안 메시지를 지속성(durability)있게 보관하는 보존(retention) 기능이 있다. 브로커는 토픽에 대한 기본적인 보존 설정이 되어 있는데, 특정 기간동안 메시지를 보존하거나 파티션의 크기가 특정 사이즈에 도달할 때까지 데이터를 보존하고 한도값에 도달하면 메시지는 만료되어 삭제된다.
6. 다중 클러스터
설치된 카프카가 확장되어감에 따라 다수의 클러스터를 운용할 수 있다. 이 방식은 다음과 같은 장점이 있다.
- 유형별 데이터 분리
- 보안 요구사항을 충족시키기 위한 데이터 격리
- 재해복구(DR) 를 대비한 다중 데이터센터
특히 카프카가 다수의 데이터센터에서 운용될 때는 센터간에 메시지를 복제해 줄 필요가 있는 경우가 많다. 이렇게 하면 온라인 어플리케이션은 양쪽 데이터센터 모두에서 사용자 활동 정보를 사용할 수 있다. 에를 들어, 사용자가 자신의 프로필에 있는 공개 정보를 수정한다면 이 변경사항은 검색 결과가 보여지는 데이터센터가 어디냐의 여부와 상관없이 보여야 한다. 혹은, 모니터링 데이터를 여러 사이트로부터 수집한 뒤 분석과 경보 시스템이 운영되고 있는 하나의 중앙 집결지로 모을 수 도 있다. 카프카 클러스터의 복제 메커니즘은 다중 클러스터 사이에서가 아닌 하나의 클러스터 안에서만 작동하도록 설계되어 있다.