kafka overview

    Cloud / / 2021. 7. 5. 14:24
    728x90
    아파치 카프카는  실시간 데이터 피드를 처리하기 위해 통합 된  고성능, 저지연을 제공하는 것을 목표로 하는 분산 스트리밍 처리 플랫폼.

    1. 소개

    Apache Kafka는 스트리밍 데이터를 실시간으로 수집하고 처리하는 데 최적화 된 분산 데이터 저장소입니다. 스트리밍 데이터는 일반적으로 데이터 레코드를 동시에 보내는 수천 개의 데이터 소스에 의해 지속적으로 생성되는 데이터를 의미합니다. 스트리밍 플랫폼은 이러한 지속적인 데이터 유입을 처리하고 데이터를 순차적으로 점진적으로 처리해야합니다. 간단히 말해서 하이엔드 차세대 분산 애플리케이션을 구축하기위한 플랫폼을 제공합니다.

    Apache Kafka는 스트리밍 플랫폼에 필수적인 세 가지 주요 기능을 제공합니다.

    1. 데이터 스트림 (메시지 큐와 유사)을 생성 및 소비 (Produce / Subscribe)합니다.
    2. 내결함성 방식으로 데이터 스트림을 저장합니다.
    3. 레코드 스트림이 발생하면 처리합니다.

    Kafka 노드는 하나 이상의 kafka 클러스터 서버에서 클러스터로 실행할 수 있습니다. Kafka는 데이터 / 메시지를 topic으로 알려진 범주의 레코드 스트림으로 저장하며 각 레코드는 키, 값 및 타임 스탬프와 연결됩니다.

     

    2. 장점

    1. 신뢰성 – kafka에서는 레코드가 배포되고 복제되며 내결함성이 있습니다.
    2. 높은 처리량 – Kafka는 방대한 양의 데이터를 처리 할 수 ​​있습니다. 또한 초당 수천 개의 메시지 처리량을 지원할 수 있습니다.
    3. 저 지연 시간 – 대부분의 새로운 사용 사례에서 요구하는 밀리 초 범위의 매우 낮은 대기 시간으로 이러한 메시지를 처리 ​​할 수 ​​있습니다.
    4. 내결함성 – 가장 좋은 장점 중 하나는 내결함성입니다. Kafka는 클러스터 내 노드 / 머신 장애에 대한 저항력을 가지고 있습니다.
    5. 내구성 – 여기서 내구성은 디스크에있는 데이터 / 메시지의 지속성을 의미합니다. 또한 메시지 복제는 내구성의 원인 중 하나이므로 메시지가 손실되지 않습니다.
    6. 확장성 – Kafka는 가동 중단없이 확장 할 수 있습니다.

    3. Apache Kafka 아키텍처

    Kafka에는 4 개의 핵심 API가 아래와 같이 있습니다.

    1. 프로듀서 API – 애플리케이션이 하나 이상의 Kafka topic에 레코드 스트림을 게시 / 생산할 수 있도록합니다.
    2. 컨슈머 API – 애플리케이션이 하나 이상의 topic를 구독 / 소비하고 이에 생성 된 레코드 스트림을 처리 할 수 ​​있도록합니다.
    3. Streams API – 애플리케이션이 스트림 프로세서로 작동하도록 허용합니다. 즉, 하나 이상의 topic에서 레코드의 입력 스트림을 소비하고 하나 이상의 주제에 대한 레코드의 출력 스트림을 생성합니다.
    4. 커넥터 API – 기존 데이터 시스템에서 작동하는 애플리케이션을 빌드하고 다른 애플리케이션의 추가를 원활하게 자동화 할 수 있습니다. 예를 들어 기존 데이터베이스에서 데이터를 캡처하여 kafka topic에 기록하거나 그 반대의 경우도 마찬가지입니다.

    kafka architecture

    3.1. Kafka 구성 요소

    안정적인 메시징 서비스를 제공하는 kafka의 핵심 구성 요소를 살펴 보겠습니다.

    kafka topic

    1. Kafka topic(주제)

    topic은 특정 카테고리에 속하는 메시지의 스트림이며 데이터는 topic에 저장됩니다. topic는 파티션으로 나뉩니다. 각 topic에 대해 Kafka는 최소한 하나의 파티션을 유지합니다. 파티션의 각 레코드 / 메시지 순서는 변경할 수 없습니다. 기본적으로 topic은 다중 구독자이며 topic에는 구독 한 소비자가 0 개 또는 여러 개일 수 있으며 데이터가 기록되기를 기다리고 있습니다.

    2. 파티션

    파티션은 순서가 지정된 레코드 시퀀스이며 순서는 변경할 수 없으며 데이터는 기록 된 순서대로 파티션에 추가됩니다. 파티션의 레코드에는 파티션 내의 각 레코드를 고유하게 식별하는 오프셋이라고하는 순차 ID 번호가 각각 할당됩니다.

    3. Producer (생산자)

    Kafka Producer는 메시지 발신자이며 producer는 하나 이상의 Kafka topic에 메시지를 쓸 수 있습니다. producer는 메시지 브로커를 보내고 메시지 브로커는 메시지를 topic의 파티션 중 하나에 간단히 추가합니다. producer는 topic의 특정 파티션에 메시지를 보낼 수도 있습니다.

    4. Consumer (소비자)

    Kafka Consumer는 topic에서 메시지를 소비 / 읽기 위해 하나 이상의 topic를 구독해야합니다.

    Kafka consumer 구독한 특정 topic에 대해서 브로커에서 데이터를 읽습니다.

    5. Broker (브로커)

    브로커는 게시 된 데이터를 유지 관리하는 시스템 그룹입니다. producer와 consumer는 항상 데이터를 게시 / 소비 할 수있는 브로커 목록에 연결됩니다. 각 브로커는 토픽 당 하나 이상의 파티션을 가질 수 있습니다. 예를 들어, 토픽에 X 개의 파티션이 있고 X 개의 브로커가있는 경우 각 브로커는 하나의 파티션을 마스터로, 다른 파티션은 팔로워로 가지며 이러한 파티션은 브로커간에 복제됩니다.

    6. zookeeper

    Kafka는 ZooKeeper를 사용하여 Kafka 브로커 그룹을 관리하고 조정합니다. ZooKeeper 서비스는 주로 kafka 클러스터를 형성하고 유지하는 데 사용됩니다. Zookeeper는 kafka 브로커의 클러스터 관리, 브로커 간 데이터 복제, 소비자가 마지막으로 읽은 / 처리 된 파티션 인덱스 저장에 사용되므로 kafka가 작동하려면 필수입니다. 각 토픽에는 하나 이상의 파티션이있을 수 있으며, Zookeeper는 어떤 파티션이 어느 브로커에서 마스터가 될지 결정합니다 (다른 브로커는 동일한 파티션의 복제본을 가지지만 팔로워 역할을합니다).

    7. Leader

    리더는 토픽의 특정 파티션에 대한 모든 읽기 및 쓰기를 담당하는 kafka 클러스터 내의 노드 (브로커 중 하나)입니다. 브로커 노드는 토픽의 특정 파티션에 대한 리더 또는 팔로워가 될 수 있습니다. 모든 파티션에는 리더 역할을하는 하나의 브로커와 역할을하는 다른 브로커가 팔로 구성됩니다.

    8. Follower

    팔로어는 주어진 토픽 파티션에 대한 리더 지시를 따르는 kafka 클러스터 내의 노드입니다. 팔로어는 데이터를 계속 복제하는 수단입니다. 현재 리더가 실패하면 팔로어 중 하나가 자동으로 새 리더가됩니다. 팔로어는 항상 메시지를 가져오고 자체 데이터 저장소를 업데이트합니다.

    9. consumer group

    각 consumer는 groupID라고하는 고유한 ID를 갖습니다. consumer 그룹은 동일한 consumer 그룹 ID를 가진 consumer 집합입니다. 한 consumer 인스턴스는 읽을 때 한 consumer 그룹의 한 파티션에서 데이터를 읽습니다. 둘 이상의 consumer 그룹이 있기 때문에이 경우 이러한 각 그룹의 한 인스턴스가 하나의 단일 파티션에서 읽을 수 있으므로 consumer 수가 파티션 수를 초과하면 일부 비활성 consumer가 있습니다.

     

    4. 카프카 클러스터

    Kafka 클러스터는 일반적으로 데이터의 안정적인 복제를 달성하는 데 사용되는 여러 브로커 노드로 구성됩니다. Kafka 브로커는 state less 이므로 zookeeper를 사용하여 클러스터 상태를 유지합니다. Zookeeper는 Kafka Broker 및 Topic Partition 쌍의 리더십 선택을 수행하는 데 사용됩니다. Zookeeper는 토폴로지의 변경 사항을 Kafka 브로커에 계속 전파하므로 클러스터의 각 노드는 새 브로커가 가입하고 브로커가 사망하고 topic이 제거되거나 추가 된시기 등을 알 수 있습니다. Kafka를 구성하려면 둘 이상의 브로커가 필요합니다.

    kafka cluster

    5. 사용 사례

    5.1 메시징 시스템

    전통적인 메시징 시스템에는 두가지 모델이 있습니다.

    • 큐잉(queuing} : consumer 그룹은 서버에서 읽을 수 있으며 각 레코드는 정확히 consumer 중 한 명에게 전달됩니다.
    • Publish-Subscribe : 게시된 레코드가 모든 consumer에게 브로드캐스트 됩니다.

    Kafka는 두가지 모델을 결합하여 데이터 소비 방식에 더 많은 유연성을 제공합니다. 이 모델의 장점은 모든 토픽에 이러한 속성이 모두 있으며 처리 및 다중 구독자를 확장 할 수 있다는 것입니다.

    Kafka는 consumer 프로세스 풀을 통해 레코드의 순서 지정 및로드 균형 조정을 모두 제공합니다. 이는 topic의 파티션을 consumer 그룹의 consumer에게 할당하여 각 파티션이 그룹 내에서 정확히 하나의 consumer에 의해 소비되도록 수행됩니다. 이렇게함으로써 kafka는 consumer가 해당 파티션의 유일한 독자임을 보장하고 데이터를 순서대로 소비합니다.

    5.2 스토리지 시스템

    Kafka는 스토리지 시스템으로 사용할 수 있습니다. Kafka 토픽에 생성 된 데이터는 디스크에 기록되고 내결함성을 위해 복제됩니다. 또한 생산자가 승인을 기다릴 수 있으므로 쓰기가 완전히 복제 될 때까지 완료된 것으로 간주되지 않고 서버에 기록이 실패하더라도 지속될 수 있습니다. 따라서 kafka를 사용하면 클라이언트가 읽기 위치를 제어 할 수 있습니다. Kafka를 고성능, 저 지연 커밋 로그 저장, 복제 및 전파 전용의 일종의 특수 목적 분산 파일 시스템으로 생각할 수 있습니다.

    5.3 스트림 처리

    스트림 처리는 입력 주제에서 데이터의 연속 스트림을 가져오고 이 입력에 대해 일부 처리를 수행하고 출력 주제에 대한 연속 데이터 스트림을 생성하는 것과 같습니다. 예를 들어 소매 애플리케이션은 판매 및 배송의 입력 스트림을 받아이 데이터에서 계산 된 재주문 및 가격 조정 스트림을 출력 할 수 있습니다.

    이는 단순히 생산자 및 소비자 API를 사용하여 달성 할 수 있습니다. 그러나 복잡한 데이터 처리를 위해 Kafka는 완전히 통합 된 Streams API를 제공합니다. 이를 통해 사소하지 않은 처리를 수행하거나 스트림을 함께 결합 할 수있는 애플리케이션을 빌드 할 수 있습니다.

    6. 왜 kafka 인가?

    Kafka는 pub-sub 메시징 시스템입니다. 이 기술은 기존 메시지 브로커(RabbitMQ)를 대체하는 높은 처리량, 안정성과 복제를 제공합니다. Kafka는 저장 및 캐싱 목적으로 파일 시스템에 의존하므로 빠릅니다. 데이터 손실을 방지하고 내결함성이 있습니다.

    7. need for Kafka

    Kafka는 모든 실시간 데이터 피드를 처리하기위한 분산 플랫폼입니다. Kafka는 지연 시간이 짧은 메시지 전달을 제공하고 시스템 오류 발생시 내결함성을 보장합니다. 수많은 다양한 consumer를 처리 할 수있는 능력이 있습니다. Kafka의 트랜잭션은 매우 빠르며 초당 2백만 번의 쓰기를 수행합니다. Kafka는 모든 데이터를 디스크에 유지하므로 기본적으로 모든 쓰기가 OS의 페이지 캐시로 이동합니다.

    8. Kafka vs RabbitMQ

    Metric apache Kafka RabbitMQ
    아키텍처 메시징 큐와 pub/sub 방식을 결합하는 파티션 된 로그 모델을 사용 메시징 큐
    메시지 보존 메시지 보존을 지원하며 정책에 의해 제어 될 수 있습니다 (예 : 메시지가 하루 동안 저장 될 수 있음). 사용자는이 보존 기간을 구성 할 수 있습니다. 메시지 보존을 지원하지 않습니다. 이는 확인을 기반으로하며 메시지가 사용되는 즉시 큐에서 삭제됨.
    multiple consumer 큐잉 및 pub-sub 모델을 결합하여 여러 consumer가 동일한 topic을 subscribe 할 수 있으며 각 메시지가 모든 consumer에게 전달됩니다. 큐잉을 기반으로 하므로 메시지가 소비 될 때 제거되므로 여러 consumer가 동일한 메시지를 모두 받을 수 없습니다.
    replication topic이 자동으로 복제되지만 사용자는 topic가 복제되지 않도록 수동으로 구성 할 수 있습니다. 메시지는 자동으로 복제되지 않지만 사용자가 수동으로 복제 할 구성 할 수 있습니다.
    프로세싱 안정적인 로그 분산 처리에서 작동합니다. 또한 Kafka Streams에 내장 된 스트림 처리에 의미가 있습니다. consumer는 단지 FIFO 기반으로 순서대로 읽고 처리합니다.

    9. 결론

    Kafka는 방대한 데이터를 처리하는 많은 애플리케이션의 중추가 되고 있습니다. 따라서 Apache Kafka를 메시지 버스로 사용하여 데이터 producer와 데이터 consumer 간의 높은 수준의 병렬 처리 및 분리를 달성하여 아키텍처를 보다 유연하고 확장 가능하며 변화하는 요구에 맞게 조정할 수 있습니다.


    [원문] - https://the5gzone.com/index.php/apache-kafka-overview/

     

     

     

     

     

    'Cloud' 카테고리의 다른 글

    메시지브로커 vs 이벤트브로커  (1) 2023.01.04
    SRE(Site Reliability Engineering)  (0) 2021.07.06
    • 네이버 블러그 공유하기
    • 네이버 밴드에 공유하기
    • 페이스북 공유하기
    • 카카오스토리 공유하기