Kafka 디자인 특징

분산 시스템

• 네트워크로 이루어진 컴퓨터들의 그룹으로서 시스템 전체가 공통의 목표로 같은 역할을 하는 시스템
• 단일 시스템보다 높은 성능을 얻을 수 있으며, 시스템 확장이 용이함
• 여러 서버(혹은 노드) 중 하나가 장애가 발생해도 시스템이 중단되지 않음

페이지 캐시

• Kafka는 처리량을 높이기 위해 페이지 캐시를 적용함
• Kafka는 잔여 메모리를 사용해서 캐시에 데이터를 저장해서 디스트 I/O를 줄임
• 페이지 캐시를 사용하기 때문에 Kafka는 SATA 디스크를 사용해도 성능상 큰 문제가 없음

배치 전송 처리

• 단일 메시지를 여러번 전송하게 되면 I/O가 빈번하게 발생하기 때문에 성능 저하가 발생할 수 있음
• 빈번한 메시징은 네트워크 오버헤드를 발생 시킬 수도 있음
• Kafka는 이런 문제를 해결하기 위해서 Producer가 배치로 메시지를 보낼 수 있도록 함
  

Kafka 데이터 모델

토픽의 이해

• 토픽은 메시지를 받을 수 있도록 논리적으로 묶은 개념
• Kafka 클러스터는 토픽에 데이터를 저장 (메일 시스템으로 치면 메일 주소같은 개념)
• 토픽은 249자 미만으로 (,.-_) 를 조합하여 자유롭게 생성할 수 있음

파티션의 이해

• 토픽을 구성하는 데이터 저장소로 토픽을 분할한 것
• 수평 확장 가능
• 파티션은 Kafka의 성능을 향상 시키기 위한 개념
  • Producer를 수평 확장시키고 Producer의 수에 맞춰 파티션을 확장하고 Producer와 대응 시키면, 짧은 시간에 여러 메시지를 병렬적으로 처리할 수 있음

파티션 수를 늘리는게 항상 좋나?

파티션을 늘리는게 Kafka에 좋지 않은 영향을 미칠 수 있음

• 파일 핸들러의 낭비
  • 각 파티션은 브로커의 디렉토리와 맵핑되고, 데이터마다 2개의 파일(인덱스와 실제 데이터)로 저장 됨
  • Kafka에서는 모든 디렉토리의 파일들에 대해 파일 핸들러를 열게 되는데, 파티션 수가 많을수록 파일 핸들러 수도 많아지게 되고 리소스 낭비로 이어짐
• 장애 복구 시간 증가
  • 카프가는 높은 가용성을 위해 리플리케이션을 지원
  • 브로커에 토픽이 있고, 토픽은 여러 개의 파티션으로 나뉘어져 있고, 각 파티션마다 리플리케이션이 동작하함
    • 하나는 리더 파티션, 나머지는 팔로워 파티션
  • 하나의 브로커가 다운되면 해당 브로커의 리더 파티션은 사용불가이므로 Kafka는 팔로워 중 하나를 리더로 지정
  • 이러한 장애 처리는 컨트롤러로 지정된 브로커가 실행되고, 컨트롤러 브로커에 장애가 발생하면 자동으로 다른 브로커가 수행
  • 파티션이 너무 많아지게 되면 한 브로커에 장애가 발생한 경우, 각 파티션에 대해 리더를 선출해야 하므로 파티션 수 만큼 선출 시간이 걸리게 돼서 장애 복구에 시간이 오래 걸리게 됨
    • 컨트롤러 브로커가 다운되면 컨트롤러 선정 시간까지 걸리게 되므로 장애 복구에 시간이 더 걸림

적절한 파티션 수는?

• 적절한 파티션 수를 정할 때는 목표 처리량을 기준으로 해야함
• Producer의 서버 수와 서버당 메시지 전송 수, Consumer의 서버 수와 서버당 메시지 전송 수를 고려하여 적절한 파티션 수를 정해야 함
• Kafka에서는 파티션을 늘리는 방법을 제공하고 있지만, 줄이는 방법에 대해서는 제공하고 있지 않음
  • 필요한 파티션의 계산이 어렵다면 적은 수의 파티션으로 운영을 하다가 병목이 발생하면 Producer 혹은 Consumer, 파티션 수를 늘려서 조절

오프셋과 메시지 순서

• Kafka에서는 각 파티션마다 메시지가 저장되는 위치를 오프셋이라고 부름
• 오프셋은 파티션 태에서 유일하고 순차적으로 증가하는 숫자(64비트) 형태
• 오프셋은 파티션에서만 유일하기 때문에 파티션이 여러개인 토픽의 관점에서 보면 같은 오프셋이 있을 수 있음
• Kafka에서는 오프셋을 사용해서 메시지의 순서를 보장함
  

[reference]
카프카, 데이터 플랫폼의 최강자 - 실시간 비동기 스트리밍 솔루션 Kafka의 기본부터 확장 응용까지