[Kafka] 카프카 핵심 가이드 - 1

카프카 스터디의 일환이자 데이터 엔지니어링 스터디를 위한 기록입니다.

Kafka 공식 문서: https://kafka.apache.org/documentation/

Chatper 1 카프카 시작하기

발행과 구독

발행과 구독의 메시지 전달의 개념 이해하기. 전송자가 데이터를 보낼 때 직접 수신자로 보내지 않고 1) 메시지를 분류해서 보내고, 2) 분류된 메시지를 구독하는 형태임. 보통 중간에서 중계해주는 브로커가 있음

• 발행자/전송자 = publish
• 구독자/수신자 = subscribe

간단한 시스템이라면 프론트엔드 서버의 모니터링 지표를 보낼때 단순하게 구조화할 수 있다. 하지만 장기간에 걸쳐 여러 지푯값을 분석하고, 서비스가 증가할수록 관리하기가 어려워짐

 

따라서, 모든 애플리케이션으로부터 지표를 받는 하나의 애플리케이션을 만들고, 어느 시스템에서든 접근/질의할 수 있는 서버를 제공하는 것이 메시지 발행/구독 시스템의 주요 아키텍처이다.

 

지표외에도 로그 또한 비슷한 작업을 할 수 있도록 추가하게 되면 다수의 발행/구독 시스템으로 확장된다.

아파치 카프카는 이러한 문제를 해결하기 위한 시스템으로 '분산 커밋 로그' 또는 '분산 스트리밍 플랫폼'이라고 불린다.

• 즉, commit log는 모든 트랜잭션 기록을 지속성durable있게 보존함으로써 시스템의 상태를 일관성 있게 복구할 수 있도록 고안됨
• 데이터는 순서를 유지한 채로 지속성 있게 보관되고, 결정적determinstic으로 읽을 수 있음
• 확장 시 실패가 발생하더라도 사용에 문제가 없도록 데이터를 분산시켜 저장할 수 있음

 

카프카의 구성요소

• 메시지(message): 데이터의 기본 단위. 일반적인 DB의 row, record와 유사하게 이해할수도 있지만, 메시지는 단순히 바이트의 배열이며 특정한 형식이나 의미가 없음. 단, key라는 메타데이터를 포함할 수도 있지만 바이트 배열일 뿐이며 key는 메시지를 저장할 파티션을 결정하기 위해 사용됨. 해시값을 사용하여 파티션에 메시지를 저장함.
• 배치(batch): 같은 토픽의 파티션에 쓰여지는 메시지들의 집합. 배치 크기가 커질수록 처리되는 메시지는 증가하지만 시간도 늘어남
• 스키마(schema): 내용을 이해하기 쉽도록 일정한 구조를 부여하는 것이 권장됨. 주로 json, xml도 있지만 아파치 Avro를 선호함. Avro는 하둡에서 고안됨.
• 토픽(topic): 메시지는 토픽 단위로 분류됨. 비슷한 개념으로 DB의 테이블이나 파일시스템의 폴더와 유사함. 토픽은 여러 개의 파티션(partition)으로 나뉘어짐. 메시지 전체에 대해 순서는 보장하지 않고 단일 파티션 안에서만 순서가 보장됨.

• 이미지 출처: 공식문서(https://kafka.apache.org/images/streams-and-tables-p1_p4.png)
• 스트림(stream): 스트림의 파티션의 개수와 상관없이 하나의 토픽에 저장된 데이터로 간주됨. 프로듀서(producer)로부터 컨슈머(consumer)로의 하나의 데이터 흐름을 나타냄

프로듀서와 컨슈머

프로듀서(producer)는 새로운 메시지를 생성하는 역할. 발행자(publisher) 혹은 작성자(writer)라고도 불림. 대부분 프로듀서는 메시지를 쓸 때 고르게 나눠서 쓰도록 되어있지만, 특정한 파티션을 지정해서 메시지를 쓰는 것도 가능함. 이때는 메시지 키와 키값의 해시를 특정 파티션으로 대응히켜 주는 파티셔너를 사용해서 구현됨

 

컨슈머(consumer)는 메시지를 읽는 역할. 구독자(subscriber) 혹은 독자(reader)라고도 불림. 컨슈머는 1개 이상의 토픽을 구독하여 메시지를 읽어롬. 메시지의 offset을 기록하여 어느 메시지를 읽었는지 유지할 수 있음. 이때 offset은 메타데이터임. 한편, 컨슈머는 컨슈머 그룹의 일원으로서 작동함. 컨슈머와 파티션 사이의 대응 관계를 컨슈머의 파티션 소유권(ownership)이라고도 함

브로커와 클러스터

하나의 카프카 서버를 브로커라고 부르며, 브로커는 프로듀서로부터 1)메시지를 전달받아 2)오프셋을 할당한 뒤 3) 디스크 저장소에 쓴다. 이때, 컨슈머의 파티션 읽기(fetch) 요청을 처리하고 발행된 메시지를 보내줌.

브로커는 클러스터의 일부로서 작동하도록 설계됨. 하나의 클러스터 안에 여러 개의 브로커가 포함될 수 있고, 그중 하나의 브로커가 클러스터 컨트롤러의 역할을 하게됨(자동으로 선정)

컨트롤러는 장애가 발생한 브로커를 모니터링 하는 등의 관리 기능을 담당함. 파티션은 클러스터 안의 브로커 중 하나가 담당하고, 그 브로커를 파티션 리더라고 함. 복제된 파티션이 여러 브로커에 할당될 수도 있는데 파티션의 팔로워(follwer)라고 부름
복제기능은 장애 발생 시 대응하기 위한 것으로 리더 역할을 이어받을 수 있게 함.

• 보존(retention): 일정 기간 동안 메시지를 지속성있게 보관하는 기능. 기간 또는 특정 사이즈에 도달할때까지 데이터를 보존함. 한도값에 도달하면 메시지는 삭제됨
• 로그 압착(log compaction); 토픽에는 같은키를 갖는 메시지 중 가장 최신의 것만 보존됨. 이 기능은 마지막 변경값이 중요한 체인지로그 형태의 데이터에 사용하는 것을 권장함

카프카는 분산처리에 특화되었기 때문에 다수의 클러스터를 운용할 수 있음. 이때 장점은

• 1) 데이터 유형별 분리
• 2) 보안 요구사항을 충족시키기 위한 격리
• 3) 재해 복구를 대비한 다중 데이터센터

한편, 카프카 클러스터의 복제 메커니즘은 다중 클러스터가 아닌 하나의 클러스터 안에서만 작동하도록 설계됨. 데이터를 다른 클러스로 복제하는 데 사용되는 미러메이커(MirrorMaker)라는 툴을 포함. 미러메이커도 큐로 연결된 카프카 컨슈머와 프로듀서임.

---

Q. 하나의 클러스터 안에서만 작동하도록 한다면서 미러메이커는 뭐지? 다른 클러스터에 쓰려면 미러메이커 쓰라는 말인가?

아래는 Gemini를 사용한 답변

카프카의 복제 메커니즘과 미러메이커의 역할 (명확한 구분)

1. 카프카의 '기본 복제 메커니즘' (Leader/Follower Replication)

• 범위: 하나의 카프카 클러스터 안에서만 작동합니다.
• 목적: 클러스터 내의 브로커 장애에 대비하기 위함입니다.
• 비유: 당신이 중요한 서류를 작성했는데, 혹시 컴퓨터가 고장 날까 봐 같은 사무실 안의 다른 동료 컴퓨터에도 사본을 저장해 두는 것과 같아요. 만약 당신의 컴퓨터가 고장 나면, 동료 컴퓨터의 사본을 바로 사용할 수 있죠.
  • 여기서 '같은 사무실'이 하나의 카프카 클러스터입니다.
  • '당신의 컴퓨터'는 리더 파티션을 가진 브로커입니다.
  • '동료 컴퓨터'는 팔로워 파티션을 가진 브로커입니다.

이 기본 복제 메커니즘은 한 클러스터 내에서 데이터의 고가용성(High Availability)과 내구성(Durability)을 보장합니다. 즉, 브로커 몇 대가 고장 나더라도 데이터가 유실되지 않고 서비스가 계속될 수 있도록 하는 것이죠.

2. 미러메이커 (MirrorMaker)

• 범위: 서로 다른 카프카 클러스터 간에 데이터를 복제합니다.
• 목적: 주로 재해 복구(Disaster Recovery)나 지리적으로 분산된 데이터 동기화를 위해 사용됩니다.
• 비유: 이제 당신의 사무실(서울 클러스터)이 아니라, 다른 도시에 있는 지사 사무실(부산 클러스터)에도 똑같은 서류 사본을 보내 보관하는 것과 같아요. 만약 서울 사무실 전체가 불타 없어져도, 부산 지사에는 서류 사본이 안전하게 남아있으니 업무를 계속할 수 있겠죠.
  • 여기서 '서울 사무실'과 '부산 지사 사무실'은 각각 독립적인 카프카 클러스터입니다.
  • '서류 사본을 보내는 과정'이 미러메이커의 역할입니다.

결론: "다른 클러스터에 쓰려면 미러메이커를 써야 하나요?" 네, 맞습니다!

카프카의 내장된 복제 기능은 한 클러스터 내에서 브로커 간의 복제만을 담당합니다. 만약 데이터센터가 다르거나, 완전히 독립적인 두 개의 카프카 클러스터가 있고, 한 클러스터의 데이터를 다른 클러스터로 보내고 싶다면 미러메이커와 같은 별도의 도구를 사용해야 합니다.

미러메이커는 기본적으로 한 클러스터의 컨슈머 역할을 하면서 데이터를 읽어오고, 다른 클러스터의 프로듀서 역할을 하면서 읽어온 데이터를 다시 쓰는 방식으로 작동하여 클러스터 간의 데이터 동기화를 가능하게 합니다.

---

카프카의 특징

• 다중 프로듀서: 클라이언트가 사용하는 토픽의 수량과 관계없이 여러 프로듀서를 처리할 수 있음.
• 다중 컨슈머: 컨슈머가 상호 간섭 없이 어떠한 메시지 스트림도 읽을 수 있음. 큐 시스템(일대일 대응)과의 결정적인 차이점. 다수의 카프카 컨슈머는 컨슈머 그룹의 일원으로 작동함으로써 하나의 스트림을 여럿이서 나눠서 읽을 수 있음
• 디스크 기반 보존: 메시지를 지속성 있게 저장할 수도 있음.메시지는 설정된 보유 규칙과 함께 저장됨. 이 옵션들은 토픽별로 설정이 가능하므로 서로 다르게 보존이 가능함.데이터 유실의 위험이 없다는 점에서 장점
• 확장성: 어떠한 크기의 데이터도 쉽게 처리할 수 있음. 하나의 브로커로 시작한 뒤 3개의 브로커를 가진 개발용, 마지막은 수백개의 대규모 클러스터로 이루어진 프로덕션 환경으로 옮길 수 있음
• 고성능: 위 특징들 덕분에 고부하 환경에도 빠른 처리속도와 수평적 확장이 가능함
• 플랫폼 기능: 개발자들이 자주 하는 작업을 쉽게 할 수 있도록 플랫폼 기능이 추가됨. YARN처럼 완전한 플랫폼은 아니지만, API와 라이브러리의 형태로 사용이 가능함. 카프카 커넥트와 카프카 스트림즈가 있음

 

 

카프카 핵심 가이드 1챕터를 요약정리한 것이며, 1.4 데이터 생태계, 1.5 카프카의 기원은 생략하였습니다.

획기적인 아이디어가 오픈소스 프로젝트로 이어진다는 건 참 멋진일인것 같다