PaaS 234

Kafka 심화) 카프카 모니터링 하기

클러스터 문제 진단하기활성 컨트롤러 수나 컨트롤러 큐 크기와 같은 지표를 모니터링 함으로써 뭔가 문제가 발생했을 때 간단히 알아차릴수 있다. 불완전 복제 파티션 다루기해당 브로커가 리더 레플리카를 잡고 있는 파티션 중 팔로워 레플리카가 따라오지 못하고 있는 파티션의 수를 나타낸다. 다수의 브로커가 일정한 수의 불완전 복제 파티션을 가지고 있다는 것은 보통 클러스터의 브로커중 하나가 내려가 있다는 것을 의미하는 경우가 많다. 가장 먼저 해야 할 일은 문제가 단일 브로커에 국한된 것인지 아니면 클러스터 전체에 연관된 것인지를 확인하는 것이다 때로는 이것이 쉽지 않은 문제일 수 있다. 만약 다음 예와 같이 불완전 복제 파티션들이 한 브로커에 몰려 있다면 해당 브로커가 문제일 가능성이 높다. 에러 메시지를 보..

PaaS/MQ 2026.02.10

Kafka 심화) 보안

보안 프로토콜PLAINTEXT : PLAINTEXT 전송 계층에는 인증이 존재하지 않는다. 사설 네트워크 안에서 인증이나 암호화가 필요없을 정도로 민감하지 않은 데이터를 처리할 때문 적합하다. SSL : SSL전송 계층은 선택적으로 클라이언트 SSL인증을 수행할 수 있다. 암호화 뿐만 아니라 클라이언트/서버 인증도 지원되기 때문에 안전하지 않은 네트워크에서 적절하다. SASL_PLAINTEXT : SASL 인증과 PLAINTEXT 전송계층이 합쳐진 것이다. 어떤 SASL메커니즘은 서버 인증 역시 지원한다. 암호화는 지우하지 않기 때문에 사실 네트워크 안에서만 적합하다. SASL_SSL : SASL 인증과 SSL 전송계층이 합쳐진 것이다. 암호화 뿐만아니라 클라이언트/서버 인증도 지워되기 때문에 안전..

PaaS/MQ 2026.02.07

Kafka 심화) 클러스터간 데이터 미러링하기

카프카 클러스터 간의 데이터 복제는 미러링 이라고 부를것이다. 아파치 카프카에는 클러스터간 데이터 복제를 수행하기 위한 툴로 미러메이커를 포함하고 있다. 클러스터간 미러링 활용 사례지역 및 중앙 클러스터고전적인 사례로는 수요와 공급에 따라서 가격을 조정해야 하는 회사가 있을 것이다. 이 회사는 사무실을 운영중인 각각의 도시에 데이터 센터를 가지고 각 지역의 수요와 공급에 대한 정보를 수집해서 그에 따라 가격을 조정한다. 이 모든 데이터는 그 후 중앙 클러스터로 미러링되어 비즈니스 분석가들이 회사 단위의 수익 보고를 할 때 사용할 수 있다. 고가용성과 재해복구 규제여러 나라에서 사업을 운영하는 회사의 경우 국가별로 다른 법적, 규제적 요구 조건을 따르기 위해 나라마다 있는 카프카 클러스터별로 서로 다른..

PaaS/MQ 2026.02.04

Kafka 심화) 데이터 파이프라인 구축하기

데이터 파이프라인 구축 시 고려사항적시성하루에 한 번 대량의 데이터를 받는 시스템이 있는 반면 데이턱 생성된 뒤 몇 밀리초 안에 받아야하는 시스템도 있다. 대부분의 데이터 파이프라인은 이 두가지 형태의 중간쯤 어딘가에 위치한다. 이러한 맥락에서 카프카를 이해하는 좋은 방법은 쓰는 쪽과 읽는 쪽 사이의 시간적 민감도에 대한 요구조건을 분리시키는 거대한 버퍼로 생각하는 것이다. 쓰는 쪽에서는 실시간으로 쓸 수 있지만, 읽는 쪽에서는 배치 단위로 읽을 수 있으며, 그 반대로 가능하다. 이것은 백프레셔(Producer가 cONSUMING 가능 이상의 데이터를 발생시킬때) 적용 역시 단순하게 해준다. 신뢰성데이터 파이프라인은 많은 경우 중요한 비즈니스 시스템에 데이터가 전달되는 통로이기도 하기 때문에, 몇 초간..

PaaS/MQ 2026.02.02

Kafka 심화) '정확히 한 번' 의미 구조

이전 챕터에서 신뢰성 보장을 제어할 수 있게 해주는 설정 매개변수들과 모범사례를 보았다. 여기서 우리는 '최소 한번' 전달에 초점을 맞췄다. 멱등적 프로듀서간혹 재시도는 메시지 중복을 발생시킨다. 가령 다음과 같은 시나리오에서..- 파티션 리더가 프로듀서로부터 레코드를 받아서 팔로워들에게 성공적으로 복제한다.- 프로듀서에게 응답을 보내기 전, 파티션 리더가 있는 브로커에 크래시가 발생한다. - 프로듀서 입장에서는 응답을 받지 못한 채 타임아웃이 발생하고, 메시지를 재전송한다.- 재전송된 메시지가 새 리더에 도착한다. 하지만 이 메시지는 이미 저장되어 있다. 이러한 케이스를 대응하기 위해서 우리는 멱등적 프로듀서를 사용한다. 멱등적 프로듀서의 작동 원리멱등적 프로듀서 기능을 켜면 모든 메시지는 고유한..

PaaS/MQ 2026.01.26

Kafka 심화) 신뢰성 있는 데이터 전달

브로커 설정복제 팩터토픽 단위 설정은 replication.factor에, 자동으로 생성되는 토픽들에 적용되는 브로커 단위 설정은 default.replication.factor 설정에 잡아준다. 이책에서 지금까지는 토픽의 복제 팩터가 3이라고 가정하였다. 이는 각 브로커가 3대의 서로 다른 브로커에 3개 복제된다는 것을 의미한다. 이엇은 합리적인 가정이고 또 카프카의 기본값이기다 하지만, 이설정은 사용자가 고칠수 있는 것이다. 그렇다면 토픽에 몇개의 레플리카가 적절한지 어떻게 결정할 수 있을까? 몇가지의 핵심 고려사항이 있다. - 가용성 : 레플리카가 하나뿐인 파티션은 정기적으로 브로커를 재시작하기만 해도 작동 불능에 빠진다. 레플리카 수가 더 많을수록 가용성은 떨어진다.- 지속성 : 각 레플리카는..

PaaS/MQ 2026.01.23

Kafka 심화) 카프카 내부 알고리즘

클러스터 멤버쉽카프카는 현재 클러스터의 멤버인 브로커들의 목록을 유지하기 위해 아파치 주키퍼를 사용한다. 각 브로커는 브로커 설정 파일에 정의되었거나 아니면 자동으로 생성된 고유한 식별자를 가진다. 컨트롤러컨트롤러는 일반적인 카프카 브로커의 기능에 더해서 파티션 리더를 선출하는 역할을 추가적으로 맡는다. 브로커가 컨트롤러가 되면, 클러스터 메타데이터 고나리와 리더 선출을 시작하기 전에 먼저 주키퍼로부터 최신 레플리카 상태 맵을 읽어온다. 브로커가 클러스터를 나갔다는 사실을 컨트롤러가 알아차리면, 컨트롤러는 해당 브로커가 리더를 맡고 있었던 모든 파티션에 대해 새로운 브로커를 할당해주게 된다. 컨트롤러는 새로운 리더가 필요한 모든 파티션을 순회해 가면서 새로운 리더가 될 브로커를 결정한다.(단순히 해당 ..

PaaS/MQ 2026.01.14

Kafka 심화) Consumer

우리는 토픽으로부터 데이터를 읽어 오는 작업을 확장할수 있어야 한다. 여러개의 컨슈머가 같은 토픽으로 부터 데이터를 분할해서 읽어올 수 있게 해야 하는것이다. 카프카 컨슈머는 보통 컨슈머 그룹의 일부로써 작동한다. 동일한 컨슈머 그룹에 속한 여러개의 컨슈머들이 동일한 토픽을 구독할 경우, 각각의 컨슈머는 해당 토픽에서 서로 다른 파티션의 메시지를 받는 것이다. 파티션보다 더 많은 컨슈머를 추가한다면 컨슈머 중 몇몇은 유휴 상태가 되어 메시지를 전혀 받지 못한다. 이것은 토픽을 생성할 때 파티션 수를 크게 잡아주는게 좋은 이유이기도 한데, 부하가 증가함에 따라서 더 많은 컨슈머를 추가할 수 있게 해주기 때문이다. 여러 애플리케이션이 동일한 토픽에서 데이터를 읽어와야 하는 경우 역시 매우 흔하다. 카프..

PaaS/MQ 2026.01.09

Kafka 심화) Producer

프로듀서 측의 전반적인 메커니즘프로듀서 API 는 매우 단순하지만, 우리가 테이터를 전송할때 내부적으로는 조금 더 많은 작업들이 이루어진다. 1) 카프카에 메시지를 쓰는 작업은 ProducerRecord 객체를 생성함으로써 시작된다. 여기서 레코드가 저장될 토픽과 밸류 지정은 필수사항이지만, 키와 파티션 지정은 선택사항이다. 일단 ProducerRecord를 전송하는 API를 호출했을 때 프로듀서가 가장 먼저 하는 일은 키와 값 객체가 네트워크 상에서 전송될 수 있도록 직렬화해서 바이트 배열로 변환하는 것이다.(=Serializing) 2) 그 다음에, 만약 파티션을 명시적으로 지정하지 않았다면 해당 데이터를 파티셔너에게로 보낸다. 파티셔너는 파티션을 결정하는 역할을 하는데, 그 기준은 보통 Prod..

PaaS/MQ 2026.01.05