[Tistory] Kafka 전체 흐름 이해하기

원글 페이지 : 바로가기

Kafka Kafka는 링크드인에서 개발한 분산형 이벤트 스트리밍 플랫폼 데이터 파이프라인을 단순화하기 위해 만들어졌고 현재는 아파치 재단에서 관리 이벤트 스트리밍 이벤트 스트리밍은 데이터베이스, 센서, 모바일, 클라우드 서비스, 소프트웨어 애플리케이션과 같은 이벤스 소스에서 실시간으로 데이터를 캡처하고, 나중에 검색할 수 있도록 내구성있게 저장하고, 이러한 데이터들을 처리하여 다양한 대상 기술로 라우팅하는 방식 어디에 사용될까? 은행, 증권 거래소와 같은 곳에서 금융, 결제 데이터 실시간 처리 회사의 여러 부서에서 생산된 데이터를 연결, 저장 및 사용할 때 데이터 플랫폼, 이벤트 중심의 아키텍처, 마이크로 서비스의 기반 역할 Kafka 전체 구조 크게 보면 프로듀서와 컨슈머, 그리고 중간에서 연결해주는 카프카 클러스터로 구성 프로듀서가 어떠한 이벤트를 발행하면 카프카 클러스터에서 해당 이벤트를 처리하여 저장하고 컨슈머는 해당 이벤트를 소비 데이터를 직접 주고받을 경우 특정 개체에서 장애가 발생하면 장애가 전파될 가능성이 있고, 시스템이 커질수록 확장에 어려움이 있음 Pub/Sub 모델 기반의 비동기 전송 방식으로 데이터의 발신/수신이 따로 처리되고 원하는 데이터만 전달받을 수 있으며, 높은 확장성 확보 Kafka 클러스터 브로커(Broker) 카프카 클라이언트(Producer, Consumer)와 데이터를 주고받는 주체 데이터 저장, 삭제는 오직 브로커를 통해서만 가능 컨슈머가 데이터를 어디까지 가져갔는지 확인하기 위한 오프셋을 관리 컨트롤러(Controller) 다른 브로커들의 상태를 체크하고 장애가 발생한 브로커를 클러스터에서 제외 리더 파티션을 재분배 주키퍼 모드에선 브로커 중 하나가 담당하고, KRaft 모드에서는 다수의 컨트롤러 설정 가능 주키퍼와 KRaft 주키퍼(Zookeeper) 카프카 클러스터를 관리하는 분산 코디네이션 서비스 클러스터 내의 변경 사항을 알림 ex) 브로커 추가/제거, 토픽 설정 정보 클러스터의 리더(컨트롤러) 선출 및 클러스터 전체 동기화하여 데이터 불일치 방지 주키퍼 역시 안정성을 위해 주키퍼 앙상블이라고 하는 클러스터를 구성 KRaft(Kafka Raft) Kafka 2.8 버전부터 도입된 쿼럼(Quorum) 기반의 프로토콜로 동작하는 기능 주키퍼 의존성을 제거하여 운영 복잡성 단순화 및 성능 개선 주키퍼 없이 내부적으로 리더 선출, 메타 데이터 관리* 토픽과 파티션 토픽 데이터를 구분하기 위해 사용되는 단위 프로듀서가 전송한 데이터(레코드)를 해당 토픽에 저장 토픽은 1개 이상의 파티션에 나누어 데이터를 저장 컨슈머는 원하는 토픽의 데이터만 골라 가져갈 수 있음* 파티션 토픽 내에서 데이터를 분리하여 저장하기 위한 공간 파티션 수만큼 분산되어 저장되기 때문에 순서가 보장되지 않음 파티션 내에서 저장되는 데이터는 큐 형식(FIFO)으로 저장되기 때문에 순서 보장 파티션과 컨슈머와 컨슈머는 각각 따로 매칭 파티션이 더 많을 경우 하나의 컨슈머에 여러 파티션 매칭 컨슈머가 더 많을 경우 노는 컨슈머가 생김* Reference https://kafka.apache.org/ https://velog.io/@juhyeon1114/Kafka-%EA%B0%9C%EB%85%90-%EC%A0%95%EB%A6%AC-w.-%EB%B8%8C%EB%A1%9C%EC%BB%A4-%EC%A3%BC%ED%82%A4%ED%8D%BC-%ED%86%A0%ED%94%BD-%ED%8C%8C%ED%8B%B0%EC%85%98-%EB%A0%88%EC%BD%94%EB%93%9C

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다