[Kafka] 1. 카프카 시작하기

* 이 글은 카프카 핵심 가이드 -  대규모 실시간 데이터와 스트림 처리 [ 개정증보판 ] 를 읽고 작성한 글 입니다.

1.1 발행/구독 메시지 전달

1.2 카프카 입문

카프카에 저장된 데이터는 순서를 유지한 채로 지속성 있게 보관, 결정적(deterministic)으로 읽을 수 있음.

확장 시 성능을 향상하고 실패가 발생하더라도 데이터 사용에는 문제가 없도록 시스템 안에서 데이터를 분산시켜 저장할 수 있음.

“분산 커밋 로그” “분산 스트리밍 플랫폼”

아파치 카프카 주요 기능 : 일정 기간 동안 메시지를 지속성 있게 보관하는 보존 기능

특정 기간, 특정 사이즈에 도당 할 때 까지 보존하도록 설정 가능(만료 시 삭제)

1.2.1 메시지와 배치

• 메시지 : 데이터의 기본 단위(단순히 바이트의 배열→ 특정한 형식이나 의미 X)
  • Key : 메타데이터. 메시지에 포함 될 수 있음
    • 메시지를 저장할 파티션을 결정하기 위해 사용.(해시값 생성한 뒤 토픽의 파티션 수로 나눴을 때 나오는 나머지의 값에 해당하는 파티션에 메시지 저장)
• 배치 : 카프카는 효율성을 위해 메시지를 배치 단위로 저장.
  • 즉, 메시지는 그저 같은 토픽의 파티션에 쓰이는 메시지의 집합.
    • 메시지를 쓸때마다 네트워크 신호가 오가는 것을 방지
    • 효율적인 데이터 전송과 저장을 위해 압축되는 경우 많음
    • 지연량과 처리량 사이에 트레이드오프 발생.
      • 즉, 배치 크기 UP → 시간당 처리수 UP → 메시지가 전달되는 데 걸리는 시간 UP

1.2.2 스키마

• 스키마 : 메시지의 구조. 카프카 입장에서 메시지는 단순한 바이트 배열일 뿐이지만, 내용을 이해하기 쉽도록 일정한 구조(스키마)를 부여하는 것이 권장됨.
  • 예시 : JSON, XML.
    • 타입 처리기능이나 스키마 버전간 호환성 유지 기능 DOWN
      • Q : 라이브러리를 사용하지 않고 JSON만 사용 시 스키마 버전 관리?
        • 사이트 에펙트가 없도록 디폴트 폼을 만들고 추가가 필요할 시 토픽을 새로 팜
  • 에이브로(Avro) : 많은 아파치 사용자들이 선호하는 직렬화 프레임워크
    • 조밀한 직렬화 형식 제공, 메시지 본체와 스키마를 분리하기 때문에 스키마가 변경되더라도 코드를 생성할 필요 없음. 즉, 강력한 데이터 타이핑과 스키마 변경에 따른 상위호환성 하위호환성 지원

1.2.3 토픽과 파티션

• 토픽(topic) : 카프카에 저장되는 메시지는 토픽 단위로 분류됨.
  • 토픽 안에서는 순서 보장하지 않음
  • 로그압착 : 같은 키를 가지는 메시지 중에서 가장 최신의 것만 보존.(마지막 변경값만 중요한 체인지 로그 형태의 데이터)
• 파티션(partition) : 토픽은 다시 여러개의 파티션으로 나뉨.
  • append-only
  • 맨 앞부터 순서대로 읽힘
  • 파티션 안에서 순서 보장
  • 카프카가 데이터 중복과 확장성을 제공하는 방법이기도 함.
    • 각 파티션이 각 서버에 저장 → 토픽이 여러 서버로 수평 확장
    • 파티션 복제 가능 → 서로 다른 서버들이 동일한 파티션 보유해 장애 대응 가능
      • Q : 장애 발생은 어떻게 감지하지?
        • 컨트롤러가 감지
        ① 클러스터의 다른 브로커의 상태를 체크하고③ 그리고 나면 새롭게 선출된 리더 파티션을 가진 브로커의 정보를 클러스터 내의 모든 브로커로 전달
      • ② 장애가 발생한 브로커에 존재하는 리더 파티션을 다른 브로커로 재분배한다.
• 스트림(Stream) : 프로듀서로부터 컨슈머로의 하나의 데이터 흐름을 나타내며, 하나의 토픽에 저장된 데이터로 간주됨
  • Q : 파티션 수가 늘어나게 되면 컨슈머 리밸런싱 등의 이슈가 발생하지 않는가? 코스트가 클 것 같다?
    • 짧은 순간의 피크를 위해서 파티션 수를 늘리는 것은 비용적으로 맞지 않음
    • 스레드 풀을 늘리고, 파티션 수는 그대로 유지

1.2.4 프로듀서와 컨슈머

• 카프카 클라이언트 : 카프카 사용자(프로듀서, 컨슈머, 카프카 커넥트, 카프카 스트림즈)
• 프로듀서 : 새로운 메시지 생성
  • 토픽에 속한 파티션들 사이에 고르게 나눠서 쓰도록 되어있음
    • Q : 어떤 방식으로 나눠지지? 라운드로빈?
  • 프로듀서가 특정한 파티션을 지정해서 메시지를 쓰기도 함
    • 키값과 키값의 해시를 특정 파티션으로 대응시켜 주는 파티셔너를 사용해서 구현됨
    • 메시지를 파티션으로 대응시켜주는 컨스텀 파티셔너를 사용할 수 있음
• 컨슈머 : 메시지를 읽음
  • 1개 이상의 토픽을 구독해서, 저장된 메시지들을 각 파티션에 쓰러진 순서대로 읽어옴
  • offset을 기록함으로써 읽은 메시지 유지
    • 파티션의 각 메시지는 고유한 오프셋을 가짐
  • 컨슈머의 파티션 소유권(컨:파 = 1:N) (파:컨 = 1: 1)
• 컨슈머 그룹 : 토픽에 저장된 데이터를 읽어오기 위해 협업하는 하나 이상의 컨슈머

1.2.5 브로커와 클러스터

• 브로커 : 하나의 카프카 서버
  • 프로듀서로부터 메시지를 전달받아 오프셋 할당한 뒤 디스크 저장소에 씀
  • 컨슈머의 파티션 읽기 요청 역시 처리하고 발행된 메시지를 보내줌
  • 초당 수천, 수백만 개 데이터 처리 가능
• 클러스터 : 카프카 브로커는 클러스터의 일부로서 작동하도록 설계됨
  • 하나의 클러스터 안에 여러 개의 브로커 포함
  • 그중 하나의 브로커가 컨트롤러 역할
    • Q : 선정 규칙 → 자동 선정
    • Q : 컨트롤러 동시에 파티션 리더도 가능? → 가능
• 컨트롤러 브로커 : 파티션을 브로커에 할당, 장애가 발생한 브로커 모니터링 하는 등의 기능
• 파티션 리더
• 파티션 팔로워