나만의 repository

1) 모니터링 1-1. 네 가지 숫자Throughput : 들어오고/나가는 메시지 양 (bytes/sec, records/sec)Error : 프로듀서/컨슈머 에러율Lag/LatencySaturation : 브로커가 바쁨 (Idle% 낮은 경우), 디스크가 꽉 참 (사용량 높은 경우)지표 몇가지1. URP > 0 : 불완전 복제 파티션이 있으니 확인 필요2. RequestHandlerIdle %가 계속 0.3보다 작은 경우 : 브로커 과부화 가능성3. Consumer Lag이 업무 시간에 계속 증가 : 처리 병목 1-2. SLO란?SLI (무엇을 측정하는가) : 특정 메시지가 3초 안에 처리되는 비율SLO (목표) : 영업 시간에 99.9%는 3초 안에 끝낸다알람 : 3초 넘는 구간이 5분 이상 지속되..

Q. 브로커/토픽에 누구나 접근 가능한 상태라면 어떻게 통제해야하나? 1. 접속 통제 : 내부/외부 리스너 분리, mTLS 또는 SASL 필수, ACL 최소 권한, TLS 전체 구간, 방화벽/VPC/VPN2. 메시지 자체 보호 : 메시지 value 전체 암호화 (AES-GCM 등) + 서명 + 일련번호 + 타임스탬프 - 연속 번호 아니면 버림 - 서명 불일치 버림3. 전용 통로 : 금융권에서는 사설망/PrivateLink/VPN으로 별도 라인 Q. OIDC로 토큰 인증 쏠 때 갱신/만료/재연결은? 동시 폭주만 막으면 된다.조기 갱신(만료 5 ~ 10분 전), 지수 백오프 + 지터, 프로세스 내 토큰 공유 캐시롤링 배포 시 소수씩 재시작모니터링: 토큰 발급 실패율/지연, 재연결 성공률 알람 ..

1. Kafka Connect는 Spring Kafka로 직접 구현한 Consumer보다 뭐가 더 좋은가?그냥 JDBC로 읽고 KafkaTemplate으로 전송하면 되는데, Kafka Connect를 왜 써야 하지? Kafka Connect의 핵심은 운영 편의성과 Pluggability이다. 직접 구현한 Producer/Consumer는:장애 발생 시 재처리 로직, offset 저장, 실패 전파, 재시작 등 모든 책임이 애플리케이션에 있음운영자는 해당 서비스를 배포하고, 장애 시 디버깅과 로깅을 파고들어야 함 반면, Kafka Connect는 다음과 같은 특성을 가진다:항목Kafka Connect직접 구현offset 저장Kafka 내부 토픽 (__consumer_offsets)보통 DB or Kafka..

Q. 카프카에서 발생할 수 있는 대표적인 에러 유형은? ProducerTimeoutException브로커 응답 지연 (네트워크, 리더 불안정)RecordTooLargeException메시지 크기가 max.request.size 초과NotEnoughReplicasExceptionISR 부족 → acks=all 충족 불가KafkaStorageException브로커 디스크 장애 (ISR 탈락 등 발생 가능) ConsumerRebalanceInProgressExceptionRebalance 중 poll 호출WakeupException안전한 종료 처리 도중 발생OffsetOutOfRangeException커밋된 offset이 사라진 경우 (retention.ms 초과)CommitFailedExceptiongro..

Ch 05. 프로그램 내에서 코드로 카프카 관리하기 p. 126카프카의 AdminClient는 Future 객체를 Result 객체 안에 감싸는데, Result 객체는 작업이 끝날 때까지 대기하거나 작업 결과에 대해 일반적으로 뒤이어 쓰이는 작업을 수행하는 헬퍼 메서드를 가지고 있다. Q. 실제 클래스 구조는 어떻게 생겼는가?CreateTopicsResult.javaKafkaFuture.java p. 137// ① 커밋된 consumer group offset 조회Map offsets = admin .listConsumerGroupOffsets(CONSUMER_GROUP) .partitionsToOffsetAndMetadata().get();// ② 다시 최신 offset 조회Map req..

Ch 04. 카프카 컨슈머: 카프카에서 데이터 읽기 p.88컨슈머는 해당 컨슈머 그룹의 그룹 코디네이터 역할을 지정받은 카프카 브로커에 하트비트를 전송함으로써 멤버십과 할당된 파티션에 대한 소유권을 유지한다. Q. 그룹 코디네이터와 컨트롤러의 차이는? 정리하자면 카프카의 단일 브로커는 컨트롤러, 그룹 코디네이터 (복수 개의 group 담당 가능), 파티션의 리더 혹은 팔로워의 세가지 역할을 동시에 수행할 수 있다.단, Kafka 3.x부터는 KRaft에서 컨트롤러 전용 노드 분리가 가능하다. p. 89 Q. 컨슈머가 죽었다고 판단해 새로운 컨슈머에 파티션을 할당했으나, 기존 컨슈머가 살아있었고 동일한 레코드를 중복 처리하게 되는 케이스가 발생 가능한가? A. 아래 시나리오와 같이 가능하다. 1. Co..

Ch 03. 카프카 프로듀서: 카프카에 메시지 쓰기 p. 62, 63buffer.memory이 매개변수는 프로듀서가 메시지를 전송하기 전에 메시지를 대기시키는 버퍼의 크리(메모리의 양)를 결정한다.batch.size같은 파티션에 다수의 레코드가 전송될 경우 프로듀서는 이것들을 배치 단위로 모아서 한꺼번에 전송한다.이 매개변수는 각각의 배치에 사용될 메모리의 양을 결정한다('개수'가 아니라 '바이트' 단위임에 주의하라) buffer.memory : 기본 값 32MBbatch.size : 기본 값 16KB buffer.memory 안에 여러 크기의 batch.size를 가진 batch 들이 생성된다 멱등성 보장 관련 설정 acks = all 모든 팔로워가 패치가 되었는지 기다린 후에 ack 응답을 보낸..

Ch 01. 카프카 시작하기 p. 7주어진 파티션의 각 메시지는 고유한 오프셋을 가지며, 뒤에 오는 메시지가 앞의 메시지보다 더 큰 오프셋을 가진다(반드시 단조증가할 필요는 없다). Q. 카프카의 오프셋은 각 파티션 내에서 반드시 단조 증가해야 하지 않나? A. 카프카에서 각 파티션에 기록되는 메시지는 순차적인 오프셋을 가진다.즉, offset n 다음엔 반드시 offset n+1 이 온다 그리고 브로커는 메시지 손실 여부를 오프셋의 단절로 인식한다.따라서 컨슈머 입장에서 만약 오프셋이 100, 101, 102, 104 순으로 온다면 103은 유실 혹은 아직 도착하지 않은 상태로 간주될 수 있다단조 증가가 깨지면 손실 또는 중복 발생으로 판단할 수 밖에 없다 Q. 그렇다면 왜 책에는 저렇게 쓰여 있을까?..

p. 3888.1.6절에서 guava event bus를 사용하여 UserController 클래스를 다시 구현했다 하지만 UserController 클래스는 여전히 스레드 풀을 생성하고 옵서버를 등록하는 등 옵서버 패턴과 관련된 비지니스와 관련 없는 코드가 많이 남아 있다. 이 UserController 클래스를 어떻게 더 개선할 수 있을지 생각해보자. EventBusConfigurator 등의 모듈에서 옵서버를 등록한다.EventDispatcher 같은 추상 인터페이스를 정의하고 GuavaEventDispatcher 구현체를 실제 UserController 에서 사용하도록 한다. p. 390read() 함수는 데이터를 읽는 전 과정을 정의하는 템플릿 메서드로, 하위 클래스별로 정의된 추상 메서드를 ..

p. 348어댑터 패턴과 퍼사드 패턴의 공통점은 설계가 좋지 않은 인터페이스를, 사용하기 용이한 인터페이스로 만든다는 점이다. 내가 이해하기로 퍼사드 패턴은 여러 서브시스템을 묶어 클라이언트에 노출할 단일, 간결한 인터페이스를 제공한다.그래서 어댑터 패턴과는 다르게 좋지 않은 설계에만 사용하는 패턴은 아닌 것으로 보인다.퍼사드는 단순히 부실한 설계를 감추는 꼼수가 아니라, 건전한 계층화와 관심사 분리를 위한 패턴이라고 생각한다. p. 348복합체 패턴은 주로 트리 구조의 데이터를 처리하는 데 사용된다. Q. 실제 개발을 하면서 트리 구조의 자료 구조를 생성하고 복합체 패턴을 활용해보신 적이 있는지? 회계 시스템에 사용해본다면..?계정과목 계층 구조계정과목 (Asset, Liability, Equity ..