• 분산 시스템 구성을 위한 중요 요소

    • 분산 시스템 도입을 위해서는 성능, 안정성, 가용성 측면에서 상세한 기능 검토가 요구
    • 분산 시스템은 대량 데이터를 여러 노드간 처리를 통해 빠르게 처리할 수 있는 큰 성능적 이점이 있지만 안정성, 가용성 측면에서 상대적인 단점을 가짐
    • 즉, 성능상 이점은 얻을 수 있지만, 카프카에 의존적인 애플리케이션이 될 수 있음

  • 단일 노드 구성

    Untitled

    • H/W(CPU, Memory, Disk 등) Scale Up방식으로 증설하는 한계(수직 확장의 한계)
    • 단일 노드에서만 가용성이 상승되어 안정적인 시스템 구성 가능
    • 소프트웨어의 업그레이드 등을 도입하기 매우 쉬움

  • 다수의 노드로 분산 구성

    Untitled

    • 개별 H/W 노드를 Scale Out 방식으로 증설하여 대용량 데이터 성능 처리를 선형적으로 향상
    • 다수의 노드가 데이터를 1/n씩 가지고 처리하므로 하나만 다운되어도 데이터 처리에 영향
    • 각 노드별 관리의 번거로움

  • 멀티 노드 카프카 클러스터

    Untitled

    • Scale Out 기반으로 노드 증설을 통해 카프카의 메세지 읽기 성능을 선형적으로 증가
    • 데이터 복제를 통해 분산 시스템 기반에서 카프카의 최적 가용성 보장

  • 멀티 파티션의 replication

    Untitled

    Untitled

    kafka-topics.bat의 —describe 옵션을 통해 조회한 결과

    kafka-topics.bat의 —describe 옵션을 통해 조회한 결과

    • partitions 3 replication-factor 3인 경우 파티션 구성
    • 브로커의 개수와 —-replication-factor의 개수가 같다면, 각 브로커가 각 파티션의 리더로 할당됨

  • 카프카 리플리케이션(Replication)

    • 카프카는 개별 노드의 장애를 대비하여 높은 가용성을 제공
    • 카프카 가용성의 핵심은 replication
    • replication은 토픽 생성 시 --replication-factor 설정값을 통해 구성
    • replication factor가 3이면 원본 파티션과 복제 파티션을 포함하여 모두 3개의 파티션을 가짐을 의미
    • replication factor의 개수는 브로커의 개수보다 클 수 없음

  • 카프카 replication의 Leader와 Follower

    Untitled

    • Producer와 Consumer는 Leader 파티션을 통해 쓰기와 읽기 수행
    • 파티션의 메세지의 복제는 Leader에서 Follower로만 수행
    • 리더 파티션을 관리하는 브로커는 pub/sub을 관리함 동시에 팔로우 파티션을 관리하는 브로커의 replication도 관리

  • Producer/Consumer의 Leader 파티션을 통한 pub/sub

    Untitled

    • kafka 2.4 부터는 producer는 Leader를 통해서만 메세지를 전송하지만, Consumer에서는 Follower에 접근이 가능해짐

  • Java Producer Clients에서 Multi Brokers 접속

    토픽에 대한 메타정보는 브로커끼리 공유(특정 파티션의 리더 등의 정보)

    토픽에 대한 메타정보는 브로커끼리 공유(특정 파티션의 리더 등의 정보)

    • Producer는 bootstrap.servers 를 통해 여러개의 브로커에 접속이 가능
    • 개별 브로커들은 토픽 파티션의 Leader와 Follower들의 메타 정보를 공유하고, Producer는 초기 접속 시 이 메타 정보를 가져와서 접속 하려는 토픽의 파티션이 있는 브로커로 다시 접속
    • 만약 브로커는 3대 가동할 때 Producer에는 브로커#1에 대한 config만 주고 접속을 하면, 메타정보를 통해 어떤 브로커로 보내야 하는지 인식하고 전송할 수 있음(3대 정상 가동하는 경우) → 메타정보를 가져오기 위한 리스트임을 인식(bootstrap.servers config)

  • Zookeeper의 개요

    zookeeper의 z node(z node 찾아보자)

    zookeeper의 z node(z node 찾아보자)

    controller broker는 특별하게 선출되지 않고 선착순으로 선정됨

    controller broker는 특별하게 선출되지 않고 선착순으로 선정됨

    Untitled

    • zookeeper는 분산 시스템간의 정보를 신속하게 공유하기 위한 코디네이션 시스템
    • zookeeper 참조 주키퍼(zookeeper)

  • Zookeeper에서 Kafka Cluster 정보 관리

    Untitled

  • Controller의 Leader 선출 수행 프로세스

    Untitled

    • 3개의 브로커와 3개의 파티션을 가진 토픽을 운영하는 경우
    • 브로커 1대가 다운된다면 남은 브로커 2대가 각각 파티션 1개, 2개씩 리더를 맏게 됨
    • 하지만 한대씩 다운되어 모두 다운되면 가장 마지막에 다운된 브로커를 controller로 기억
    • 바로 복구를 하더라도 5분 정도 동안은 마지막 controller 역할을 한 브로커만 모든 파티션의 리더가 되고 5분 정도 소요된 후 각각 브로커에 파티션의 리더가 할당됨(Preferred Leader Election)

  • ISR(In-Sync-Replicas)의 이해

    • Follower들은 누구라도 Leader가 될 수 있지만, 단 ISR내에 있는 Follower들만 가능
    • 파티션의 Leader 브로커는 Follower 파티션의 브로커들이 Leader가 될 수 있는지 지속적으로 모니터링을 수행하여 ISR 관리
    • Leader 파티션의 메세지를 Follower가 빠르게 복제하지 못하고 뒤쳐질 경우 ISR에서 해당 Follower는 제거되며 Leader가 문제가 생길 때 차기 Leader가 될 수 없음

  • ISR(In-Sync-Replicas) 조건

    Untitled

    • 브로커가 zookeeper에 연결되어 있어야함(필수)
    • zookeeper.session.timeout.ms로 지정된 시간(default = 6000, max = 18000)내에 HeartBeat을 지속적으로 zookeeper에 보냄
    • replica.lag.time.max.ms로 지정된 시간(default = 10000, max = 30000)내에 Leader의 메세지를 지속적으로 가져 가야함
    • 즉, 계속 zookeeper에 생존 신호를 보내고 신호 주기를 넘어서면 ISR에서 제거됨
    • Follower는 Leader에게 Fetch 요청을 수행하며, Fetch 요청에는 Follower가 다음에 읽을 메세지의 offset을 포함
    • Leader는 Follower가 요청한 offset 번호화 현재 Leader partition의 가장 최신 offset 번호를 비교하여 Follower가 얼마나 Leader 데이터 복제를 잘 하는지 확인

  • min.insync.replicas의 이해

    • min.insync.replicas 파라미터는 브로커의 설정값
    • Producer가 acks=all로 성공적으로 메세지를 보낼 수 있는 최소한의 ISR 브로커 개수 의미
    • 즉, acks=all 이라도 min.insync.replicas=2일 때 브로커 3대를 가정한 경우 브로커 2대에만 복제가 이뤄지면 acks 메세지를 받음
    • 만약 위 경우에서 1대의 브로커만 생존한 경우 min.insync.replicas=2이므로, NOT_ENOUGH_REPLICAS 에러 발생

  • Preferred Leader Election

    Untitled

    • 파티션 별로 최소 할당된 Leader/Follower Broker 설정을 Preferred Broker로 그대로 유지
    • Broker가 shutdown후 재 기동될 때 Preferred Leader Broker를 일정 시간 이후에 재 선출
    • auto.leader.rebalance.enable=true로 설정하고 leader.imbalance.check.interval.seconds를 일정시간으로 설정(default = 300000ms)
    • 즉, 최초 파티션 할당을 기억하고 있다가 리더를 원래대로 설정 가능한 경우를 300초(5분) 간격으로 확인하고 원래 리더로 돌아가는 설정
    • 주의할 점은 마지막 controller였던 브로커가 가장 먼저 시작되어야 함 → 이전까지 받은 메세지에 대해 controller를 제외하고는 메세지를 가지고 있지 않기 떄문에 메세지 손실 가능성

  • Unclean Leader Election

    • 기존의 Leader 브로커가 오랜 기간 살아나지 않을 경우 복제가 완료되지 않은(Out of sync) Follower Broker가 Leader가 될지 결정해야 함
    • 이때 기존의 Leader 브로커가 가진 메세지 손실 여부를 감수하고 복제가 완료되지 않은 Follower Broker가 Leader가 되려면 unclean.leader.election.enable=true로 설정 후 Unclean Leader Election 수행