3장 카프카 디자인

카프카 디자인의 특징

• 확장이 쉬운 분산 시스템

• 페이지 캐시
  • 페이지 캐시는 메모리에 있고, 공유할 수 있기 때문에, 카프카 클러스터를 같은 시스템, 서버에 구축하는것이 좋다.
• 배치 전송 처리
  • 카프카에서는 작은 I/O가 빈번하게 일어나기 때문에 이러한 I/O들을 묶어 배치로 처리하는 방식을 취한다.(ex: 메시지 4개를 모은 후 한번만 I/O 작업을 한다.)

---

카프카 데이터 모델

• 토픽의 이해
• 파티션의 이해
  • 토픽을 분할한 것
  • EX) 4개의 토픽을 보내는 상황에서 파티션이 1개라면, A->B->C->D 순서로 보내기 때문에 총 4초가 걸리는 반면, 프로듀서와 파티션을 늘려서 4개의 프로듀서가 각각 1개의 파티션에 메시지를 보내면, 4개의 메시지가 보내진다고 해도 1초밖에 안걸리게 된다.
• 파티션 확장의 단점
  
  • 파일 핸들러의 낭비
    • 각 파티션은 카프카 브로커의 디렉토리에 연결되어 있고, 데이터마다(인덱스와 실제 데이터) 파일이 있으므로, 파티션이 많으면 많아질 수록 많은 파일 핸들을 열어 두게 되고, 결과적으로 안열어도 될 파일 리소스를 열게 되므로 리소스를 낭비할 수 있다.
  • 장애 복구 시간 증가
    • 만약 A 브로커가 다운 시, A브로커가 담당하고 있던 1000개의 파티션이 있다고 하면, 해당 파티션들에 대해 리더 선출을 다시 해야하므로, 장애복구에 1000 X (리더선출시간) 만큼의 걸리게 된다.
• 내 토픽의 적절한 파티션 수는
  • 프로듀서가 카프카에 보내는 메시지 양/속도와 컨슈머에서 처리하는 메시지 양/속도를 고려하여 프로듀서양을 고려하여 적절하게 파티션 수와, 컨슈머/프로듀서 수를 조정해야 한다.
  • 토픽을 8개의 파티션으로 나누어, 8개의 프로듀서가 5메시지/초 보낸다면 40메시지/초 가걸리고, 컨슈머가 처리하는 속도를 고려하여 컨슈머 수를 조정해야 한다.
• 오프셋과 메시지 순서
  • 카프카에서는 메시지가 저장되는 위치를 오프셋 이라고 하며, 파티션마다 고유의 오프셋이 존재하고, 오프셋은 순차적으로 증가하는 숫자 형태로, 프로듀서가 해당 파티션에 쓸 때는 쓰기 오프셋 위치부터 쓰게 되고, 컨슈머가 해당 파티션을 가져 갈 때는 읽기 오프셋 위치부터 순차적으로 가져가게 된다.

---

카프카의 고가용성과 리플리케이션

• 리플리케이션 팩터와 리더, 팔로워의 역할
  • 카프카의 리플리케이션 기능
    • 카프카의 리플리케이션은 토픽이 아니라, 토픽을 이루는 각각의 파티션을 리플리케이션 한다.
    • 리플리케이션 팩터를 지정하여 파티션들을 여러 서버에 복제하고, 하나의 브로커가 죽어도 다른 서버에서도 이미 복제하여 데이터를 갖고 있기 때문에 장애를 대비할 수 있다.
    • 해당 파티션의 리더가 죽었을 시, ISR이 발생하여 FOLLOWER가 새로운 리더로 자동으로 선출된다.
• 리더와 팔로워의 관리
  • 팔로워는 리더의 데이터를 주기적으로 보면서 자신에 없는 데이터를 리더로부터 가져온다.(pull)
  • 하지만, 팔로워가 데이터를 제대로 가져오지 못하여 데이터가 안맞는 상황에서 리더까지 다운된다면?
  • 이러한 문제를 카프카에서는 ISR(In Sync Replica) 개념으로 해결하고 있다.
  • ISR 동작방식
    1. 프로듀서가 A 메시지를 토픽의 리더에 보낸다.
    2. A 메시지는 토픽의 리더가 저장.(리더만 해당 토픽 혹은 파티션의 정보를 읽고 쓸 수 있다.)
    3. 팔로워들은 해당 리더 데이터를 주기적으로 확인하며, 확인했다는 확인 응답을 보내고, 리더는 이러한 확인응답을 기반으로 팔로워들의 상태를 감시하고, 응답이 없는 팔로워는 추방당하며, 리더자격도 상실한다.
    4. 리더가 다운될 시, 리더자격이 있는 팔로워중 하나가 리더로 승격하여 작업을 진행하게 된다.

---

모든 브로커가 다운된다면

• 리플리케이션 팩터와 리더, 팔로워의 역할
  • 모든 브로커 다운 시, 가장 많은 데이터를 가지고 있는 브로커를 살려야 할 것이다, 하지만 서비스 측면에서 봤을 땐 메시지가 일부 유실되더라도, 가장 빨리 복구되는 브로커를 새로운 리더로 선출해야 하는 방법도 있다.
    • 이와 관련된 설정 : unclena.leader.election.enable=false ( 기존 리더가 살아나기를 기다리는 방법) 혹은 true( 새로운 리더를 뽑아서 빠르게 서비스를 재개하는 방법)
• 카프카에서 사용하는 주키퍼 지노드의 역할
  • zkCli.sh을 실행 후  ls명령어를 사용하여 다음과 같은 카프카와 관련된 디렉토리들을 확인할 수 있다. 
  • /kafka/controller : 카프카는 클러스터 내 브로커중 하나를 컨트롤러로 선정하고, 컨트롤러는 브로커 레벨에서의 실패를 감지하고, 실패한 브로커에 의해 영향받는 모든 파티션의 리더 변경을 책임진다. 컨트롤러를 통해 매우 빠르게 배치 형태로 리더십을 변경할 수 있다. 만약 컨트롤러인 브로커가 다운된다면, 남아있는 브로커 중 하나가 컨트롤러가 된다.
  • /kafka/brokers : 브로커와 관련된 정보들이 저장된다. 대표적으로는, 카프카 broker들은 자신의 broker.id를 brokers/ids 디렉토리에 broker.id로 지노드를 작성하여 자기 자신을 등록한다. 이 때, 사용되는 노드는 임시노드로 카프카 클라이언트와 주키퍼의 연결이 해제 될 시, 자동으로 삭제되는 노드이다. 또 한, /brokers/topics 디렉토리에서 토픽에 대한 정보(ISR, 파티션 수, 리더정보) 를 확인할 수 도 있다.
  • /kafka/consumers 
    • 컨슈머가 각각의 파티션에 대해 어디까지 읽었는지를 기록하는 오프셋 정보 저장.
    • 오프셋 정보는 지워지면 안되기 때문에 영구노드로 저장한다.
    • 하지만, 0.9버전 이상부터는 카프카는 컨슈머 오프셋을 자신의 토픽으로 저장하여 사용한다.(_consumer_offesets)
  • /kafka/config
    • 토픽, 유저, 컨슈머, 프로듀서 등의 상세 설정을 확인.