[Kafka 핵심가이드] 1장: 카프카 시작하기

카프카의 구동 원리 ( Pub sub )

• Pub / Sub
  • 전송자가 데이터를 보낼 때 직접 수신자로 보내지 않는다는 특징을 가진다.
  • 전송자가 메시지를 보내고 수신자는 이런 메시지를 중계해 주는 중개인을 통해 메시지를 전달받는다
• 초기의 Pub sub System
  • 초기에는 서버에서 매트릭 서버로 로그를 쌓았다.

하지만 해당 방법자체가 오래가지 않아 장기간 지표값을 분석하려 한다면 해당 대시보드가 제대로 작동되지 않는다는 걸 알게 된다고 한다.

 

<내 생각>

아마, 추측하건대 장기간 지표값을 분석하게 되면 서버 측의 메트릭들을 하나의 UI 서버가 구독하고 있기에, 데이터가 많아질수록 UI의 랜더링이라던지 성능 저하가 발생하는 걸 이야기하지 않을까 싶었다.

 

해당 아키텍처에서 필요에 의해 하나씩 발전시킨다고 하면 아래의 아키텍처로 이어지게 된다.

해당처럼 필요에 의해 하나씩 추가를 진행하게 될 때, 연결을 추적하는 것이 힘들어지게 된다.

 

이때, pubsub을 통해 중간의 중개인을 통해 메시지를 발행하고 해당 중개인에서 구독하고 있는 내용들만을 각 서버가 받을 수 있게 한다면 로직은 보다 간편해진다.

이렇게 되면, 각각의 데이터를 제공받는 서비스는 제공을 하는 ( Publish ) 서버들과의 직접적인 연결이 되어있지 않더라도, 중개인을 통해 데이터를 전달받을 수 있고 중개인에서 데이터가 어떻게 발행되고 있는지에 대한 로그 추적이 쉬워질 것이다.

위 그림 1-2처럼 포인트 투 포인트 ( point to point ) 연결을 활용하는 방식보다 명백하게 바람직할 순 있으나, 해당 부분에는 중복이 많다.

 

이렇게 되면 버그도 한계도 각각 다수의 데이터 큐 시스템을 유지관리해야 한다.

 

메시지 교환을 필요로 하는 사례가 추가로 생길 수 있는데, 비즈니스가 확장됨에 따라 함께 확장되는 일반화된 유형의 데이터를 발행하고 구독할 수 있는 중앙 집중화된 시스템이 필요하다.

카프카 입문

카프카는 위 문제를 해결하기 위해 고안되었다.

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

카프카는 파일시스템이나 데이터베이스 커밋로그는 모든 트랜잭션 기록을 지속성 있게 보존함으로써 시스템의 상태를 일관성 있게 복구할 수 있도록 고안되었다.

 

카프카에 저장된 데이터는 순서를 유지한 채로 지속성 있게 보관되며 ( Queue ) 결정적으로 읽을 수 있다는 특징을 가진다.

 

또한, 확장 시 성능을 향상하고 실패하더라도 데이터 사용에는 문제가 없도록 시스템 안에서 데이터를 분산시켜 저장이 가능하다.

메시지와 배치

메시지

• 카프카 데이터의 기본 단위를 의미한다.
• 데이터베이스의 Row, Record와 비슷하게 보일 수 있다.
• 메시지는 단순 바이트의 배열일 뿐이기에, 여기에 포함된 데이터는 특정한 형식이나 의미가 없다.
• 메시지는 key라 불리는 메타 데이터를 포함할 수 있다.
  • key는 메시지를 저장할 파티션을 결정하기 위해 사용된다.
  • key 역시 단순 바이트 배열로 이뤄져 있다.

배치

• 카프카는 효율성을 위해 메시지를 배치(batch) 단위로 저장한다.
• 단순히 같은 토픽의 파티션에 쓰이는 메시지 집합을 의미
• 메시지를 사용할 때마다 네트워크 I/O는 막대한 오버헤드를 발생시키는데, 배치를 통해 이를 방지한다.
  • 하지만, 이는 Latency와 Throughput 사이의 트레이드오프를 발생시킨다.

 

토픽과 파티션

• 카프카에 저장되는 메시지는 Topic 단위로 분류된다.
• Topic은 다시 여러 Partition으로 나뉜다.
  • Partition에 메시지가 쓰일 때, 추가만 가능한 형태로 쓰인다.
  • 읽을 땐 맨 앞부터 끝까지의 순서로 읽힌다.
  • 토픽에 여러 파티션이 있는 경우, 토픽 안의 메시지 전체에 대한 순서는 보장되지 않는다.
    • 단일 파티션의 경우만 순서가 보장된다.
• 파티션을 통해, 카프카는 데이터 중복과 확장성을 제공하는 방법 중 하나이기도 하다.
  • 각 파티션이 서로 다른 서버에 저장될 수 있다.
    • 하나의 토픽이 여러 개의 서버로 수평적으로 확장되어 하나의 서버의 용량을 넘어가는 성능을 보여줄 수 있다.
  • 파티션의 복제기능
    • 서로 다른 서버들의 동일한 파티션의 복제본을 저장하고 있기에, 한 서버에 장애가 발생하더라도 다른 서버에서 계속해서 읽고 쓸 수 있다.

⇒ 아마 이건, 카프카 구버전일 때는 주키퍼( zookeeper )에 의해 가능하지 않을까?

신버전은 주키퍼가 필요 없어졌다.

 

스트림

파티션의 개수와 상관없이 하나의 토픽에 저장된 데이터로 간주되며, 프로듀서로부터 컨슈머로의 하나의 데이터 흐름을 나타낸다.

 

프로듀서와 컨슈머

카프카 클라이언트

• 시스템의 사용자이며, 프로듀서 & 컨슈머 두 가지 종류를 가지고 있다.

프로듀서

• Publisher, Writer
• 메시지 생성주체
  • 특정한 토픽에 생성된다.
• 기본적으로 프로듀서는 메시지를 작성할 때, 토픽에 속한 파티션들 사이에 고르게 나눠서 쓰도록 되어있다.
  • 특정 경우, Partitioner를 통해 특정 파티션을 지정하여 메시지 작성할 수도 있다.

컨슈머

• Subscriber, Reader
• 메시지 소비 주체 1개 이상의 토픽을 구독해서, 저장된 메시지를 각 파티션에 쓰인 순서대로 읽는다.
• offset을 기록함으로써, 어느 메시지까지 읽었는지 유지한다.
  • 카프카가 메시지를 저장할 때, 각 메시지에 부여하는 메타데이터이다..
  • 지속적으로 증가하는 정수값이다.
  • 파티션의 각 메시지는 고유한 오프셋을 가지며, 앞서 저장된 메시지는 뒤에 오는 메시지보다 반드시 작은 값을 갖는다.

컨슈머 그룹

• 컨슈머는  Consumer Group의 일원으로서 작동한다.
• 하나 이상의 컨슈머로 구성한다.
• 컨슈머 그룹은 각 파티션이 하나의 컨슈머에 의해서만 읽히도록 한다
  • 컨슈머와 파티션의 대응 관계를 Ownership이라고 한다.
• 컨슈머를 수평 확장 할 수 있다.
• 한 컨슈머에 장애가 발생하더라도, 다른 컨슈머가 장애가 난 컨슈머가 읽고 있던 파티션을 재할당받은 뒤 이어서 데이터를 읽을 수 있다.

 

중개인와 클러스터

브로커

• 하나의 카프카 서버를 Broker라고 부른다.
• 프로듀서로부터 메시지를 전달받아 오프셋을 할당한 뒤 디스크 저장소에 쓴다.
• 컨슈머의 파티션 fetch 요청에 응답하여 메시지를 전달한다.

 

클러스터

• 중개인은 Cluster의 일부로 작동하도록 설계되었다.
• 하나의 클러스터 안에 여러 개의 중개인가 포함될 수 있다.
  • 브로커 중 하나가 Cluster Controller 역할을 한다.
    • 작동 중인 중개인 중 하나로 자동 선정된다.
    • 파티션을 중개인에 할당해주거나, 장애가 발생한 브로커를 모니터링하는 등의 작업을 수행
• 파티션은 클러스터 안의 브로커 중 하나가 담당한다.
  • 그 브로커를 Partition Leader라고 부른다.
• 복제된 파티션이 여러 브로커에 할당될 수도 있다.
  • 복제된 파티션을 가지고 있는 브로커들을 Follower라고 한다.

카프카의 Replication, Retention

Replication

• 파티션의 메시지를 중복 저장함으로써, 리더 브로커에 장애가 발생할 경우 팔로워들 중 하나가 리더 역할을 이어 수행한다.
• 모든 프로듀서는 리더 브로커에 메시지를 발행해야 하지만, 컨슈머는 리더, 팔로워 상관없이 한 곳에서 데이터를 읽어올 수 있다.

Durability Retention

• 중개인은 토픽에 대해 기본적인 보존 설정이 되어 있다.
  • 특정 기간 동안 메시지를 보존
  • 파티션이 특정 크기에 도달할 때까지 데이터를 보존

Kafka의 특징

1. 다중 프로듀서
   • 한 토픽에 대해 여러 프로듀서가 메시지를 생성할 수 있다.
2. 다중 컨슈머
   • 여러 컨슈머가 상호 간섭 없이 어떠한 메시지도 읽을 수 있다.
   • 다른 메시지큐 서비스와 달리, 컨슈머 단위가 아닌 컨슈머 그룹 단위로 메시지가 소비된다.
3. 디스크 기반 보존
   • 메시지를 지속성 있게 저장할 수 있다 -> 즉시 메시지를 읽지 않아도 보존된다.
   • 토픽별로 보존 정책을 지정할 수 있다.
4. 확장성
   • 유연한 확장성 덕분에 어떠한 크기의 데이터도 처리할 수 있다.
   • 클러스터 작동 중에도 시스템 중단 없이 확장 가능하다 (availability)