Kafka 알아보기

대표적으로 메시징 시스템은 Kafka, RabbitMQ, Active MQ가 존재한다고 하고 그중 Kafka를 사용하기 위해 정리했습니다.

간단한 장점

메세징 큐의 일종말 그대로 분산형 스트리밍 플랫폼이다.

대용량의 실시간 로그 처리에 특화되어 설계된 메시징 시스템, 기존 범용 메시징 시스템대비 TPS가 매우 우수

1. Kafka

Kafka가 어떻게 구성되어 있는지 아래 그림을 통해 먼저 보도록 하겠습니다.

• Zookeeper ( Apache Zookeeper )

• 본래 Zookeeper의 용도는 클러스터 최신 설정정보 관리 및 동기화, 리더 채택 등 클러스터의 서버들이 공유하는 데이터를 관리 하기 위하여 사용된다. ( Borker에 분산 처리된 메시지 큐의 정보를 관리 )
  클러스터를 관리하는 Zookeeper 없이는 Kafka 구동이 불가능하다. ( Kafka 가동을 원한다면 Zookeeper를 먼저 가동해야함 그렇기에 Kafka 다운시 Zookeeper도 같이 제공된다. )

• Broker

  • Kafka Server를 의미하며 한 클러스터 내에서 Kafka Server를 여러 대 띄울 수 있다.

• Topic

  • 메시지가 생산되고 소비되는 주제이다. ( A, B 그룹이 메시지를 전송하여 대화를 하는데 B 그룹의 대화가 A 그룹에 전달되지 않고 A 그룹에서만 보여줘야 합니다. )

  • 주제에 따라 여러 topic을 생성하면 된다. ( email topic, sms topic, pub topic, sub topic )

• Partition

  • topic 내에서 메시지가 분산되어 저장되는 단위이다.

    • 한 topic에 Partition이 3개가 존재하다면 3개의 Partition에 대해서 메시지가 분산되어 저장이 된다.

    • 이 때 Queue 방식으로 저장이 되므로 Partition의 끄트머리에 저장되어 Partition 내에서는 순서를 보장해주지만, Partiton끼리는 메시지 순서를 보장해주지 않는다. (그렇기에 Topic 내 하나의 Partition과 여러개의 Partition이 존재할 때는 차이점이 있다)

• Log

  • Partition의 한 칸을 Log라 표현한다.

    • Log는 key, value, timestamp로 구성된다.

• Offset

  • Partition의 각 메시지를 식별할 수 있는 유니크 값이다.

    • 메시지를 소비하는 Consumer가 읽을 차례를 의미하며, Partition마다 별도로 관리가 이루어진다.

    • 0 부터 시작하여 1씩 증가한다.

2. Producer, Consumer Group ( 메시지 생산/소비 )

• Producer

  • Producer는 정해진 Topic으로 메시지를 기록한ㄷ.

  • Partition이 여러 개 존재할 경우, 기록 될 Partition의 선택은 기본적으로 Round-Robin 방식을 따른다.

    Round-Robin: 시분할 시스템을 위해 설계된 선점형 스케줄링의 하나로서, 프로세스들 사이에 우선순위를 두지 않고, 순서대로 시간단위(Time Quantum/Slice)로 CPU를 할당하는 방식의 CPU 스케줄링 알고리즘이다.

    • Partition이 여러 개 있으면 병렬 처리라는 이점이 존재하지만, Partition 개수는 주의해서 잘 설정해주어야 한다.

  • 각 Partition 내에서는 가장 마지막 offset 뒤에 신규 메시지가 저장되므로, partition 내에서는 순서가 보장되지만 실제 메시지가 사용되는 순서는 순서가 보장되지 않는다.

• Consumer Group (Consumer Group 참고링크 *필독)

  • Counsumer Group은 하나의 Topic을 담당한다.

    • Topic은 여러 개의 Consumer Group이 접근할 수 있지만, 하나의 Consumer Hroup은 하나의 Topic에만 접근할 수 있다.

  • Partition 접근하는 Consumer 관리)

    • Consumer Group 내에서 Consumer 인스턴스들은 Topic 내에 Partition에서 다음에 소비할 offset이 어디 인지 공유하면서 메시지를 소비한다. 그렇기에 다음에 소비할 offset을 잘 관리할 수 있다.

      • 예를 들어 Consumer Group이 없을경우, 하나의 Partition에 2개의 Consumer가 동시에 접근할경우 어떤 Consumer가 몇 번의 offset을 소비해야 하는지 알 수 없게 된다.

      • 즉 Consumer Group을 통하여 하나의 Partition에는 하나의 Consumer 인스턴스만 접근할 수 있도록 관리 한다.

  • offset을 공유하여 고가용성을 확보)

    • Partition에는 하나의 COnsumer 인스턴스만 접근이 가능하기에 특정 Consumer 인스턴스테 에러가 발생하면 다른 Consumer 인스턴스는 에럭 ㅏ발생한 COnsumer 인스턴스가 소비하던 Partition을 소비하게 된다.

      • 즉 Consumer가 다운될 경우를 대비하여 Consumer Group의 Consumer 인스턴스들은 offset을 공유하고 있으며, 이를 통하여 고가용성이 확보된다.

Partition과 Consumer 관계

대량의 메시지가 Kafka를 통해 쓰여진다고 가정을 해보자.

1. Partition 1개 /Consumer 인스턴스 1개
   메시지가 대량으로 생산되어야 하는데 처리하는 Consumer가 1개라 속도가 느림
2. Partition 1개 /Consumer 인스턴스 4개
   Consumer를 늘렸지만 Consumer Group에서 Partition은 하나의 Consumer 밖에 접근을 못하는 구조이기에 Consumer를 늘려도 소용이 없다.
3. Partition 4개 /Consumer 인스턴스 4개
   Consumer는 하나의 Partition에 접근할 수 있기에, Partition과 Consumer는 1:1 구조가 되어 제일 좋다.
4. Partition 4개 /Consumer 인스턴스 3개
   3번에서 운영이 되다가 Consumer가 하나가 죽었다. 하지만 Consumer Group에서 offset이 공유가 되기에 다른 Consumer가 해당 Partition에 접근하면 된다.

Partition은 늘리는건 자유롭지만 한번 늘리게 되면 다시는 줄일수 없게 된다 그렇기에 항상 Partition의 개수는
Partition >= Consumer 를 유지해주는 것이 제일 좋다. ( Consumer > Partition 은 불가능 )
하나의 Partition에 하나의 COnsumer가 담당하는 것이 제일 좋지만 딱 맞춰도 변수가 존재합니다. Consumer 수가 모자라도 상관은 없지만 Partition은 늘리면 줄일 수 없기에 처리량을 고려해야 Partition과 Consumer의 수를 선택해야 한다.

 

출처 : https://victorydntmd.tistory.com/344