아파치 카프카 기본개념 (Apache Kafka)

1. 카프카 소개

 

아파치 카프카(Apache Kafka)는 분산형 메세지 큐 시스템으로 

아파치재단 공식 사이트에서 카프카는 Apache Kafka® is an event streaming platform" "라고 표현하고 있다.

 

단어의 의미 그대로 이벤트를 스트리밍 서비스를 하기위한 프로그램이라고 보면 될것 같다. 

 

먼저 구조는 다음과 같다.

 

카프카(Kafka)의 구조

모든 source system은 kafka로 데이터를 보내고 target은 Kafka로 데이터를 요청하여 받아갈 수 있다.  다시 말하면 target system 입장에서는 kafka에서 필요한 데이터를 가져가서 사용하는 형태로 되어있다. 

 

추가로 실시간 데이터 처리에 용이하여 수많은 데이터(Event)를 처리해야 하는 대기업 및 여러 중소, 스타트업에서도

카프카의 실시간 메세징 기능을 활용하려 하고 있다. 

 

---

2. 카프카 구성요소(명칭)와 동작 원리 

Kafka는 발행-구독(publish-subscribe) 방식으로 동작하며 다음과 같은 요소(producer, consumer, broker)로 구성된다.

아래의 그림은 단일 서버(broker) 기준 kafka의 동작방식을 나타낸다.

-- Cluster 관련해서는 추후에 더 설명 예정

 

Kafka 비동기식 구조 

자 이제 위의 그림에서 나온 단어들을 한번 천천히 살펴보도록 하자.

 

 (1) Producer 

    Producer는 데이터를 생산하는 주채로 예를 들어 공공데이터 포탈의 데이터나 기계에 달려있는 센서 등 데이터를 

생산하는 모든 개채를 말한다. Producer는 생산된 데이터를 Topic이라는 저장?공간에 집어 넣어 준다.

 

 (2) Broker

    Kafka의 Node즉 클러스터 단위 1개를 Broker라고 칭한다 Producer와 Consumer의 중간 단계에서 두 사이의 데이터 중계 역할을 담당하기에 이름을 이렇게 부르는것 같다.

 

 (3) Topic

    일종의 저장공간으로 Producer로 부터 데이터를 받아 저장하고 있다. 각각의 Topic은 이름이 부여되어 있으며 이 저  장된 데이터를 Consumer가 요청하면 그쪽으로 보내어 활용할 수 있다. (Topic의 내부는 조금있다 더 자세하게 다루어 보자)

 

 (4) Consumer 

    데이터를 소비하는 주체로서 Topic에게 데이터를 요청하여 "소비" 한다는 개념으로서 이름이 Consumer로 지어진 것 같다. 

 

여기서 중요한점은 Producer와 Consumer는 직접적인 관계를 가지지 않으며 중계소인 Broker Topic을 통해서 데이터가 교환 되기 때문에 "비동기식"이라고 한다. 

---

3. 구성요소 특징 및 상세 

Kafka Topic 내부 구성

1. 토픽(Topic) : 특정 스트림 데이터이며, 카프카 클러스터에 데이터를 관리할 시 기준이 된다.

• Similar to a table in a database (without all the constraints)
• 원하는 수만큼 토픽은 가질 수 있다.
• 토픽은 토픽 이름(=name)으로 구분됨
• 토픽은 파티션으로 나눠서 처리되며 각 파티션은 순서가 있고 각각의 파티션 내 메시지는 offset이라는 단위로 고유 id가 증가한다. 스트리밍 처리를 할때 해당 파티션이 어디까지 데이터를 전송했는지가 이 offset번호로 기억된다. 
  • 파티션(Partition): 각 토픽 당 데이터를 분산 처리하는 단위. 카프카에서는 토픽 안에 파티션을 나누어 그 수대로 데이터를 분산처리 한다. 카프카 옵션에서 지정한 replica의 수만큼 파티션이 각 서버들에게 복제된다
    (replica로 복제된 파티션은 Cluster 그룹내에 있는 다른 kafka에 동일하게 저장된다)
  • offset은 특정 partition 에서만 의미가 있으며 순서 또한 속해있는 파티션 내에서만 보장된다. (즉, 'partion 0의 offset 3'은 'partion 1의 offset 3'에 있는 데이터와 다르다.)
• 데이터의 보존 주기는 default 7일이고 변경 가능하다. (log.retention.hours/log.retention.check.interval.ms=300000 설정) 
• 데이터가 특정 파티션에 쓰여지면 절대 변경되지 않는다. (새로운 데이터는 새로운 파티션-오프셋에 쓰여짐)
• 특정 키로 파티션을 지정하지 않으면, 데이터는 랜덤하게 파티션이 지정되어 쓰여진다.
• 파티션의 개수도 설정으로 지정이 가능하다(num.partitions=x) 설정후 생성되는 토픽의 파티션 초기 설정이 x값으로 지정된다. 
• 데이터 처리량에 따라 Partition을 조정해야 한다. 
• 파티션의 개수에 따라 연결할 수 있는 Consumer의 개수가 다르다 설정된 파티션의 개수보다 Consumer가 많은 경우 Consumer가 동작하지 않을 수 있다.

2. Brokers

• Kafka Cluster는 여러대의 broker(server)로 구성된다.
• 각 broker는 고유한 id 값으로 구분되며 특정 topic partition을 포함한다.
• bootstrap broker라 불리는 어떤 broker 에나 연결이 된다면, 전체 클러스터에 연결된 것이다.
• 통상 3개의 broker로 운영을 하는게 이상적이나 기업과 시스템의 규모에 따라서 100개 이상의 broker를 클러스터로 구성하여 운영하는 경우도 있다.
• Kafka topic 파티션의 Replication Factor(RF)는 broker 설정 중 offsets.topic.replication.factor에 의해 결정된다. 기본 값은 3으로, 하나의 파티션이 총 세 개로 분산 저장된다. (아래 사진은 replication factor가 2인 모습 -> leader 파티션 1 + ISR 파티션 1 / ISR = In-Sync Replica)

Kafka reflica 구조

3. Producers

• Producer는 topic에 데이터를 write 한다.
• Producer는 데이터를 쓰는 때에 자동적으로 어떤 브로커와 파티션에 데이터를 write 할지 알고있다.
• Producer는 데이터를 write 할 때의 receive acknowledgment 를 선택할 수 있다.
  • acks=0 : Producer는 acknowledgment를 기다리지 않음(데이터 손실 가능성이 있다.)
  • acks=1 : producer는 leader acknowledgment를 기다렸다가 다음 액션을 함(제한된 데이터 손실 가능성)
  • acks=all: leader+ISR acknowledgment를 모두 기다림(no data loss)
    

    

• Message keys
  • Producer는 메시지 데이터와 함께 key를 선택하여 보낼 수 있다. (string, number, etc...)
  • key=null 이라면, 데이터는 라운드로빈 동작으로 브로커에 순차적으로 데이터를 송신한다.
  • key를 지정하여 데이터를 송신하면, 해당 key로 보내지는 데이터는 항상 (특정)같은 파티션으로 보내진다. (key hashing 방식)

 

4. Consumers & Consumer Groups

• Consumer는 topic에 있는 데이터를 read 한다.
• Consumer는 데이터를 읽을 때에 자동적으로 어떤 브로커와 파티션에서 데이터를 read 할지 알고있다.
• 데이터는 각 파티션 내에서 순서대로 읽어온다.
  

  

• Consumer Groups
  • Consumer는 Consumer Groups 안에 속하여 데이터를 read 한다.
  • 그룹 내 각 Consumer는 서로 다른 partition에 할당된다.
  • 만약 컨슈머의 수가 파티션의 수보다 많다면 몇 컨슈머는 수행 하는 것이 없이 놀고 있을 수 있다.
  • 컨슈머는 자동적으로 GroupCoordinator와 ConsumerCoordinator를 사용하여 컨슈머와 파티션을 할당 한다.
    

    

• Consumer Offsets
  • Kafka는 어디 까지 reading 했는지에 대한 offset 정보를 저장하고 있다. (__consumer_offsets)
  • '__consumer_offsets' 덕분에, 컨슈머가 죽더라도 마지막 offset 다음부터 데이터를 읽을 수 있다.
    

    

  • 3 delivery semantics:
    • At most once
      • offsets are committed as soon as the message is received.
      • If the processing goes wrong, the message will be lost (it won`t be read again.)
    • At least once (usually preferred):
      • offsets are committed after the message is processed.
      • If the processing goes wrong, the message will be read again.
      • This can result it duplicate processing of messages. Make sure your processing is idempotent (i.e. processing again the messages won`t impact your systems)
    • Exactly once:
      • Can be archieved for kafka => kafka workflows using Kafka Streams API
      • For Kafka => External System workflows, use an idempotent consumer.

5. Zookeeper

• Zookeeper는 분산 코디네이션 시스템이다.
• 카프카 브로커를 하나의 클러스터로 코디네이팅하는 역할을 하며, 카프카 클러스터의 리더(Leader)를 발탁하는 방식을 제공한다.
• 새로운 토픽 생성, 브로커 서버 다운 등 모든 카프카 클러스터 내 변화들에 대하여 알림을 준다.
• 카프카는 주키퍼 없이는 작동할 수 없다.
• 보통 홀수 개의 서버 (3,5,7)수로 주키퍼는 운영됨
• consumer offset은 zookeeper가 가지고 있지 않다. (-> kafka topic 내 저장함 after v0.10)
  

  

이상으로 간단하게 Kafka의 개념과 구성요소 등에 대해서 작성하였다.
전체적인 kafka의 컨셉 디자인은 아래와 같이 정리할 수 있다.

 

인용 

https://velog.io/@king3456/Apache-Kafka-%EA%B8%B0%EB%B3%B8%EA%B0%9C%EB%85%90