Kafka 구성 및 Send/Receive

1. Kafka의 구성
  1.1 시스템 구성
  1.2 메시징 구성
2. 메시지 송수신 과정
  2.1 Producer의 메시지 send
  2.2 Consumer의 메시지 receive
  2.3 메시지 전송시의 Partitioning
3. Replica 역할
  3.1 replica 동기상태
  3.2 구조
  3.3 메시지 전달 보증 수준

 

 

1. Kafka의 구성

1.1 시스템 구성

• Kafka Cluster
  • Broker
    • 메시지 수집/전달
    • 하나의 서버 당 하나의 데몬 프로세스로 동작하여 메시지 수신/전달 요청을 받아들임
    • 여러대의 클러스터로도 구성 가능
      • Broker 의 손쉬운 scale-out 가능 -> 수신/전달 처리량 향상
    • Broker에서 받은 데이터는 디스크에 저장됨
      • 디스크의 용량이 한계가 있으므로 기간/용량 중 하나를 기준으로 설정하여 관리할 수 있다.
        • 기간으로 설정한 경우, default값은 1주이며, 해당 기간보다 오래된 데이터를 삭제
        • 크기로 설정한 경우, 쌓인 데이터가 설정값보다 커진 경우 삭제
      • key를 기준으로 최신 key의 데이터를 남겨두고, 오래된 데이터를 지우는 옵션도 존재한다.
        • cleanup.policy를 delete가 아닌 compact 옵션으로 설정하므로서 가능
      • 삭제된 데이터는 복구가 불가능하다.
  • Zookeeper
    • 분산 코디네이터 (병렬처리 오픈소스 소프트웨어의 설정관리, 동기화, 잠금관리 등 )
    • 분산 메시지들의 메타 데이터 ( 토픽 / 파티션 등)을 관리하는 요소로 사용
    • 카프카 Broker 서버 대수와 동일하며, 주로 3,5 등 홀수로 구성한다 (주로 짝수 운영. 한 대는 장애 대응에 활용)
• Producer
  • 메시지 생산을 담당
    • Producer는 메시지를 Consumer에게 메시지를 직접 전달하는 것이 아니라 Broker를 통해 전달.
      • Broker 내의 Topic에 메시지를 등록(Publish) 하는 형태로 이루어진다.
  • Producer API 를 내포한 다양한 오픈소스 활용
    • Apache Log4j, Apache Flume, Fluentd, Logstash 등
• Consumer
  • 메시지 소비를 담당
    • Consumer는 여러개 존재하는 Topic중 하나를 선택하여 메세지를 받는다.
      • 같은 토픽을 구독(Subscribe)하면 같은 메시지를, 다른 토픽을 구독하면 다른메시지를 받는다.
    • Consumer Group을 두어 여러 Consumer가 한 개의 Topic에 대해 분산처리할 수 있다.
  • Consumer API 를 내포한 다양한 오픈소스 활용
    • Apache Spark, Apache Samza, Apache Flink, Apache Flume, Fluentd, Logstash 등
• Kafka Client
  • Topic 생성 등 Kafka 운영상의 조작을 수행하는 서버

 

1.2 메시징 구성

카프카 분산 아키텍처

• Topic
  • 메시지가 쓰여지는 곳
• Partition
  • 각 토픽 당 데이터를 분산하는 단위
  • Patition 분산 배치에 대한 정보는 Broker가 가지고 있음
  • Producer/Consumer에서는 Topic만 지정하면 자동으로 Patition이 매칭이 되므로 신경쓸 필요가 없으며, 특정 Patition을 지정하여 송신을 할 수 도 있다
• Offset
  • 토픽에 저장된 메시지의 위치 값
  • 파티션 단위이며, 각 파티션에서 수신한 메시지에는 번호가 부여되어 있음
  • Consumer가 얻는 메세지의 범위를 제어함
  • 종류
    • LEO ( Log End Offset) : Partition이 가지고 있는 데이터의 끝
      • Broker에 의해 Partition에 관한 정보로 관리/업데이트
    • Current Offset : Consumer가 어디까지 읽었는지를 나타냄
      • Consumer가 데이터를 읽을때마다 업데이트
    • Commit Offset : Consumer가 어디까지 Commit했는지를 나타냄.
      • Consumer Group마다 관리/업데이트되며, Consumer가 보낸 Offset Commit 요청에 기반하여 업데이트
      • Consumer Group마다 관리/업데이트되므로, 여러 Consumer Group이 메시지를 가져오는 경우 Commit Offset도 Consumer Group 수 만큼 존재하게 됨

• Consumer Group
  • 글로벌 ID를 컨슈머 그룹 전체에서 공유하고, Consumers는 자신이 속한 Consumer Group을 식별하여 읽어들일 파티션을 분류한다

 

2. 메시지 송수신 과정

• 메시지 단위로 송수신 할 수 도 있고 아주 짧은 시간동안 일부 메시지를 모아 송수신 할 수도 있다.

 

2.1 Producer의 메시지 send

• Producer도 자체 메모리를 사용해 버퍼처럼 활용할 수 있다. 쌓인 데이터의 크기 혹은 시간을 기준으로 정할 수 있다. 이를 통해 마이크로 배치단위 전송이 가능하다.

2.2 Consumer의 메시지 receive

• Current offset에서 최신 메시지 까지 Broker에게 요청하고, 이를 반복하면서 메시지를 얻는다.
• 한번에 요청하는 메시지 개수만큼 Current offset을 업데이트 한다.
• 즉 Consumer 역시도 마이크로 배치 처리가 가능하며 처리량과 대기 시간의 trade off를 고려하여 배치간격을 정해야 한다.

2.2.1 Consumer의 roll-back

• 메시지를 취득 중 Consumer의 장애가 났을 시, Current offset에서 roll back하여 최종 Commit offset부터 다시 재취득한다.

1. Commit offset이후 데이터 4,5,6 획득

2. 장애발생. 장애로부터 복구과정 ( Commit Offset으로 Current Offset 까지 Roll back)

3. 다시 실행되는 과정에서 4,5,6 데이터 중복 취득

 

• 재취득된 메시지의 처리는 Consumer API를 사용한 애플리케이션에서의 처리에 따라 다르다. 즉 Kafka Broker 에서 관여하는 일이 아니다.
• 동일한 메시지의 중복 처리에 대한 허용이 필요하고, 고장 감지/복구에 관해서도 알아서 처리해야 하는데, Spark Streaming등 Kafka 연계 기능을 제공하는 대부분의 분산 처리 프레임워크들은 Consumer의 고장이나 장애를 감지하는 기능이 있으므로 우리가 신경쓸 부분은 아니다.

2.3 메시지 전송시의 Partitioning

• Producer에서 메시지를 전송할 때 어떤 파티션으로 보낼 지 선택 후 전송할 수 있으며, 선택하지 않으면 Round Robin방식으로 전송하게 된다.
  • 메시지에 포함된 key, value 중 , 특정 key 값을 가진 메시지를 특정 partition에만 전송하게끔 할 수 있다. 같은 key를 가진 메시지는 같은 partition에 모이게 된다
    • 이 경우 동일 key 메시지를 동일한 컨슈머 그룹에서 읽어 처리할 수 있으나, 데이터의 개수가 일정하지 않은 경우 편향되어 리소스를 효율적으로 활용하지 못하는 경우가 있을 수 있다.
  • 메시지 key를 지정하지 않는다면 모든 partition에 RR 방식으로 메시지가 보내지게 된다.

 

3. Replica 역할

• Kafka 의 Broker은 서버의 장애에 대비하여 수신한 메시지를 잃지 않기 위해 복제 구조를 갖는다.
• 토픽 단위로 replica 수를 지정할 수 있으며, 지정한 개수만큼 broker들에 배치된다.
• 이 때, 복제된 것을 포함한 파티션에 개수에서 한 개는 Leader, 나머지들은 Follower가 된다.
  • Leader 는 Producer/Consumer과 직접적으로 데이터를 읽고 쓰게끔 하는 역할을 한다.
  • Follower들은 단순히 Leader로 부터 데이터를 받아 복제하는 역할을 한다.

3.1 replica 동기상태

• Leader Replica의 복제상태를 유지하고 있는 follower replica ( = 리더의 현 상태와 동일한 replica) : ISR (In-Sync Replica)
• Leader Replica의 복제상태와 다른 follower replica : Under Replicated Partitions.
• 최소 ISR 수를 옵션으로 설정할 수 있으며, 이를 통해 장애가 났을 시에도 읽고 쓰는 행동을 계속 할 수 있게끔 할 수 있다

3.2 구조

• 복제를 사용할 때는 High Watermark 를 활용한다. High Watermark는 복제가 완료된 offset을 의미하며 LEO와 동일하거나 오래된 것이 된다.
• 이 때 Consumersms High Watermark 까지 기록된 메시지를 얻을 수 있다.

3.3 메시지 전달 보증 수준

• Ack는 메시지가 잘 보내졌는지를 나타내는데, Producer에서 메시지를 보낼 때 언제 어느때에 Ack 을 보낼 건지를 설정할 수 있다.
  • Ack = 0
    • Producer는 메시지를 보낼 때 Ack 신호를 기다리지 않고 다음 메시지를 전송한다
  • Ack = 1
    • Leader Replica에 메시지가 전달되면 Ack 를 반환한다
  • Ack = all
    • 모든 ISR 수 만큼 복제되면 Ack 를 반환한다 ( = 모든 Replica가 동일한 메시지를 가지고 있으면)
• Producer는 Ack=1, all 일 경우 Time out으로 설정된 시간 내에 Ack 신호가 돌아오지 않을 때 전송에 실패했다고 판단한다. 또한 이 때 ' 메시지의 전달' 은 Broker에게 메시지가 도달했다는 의미로, 버퍼에 저장이 되며 실제로 디스크에 저장된 시점을 의미하는 것이 아니다.
• Ack = all 인 경우 최소 ISR 개수 (min.insync.replicas 옵션)에 따라 Kafka의 처리방식이 달라진다.
  • 만약 Ack = all이고 min.insync.replicas = replica개수 일 때, 서버 한 대 가 고장이나면, 운영할 수 있는 replica개수가 min.insync.replicas-1 이므로, 고장난 replica가 ISR로 복구될 때 까지 데이터를 Topic에 쓸 수 없다.
  • 만약 Ack = all이고 min.insync.replicas = replica-1 일 때, 서버 한 대 가 고장이나도 ISR이 min.insync.replicas 를 만족하여 데이터 전송을 이어서 진행할 수 있지만, 이후에 서버 한대가 더 고장나면 첫 번 째 서버가 고장난 이후에 전송된 데이터들의 손실 위험이 있다.
  • 따라서 min.insync.replicas 는 서버에 장애 발생 시 데이터의 유실을 막는 것 과 전체 시스템을 계속 진행하여 이어나가는 것 사이의 균형을 옵션으로 상황에 따라 잘 조절 해야한다.

---

* 카프카에서 전달하는 메시지의 순서보증이 가능할까?

   -> 단일 파티션이라면 가능! 하지만 카프카의 장점인 확장성을 제대로 활용하지 못하게 된다.