이번주 발재 요약
kafka consumer, publisher 도입 및 이벤트화
consumer Group
- consumer
- 최대 성능 조건은 partition 갯수 = consumer 갯수
- 같은 partition에 consumer 여러 개면, 순서보장이 되지않기때문이다.
- consumer
publisher
partition
- 같은 토픽에서 key, value 로 같은 key에 대해서는 같은 partition에 일을 pub하기때문에 항상 순서 보장된다.
topic
- topic당 partition의 갯수를 정할수있으며, 더 늘리는것만 가능하다.(순서보장때문에)
broker
카프카 서버 Unit
Pub에게 메시지 받아서 offset 지정후 디스크에 저장
Consumer의 파티션 read에 응답해 디스크의 메시지 전송
Cluster내에 각각 한개씩 존재하는 Role BrokerController
- 다른 브로커의 모니터링하며, 장애가 발생한 Broker에 특정 토픽의 Leader에 문제가 발생시 -> 다른 브로커의 파티션 중 Leader 역할을 부여 및 재분배하는 역할을 수행
Coordinator
- 컨슈머 그룹을 모니터링하고, 특정 그룹 내의 특정 컨슈머가 장애 발생시, 해당 파티션을 다른 컨슈머에게 매칭해주는 역할
공개 Q/A
current offset 은 유실 될 가능성은 없나요? 예를들어, 서버에서 1, 2번 offset 을 처리했는데, offset 2번까지 읽었다라는 내용이 유실되어 카프카에 업데이트 되지 않는다던지.. 혹은 1, 2번 offset 을 읽고 서버 처리를 시작했는데, 서버가 중단되어 1,2 번이 읽었다고 카프카에 처리가 되어있는데, 실질적으로 서비스 처리가 되지 않았다라던지 같은 문제요.
컨슈머가 다음 메시지를 줘~ 브로커가 다음 메시지를 알아서 주는 구조는 정확히는 아닙니다.
브로커는 각 컨슈머의 current offset을 직접 관리해주지는 않습니다. current-offset은 브로커의 별도 내부 토픽에 저장되긴합니다.auto-commit: 1번 메시지를 poll(조회)하고, 1번 메시지를 커밋(commit)하고 2번 메시지를 처리… max.poll.count 한번에 데이터를 조회하는 개수를 설정할 수 있어요. default: 500. 메시지를 bulk로 조회하고 한번에 커밋(manual)하고 따로 커밋 액션을 하지 않더라도 백그라운드에서 커밋을 호출해서 메시지를 읽었다고 표시해요.
- 이런 관점에서 발생할 수 있는 다양한 이슈가 있을 수 있죠.
- auto-commit이 아닌 manual-commit으로 처리하거나, max.poll.count를 1로 줄이거나, auto.commit.interval.ms을 늘리거나..
Offset Commit, Auto-commit, Manual-commit
- 카프카가 메시지를 중복처리하지 않게하는 방법들
- 카프카가 메시지를 유실처리하지 않게하는 방법들
- 아까 Partition의 개수는 줄일 수 없다고 하셨었는데, 그렇다면 Consumer의 개수는 자유롭게 조정이 가능한 건가요?
- 파티션은 카프카 브로커의 설정 정보에요. 컨슈머는 브로커에 연결하는 클라이언트의 수 이기 때문에 컨슈머는 scale out 이 가능 -> 처리량을 늘리고 싶을 때는 컨슈머 팟 개수를 늘릴 수 있습니다.
- 브로커 설정은 컨슈머 수에 비해서는 정적인 설정에 가깝습니다. 잘 변경하지 않습니다.
- 카프카에서 컨슈머가 오프셋을 수동으로 커밋할때, 커밋을 안하면(처리 실패) 다음 오프셋으로 안넘어가고 현재 오프셋에 계속 멈춰있는건가요?
그렇다면 커밋 실패시 다른 메시지들을 처리를 못하니 병목현상이 발생하는게 아닐까 싶습니다.- 맞아요. 그래서 이 메시지의 실패가 다음 메시지로 넘어갈 수 없기 때문에 DLQ 등의 부가적인 설정들이 필요해요.
- 순차 보장때문에라도, 같은 토픽에서 메시지 실패에서 다음 메시지로 넘어갈수없게 정책을 가져가는것이맞음
- 실패된 메시지에 따른 정책 설정
- 카프카 라이브러리를 활용할때 프로듀서의 설정으로 재시도 정책을 설정하거나 DLQ(Dead Letter Queu)를 설정하는 것이 쉽게 가능해요.
- AWS SQS에서는 메시지 수집시 커밋이 되지 않은 메시지를 N번 재발행하는 기능과 N번 실패시 DLQ로 보내는 기능이 존재하는데요.,
카프카에도 비슷한 기능이 존재할까요? 컨슈머의 실패 처리를 어떻게 해야할지 고민입니다.- 위의 답변과 동일함
- 현업에서 카프카 설정 시에, 리밸런싱을 최대한 억제하기 위해서는 어느 정도의 컨슈머 개수와 파티션 개수를 설정해야 적당할까요?
- 리벨런싱을 최소화하는게 처리량 관점에서 중요해요. 컨슈머 개수와 파티션 개수를 적절하게 설정해야한 것은 연관성이 조금 달라요. 파티션과 컨슈머 수를 같게 유지하는게 도움이 되겠지만, 배포시점이나 특정 컨슈머의 장애 혹은 지연처리 등으로 리벨런싱은 항상 발생할 수 있어요.
- max.poll.interval.ms, heartbeat.interval.ms 두가지 속성으로 리벨런싱을 결정하는데 값을 조정하면서 리벨런싱을 최소화 할 수도 있음
- 카프카 토픽에 저장된 데이터는 “일시적으로 영속화” 되는 것으로 이해했습니다. 하지만 RDB처럼 무기한 저장을 보장하지는 않을 것 같은데, 현업에서는 보관 정책? 주기?를 어떻게 설정하시나요?
- 리텐션 정책. 이 저장된 메시지들을 얼마나 저장할까?
- 기간단위
- 용량단위
- 현업에서는 저는 항상 기간단위 리텐션 정책을 활용. 기본값: 7일(아마도)
- 우리가 컨슈머 메시지를 제대로 처리하지 못했을때 메시지를 다시 읽어야 하는데 너무 빨리 메시지가 삭제되면 복구가 불가능하고,
- 또 너무 길게 하면 카프카의 특성상 과거데이터는 사용될 일이 거의 없기 때문에 저장공간의 비효율을 야기할 수 있습니다.
- 리텐션 정책. 이 저장된 메시지들을 얼마나 저장할까?
- 이벤트 페이로드를 구성할 때, Zero-Payload 및 Full-Payload 방식이 있는 것으로 학습했습니다.
각 방식마다 장단점이 있지만 실무에서는 어떤 방식을 주로 적용하는지 궁금합니다.- Zero-Payload:
- 메시지의 양이 많고 컨슈머가 다양해서 원하는 데이터가 다 다를때 보통 이런 형태를 활용해요.
- ex) 결제 완료 카프카 메시지:
- paymentId..
- Full-Payload:
- 메시지의 양이 너무 많은데, 이 메시지를 발행할때마다 추가 정보를 얻기 위해 API 호출 등의 부가 작업이 무겁다고 판단되면 메시지에 컨슈머가 원하는 모든 내용들을 담아서 전달해요.
- 모든 컨슈머가 동일한 형태의 이벤트 바디를 원하는 경우
- 1:1 이벤트 발행 컨슘 관계인 경우..
- Zero-Payload:
- 아직 Kafka에 대한 이해도가 낮아서 그런지, Try if you want 부분이 모호하게 느껴집니다.
Kafka를 애플리케이션 내에서만 활용하다가 외부 모듈로 분리해보라는 의미일까요?- 어플리케이션 이벤트 발행을 카프카로 발행하고 어플리케이션 이벤트 리스너도 카프카 컨슈머로 변경하고. 어플리케이션 이벤트는 트랜잭션을 같이 물고 처리하거나(BEFORE_COMMIT, AFTER_COMMIT) 할 수 있기 때문에 일반적으로 application layer에서 설정해요.
- 그런데 카프카 컨슈머는 시스템의 인입단계로 보기 때문에 interface layer라고 보는 경우가 더 많아요. consumer layer라고 만드는 경우도 있고요. 어쨋든 트랜잭션을 관리하는 application 외부 layer가 될거에요. 그래서 이 변경까지 함께 고려해서 적용한다면 우리 서비스가 배포단위가 분리되더라도 별다른 코드작업 없이 분리가 가능할 것이다.
- Kafaka 구동 할려고 검색 해보니까 Zookeeper에 대한 내용도 나오는데.. Zookeeper에 대한 간단하게 알려줄수 있을까요? 그리고 이번 과제에서 Zookeeper에 대한것도 알아야 될까요?
- 전에는 카프카가 주키퍼를 필수로 연결해서 운영했어야만 했는데, 요즘에는 주키퍼 없이 카프카를 운영할 수 있어요.
- 주키퍼가 하는일이 카프카의 컨트롤러가 하는일을 주키퍼가 해줘요.주키퍼는 컨트롤러 선출만 도와줍니다.
- 주키퍼가 하는 주요 역할
- 메타데이터 관리
- 컨트롤러 선출