KAFKA21 [카프카 프로그래밍] 파티션 개수와 컨슈머 개수의 처리량 파티션과 컨슈머는 통상 1:1.데이터 처리 늘리려면 컨슈머 개수 늘림과 동시에 파티션 개수 늘리면 됨.그러나, 파티션 개수 줄이는 것은 불가능! 따라서 파티션 개수 늘리는 것은 신중하게! 이 포스팅은 모두 인프런의 [아파치 카프카 애플리케이션 프로그래밍] 개념부터 컨슈머, 프로듀서, 커넥트, 스트림즈까지!를 듣고 제가 다시 볼 내용들을 정리한 포스팅입니다. DevOps/Kafka 2024. 6. 27. [카프카 프로그래밍] 토픽과 파티션 토픽토픽은 카프카에서 데이터 구분 위해 사용.토픽은 1개 이상 파티션 소유파티션파티션에서 프로듀서가 보낸 데이터들이 저장되는데 이 데이터들을 레코드라 함.파티션은 결론적으로 큐와 비슷하지만 차이가 있다면 큐는 데이터를 가져가면 삭제하지만 카프카에서는 삭제하지 않는다는 것.그래서 여러 컨슈머 (이를 테면 하둡과 엘라스틱 서치가 있다 치자.) 들이 모두 데이터를 가져갈 수 있음.토픽과 파티션이 배치 되는 방법파티션이 5개인 토픽을 생성했을 때 보통 0번부터 라운드 로빈 방식으로 리더 파티션들이 생성.카프카 클라이언트는 리더 파티션이 있는 브로커와 통신하여 데이터를 주고 받아 특정브로커에 통신이 집중되는 핫스팟 현상을 막고 선형 확장 하여 데이터가 많아져도 자연스럽게 대응.위 같이 특정 브로커에 파티션이 쏠릴.. DevOps/Kafka 2024. 6. 27. [카프카 프로그래밍] 브로커의 역할 1️⃣ 컨트롤러다수 브로커 중 한대가 컨트롤러의 역할을 해서 헬스체크하고 비정상이면 빠르게 클러스터에서 빼내기.2️⃣ 컨슈머 오프셋 저장어느 레코드까지 가져갔는지 확인하려고 오프셋 커밋. _consumer_offsets 토픽에 저장이건 언제보냐? 장애 났을 때 어디까지 토픽 저장됐는 지 확인할 때 본다.3️⃣ 그룹 코디네이터파티션을 컨슈머와 매칭되도록 분배.컨슈머가 보통 1:1 처리 중인데 만약 컨슈머가 장애나서 빠지면 파티션을 정상 컨슈머로 할당해서 한 컨슈머가 여러 파티션 처리하게 우선 리밸런스함.4️⃣ 데이터의 저장카프카를 실행할 때 config/server.properties의 log.dir 옵션에 정의한 디렉토리에 데이터를 저장하는데 토픽 이름과 파티션 번호의 조합으로 하위 디렉토리를 생성하여 .. DevOps/Kafka 2024. 6. 23. [카프카 프로그래밍] 카프카 생태계와 브로커, 주키퍼 카프카 생태계카프카 프로듀서가 기본적으로 데이터를 넣고, 컨슈머가 데이터를 가져간다.stateful/stateless하게 다시 토픽을 처리해서 넣고 싶을 때는 스트림즈.데이터베이스에서 가져와서 토픽에 데이터를 넣는 역할은 커넥트(소스) 다시 가져가는 애가 커넥트(싱크).그럼 그냥 프로듀서, 컨슈머랑 같은거 아니야? 🙅 프로듀서 컨슈머와의 차이는 템플릿으로 반복적으로 만들 수 있다는 거다. (rest api)프로듀서, 커넥트, 컨슈머, 스트림즈는 모두 java library로 제공되며, go나 js는 써드 파티라 모든 기능이 제공된다고 볼 수 없다는 점 유의.브로커는 뭐해?브로커0, 1, 2에 모두 데이터를 저장해서 브로커0이 죽더라도 컨슈머가 브로커1, 브로커2에서 가져갈 수 있게 분산 저장해.주키퍼는.. DevOps/Kafka 2024. 6. 22. [카프카 프로그래밍] 아파치 카프카가 데이터 파이프라인으로 적합한 4가지 이유 높은 처리량 (처리량 더 늘리려면 컨슈머를 늘린다. 이러려면 물론 파티션(브로커)을 동일한 개수만큼 더 늘려야.)확장성 (하루에 처리량이 예상치 못하게 가변적일 때 브로커 개수를 스케일 인, 아웃하여 유동적으로 운영 가능.)영속성 (데이터를 생성한 프로그램이 종료되더라도 사라지지 않는다는 특징. 다른 메시징 플랫폼과 다르게 메모리가 아닌 파일 시스템에 저장하기 때문. 빠른 이유는 한 번 읽은 내용을 메모리에 저장했다가 다시 사용하는 방식이라 처리량이 높은 것. 따라서 급작스럽게 종료돼도 재시작하여 처리하면 됨.)고가용성 (한 브로커에 장애가 발생하더라도 복제된 데이터가 나머지 브로커에 저장되어 있어 지속적 데이터 처리 가능) DevOps/Kafka 2024. 6. 16. [카프카 프로그래밍] 아파치 카프카의 탄생과 기본 구조 Kafka의 탄생 배경why? 링크드인에서 소스 어플리케이션과 타깃 어플리케이션 개수가 점점 많아지면서 데이터 전송 라인이 복잡해지는 문제를 해결하기 위해과거 구성도여러 방법을 시도해 보았으나 더 복잡해짐현재 구성도 (카프카)Unified Log라는 중앙 로그를 두어 중앙 집중화 하여 개발자 입장에서도 이전에는 데이터 스토어 백엔드 관리와 백엔드에 따른 포맷, 별도의 앱 개발을 히야 했는데 이젠 카프카에만 데이터를 전달하면 나머지는 필요한 곳 또는 다른 서비스들이 각자 가져갈 수 있어서 자신들 본연의 업무에만 집중할 수 있게 되었다.메시지 큐 구조를 살린 카프카 내부 구조프로듀서가 보낸 데이터 (메시지, 토픽) 는 특정 하나의 파티션에 적재되고, 차례대로 컨슈머는 파티션에서 가져간다 (FIFO)전체적으로.. DevOps/Kafka 2024. 6. 16. 이전 1 2 다음
