일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- 푸시 번역
- notification
- php
- nginx설치
- 자바스크립트
- nginx설정
- 도메인 주도 개발
- 카프카
- 푸시
- Push
- ddd
- Design Pattern
- JPA
- Java
- 디자인패턴
- APNS
- 웹사이트최적화기법
- 성능
- graphql
- kafka
- 웹사이트 성능
- 웹사이트성능
- nginx
- git
- 페이스북 번역
- GCM 번역
- GCM
- gcm 푸시 번역
- 카프카 트랜잭션
- Today
- Total
목록kafka (10)
간단한 개발관련 내용
10.1 클러스터간 미러링 활용 사례Kafka의 클러스터간 미러링은 여러 목적을 위해 사용됩니다. 주요 활용 사례는 다음과 같습니다:지역 및 중앙 클러스터:데이터를 로컬 클러스터에서 수집하고 중앙 클러스터로 집적하는 구조입니다. 이를 통해 데이터 일관성과 분석에 유용합니다.고가용성과 재해 복구 (DR):한 클러스터에 장애가 발생했을 때 미러링된 클러스터로 페일오버를 수행해 가용성을 유지합니다.규제 준수:국가 및 지역별 규제에 따라 데이터를 물리적으로 분리해야 하는 경우 미러링을 통해 요구사항을 충족할 수 있습니다.클라우드 마이그레이션:온프레미스에서 클라우드로 이전할 때 데이터를 안전하게 이전할 수 있습니다.엣지 클러스터 데이터 집적:엣지에서 수집한 데이터를 중앙 클러스터로 전송해 데이터 분석 및 머신러닝..
SMT는 Single Message Transform의 약자로, Apache Kafka의 Kafka Connect 프레임워크에서 사용되는 단일 메시지 변환 기능입니다. SMT는 Kafka Connect가 데이터를 소스 커넥터를 통해 가져오거나 싱크 커넥터를 통해 내보낼 때, 각 개별 메시지에 대해 변환 또는 수정을 적용하는 간단한 처리 단계입니다.SMT의 역할Kafka Connect에서 SMT는 데이터 흐름의 중간에서 작동하며, 각 메시지에 대해 필터링, 변환, 필드 추가 또는 제거와 같은 작업을 수행할 수 있습니다.SMT를 사용하는 목적데이터 변환: 메시지의 포맷이나 필드를 변환합니다.데이터 정제: 불필요한 필드를 제거하거나 새로운 필드를 추가합니다.메타데이터 추가: 타임스탬프나 키 값 등 메타데이터를..
8.1 멱등적 프로듀서목적:동일 메시지가 브로커에 중복 저장되는 것을 방지.프로듀서의 재시도로 인한 중복만 방지하며, 동일 메시지를 반복 호출한 경우는 탐지하지 못함.작동 원리:프로듀서 ID (PID)와 시퀀스 번호를 사용해 각 메시지를 고유하게 식별.브로커는 마지막 5개 메시지의 시퀀스 번호를 추적하여 중복 메시지 필터링.프로듀서 설정:enable.idempotence=true.max.in.flight.requests.per.connection .제약사항:브로커 장애나 리더 교체로 인해 일부 메시지가 유실될 수 있음. 8.2 트랜잭션목적:다중 파티션 쓰기 및 오프셋 커밋을 원자적으로 처리하여 데이터 일관성 보장.정확히 한 번 의미 구조(Exactly Once Semantics, EoS) 구현.활용 사례..
1. 카프카 트랜잭션의 목적Exactly-once semantics (EoS): 메시지를 정확히 한 번만 처리.프로듀서-컨슈머 간 원자적 작업:데이터 생산(프로듀서) 및 소비(컨슈머)를 원자적으로 연결.데이터 무결성:장애 발생 시 중복 메시지 방지 및 데이터 일관성 유지. 2. 카프카 트랜잭션의 주요 구성 요소transactional.id:트랜잭션을 구분하는 고유 ID.프로듀서는 transactional.id를 기반으로 트랜잭션 작업을 수행.Producer ID (PID):프로듀서 인스턴스에 부여되는 고유 ID.브로커는 PID를 통해 트랜잭션 상태를 관리.Epoch:트랜잭션 버전 관리.장애 복구 시 동일한 transactional.id로 중복 작업 방지(팬싱).트랜잭션 로그:브로커는 트랜잭션 상태(시작,..
카프카 트랜잭션의 팬싱(Fencing)은 트랜잭션 프로듀서 간의 중복 방지 및 일관성 보장 메커니즘입니다. 이 기능은 트랜잭션 ID(transactional.id)를 기반으로 작동하며, 특정 트랜잭션이 잘못되거나 장애 상황이 발생했을 때, 중복 트랜잭션 프로듀서가 메시지를 잘못 기록하는 것을 방지합니다.1. 팬싱이 필요한 이유트랜잭션 프로듀서는 상태를 유지하며 트랜잭션 ID(transactional.id)를 통해 클러스터와 연관됩니다. 이때 다음과 같은 상황에서 중복 프로듀서가 발생할 수 있습니다:프로듀서 장애로 인해 클러스터와 연결이 끊긴 경우.네트워크 지연 또는 일시적인 장애로 기존 프로듀서가 복구되지 못했는데, 동일한 transactional.id로 새 프로듀서가 시작된 경우.이 상황에서 두 프로듀..
카프카 완벽 가이드 6장 요약: 카프카 내부 매커니즘6.1 클러스터 멤버십카프카는 브로커의 목록을 유지하기 위해 Apache Zookeeper를 사용.Zookeeper는 브로커가 클러스터에 속해 있는지 확인하고 리더 선출 등 여러 작업을 수행.6.2 컨트롤러컨트롤러 역할:파티션 리더 선출 및 메타데이터 관리.브로커가 추가되거나 제거될 때 파티션의 리더를 선출하고 클라이언트 요청 처리 시작.KRaft (Kafka Raft):Zookeeper 의존 제거: 자체적으로 리더 선출 및 메타데이터 관리.액티브 컨트롤러가 브로커 요청 처리, 팔로워 컨트롤러는 데이터 복제.메타데이터 동기화 및 성능 병목 해결.6.3 복제 (Replication)리더 레플리카:파티션의 리더 역할을 수행하며 쓰기 요청 처리.클라이언트 요..