GW LABS

6.1 컨슈머 오프셋 관리 컨슈머 동작 중 가장 핵심은 오프셋 관리 __consumer_offsets 토픽에 각 컨슈머 그룹별로 오프셋 위치 정보가 기록 __consumer_offsets은 다음에 읽어야 할 메시지의 오프셋을 기록된다. 6.2 그룹 코디네이터 리밸런싱: 컨슈머 그룹에서 각 컨슈머들에게 작업을 균등하게 분해하는 동작 그룹 코디네이터: 안정적인 컨슈머 그룹 관리를 위한 별도의 코디네이터 heartbeat.interval.ms: 그룹 코디네이터와 하트비트 인터벌 시간 session.timeout.ms: 컨슈머가 특정 시간 안에 하트비트를 받지 못하면 문제가 발생했다고 판단해 컨슈머 그룹에서 해당 컨슈머는 제거되고 리밸런싱 동작 max.poll.interval.ms: 컨슈머는 주기적으로 poll..

5.1 파티셔너 토픽은 성능 향상을 위한 병렬 처리가 가능하도록 파티션으로 나뉘고, 최소 하나 이상의 파티션으루 구성 메시지는 토픽 내 파티션 로그 세그먼트에 저장 토픽의 어느 파티션에 메시지를 저장할지 결정하는 것이 파티셔너 메시지의 키를 해싱하여 처리 트래픽이 많아질 경우 파티션을 늘릴 수 있는데, 이 경우 해시 테이블이 변경되기 때문에 동일 파티션이 아닌 다른 파티션으로 메시지가 전송 될 수 있음 되도록이면 파티션 수를 변경하지 않는 것이 좋음 5.1.1 라운드 로빈 전략 키값을 지정하지 않고 메시지가 전송되면 라운드 로빈 방식으로 레코드 전송 배치 전송 옵션을 사용할 경우 라운드 로빈 옵션은 지연시간과 압축 비효율을 발생시킬 수 있음 5.1.2 스티키 파티셔닝 전략 하나의 파티션에 리코드 수를 먼..

4.1.1 리플리케이션 동작 개요 토픽 생성시 replication factor 옵션으로 리플리케이션 수를 조정 토픽을 구성하고 있는 파티션이 리플리케이션 된다. 4.1.2 리더와 팔로워 리더: 모든 읽기와 쓰기는 리더를 통해서만 가능 팔로워: 새로운 리더가 될 준비를 하고 있으며 리더로 부터 새로운 메시지를 복제함 4.1.3 복제 유지와 커밋 리더와 팔로워는 ISR(InSyncReplica)라는 논리적 그룹으로 묶여 있음 리더는 ISR내 팔로워가 메시지를 모두 받을 때까지 대기 팔로워가 메시지를 수신하면서 장애가 났는지 지속적으로 감시 리더가 팔로워 리플리케이션 동작에 문제가 있다고 판단하면 추방함 커밋 오프셋은 replication-offset-checkpoint라는 파일에 저장 4.1.4 리더와 팔..

카프카 아키텍처 3.1.1 리플리케이션 각 메시지들을 여러 개로 복제해서 카프카 클러스터 내 브로커들에 분산시키는 동작 topic의 replication-factor 옵션으로 브로커에 분산할 수 있음 리플리케이션 기준 테스트/개발환경: 리플리케이션 펙터 수를 1로 설정 운영 환경(로그성 메시지로서 약간의 유실 허용): 리플리케이션 팩터 수를 2로 설정 운영 환경(유실 허용하지 않음): 리플리케이션 팩터 수를 3으로 설정 3.1.2 파티션 토픽의 처리량을 높이기 위해 병렬 처리가 가능하게 만든 것을 의미 파티션의 수만큼 컨슈머를 연결할 수 있음 파티션은 늘리는 것은 가능하지만 줄일 수는 없다! 2~4로 설정 후 LAG 등의 지표를 통해 늘려나가는 것이 좋다 3.1.3 세그먼트 파티션 안에 N개의 세그먼트로..

카프카 도커 컴포즈 설정 # 로컬 PC의 메모리 부족 이슈로 브로커들이 안뜰수도 있다. # 수를 조정해가면서 개발환경을 구축하자. version: '3.6' services: zookeeper: container_name: zookeeper image: confluentinc/cp-zookeeper:6.1.2 volumes: - "./zookeeper/data:/data" - "./zookeeper/logs:/datalog" ports: - "2181:2181" environment: ZOOKEEPER_CLIENT_PORT: 2181 ZOOKEEPER_TIME_TICK: 2000 # Ephemeral Node의 헬스 체크 간격 kafka1: container_name: kafka1 image: confl..

1.1 잘란도와 트위터의 카프카 도입 사례 잘란도가 느낀 카프카의 장점 빠른 데이터 수집이 가능한 높은 처리량 순서 보장 적어도 한 번 전송 방식 자연스러운 백프레셔 핸들링 강력한 파티셔닝 트위터가 느낀 카프카의 장점 비용 절감 효과 강력한 커뮤니티 1.3 카프카의 주요 특징 높은 처리량과 낮은 지연시간 높은 확장성 고가용성 내구성 개발 편의성 운영 및 관리 편의성 1.5 다양한 카프카의 사용 사례 데이터 파이프라인: 넷플릭스 사례 데이터 통합: 우버 사례

9.1 inverted index란 token: 공백 기준으로 문장을 나누어 생긴 단어 inverted index: 문서에서 토큰이 몇 번 출현했는지 빈도를 저장한 해시맵 형태의 자료구조 검색 결과를 얻기 위해서는 토큰이 검색어와 정확하게 일치해야한다. analyze API 문자열이 어떻게 토크나이징 되는지 확인할 수 있는 API curl --location --request GET 'localhost:9200/_analyze?pretty' \ --header 'Content-Type: application/json' \ --data-raw '{ "analyzer": "standard", "text": "I am a boy" }' # 결과 { "tokens": [ { "token": "i", "start..

7.1 클러스터의 상태 확인하기 cat API: 클러스터의 상태, 노드의 상태, 샤드의 상태 등 정보 확인 기능 /_cat/health?format=json&pretty status green: 모든 샤드가 정상적으로 동작하고 있는 상태 yellow: 모든 프라이머리 샤드는 정상적으로 동작하고 있으나, 일부 혹은 모든 레플리카 샤드가 정상적으로 동작하고 있지 않은 상태 red: 일부 혹은 모든 프라이머리 샤드/레플리카 샤드가 정상적으로 동작하고 있지 않은 상태 데이터 유실 가능성이 있다. 7.2 노드의 상태와 정보 확인하기 /_cat/nodes /_cat/nodes?v&h=id,name,disk.used_percent 조회하고 싶은 노드의 정보값을 파라미터로 넘겨 확인할 수 있다. 7.3 인덱스의 상태와..