실전 카프카 개발부터 운영까지

1\. 도입배경회사의 규모가 커지며 다양한 데이터 요구사항을 근본적으로 해결하기 위해 이벤트 드리븐 시스템으로의 전환 결정.2\. 동기 방식의 문제점1) 모든 데이터 변경에 대한 올바른 전달 보장 문제2) 동일한 데이터를 동시에 수정하면서 순서를 보장 해야하는 문제,

성능비교카프카는 매우 높은 처리량과 낮은 지연시간을 자랑한다위 표에서 볼 수있듯이 카프카가 처리량이 제일 높고, Rabbit MQ가 응답속도가 제일 빠르다처리량과 응답속도를 같이 비교하였을 때 카프카가 독보적으로 성능이 좋다카프카는 확장 가능하도록 초기부터 설계되었다손

카프카 환경 구성 이 책의 실습 환경 구성 > 실제 운영 환경에서는 서비스의 안정성이 최우선이므로 단독 서버 형태로 운영하는 경우는 없고, 대부분 이중화 또는 클러스터 형태로 구성한다. 주키퍼의 경우 최소 수량인 EC2 인스턴스 3대로 구성 카프카의 경우도 최소 수

메세지들을 여러 개로 복제해서 카프카 클러스터내 브로커들에게 분산시키는 동작을 의미리플리케이션으로 인해 하나의 브로커가 종료되더라도 카프카는 안정성을 유지할 수 있다.토픽생성시 --replication-factor 옵션은 카프카 내 리플리케이션 유지 개수를 의미한다.

네트워크상에서 연결된 컴퓨터들의 그룹높은 성능장애 대응 탁월시스템 확장 용이카프카도 분산 시스템이다최초 구성한 클러스터의 리소스가 한계치에 도달해 더 높은 메세지 처리량이 필요한 경우, 브로커를 추가하는 방식으로 확장이 가능하다브로커는 온라인 상태에서 매우 간단하게 추

ProducerRecord라고 표시된 부분은 카프카로 전송하기 위한 실제 데이터이다레코드는 토픽, 파티션, 키, 벨류로 구성된다레코드의 토픽과 벨류는 필수값이다특정 파티션을 지정하기 위한 레코드의 파티션과 특정 파티션에 레코드들을 정렬하기 위한 레코드의 키는 필수값이

컨슈머는 카프카의 토픽에 저장되어 있는 메세지를 가져오는 역할을 담당한다프로듀서가 토픽으로 메세지를 전송하면 메세지들은 브로커들의 로컬 디스크에 저장된다컨슈머를 이용해 토픽에 저장된 메세지를 가져올 수 있다컨슈머 그룹은 하나 이상의 컨슈머들이 모여있는 그룹을 의미한다컨

고용성 분산 스트리밍 플랫폼인 카프카는 무수히 많은 데이터 파이프라인의 정중앙에 위치하는 메인 허브 역할을 한다카프카는 초기 설계 단계에서부터 일적인 하드웨어 이슈 등으로 브로커 한두 대에서 장애가 발생하더라도 중앙 데이터 허브 로서 안정적인 서비스가 운영될 수 있도록

토픽은 chaptor4-topic03이고, 파티션 수는 1, 리플리케이션 팩터 수는 2로 진행한다1\. 토픽을 생성한다2\. 토픽 상세보기를 통해 리더를 확인한다3\. kafka2 에서 토픽 생성했음에도 리플리케이션은 1,3에서 되는 마법 퉷4\. cat 을 사용해 리

컨트롤러는 리더 선출을 담당한다카프카 클러스터 중 하나의 브로커가 컨트롤러 역할을 한다파티션의 ISR 리스트 중에서 리더를 선출한다리더를 선출하기 위한 ISR 리스트 정보는 안전한 저장소에 보관되어 있어야 하는데, 가용성 보장을 위해 주키퍼에 저장되어있다컨트롤러는 브로

카프카의 토픽으로 들어오는 메세지는 세그먼트라는 파일에 저장된다메세지는 정해진 형식에 맞추어 순차적으로 로그 세그먼트 파일에 저장된다로그 세그먼트는 메세지 내용뿐만 아니라 메세지의 키, 벨류, 오프셋, 메세지 크기 같은 정보도 함께 저장된다로그 세그먼트 파일들은 브로커

프로듀서의 기본 역할은 소스의 메세지들을 카프카 토픽으로 전송하는 것이다.전송하려는 메세지들은 프로듀서의 send() 메소드를 통해 시리얼라이저, 파티셔너를 거쳐 카프카로 전송된다.카프카의 토픽은 성능향상을 위해 벙렬처리가 가능하도록 파티션으로 나눠 처리한다카프카로 전