카프카 기본

기본

분산 시스템

• 분산 시스템은  네트워크상에서 연결된 컴퓨터들의 그룹.
• 단일 시스템이 갖지 못한 높은 성능이 목표
• 성능 뿐 아니라 하나의 서버 또는 노드 등에 장애가 발생할 때 다른 서버/노드가 대신 처리하므로 장애 대응 면에서도 탁월
• 부하가 높은 경우 확장도 용이하다.
• 카프카 역시 마찬가지.
• 최초 구성한 클러스터 리소스가 한계치에 도달했을 때, 브로커를 추가하는 방식으로 확장 가능하다.
  • (이미 메시지가 들어오는 상태에서 줄이는 것도 쉽게 가능한가?)

 

페이지 캐시

• 다른 메시징 시스템은 메시지를 전송하고 나면 메시지를 삭제함.
  • 아직도 그런지 모르겠음. 2018에 나온 카프카, 데이터 플랫폼의 최강자는 그렇게 설명했음.
• 카프카는 디스크에 세그먼트 형식으로 메시지를 저장함.
• 디스크에 저장하기 때문에 어떤 이유로 메시지를 전송하지 못한 경우에도 다시 전송할 수 있음.
• 하지만 디스크 I/O가 발생함.
• 카프카는 이 문제를 OS의 페이지 캐시로 해결함.
• 페이지 캐시란 직접 디스크에 I/O 하지 않고, 물리 메모리 중 애플리케이션이 사용하지 않는 일부 잔여 메모리를 활용함.
• 카프카는 페이지 캐시를 통해 데이터를 읽고 쓰게 설계됨.
• 메모리에 I/O 하기 때문에 디스크 I/O에 비해 훨씬 빠름

 

배치 전송

• 프로듀서가 메시지를 전송할 때 10개의 메시지를 10번 전송하는 것은 네트워크 오버헤드가 발생할 수 있음.
• TPS 10000이라면 1초에 10000번의 네트워크 I/O가 발생하는 것임.
• 카프카는 이 문제를 배치 전송으로 해결함. 
• 프로듀서는 이벤트가 발생할 때마다 메시지를 전송하는 것이 아닌 메시지 여러 개를 묶어서 한 번에 전송함.
• 이렇게 하면 네트워크 I/O가 확연하게 줄어들기 때문에 오버헤드가 발생할 확률이 낮아짐.
• 카프카에서는 배치 전송을 권장하고 있음.

 

압축 전송

• 카프카에서는 gzip, snappy, lz4, zstd 등 압축 타입을 지원함.
• 압축만으로도 네트워크 대역폭이나 회선 비용을 줄일 수 있는데 배치 전송과 결합하면 더욱 높은 효과를 얻을 수 있음.
• 높은 압축률이 필요한 경우 gzip, zstd를 권장
• 빠른 응답속도가 중요하다면 lz4, snappy 권장
• 하지만 메시지 형식이나 크기에 따라 달라질 수 있으니 직접 테스트 해보고 결정하는 것이 좋음.

 

토픽, 파티션, 오프셋

• 카프카는 '토픽'에 데이터를 저장함.
  • 하지만 이는 논리적 개념이고 실제로 데이터가 저장되는 곳은 파티션임.
  • 토픽 내에서 파티션으로 나뉘는 이유는 병렬 처리 때문.
• 파티션의 메시지가 저장되는 위치를 오프셋이라고 부름.
• 오프셋은 순차적으로 증가하는 64비트 정수임.
• 각 파티션에서 오프셋은 고유한 숫자임.
• 카프카는 오프셋을 통해 메시지의 순서를 보장함.
• 컨슈머에서는 오프셋을 이용해 마지막까지 읽은 메시지 위치를 알 수 있음.

 

고가용성

• 카프카는 고가용성 보장을 위해 리플리케이션 기능을 제공.
• 리더와 팔로워라는 용어로 구분.
• 고가용성을 위해 무작정 늘리면 안 됨. 그만큼 브로커의 디스크 공간이 소비됨.
• 팩터 수를 3으로 권장함.

 

주키퍼 의존성

• 주키퍼는 하둡이나 HBase 등에서도 사용되는 아파치 탑 레벨 프로젝트임.
• 여러 대의 서비스를 앙상블로 구성하고, 살아 있는 노드 수가 과반수 이상 유지된다면 지속적인 서비스가 가능함.
  • 3대로 구성할 경우 2대가 죽으면 나머지 1대도 사용할 수 없음.
• znode를 이용해 카프카의 메타데이터를 기록함.
• 주키퍼는 지노드를 이용해 브로커의 노드 관리, 토픽 관리, 컨트롤러 관리 등 매우 중요한 역할임.
• 하지만 카프카가 발전하고 주키퍼 성능의 한계가 드러나기 시작함.
• 카프카 팀은 주키퍼 의존성을 걷어내는 작업을 진행 중임.
• 이미 주키퍼 의존성이 제거된 버전이 릴리스 되었지만 아직 운영에서 쓰기엔 무리.