실전 카프카 개발부터 운영까지 (3) - 카프카 기본 개념과 구조

카프카 아키텍처

카프카 아키텍처

 

3.1.1 리플리케이션

• 각 메시지들을 여러 개로 복제해서 카프카 클러스터 내 브로커들에 분산시키는 동작
  • topic의 replication-factor 옵션으로 브로커에 분산할 수 있음
• 리플리케이션 기준
  • 테스트/개발환경: 리플리케이션 펙터 수를 1로 설정
  • 운영 환경(로그성 메시지로서 약간의 유실 허용): 리플리케이션 팩터 수를 2로 설정
  • 운영 환경(유실 허용하지 않음): 리플리케이션 팩터 수를 3으로 설정

 

3.1.2 파티션

• 토픽의 처리량을 높이기 위해 병렬 처리가 가능하게 만든 것을 의미
• 파티션의 수만큼 컨슈머를 연결할 수 있음
• 파티션은 늘리는 것은 가능하지만 줄일 수는 없다!
• 2~4로 설정 후 LAG 등의 지표를 통해 늘려나가는 것이 좋다

 

3.1.3 세그먼트

• 파티션 안에 N개의 세그먼트로 메시지가 저장 된다.

 

3.2.1 분산 시스템

• 높은 처리량과 가용성을 보장
• 브로커를 추가하는 방식으로 확장이 용이

 

3.2.2 페이지 캐시

• 카프카는 OS의 페이지 캐시를 활용하는 방식으로 설계되어 있음
• 직접 디스크 I/O를 하지 않고 물리 메모리 중 애플리케이션이 사용하지 않는 일부 잔여 메모리를 활용

 

3.2.3 배치 전송 처리

• 네트워크 오버헤드를 줄이고 처리속도를 증가시키는 배치 전송을 지원

 

3.2.4 압축 전송

• 메시지 전송 시에 압축 기능을 제공하고 있음
  • gzip, snappy, lz4, zstd 등의 타입을 지원
  • 높은 압축률: gzip, zstd
  • 빠른 응답 속도: lz4, snappy

 

3.2.5 토픽, 파티션, 오프셋

• 토픽 > 파티션 > 오프셋
  • 파티션의 메시지가 저장되는 위치를 오프셋이라고 부름
  • 오프셋은 순차적으로 증가하는 숫자(64비트 정수)

 

3.2.6 고가용성 보장

• 노드 장애 대응 외의 리플리케이션 기능을 제공
• 리플리케이션 기능은 토픽을 복제하는 것이 아닌 파티션을 복제

 

3.3.1 프로듀서 디자인

• 레코드: 토픽, 파티션, 키, 밸류로 구성
• 파티셔너: 레코드에 파티션이 지정되지 않았다면 키를 가지고 파티션을 선택하는 로직 수행
• 프로듀서는 send() 메소드 동작 이후 레코드들을 파티션별로 모았다가 배치전송을 수행

 

3.3.2 프로듀서의 주요 옵션

• bootstrap.servers: 클라이언트가 카프카 클러스터에 처음 연결하기 위한 호스트와 포트 정보
• client.dns.lookup: 클라이언트가 연결 실패시 다른 IP로 시도하는 설정
• acks: 프로듀서가 카프카 토픽의 리더 측에 메시지를 전송한 후 요청을 완료하기를 결정하는 옵션
  • 0: 빠른 전송을 의미하지만, 일부 메시지 손실 가능성
  • 1: 리더가 메시지를 받았는지 확인하지만, 모든 팔로워를 확인하지 않음
  • all(-1): 팔로워도 메시지를 받았는지 체크
• buffer.memory: 프로듀서가 카프카 서버로 데이터를 보내기 위해 잠시 대기할 수 있는 전체 메모리 바이트
• compression.type: 프로듀서가 메시지 전송 시 선택할 수 있는 압축 타입. none, gzip, snappy, lz4, zstd
• enable.idempotence: 멱등성 옵션. 중복없는 전송이 가능하다.
  • max.in.flight.requests.per.connection은 5이하, retries는 0 이상, aks는 all로 설정해야 함
• max.in.flight.requests.per.connection: 하나의 커넥션에서 프로듀서가 최대한 ACK 없이 전송할 수 있는 요청 수. 메시지의 순서가 중요하다면 1로 설정하는 것이 좋음
• retries: 일시적인 오류로 인해 전송에 실패한 데이터를 다시 보내는 횟수
• batch.size: 배치 전송시 사이즈
• linger.ms: 배치 형태의 메시지를 보내기 전 추가적인 메시지를 기다리는 시간
• transactional.id: ‘정확히 한 번 전송’을 위해 사용하는 옵션. enable.idempotence를 true로 설정해야 함

 

3.3.3 프로듀서 예제

• 결과확인 하지 않는 방식
• 동기 방식
  • Future 타입으로 받아온 레코드 메타 데이터의 결과를 기다리는 방식으로 구현
• 비동기 방식
  • 콜백을 구현하여 레코드 전송시에 콜백을 함께 보냄

 

3.4.1 컨슈머의 기본 동작

• 컨슈머 그룹: 하나 이상의 컨슈머가 속한 그룹
  • 각 파티션의 리더에게 카프카 토픽에 저장된 메시지를 가져오기 위한 요청전송
  • 파티션 수와 컨슈머 수는 일대일로 매핑되는 것이 이상적

 

3.4.2 컨슈머의 주요 옵션

• bootstrap.servers: 브로커의 정보 입력
• fetch.min.bytes: 한 번에 가져올 수 있는 최소 데이터 크기. 만약 지정한 크기보다 작은 경우, 요청에 응답하지 않고 데이터가 누적될 때까지 기다린다.
• group.id: 컨슈머가 속한 컨슈머 그룹을 식별하는 식별자.
• heartbeat.interval.ms: 컨슈머 상태체크를 위한 하트비트 인터벌. session.timeout.ms보다 낮은 값으로 설정해야 하며 일반적으로 1/3으로 설정
• max.partition.fetch.bytes: 파티션당 가져올 수 있는 최대 크기
• session.timeout.ms: 컨슈머가 종료된 것인지 판단하는 지표. 만약 종료되었다고 판단되면 컨슈머 그룹에서 제외하고 리밸런싱을 시작
• enable.auto.commit: 백그라운드로 주기적으로 오프셋을 커밋
• auto.offset.reset: 카프카에서 초기 오프셋이 없거나 현재 오프셋이 더 이상 존재하지 않는 경우에 다음 옵션들로 reset
  • earliest: 가장 초기의 오프셋값으로 설정
  • latest: 가장 마지막의 오프셋값으로 설정
  • none: 이전 오프셋값을 찾지 못하면 에러
• fetch.max.bytes: 한 번의 가져오기 요청으로 가져올 수 있는 최대 크기
• group.instance.id: 컨슈머의 고유한 식별자. 설정된다면 static 멤버로 간주되어 불필요한 리밸런싱을 하지 않음
• isolation.level: 트랜잭션 컨슈머에서 사용되는 옵션으로, read_uncommitted는 기본값으로 모든 메시지를 읽고, read_committed는 트랜잭션이 완료된 메시지만 읽음
• max.poll.records: poll() 요청으로 가져오는 최대 메시지 수
• partition.assignment.strategy: 파티션 할당 전략
• fetch.max.wait.ms: fetch.min.bytes에 의해 설정된 데이터보다 적은 경우 요청에 대한 응답을 기다리는 최대 시간

 

3.4.3 컨슈머 예제

• 오토 커밋
  • 오프셋을 주기적으로 커밋하므로 관리자가 오프셋을 따로 관리하지 않아도 됨
  • 컨슈머 종료 등이 빈번히 일어나면 일부 메시지를 못가져오거나 중복으로 가져올 가능성
• 동기 가져오기
  • poll()을 이용해 메시지를 가져온 후 처리까지 완료하고 현재 오프셋을 커밋(consumer.commitSync())
  • 속도는 느리지만 메시지 손실은 거의 발생하지 않음
  • 그래도 메시지 중복이슈는 피할 수 없음
• 비동기 가져오기
  • consumer.commitAsync()를 사용하여 비동기 커밋
  • 비동기 방식은 오프셋 커밋 실패시 재시도를 하지 않음(마지막 오프셋만 커밋되면 순서상 문제 없기 때문)
    • 이렇게하여 비동기 방식의 중복을 최대한 줄임

 

스프링부트 카프카어드민, 프로듀서, 컨슈머 구성법

• https://sup2is.github.io/2020/06/03/spring-boot-with-kafka-cluster.html

 

 

GitHub - youlive789/kafka-study: 카프카 스터디 - 도서:실전 카프카 개발부터 운영까지