아파치 카프카 애플리케이션 프로그래밍 with 자바

링크드인에서 만들었다. 링크드인은 아래와 같은 문제점을 겪었다.데이터를 생성하는 소스 애플리케이션과 데이터가 최종 적재되는 타킷 애플리케이션이 1:1 단방향 통신으로 연결되어 있었다. 아키텍처가 거대해지면서 소스 애플리케이션과 타킷 애플리케이션의 수가 많아지면서 데이터

이 장에서는 카프카를 실습해보면서 카프카의 동작을 이해해보았다. 각 단계별로 실습을 정리했다.AWS의 EC2 1대로 카프카 클러스터를 구성했다. EC2 인스턴스를 생성한다. 인스턴스 생성을 완료하고 나면 인스턴스에 아래의 명령으로 자바를설치한다.위의 링크로 카프카 바이

카프카 브로커는 카프카 클라이언트와 데이터를 주고받기 위해 사용하는 주체이자, 데이터를 분산 저장하여 장애가 발생하더라도 안전하게 사용할 수 있도록 도와주는 애플리케이션이다. 데이터를 안전하게 보관하고 처리하기 위해 보통 3대 이상의 브로커 서버를 1개의 클러스터로 묶

토픽은 카프카에서 데이터를 구분하기 위해 사용하는 단위이다. 토픽은 1개 이상의 파티션을 소유하고 있다. 파티션에는 프로듀서가 보낸 데이터들이 들어가 저장되는데 이 데이터를 '레코드(record)라 부른다.파티션은 카프카의 병렬처리의 핵심으로써 그룹으로 묶인 컨슈머들이

레코드는 타임스탬프, 메시지 키, 메시지 값, 오프셋, 헤더로 구성되어 있다. 프로듀서가 생성한 레코드가 브로커로 전송되면 오프셋과 타임스탬프가 지정되어 저장된다. 브로커에 한번 적재된 레코드는 수정할 수 없고 로그 리텐션 기간 또는 용량에 따라서만 삭제된다. 각 구성

토픽은 카프카의 시작과 끝이다. 그만큼 토픽은 카프카에서 중요한 역할을 한다. 그러므로 토픽을 사용함에 있어 발생하는 여러 가지 운영상 고려사항을 알아본다.토픽의 파티션 개수는 카프카의 성능과 관련이 있다. 그렇기 때문에 토픽을 운영함에 있어 적절한 파티션 개수를 설정

프로듀서는 카프카에 데이터를 저장하는 첫 단계이다.카프카의 acks 옵션은 0, 1, all(또는 -1)값을 가질 수 있다. 이 옵션을 통해 프로듀서가 전송한 데이터가 카프카 클러스터에 얼마나 신뢰성 높게 저장할지 지정할 수 있다. acks 옵션에 따라 성능이 달라질

컨슈머는 카프카에 적재된 데이터를 처리한다.카프카는 처리량을 늘리기 위해 파티션과 컨슈머 개수를 늘려서 운영할 수 있다. 파티션을 여러 개로 운영하는 경우 데이터를 병렬처리하기 위해서 파티션 개수와 컨슈머 개수를 동일하게 맞추는 것이 중요하다. 파티션 개수가 n개라면