강의 메모 # 토픽과 파티션 # 토픽과 파티션 # 토픽은 반드시 1개 이상의 파티션을 가져야한다. 파티션에는 프로듀서가 보낸 데이터들이 들어가 저장되는데, 이 데이터를 ‘레코드’라고 한다. 파티션에 있는 구조는 큐와 비슷 일반적인 큐는 데이터를 pop() 하면 삭제되는데, 카프카는 컨슈머가 데이터를 가져가더라도 데이터가 삭제되지않고 유지된다. 여러개의 컨슈머 그룹들이 토픽의 데이터를 여러번 가져갈 수 있다. 토픽 생성시 파티션이 배치되는 방법 # 파티션이 5개일 경우 그림과 같이 배치될 수 있다 0번 브로커부터 시작하여 round-robin 방식으로 리더 파티션들이 생성된다. ...
강의 메모 # 레코드 # 레코드 # 레코드는 타임스탬프, 헤더, 메시지 키, 메시지 값, 오프셋으로 구성되어있다. 프로듀서가 생성한 레코드가 브로커로 전송되면 오프셋이 지정되고, 옵션에 따라서 타임스탬프가 저장된다. 기본적으로 프로듀서는 오프셋을 가지고있지않고 레코드가 브로커에 저장될때만 오프셋이 있다. 브로커에 한번 적재된 레코드는 수정할 수 없다. 로그 리텐션 기간 또는 용량에 따라서만 삭제된다. 레코드 - 타임스탬프 # 스트림 프로세싱에서 활용하기 위한 시간을 저장하는 용도 기본값 : 프로듀서 레코드 생성 시간 (CreateTime) 또는 브로커 적재 시간(LogAppendTime)으로 설정할 수도 있다. ...
강의 메모 # 클라이언트 메타데이터와 브로커 통신 # 클라이언트 메타데이터 # 카프카 클라이언트는 통신하고자 하는 리더 파티션의 위치를 알기 위해 데이터를 주고받기 전에 메타데이터를 브로커로부터 전달받는다. 다음과 같은 옵션으로 리프래쉬된다. metadata.max.age.ms : 메타데이터를 강제로 리프래쉬하는 간격 (기본값: 5분) metadata.max.idle.ms : 프로듀서가 유휴상태일 경우 메타데이터를 캐시에 유지하는 기간 프로듀서가 특정 토픽으로 데이터를 보낸 이후 지정한 시간이 지나고나면 강제로 메타데이터를 리프래쉬 (기본값 5분) 리더 파티션이 어디에 위치하고있는지를 받게되는것! 클라이언트 메타데이터가 이슈가 발생한 경우 # 카프카 클라이언트는 반드시 리더 파티션과 통신해야한다. ...
강의 메모 # 브로커의 복제(Replication) # 브로커의 역할 - 복제(Replication) # 데이터 복제 : 클러스터로 묶인 브로커 중 일부에 장애가 발생하더라도 데이터를 유실하지 않고 안전하게 사용하기 위함이다. 토픽을 생성할때 파티션의 복제 개수(replication factor) 같이 설정 - default는 브로커에 설정된 옵션 값으로 설정 복제 개수의 최솟값은 1(복제 없음) 최댓값은 브로커 개수만큼 설정하여 사용 가능 복제된 파티션의 구성 : 리더(leader), 팔로워(follower) 리더 : 프로듀서, 컨슈머와 직접 통신하는 파티션 팔로워 : 리더의 데이터가 추가되면 복제해가는 역할 복제 과정 : 팔로워 파티션들은 리더 파티션의 오프셋을 확인하여 현재 자신이 가지고있는 오프셋과 차이가 나는 경우 리더 파티션으로부터 데이터를 가져와서 자신의 파티션에 저장한다. ...
강의 메모 # ISR (In-Sync-Replicas) # ISR (In-Sync-Replicas) # 리더 파티션과 팔로워 파티션이 모두 싱크가 된 상태를 뜻한다. 리더 파티션의 오프셋이 0~3까지 있을때 팔로워 파티션도 0~3이 있다. (동기화 완료 - 리더 파티션의 모든 데이터가 팔로워 파티션에 복제가 완료되었다 라는 뜻) unclean.leader.election.enable # 모두 복제되지 않은 상황이고, 이렇게 싱크가 되지 않은 팔로워 파티션이 리더 파티션으로 선출되면 데이터가 유실될 수 있다. 유실이 발생하더라도 서비스를 중단하지 않고 지속적으로 토픽을 사용하고 싶으면 ISR이 아닌 팔로워 파티션을 리더로 선출하도록 설정할 수 있다. ...
강의 메모 # 카프카 브로커, 클러스터, 주키퍼 # 주키퍼 # 카프카 클러스터를 운영하기 위해 반드시 필요한 애플리케이션 카프카 2.0 버전 까지는 반드시 필요했지만 카프카 3.0부터는 주키퍼가 없더라도 운영됨 아직까지는 주키퍼를 완벽하게 대체하지 못하므로 주키퍼가 있는 카프카 클러스터 운영 기업이 많음 1개의 브로커는 하나의 서버나 인스턴스에서 동작 브로커 3개가 있는 모습 브로커 # 데이터를 분산 저장하여 장애가 발생하더라도 안전하게 사용할 수 있도록 도와주는 애플리케이션 하나의 서버에는 하나의 카프카 브로커 프로세스가 실행됨 3대 이상의 브로커 서버를 1개의 클러스터로 묶어서 운영한다 카프카 클러스터로 묶인 브로커들은 프로듀서가 보낸 데이터를 안전하게 분산 저장하고 복제하는 역할을 수행한다. ...
강의 메모 # 로그와 세그먼트 # log.segment.bytes : 바이트 단위의 최대 세그먼트 크기 지정 (기본 값은 1GB) log.roll.ms(hours) : 세그먼트가 신규 생성된 이후 다음 파일로 넘어가는 시간 주기 (기본값은 7일) 프로듀서가 데이터를 전송하면 active 되어있는 .log 파일에 offset 22번으로 들어간다. (FIFO) 가장 최초의 offset 번호가 파일 이름이 된다 가장 마지막 세그먼트 파일을 active segment라고 한다. 브로커의 삭제 대상에서 포함되지 않는다. retention 옵션에 ㄸ라 삭제 대상으로 지정된다. 세그먼트와 삭제 주기 (cleanup. ...
기술 블로그 정리 # Transactional Outbox 패턴이 등장하게된 상황 # Event Driven Architecture > 메시지 발행의 신뢰성 보장 패턴 Event driven ARchitecture : Message Broker를 이용해 다양한 메시지(이벤트)를 publish(발행) 하고, 그에 연관된 작업을 비동기적으로 처리하여 시스템을 통합 DB 트랜잭션을 실행한 뒤, 연관 메시지를 Message Broker에 publish 하게 되는데, 메시지 publish가 반드시 완료되어야하는 경우가 있다. 예시) 리디 주문 기능; 주문이 발생하면 사용한 캐시&포인트 금액을 차감하고 상품을 지급하며 주문 완료로 상태를 바꾸는 DB 트랜잭션이 발생 -> Message Broker에 주문 완료 메시지를 publish 이 경우, DB와 Message Broker의 트랜잭션 원자성 보장이 어렵다. ...
강의 메모 # 아파치 카프카의 탄생과 기본 구조 # 카프카의 탄생 각각의 애플리케이션끼리 연결하여 데이터를 처리하는게 아닌, 한 곳에 모아 처리할 수 있도록 중앙집중화했다. 메시지 큐 구조를 그대로 살린 카프카 내부 구조 # 카프카 내부에 데이터가 저장되는 파티션의 동작은 FIFO(First In First Out) 방식의 큐 자료구조와 유사하다. 큐에 데이터를 보내는 것이 프로듀서 큐에서 데이터를 가져가는 것이 컨슈머 적재된 데이터를 하나하나 가져가더라도 파티션 내의 데이터는 삭제되지 않는다. 데이터를 읽는것 : 커밋 (데이터를 어디까지 읽었는지를 기록) 카프카가 데이터 파이프라인으로 적합한 4가지 이유 # 1. ...
tech blog 글 읽고 정리하기 # CDC 너두 할 수 있어(feat. B2B 알림 서비스에 Kafka CDC 적용하기) # B2B 알림 서비스에 CDC를 도입을 하게 되었다. B2B 알림 서비스 # B2B 알림 서비스 프로젝트가 무엇일까? 배민 B2C 고객 서비스에서는 알림센터라는 시스템을 통해 고객에 알림을 발송한다. 하지만, 사장님에게 발송되는 알림은 플랫폼이 부재한 관계로 카카오 알림톡으로 발송하고 있었다. 개선을 위해 알림센터를 활용해 사장님에게 전달되는 메시지를 내부 서비스를 통해 전달함으로써, 내부 서비스 활용도와 사용자 편의성을 향상시키고자 진행한 프로젝트가 ‘B2B 알림서비스’다. ...