목록전체 글 (76)
CheerUp_Cheers
카프카 컨슈머, 메시지를 소비하는 주체프로듀서 장을 읽고 나니 컨슈머 쪽은 좀 만만해 보였는데, 막상 읽어보니 만만한 게 아니었다. 리밸런스, 오프셋 커밋, 폴링 루프 종료까지 어디 하나 대충 넘어가면 중복 처리나 메시지 유실로 바로 이어지는 지점들이다.컨슈머 그룹이 존재하는 이유카프카 컨슈머는 대부분 컨슈머 그룹의 일원으로 동작한다. 파티션 수와 컨슈머 수가 같으면 가장 효율적이고, 컨슈머가 파티션보다 많으면 몇몇은 그냥 놀게 되고, 반대로 파티션이 컨슈머보다 많으면 처리가 밀리기 시작한다. 그래서 나중에 컨슈머를 늘려서 확장할 여지를 남겨두려면 처음부터 파티션 수를 좀 넉넉하게 잡아두는 게 맞다는 이야기가 나온다.개수파티션 = 컨슈머 : 효과적파티션 파티션 > 컨슈머 : 지연컨슈머가 지연처리가 긴 ..
카프카 프로듀서, 그냥 send() 한 줄이 아니었다프로듀서를 실무에서 쓸 때는 대개 send() 한 줄로 끝나는 것처럼 보인다. 근데 이 장을 읽어보니 그 한 줄 뒤에서 벌어지는 일이 생각보다 많았다. 3장은 프로듀서의 내부 흐름과, 신뢰성·성능에 영향을 주는 설정값들을 다룬다.메시지 한 통이 브로커까지 가는 길책이 그려주는 전송 과정은 대략 이렇다.1. 먼저 ProducerRecord를 만든다. 여기엔 토픽과 밸류가 필수이고, 만들어진 레코드는 시리얼라이저를 거쳐 바이트 배열로 직렬화된다.2. 그다음 파티션이 정해지는데, 명시적으로 지정하지 않으면 키값을 기준으로 결정된다.3. 이렇게 만들어진 레코드는 곧바로 전송되는 게 아니라 같은 파티션으로 가는 레코드들끼리 배치로 묶여서 브로커에 전달된다.4. ..
카프카 설치 및 설정하기1장이 "카프카가 왜 필요한가"를 설득하는 챕터였다면, 2장은 실용서로써의 내용이 이어진다. 주키퍼 설치부터 브로커 설정값, 하드웨어 스펙, OS 튜닝까지의 내용을 다룬다. 주키퍼부터 세워야 한다카프카 이야기를 하다 보면 자꾸 주키퍼가 먼저 나온다. 브로커, 토픽, 파티션 같은 메타데이터를 저장하는 역할을 주키퍼가 맡고 있어서 그렇다. (실무에서는 Kraft로 적용하기로 하였기에, 참고만 한다) 일단 이 책의 예제 버전 기준으로는 주키퍼 설치가 먼저다. 주키퍼는 혼자 두는 경우가 거의 없다. 여러 대를 묶어서 앙상블을 구성하는데, 여기서 재밌는 규칙이 하나 있다. 요청에 응답하려면 과반수 이상의 서버가 응답해야 한다는 것. 그래서 앙상블은 항상 홀수로 구성하는 게 권장된다. 5대짜..
카프카, 실무에 적용카프카의 실용성, 확장성에 대해서 회사에 계속된 어필의 결과로 일부 로직을 이벤트 기반으로 처리 할 수 있는 기회가 생겼고, 조만간 카프카를 실무에 세팅하고 적용할 예정이다. 근데 막상 그때 가서 "왜 하필 카프카야?", "RabbitMQ를 쓰면 안되는거야?" 라는 질문을 받으면 "다른 빅테크 기업에서 사용하니까", "성능이 좋다고 해서" 같은 궁색한 답밖에 못 할 것 같아서, 개념을 좀더 제대로 잡아두려고 "카프카 핵심가이드"를 잡았다. 아직 실무에 발 담그기 전이니만큼, 책 정리하듯 훑어보기로 했다. 1장은 카프카라는 게 왜 등장했는지, 그리고 카프카를 이루는 기본 개념들을 훑는 챕터다.발행/구독, 별거 아닌 것 같지만발행/구독(pub/sub) 메시지 전달의 핵심은 사실 단순하다...
DDD?DDD(Domain Driven Design)는 약자 그대로, 도메인 주도 설계로 아키텍처적인 얘기를 하는 것으로 보인다. 본인도 DDD는 아키텍처중에 하나 아닌가? 하는 생각이 들었다. 하지만, 수강한 DDD 강의에서는 DDD를 아키텍처로 보기보다는, 일을 편하게 하기 위한 방법 또는 같이 일하는 이해관계자들과의 동일한 의사소통 설계로 설명을 한다. 처음에는 이해가 되지 않았지만, 이벤트 스토밍을 겪어보니 일을 잘하는 방식과 닮아있었다. 간단 용어 사용자: 애플리케이션을 사용하는 불특정 다수로, 요구 사항을 가지고 있음.도메인 전문가: 소프트웨어 개발이 아닌 업무 도메인에 전문 지식이 있는 사람으로, 용어나 구조의 부정확성을 지적해야 함.개발자: 소프트웨어를 개발하는 사람으로, 기능과 시스템 설..
Chapter44.1 토픽과 파티션4.1.1 적정 파티션 개수토픽 생성 시 파티션 개수 고려사항데이터 처리량메시지 키 사용 여부브로커, 컨슈머 영향도데이터 처리 속도 올리는 법컨슈머의 처리량 늘리는 것 스케일 업, GC 튜닝 → 컨슈머 특성상 다른 시스템과 연동으로 일정 수준 힘듬.컨슈머를 추가하여 병렬처리량을 늘리기. 프로듀셔 전송 데이터량 → 컨슈머 랙이 생김.메시지 키 사용 여부 메시지 키와 데이터 처리 순서에 대해 고려 해야 함.기본 파티셔너 메시지 키를 해시로 변환하여 파티션에 매칭함. 파티션 개수가 달라지는 순간 메시지키를 사용하는 특정 메시지 키의 순서는 보장 받을 수 없음.커스텀 파티셔너 파티션 개수가 변해도 메시지 키의 매칭을 가져갈 수 있게. 커스터밍하기 싫다면 처음부터 파티..