메시지가 분류되는 단위가 토픽이고, 토픽을 이루는 하나하나의 로그가 파티션이다. DB로 치면 토픽이 테이블 자리에 있고, 파티션은 그 테이블을 나눠 담은 append-only 파일이다.
하나의 로그인 파티션
파티션은 커밋 로그 관점에서 하나의 로그다. 쓸 때는 끝에 붙고, 읽을 때는 맨 앞에서부터 순서대로 읽으며, 각 메시지가 고유한 오프셋을 가진다.
수평 확장과 복제
카프카가 데이터 중복과 확장성을 제공하는 방법이 파티션이다. 각 파티션이 서로 다른 서버에 저장될 수 있으므로 하나의 토픽이 여러 서버로 수평 확장되고, 파티션이 복제될 수 있으므로 특정 서버에 장애가 나도 읽고 쓰지 못하는 상황이 오지 않는다. 레플리카와 리더가 그 이야기다.
키와 파티셔너
메시지에 붙는 메타데이터가 키다. 특별한 의미 없는 바이트 배열이고, 용도는 어느 파티션에 저장할지 결정하는 것 하나다.
키의 해시값 % 토픽의 파티션 수 = 저장될 파티션
이 대응을 담당하는 것이 파티셔너다. 키를 주지 않으면 파티션들 사이에 고르게 분산된다. 같은 키를 가진 메시지는 항상 같은 파티션에 가고, 따라서 순서가 보장되며 같은 컨슈머가 처리한다. 상태를 가진 스트림 처리가 이 성질 위에 서 있다.
오프셋
오프셋은 지속적으로 증가하는 정수값으로, 카프카가 메시지를 저장할 때 부여하는 메타데이터다. 앞 메시지의 오프셋이 뒤 메시지의 오프셋보다 작다는 것만 보장되고 연속적일 필요는 없다. 값은 대체로 카프카 자체에 저장되고, 덕분에 컨슈머는 읽기를 멈췄다 다시 시작해도 마지막으로 읽은 다음 메시지부터 읽는다.
스트림이라는 이름
하나의 토픽에 저장된 데이터 전체는 스트림이라고 부른다. 프로듀서에서 컨슈머로 흐르는 하나의 데이터 흐름이고, 시간이 지난 뒤 한꺼번에 대량 처리하는 하둡 같은 오프라인 프레임워크와 대비된다.
순서 보장의 범위
카프카에서 가장 자주 오해하는 지점이 순서다. 토픽 전체의 순서는 보장되지 않고 단일 파티션 안에서만 보장된다. 순서가 중요한 메시지들은 같은 파티션에 들어가야 하고, 그 수단이 키다.
파티션 수를 바꿀 때
파티션 수는 늘리는 것만 되고 줄이는 것은 안 된다. 늘리는 것도 함부로 할 일이 아니다. 키를 기준으로 파티션을 고르고 있었다면, 파티션 수가 바뀌는 순간 해시의 나머지가 달라져서 같은 키가 다른 파티션으로 간다. 그동안 유지되던 순서 보장과 컨슈머 대응이 그 지점에서 끊어진다. 그래서 파티션 수는 현재가 아니라 미래의 사용량 예측값을 기준으로 처음에 정한다. 파티션 수 결정에서 계산법을 본다.