GW LABS

6.1 컨슈머 오프셋 관리 컨슈머 동작 중 가장 핵심은 오프셋 관리 __consumer_offsets 토픽에 각 컨슈머 그룹별로 오프셋 위치 정보가 기록 __consumer_offsets은 다음에 읽어야 할 메시지의 오프셋을 기록된다. 6.2 그룹 코디네이터 리밸런싱: 컨슈머 그룹에서 각 컨슈머들에게 작업을 균등하게 분해하는 동작 그룹 코디네이터: 안정적인 컨슈머 그룹 관리를 위한 별도의 코디네이터 heartbeat.interval.ms: 그룹 코디네이터와 하트비트 인터벌 시간 session.timeout.ms: 컨슈머가 특정 시간 안에 하트비트를 받지 못하면 문제가 발생했다고 판단해 컨슈머 그룹에서 해당 컨슈머는 제거되고 리밸런싱 동작 max.poll.interval.ms: 컨슈머는 주기적으로 poll..

5.1 파티셔너 토픽은 성능 향상을 위한 병렬 처리가 가능하도록 파티션으로 나뉘고, 최소 하나 이상의 파티션으루 구성 메시지는 토픽 내 파티션 로그 세그먼트에 저장 토픽의 어느 파티션에 메시지를 저장할지 결정하는 것이 파티셔너 메시지의 키를 해싱하여 처리 트래픽이 많아질 경우 파티션을 늘릴 수 있는데, 이 경우 해시 테이블이 변경되기 때문에 동일 파티션이 아닌 다른 파티션으로 메시지가 전송 될 수 있음 되도록이면 파티션 수를 변경하지 않는 것이 좋음 5.1.1 라운드 로빈 전략 키값을 지정하지 않고 메시지가 전송되면 라운드 로빈 방식으로 레코드 전송 배치 전송 옵션을 사용할 경우 라운드 로빈 옵션은 지연시간과 압축 비효율을 발생시킬 수 있음 5.1.2 스티키 파티셔닝 전략 하나의 파티션에 리코드 수를 먼..

4.1.1 리플리케이션 동작 개요 토픽 생성시 replication factor 옵션으로 리플리케이션 수를 조정 토픽을 구성하고 있는 파티션이 리플리케이션 된다. 4.1.2 리더와 팔로워 리더: 모든 읽기와 쓰기는 리더를 통해서만 가능 팔로워: 새로운 리더가 될 준비를 하고 있으며 리더로 부터 새로운 메시지를 복제함 4.1.3 복제 유지와 커밋 리더와 팔로워는 ISR(InSyncReplica)라는 논리적 그룹으로 묶여 있음 리더는 ISR내 팔로워가 메시지를 모두 받을 때까지 대기 팔로워가 메시지를 수신하면서 장애가 났는지 지속적으로 감시 리더가 팔로워 리플리케이션 동작에 문제가 있다고 판단하면 추방함 커밋 오프셋은 replication-offset-checkpoint라는 파일에 저장 4.1.4 리더와 팔..

카프카 아키텍처 3.1.1 리플리케이션 각 메시지들을 여러 개로 복제해서 카프카 클러스터 내 브로커들에 분산시키는 동작 topic의 replication-factor 옵션으로 브로커에 분산할 수 있음 리플리케이션 기준 테스트/개발환경: 리플리케이션 펙터 수를 1로 설정 운영 환경(로그성 메시지로서 약간의 유실 허용): 리플리케이션 팩터 수를 2로 설정 운영 환경(유실 허용하지 않음): 리플리케이션 팩터 수를 3으로 설정 3.1.2 파티션 토픽의 처리량을 높이기 위해 병렬 처리가 가능하게 만든 것을 의미 파티션의 수만큼 컨슈머를 연결할 수 있음 파티션은 늘리는 것은 가능하지만 줄일 수는 없다! 2~4로 설정 후 LAG 등의 지표를 통해 늘려나가는 것이 좋다 3.1.3 세그먼트 파티션 안에 N개의 세그먼트로..

1.1 잘란도와 트위터의 카프카 도입 사례 잘란도가 느낀 카프카의 장점 빠른 데이터 수집이 가능한 높은 처리량 순서 보장 적어도 한 번 전송 방식 자연스러운 백프레셔 핸들링 강력한 파티셔닝 트위터가 느낀 카프카의 장점 비용 절감 효과 강력한 커뮤니티 1.3 카프카의 주요 특징 높은 처리량과 낮은 지연시간 높은 확장성 고가용성 내구성 개발 편의성 운영 및 관리 편의성 1.5 다양한 카프카의 사용 사례 데이터 파이프라인: 넷플릭스 사례 데이터 통합: 우버 사례