ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • kafka란?,Zookeeper
    웹서버/kafka 2024. 4. 25. 18:17
    728x90
    반응형

     

     

     

    1. Kafka는 무엇이며, 등장배경 

    kafka가 등장하기전 대부분 데이터 etl(추출,변환,로드) 에 작업들은 배치 워크프로세스로 진행되는 경우가 많았습니다.

    kafka는 위와같은 작업을 실시간 데이터 피드 방식으로 진행하는 서버입니다.

    카프카(Kafka)파이프라인, 스트리밍 분석, 데이터 통합 및 미션 크리티컬 애플리케이션을 위해 설계된 고성능 분산 이벤트 스트리밍 플랫폼이다.

     

    1.1 등장 배경

    기존 어플리케이션에서 사용자에 대한 상태데이터가 존재하고 해당 데이터를 통해 분석을 하기위해 메트릭 서버가 존재한다고 가정하자. 해당 메트릭서버는 프론트서버에서 사용자 상태데이터를 받고 데이터를 저장한다. 그렇다면 위 같이 간단한 구조가 완성된다.

     

     

     

    하지만 시간이 흘러 서비스는 점점 확장되고 , 여러가지 기능 메트릭 분석, 활동 상태모니터링 , DB 모니터링등 서비스들이 많아 질경우 위와같은 구조로 많은 서버들과 얽히고 설키며 복잡한 모양새를 보여준다.

    이를 해결하기 위해 중앙에서 데이터를 전달받고 해당 데이터가 필요한곳으로 뿌려주는 게시/구독( Publish/Subscribe ) 형식에 모델이 나타났다.

     

    하지만 이역시도 시간에 지남에 따라 로깅,추적 등에 추가적인 게시/구독( Publish/Subscribe ) 형식이 계속 추가되면서 복잡성이 나타나며 ,여러 시스템을 유지 관리하고 있어 모든 시스템에는 고유한 버그와 제한 사항이 있다. 

     

    그래서 이 문제를 해결하기 위해  kafka 즉,  게시/구독 메시징 시스템입니다. 종종 "분산 커밋 로그"로 설명되거나 최근에는 "분산 스트리밍 플랫폼"으로 설명됩니다. 파일 시스템 또는 데이터베이스 커밋 로그는 모든 트랜잭션에 대한 내구성 있는 기록을 제공하도록 설계되어 시스템의 상태를 지속적으로 구축하기 위해 재연할 수 있습니다. 마찬가지로 Kafka 내의 데이터는 내구성 있고 순서대로 저장되며 결정론적으로 읽을 수 있습니다. 또한 데이터를 시스템 내에 배포하여 장애에 대한 추가 보호 기능을 제공할 뿐만 아니라 성능 확장을 위한 중요한 기회를 제공할 수 있습니다

     

    1.2 카프카 상세

    Kafka 내의 데이터 단위를 메시지라고 합니다. 데이터베이스 배경에서 Kafka에 접근하는 경우 이를 행 또는 레코드와 유사하다고 생각할 수 있습니다. 하지만  메시지는 단순히 바이트 배열이므로 메시지에 포함된 데이터는 Kafka에게 특정 형식이나 의미를 갖지 않습니다. 메시지에는 키라고 하는 선택적 메타데이터 비트가 있을 수 있습니다. 키도 바이트 배열이며 메시지와 마찬가지로 Kafka에게 특별한 의미가 없습니다. 키는 메시지가 보다 제어된 방식으로 파티션에 기록될 때 사용됩니다. 가장 간단한 스키마는 키의 일관된 해시를 생성한 다음 해시 모듈로의 결과(항목의 총 파티션 수)를 사용하여 해당 메시지의 파티션 번호를 선택하는 것입니다. 이렇게 하면 동일한 키를 가진 메시지가 항상 동일한 파티션에 기록됩니다. 

     

    메시지는 Kafka 자체에 대한 바이트 배열이지만 쉽게 이해할 수 있도록 메시지 내용에 추가 구조 또는 스키마를 적용할수있습니다. 메시지 스키마에 사용할 수 있는 옵션은 응용 프로그램의 개별 요구 사항에 따라 다양합니다. JSON(Javascript Object Notation) 및 XML(Extensible Markup Language)과 같은 단순한 시스템은 사용하기 쉽고 사람이 읽을 수 있습니다

     

    1-3 kafka 토픽

    토픽은 데이터베이스 테이블 , 파일시스템에 폴더로 생각하면 된다.

    4개의 파티션이 있는 토픽을 보여주며, 각 파티션의 끝에 쓰기가 추가됩니다. 파티션은 Kafka가 중복성과 확장성을 제공하는 방법이기도 합니다. 각 파티션은 서로 다른 서버에서 호스팅될 수 있으며, 이는 단일 토픽을 여러 서버에 걸쳐 수평으로 확장하여 단일 서버의 기능을 훨씬 능가하는 성능을 제공할 수 있음을 의미합니다.

     

    구독자는 토픽에서 메세지가 생성된 순서대로 데이터를 읽습니다.

     

     

    1-4 broker

     

    Kafka 브로커는 클러스터의 일부로 작동하도록 설계되었습니다. 브로커 클러스터 내에서 하나의 브로커는 클러스터 컨트롤러(클러스터의 라이브 멤버에서 자동으로 선택됨)로도 작동합니다. 컨트롤러는 브로커에 파티션을 할당하고 브로커 오류를 모니터링하는 등의 관리 작업을 담당합니다. 파티션은 클러스터의 단일 브로커가 소유하며 해당 브로커를 파티션의 리더라고 합니다.

     

    파티션이 여러 브로커에 할당될 수 있으며, 이로 인해 파티션이 복제됩니다. 이렇게 하면 파티션에 있는 메시지의 중복성이 제공되므로 브로커 오류가 발생할 경우 다른 브로커가 리더십을 인계받을 수 있습니다. 

     

    Apache Kafka의 주요 기능은 일정 기간 동안 메시지를 영구적으로 저장보존 하는것입니다. Kafka 브로커는 특정 기간(예: 7일) 동안 또는 토픽이 특정 크기(바이트)(예: 1GB)에 도달할 때까지 메시지를 보존하고 토픽에 대한 기본 제한 설정으로 구성됩니다. 이러한 제한에 도달하면 메시지가 만료되고 삭제되므로 보존 구성은 언제든지 사용할 수 있는 최소 데이터 양이 됩니다.

    2. Zookeeper

    Kafka 클러스터에 대한 메타데이터와 소비자 클라이언트 세부 정보를 저장합니다.

     

     

    Kafka 없이 데이터를 처리할 때의 복잡성

    • 서버 간 직접 연결: 여러 서버가 서로 다른 데이터를 교환하거나 서로 필요한 데이터를 받아오기 위해 서버 간 직접적인 연결을 설정해야 합니다. 예를 들어, 서버 A에서 생성된 데이터를 서버 B, C, D가 각각 받으려면, 각 서버 간에 개별적으로 데이터를 주고받는 코드를 작성해야 합니다.
    • 다양한 프로토콜: 각 서버가 데이터를 다르게 처리하거나, 사용하는 통신 프로토콜이나 데이터 포맷이 다를 경우, 데이터 변환과 통신을 위한 코드가 더 복잡해질 수 있습니다.
    • 실시간 데이터 처리의 어려움: 데이터를 실시간으로 여러 곳에서 동시에 처리하려면, 각각의 서버 간 데이터 동기화를 관리해야 하며, 이 역시 복잡한 문제로 이어집니다.

    이렇게 여러 서버 간에 직접 데이터를 주고받는 방식은 시스템이 커질수록 복잡해지고, 유지보수가 어려워지며, 확장성에도 한계가 생깁니다.

    Kafka를 사용할 때의 단순화된 구조

    Kafka는 중앙 허브 역할을 합니다. 데이터를 필요로 하는 서버들이 모두 Kafka를 통해 데이터를 주고받기 때문에 복잡성이 크게 줄어듭니다.

    • 중앙 집중화: Kafka를 이용하면, Producer(데이터를 생성하는 서버)는 Kafka에 데이터를 보내기만 하면 되고, Consumer(데이터를 소비하는 서버)는 Kafka에서 데이터를 구독해서 가져가기만 하면 됩니다. 모든 서버가 Kafka와만 소통하므로, 서로 간의 직접적인 연결이 필요 없습니다.
    • 확장성: 각 서버는 자신이 필요로 하는 Topic만 구독하면 되므로, 새로운 기능이 추가되거나 다른 시스템이 데이터를 필요로 할 때도 Kafka에 연결하기만 하면 됩니다. 이 방식은 매우 유연하고 확장 가능합니다.
    • 다양한 처리 방식: Kafka를 통해 데이터를 여러 Consumer가 동시에 구독할 수 있으므로, 하나의 데이터를 여러 서버가 동시에 받아서 각각 다른 방식으로 처리할 수 있습니다. 예를 들어, 한 Consumer는 실시간 데이터 분석을 하고, 다른 Consumer는 데이터를 저장하거나 백업하는 작업을 할 수 있습니다.

    예시로 비교해보자면:

    Kafka를 사용하지 않을 때:

    서버 A에서 데이터를 생성하고 서버 B, C, D가 그 데이터를 필요로 한다고 가정해봅시다. 이 경우 서버 A는 각 서버 B, C, D에 데이터를 직접 전송해야 합니다. 이렇게 되면 서버 A는 데이터를 전송하는 로직을 세 번 따로 작성해야 하고, 각 서버가 데이터 수신을 위한 별도의 코드도 필요합니다.

    Kafka를 사용할 때:

    서버 A는 Kafka에 데이터를 보내고, 서버 B, C, D는 Kafka에서 필요한 데이터를 구독하기만 하면 됩니다. 서버 A는 데이터를 한 번만 전송하면 되고, 서버 B, C, D는 Kafka와만 연결되면 됩니다. 이 구조는 매우 단순하고 효율적입니다.

    따라서 Kafka를 도입하면 서버 간 데이터 송수신 구조가 단순화되고, 유지보수와 확장성이 훨씬 수월해집니다.

    728x90
    반응형
Designed by Tistory.