Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Publish & Subscribe Read and write streams of data like a messaging system.

  2. Process Write scalable stream processing applications that react to events in real-time.

  3. Store Store streams of data safely in a distributed, replicated, fault-tolerant cluster.

...


Image Added


A streaming platform has three key capabilities:

...

모든 Consumer 인스턴스가 서로 다른 Consumers Group을 갖고 있으면 각 레코드가 모든 소비자 프로세스에 브로드 캐스팅됩니다.


Image RemovedImage Added


2 개의 consumer groups이있는 4개의 파티션 (P0-P3)을 호스팅하는 2대의 서버 Kafka 클러스터. 소비자 그룹 A에는 두 개의 소비자 인스턴스가 있고 그룹 B에는 네 개의 인스턴스가 있습니다.

...

서버와 클라이언트 사이 또는 서버 내부적으로 데이터를 주고받는 과정에서는 I/O가 발생. 빈번하게 일어날경우 속도가 저하될 수 있다.

Image RemovedImage Added


UseCase

kafka as a Messaging System

...

  • 다양한 시스템과 연동하기 위한 멀티 프로토콜과 데이터 타입 지원

  • 느슨한 결합(Loosely coupled)을 위한 메시지 큐 지원

  • 정기적으로 데이터를 가져오는 대신 이벤트 기반 통신 지원

Image RemovedImage Added

Image RemovedImage Added

Image RemovedImage Added

Image RemovedImage Added


Topic

카프카 클러스터는 Topic이라 불리는 곳에 데이터를 저장한다. 우리가 많이 사용하는 메일 시스템과 비교하면, 토픽은 메일주소라고 생각하면 쉽다.

카프카에서는 데이터를 구분하기 위한 단위로 토픽이라는 용어를 사용하는데, 249자 미만으로 영문,숫자, '-','.','_','-'를 조합하여 자유롭게 만들 수 있다.


Image RemovedImage Added


Partition

파티션이란 토픽을 분할한 것이다. 그럼 왜 하나의 토픽을 파티셔닝하는 걸까?

...

하지만 카프카에서는 컨슈머도 있기 때문에 컨슈머의 입장도 고려해야 합니다. 컨슈머 입장에서 8개의 컨슈머를 통해 각각 초당 5개의 메시지를 카프카의 토픽에서 가져올 수 있다면, 해당 토픽의 파티션 수는 컨슈머 수와 동일하게 8개로 맞추어 켠슈머마다 각각의 파티션에 접근할 수 있게 해야 합니다.


Image RemovedImage Added


Offset

카프카에서는 각 파티션마다 메시지가 저장되는 위치를 오프셋이라고 부르고 오프셋은 파티션 내에서 유일하고 순차적으로 증가하는 숫자(64비트) 형태로 되어 있다.

Image RemovedImage Added

여기서 쓰기의 의미는 프로튜서가 메시지를 보내면 메시지가 각 파티션 별로 분산되어 데이터를 저장하는 상태를 나타낸다. 각각의 파티션에는 프로튜서가 전송한 메시지들이 저장되어 있으며, 저장된 위치를 유니크하고 순차적인 숫자 형태인 0,1,2 같은 형태로 나타내고 있다. 이러한 숫자는 파티션마다 유니크한 값을 가지며 카프카에서 이를 오프셋이라고 한다. 오프셋은 하나의 파티션 내에서만 유일한 숫자이다.

...

토픽을 이루는 각각의 파티션을 리플리케이션하는 것.

Image RemovedImage Added

Image RemovedImage Added

Image RemovedImage Added

Image RemovedImage Added

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

    카프카에는 리플리케이션 팩터(Factor)라는 것이 있음. 카프카의 기본값은 1로, 변경하고 싶다면

    레플리는 2로 설정해주는 것이 좋다.

    리더와 팔로워는 각자 역할이 나뉘어 있는데 가장 중요한 핵심은 모든 읽기와 쓰기가 리더를 통해서만 일어난다는 점, 즉 팔로워는 리더의 데이터를 그대로 리플리케이션만 하고 읽기와 쓰기에는 관여하지 않습니다. 리더와 팔로워는 저장된 데이터의 순서도 일치하고 동일한 오프셋과 메시지를 갖게 됩니다.

    단점은, 100G이면, 리플리케이션을 하는 다른 브로커에도 100G 들어간다.

  • 리더와 팔로워의 관리

    리더는 모든 데이터의 읽기 쓰기에 대한 요청에 응답하면서 데이터를 저장해나가고, 팔로워는 리더를 주기적으로 보면서 자신에게 없는 데이터를 리더로부터 주기적으로 가져오는 방법으로 리플리케이션을 유지합니다. 리더와 팔로워 모두 주어진 역할에 맞게 잘 동작하고 있다면 전혀 문제가 없지만 팔로워에 문제가 있어 리더로부터 데이터를 가져오지 못하면서 정합성이 맞지 않게 된다면 어떻게 될까요? 결국 리더가 다운되는 경우 팔로워가 새로운 리더로 승격되어야 하는데, 데이터가 읽치하지 않으므로 큰 문제가 발생할 수 있다. 카프카에서는 이러한 현상을 방지하고자 ISR(In Sync Replica)라는 개념을 도입했다.

    ISR - 현재 리플리케이션되고 있는 리플리케이션 그룹. ISR에는 중요한 규칙 하나가 있는데, 그 규칙은 ISR에 속해있는 구성원만이 리더의 자격을 가질 수 있다. peter토픽이 리플리케이션 팩터2로 구성되어 리더는 1번 브로커, 팔로워는 2번 브로커에 위치하고 있다면, ISR구성원은 1,2입니다. 그런데 급작스러운 이유로 브로커 1이 다운되면, ISR의 구성원인 2번 브로커에 있는 팔로워가 새로운 리더로 승격.

...