[카프카, 데이터 플랫폼의 최강자] 3장. 카프카 디자인

3.1. 카프카 디자인의 특징

3.1.1. 분산 시스템

분산 시스템은 네트워크로 이루어진 컴퓨터들의 그룹으로서 시스템 전체가 공통의 목표를 가지고 있습니다. 다시 말해 같은 역할을 하는 여러 대의 서버로 이뤄진 서버 그룹을 분산 시스템이라고 합니다.

장점은 다음과 같습니다.

• 단일 시스템보다 더 높은 성능을 얻을 수 있다.
• 분산 시스템 중 하나의 서버 또는 노드 등이 장애가 발생하면 다른 서버 또는 노드가 대신 처리한다.
• 시스템 확장이 용이하다.

3.1.2. 페이지 캐시

카프카는 처리량을 높이기 위한 기능을 몇 가지 추가했고 그 기능 중 하나가 페이지 캐시 입니다.

OS는 물리적 메모리에 애플리케이션이 사용하는 부분을 할당하고 남은 잔여 메모리 일부를 페이지 캐시로 유지해 OS의 전체적인 성능을 향상 시킵니다.

이렇게 잔여 메모리를 이용해 디스크에 읽고 쓰기를 하지 않고 페이지 캐시를 통해 읽고 쓰는 방식을 사용하면 처리 속도가 매우 빠르기 때문입니다.

카프카는 이러한 특징을 이용해 빠른 액세스를 하기 위해 OS의 페이지 캐시를 이용하도록 디자인 되었습니다.

운영 팁
JVM 옵션을 사용해 힙 메모리를 5기가 정도로 설정하고 나머지는 페이지 캐시로 사용하도록 설정 권장.
페이지 캐시를 다른 애플리케이셔과 나눠 쓰는 것을 방지하기 위해 카프카 전용 서버로 구축 권장.

3.1.3. 배치 전송 처리

메시지를 보낼 때 건 바이 건으로 보내는 것이 아니라 작은 I/O를 묶어서 처리할 수 있도록 배치 작업을 하는 것이 가능.

배치 작업을 하는 이유는 작은 메시지를 빈번하게 보낼 경우 이게 곧 네트워크 오버헤드가 될 수 있기 때문.

오버헤드: 간접비, 비용

3.2.카프카 데이터 모델

토픽과 파티션 데이터 모델이 핵심

• 토픽은 메시지를 받을 수 있도록 논리적으로 묶은 개념
• 파티션은 토픽을 구성하는 데이터 저장소로서 수평 확장이 가능한 단위.

3.2.1. 토픽의 이해

• 카프카 클러스터는 토픽이라 불리는 곳에 데이터를 저장.
• 토픽 이름은 249자 미만으로 영문, 숫자, ',', '_', '-' 을 조합하여 정할 수 있음.
• 토픽 이름에 접두어로 서비스 명을 추가해 다른 서비스와 중복을 피할 수 있음.
• 이름을 용도와 다른 서비스와 중복 되지 않게 잘 짓자!

3.2.2. 파티션의 이해

• 여러 프로듀서로 특정 토픽의 하나의 파티션에 메시지를 보내면 서비스 지연 발생.
• 서비스 지연이 발생하는 이유는 파티션 내에서 전송 순서가 보장 되기 때문.
• 효율적인 메시지 전송과 속도를 높이려면 토픽의 파티션 수를 적절히 유지하는게 중요.
• 특정 토픽의 파티션 수를 늘리면 여러 메시지를 병렬로 처리할 수 있음.
• 프로듀서 수는 그대로고 파티션수만 늘리면 효과가 없음.
• 파티션 수는 다시 줄일 수 없음

적절한 파티션 수를 유지해야 하는 이유

1) 파일 핸들러 낭비 방지: 각 파티션은 브로커의 디렉토리와 매핑되며, 저장되는 데이터 마다 2개의 파일(인덱스, 실제 데이터)이 있음. 파티션의 수에 비례하게 파일 핸들러도 많아지게 됨.
2) 장애 복구 시간 증가: 리더 파티션에 장애 발생시 팔로워 파티션 사이에서 리더를 재 선출하는데 그 소요시간이 파티션의 수에 영향을 받음.

3.2.3. 오프셋과 메시지 순서

• 각 파티션마다 메시지가 저장되는 위치를 오프셋이라고 부르고, 오프셋은 파티션 내에서 유일하고 순차적으로 증가하는 숫자(64비트 정수).
• 파티션 마다 유니크한 숫자인 파티션을 가짐.
• 파티션 내 순서는 보장되지만, 토픽 자체에서의 유입 순서는 보장 받을 수 없음.
• 컨슈머가 데이터를 가져갈 때는 오프셋 순서대로만 가져갈 수 있음

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

• 카프카는 높은 가용성 보장을 위해 리플리케이션(복제) 기능 제공.
• 리플리케이션은 토픽 자체에 대한 복제가 아닌 파티션에 대한 복제를 말함..

3.3.1. 리플리케이션 팩터와 리더, 팔로워의 역할

# 기본 리플리케이션 팩터 값 설정 방법
 default.replication.factor = 2
## 위 항목을 찾고 2 또는 3으로 설정
## 이 항목은 모든 카프카 브로커가 동일하게 설정되어 있어야함. 

• 파티션 중에서 읽기와 쓰기를 하는 파티션은 리더, 그 외에는 팔로워라고 부름. 팔로워는 리더의 데이터를 그대로 리플리케이션 하기만 하고 읽기와 쓰기에는 기여하지 않음.

# 파티션 리더/팔로워 확인 방법
../kafka/bin/kafka-topics.sh  --zookeeper <zookeepers> --topic <topic-name> --describe

토픽 describe 예시

• 위 예시를 기준으로 1번이 리더이고 2번이 팔로워 인 것을 알 수 있으며, 1번 브로커에 장애 발생시 2번 브로커의 파티션이 리더가 되서 서비스를 정상적으로 유지, 운영 함.
• 카프카는 메시지를 디스크에 저장하고, 리플리케이션 팩터 값은 디스크에 적재되는 데이터의 양에 영향을 줌

3.3.2. 리더와 팔로워의 관리

• 카프카는 ISR(In-sync Replica)란 개념을 사용해 리더와 팔로워 간에 데이터 정합성을 유지하고 리더에 문제가 발생했을 때 신뢰할 수 있는 팔로워가 리더가 될 수 있도록 운영하는 리플리케이션 그룹.
• 특정 팔로워에 문제가 발생하면 그 팔로워는 ISR에서 제외됨

3.4. 모든 브로커가 다운된다면

선택지는 총 2가지 임

• 마지막 리더가 살아나기를 기다린다.
  • 시스템 서비스 재 운영에 긴 시간이 소요될 수 있음
• ISR에서 추방되었지만 먼저 살아나면 자동으로 리더가 된다.
  • 위 방식보다 시스텀 서비스 재 운영에 소요되는 시간이 짧아지지만 일부 데이터가 유실될 수 있음.

토픽 옵션에 따른 파티션, 레플리카, 클러스터 구성 예시

주키퍼 지노드에 저장되는 주요 정보

• controller
  • 카프카 브로커 중 하나가 컨트롤러로 선정됨.
  • 브로커 레벨에서 실패 감지시 실패한 브로커에 의해 영향받는 모든 파티션의 리더 변경을 책임지고 있음.
  • 컨트롤러를 통해 많은 수의 파티션들에 대해 빠르게 배치 형태로 리더십 변경 가능
  • 컨트롤러인 임의로 선정되며, 브로커가 다운되면 나머지 브로커 중 하나가 선정됨
• brokers
  • 브로커 관련된 정보가 되며 카프카 설치시 브로커 컨피그에서 수정한 브로커 아이디 확인 가능.(브로커 아이디는 중복될 수 없고, 중복 발생시 에러 출력)
  • 주키퍼의 임시 노드를 사용해 등록하고 만약 브로커가 종료되거나 다운되면 지노드가 사라짐. topic라는 지노드를 확인하면 토픽 정보도 확인 가능.
• consumers
  • 컨슈머에 대한 정보가 저장되며, 컨슈머가 각각의 파티션들에 대해 어디까지 읽었는지를 기록하는 오프셋 정보가 저장됨. 중요 정보이므로 영구 노드로 저장됨.
  • 현재는 주키퍼와 카프카 중 오프셋 정보를 저장할 공간을 선택할 수 있지만, 주키퍼에 저장하는 방식은 향후 사라질 예정.
• config
  • 토픽의 살세 설정 정보를 확인할 수 있는 노드.

영구 노드와 임시 노드
영구 노드는 삭제할 수 있는 반면, 임시노드는 생성한 클라이언트의 연결 중단 혹은 장애 발생시 삭제됨.