kafka 학습 내용 정리 - 추가중 ...
카프카 생태계
프로듀서에서 데이터 넣고 토픽 데이터 들어가서 컨슈머가 데이터를 가지고 간다.
토픽 데이터를 토픽에 넣고 싶을때 스트림즈를 쓴다.
오픈소스 아파치 카프카에 포함되어 있는 툴이다.
아파치 카프카의 릴리즈 동일한 구조로 되어있다. (기능을 같이 쓰려면 같은 오픈소스 아파치 카프카 배포되는것만)
커넥트는 데이터 파이프라인 운영 핵심 툴이다.
소스 커넥터 (프로듀서)
싱크 커넥터 (컨슈머)
특정 데이터 소스에서부터 커넥트 (소스) 읽어와서 토픽에 넣고 커넥트(싱크)는 타겟으로 보내는 컨슈머 역할을 한다.
반복적으로 여러번 생성할 수 있는것이 장점이여서 카프카 클러스터에서 따로 운영하지 않는다.
mm2 툴 (미러 메이커 툴)
클러스터 단위로 카프카 운영할 때 토픽 데이터를 완벽하게 복제하기 위해서 사용

카프카 브로커와 클러스터
주키퍼는 카프카 클러스터 운영하기 위한 애플리케이션
카프카가 2버전 까지는 반드시 주키퍼 필요 3버전 부터는 카프카 클러스터에서 쥬키퍼 없어도 운영 가능
브로커는 데이터를 분산 저장하여 장애가 발생하더라도 안전하게 사용할 수 있도록 도와주는 애플리케이션
컨슈머 입장에서 데이터를 안정하게 사용할 수 있다.
여러개의 카프카 클러스터가 연결된 주키퍼
주키퍼 앙상블에는 여러 종류의 클러스터를 동시에 운영가능

kafka-console-consumer.sh
토픽으로 전송한 메시지를 확인해볼 수 있다. --bootstrap-server 에서 카프카 클러스터 정보, --topic 토픽 이름이 필요하다. from-beginning 옵션을 주면 토픽에 저장된 가장 처음 데이터부터 끝까지 출력한다. (FIFO)
메시지 키를 확인하고 싶을 때, (값을 구분하고 싶은 용도) property 옵션을 주면된다. -> key-separator
bin/kafka-console-consumer.sh --bootstrap-server my-kafka:9092 \ --topic hello.kafka \ --property print.key=true \ --property key.separator="-" \ --from-beginning
--max-messages : 최대 컨슘 메시지 개수 설정
데이터가 수없이 들어올 때 계속 프린트 되기 때문에 많은 데이터가 보인다. 특정 토픽에 대해 데이터를 보고 싶을 때 쓴다.
--partition 옵션
특정 파티션만 컨슘할 수 있다.
topic은 파티션 한개 가지고 있다. (최소) 파티션이 여러개 있으면 특정 파티션에 대해서만 데이터를 계속 가지고 오고 싶을 때가 있다.
--partition 2 이런식으로 숫자를 주면 된다.
--group
그룹 옵션을 사용하면 컨슈머 그룹을 기반으로 kafka-console-consumer 가 동작한다. 컨슈머 그룹으로 토픽의 레코드를 가져갈 경우 어느 레코드 까지 읽었는지에 대한 데이터가 카프카 브로커에 저장된다. 커밋을 하게 된다!
consumer group 이란것을 사용하게 되면 어느 record 까지 읽었는지에 대한 offset을 __consumer_offsets 에 남긴다.
여기서 컨슈머 랙을 확인해볼 수 있는데 지연의 정도를 나타낸다. (마지막 레코드의 오프셋 과 가져간 레코드의 오프셋의 차이)
이 정보는 컨슈머의 상태를 조회할 때 유용하다.
오프셋 리셋이란 기능도 존재하는데 최신의 파티션의 데이터를 조회해볼 수 있는 기능이다. (왜냐하면, 토픽의 데이터는 삭제되지 않고 리텐션 기간에 삭제되기 때문에)
kafka-producer-perf-test.sh/ kafka-consumer-perf-test.sh
퍼포먼스를 측정하는데 사용된다. 네트워크가 정상적으로 처리가 되고 있는지 확인해본다.
'IT' 카테고리의 다른 글
Mongo 7 - 집계 (0) | 2024.03.11 |
---|---|
6장 - 키-값 저장소 설계 (0) | 2024.02.12 |
대규모 시스템 설계 기초 - 5장 (0) | 2024.02.04 |
대규모 시스템 설계 기초 - 4장 (1) | 2024.01.30 |
1/21 개발일기 (clustered index, non-clusted index) (0) | 2024.01.21 |
댓글
이 글 공유하기
다른 글
-
Mongo 7 - 집계
Mongo 7 - 집계
2024.03.117.1 파이프라인 모든 단계의 입력과 출력은 도큐먼트다. 한 번에 입력 도큐먼트 스트림 하나씩 가져와서 각 도큐먼트 하나씩 처리하고 출력 도큐먼트 스트림 생성 각 단계는 knobs, tunables 셋 제공 이 항목 조정해서 각 단계 매개변수로 지정해 원하는 작업을 수행한다. mongod.conf 파일이나 명령줄 옵션을 통해 조정할 수 있다. 예를 들면 캐시 크기 4GB 설정한다고 하면 mongod.conf 파일에 아래 내용을 추가한다. *knobs, tunables → 데이터베이스 성능 최적화 하기 위해 조정할 수 있는 설정 및 매개변수이다. storage: wiredTiger: engineConfig: cacheSizeGB: 4 7.2 익숙한 작업들 일치 → 선출 → 정렬 → 건너뛰기 → 제한 단계가… -
6장 - 키-값 저장소 설계
6장 - 키-값 저장소 설계
2024.02.12시작 키 값 저장소는 비 관계형 데이터베이스이다. 잘 아시다싶이 키 값은 고유 식별자를 키로 가져가야 한다. 문제 이해 및 설계 범위 확정 6장에서 다룰 키-값 저장소 설계는 다음 요건을 충족하는것을 만들것이다. - 키-값 쌍의 크기는 10KB 이하 - 큰 데이터를 저장할 수 있어야 한다. - 높은 가용성 - 높은 규모 확장성 - 데이터 일관성 수준 조정 가능 - 응답 지연시간이 짧아야 한다. 단일 서버 키-값 저장소 한대 서버에 키-값 저장소를 설계해서 해시 테이블에 저장하면 어떨까? 이 방법이 가장 직관적이다. 모든 데이터를 안에 두게 되면 크기가 문제가 될 수 있다. - 데이터 압축 - 자주 쓰이는 데이터 메모리에 두고 나머지는 디스크 저장 임시방편으로 이런 제시를 할 수 있겠지만 서버를 무한정 늘… -
대규모 시스템 설계 기초 - 5장
대규모 시스템 설계 기초 - 5장
2024.02.04가상 면전 사례를 읽다보면 백엔드를 깊이있게 이해하고 있다는 느낌이 든다. 느낌만….? 바로 5장을 보기 시작해보자. 5장은 안정 해시 설계에 대한 퀘스천이다. 안정 해시란 키워드에 대한 정의부터 시작해보자. 주어진 입력에 대해 항상 동일한 해시 값을 생성하는 해시 함수를 의미한다. 파일이 변경되어 있지 않는 다면 항상 동일한 해시 값을 반환하여 파일이 변하지 않았음을 의미한다. 여기서 몇가지 고려해볼것이 있다. 바로 gogo ~ 해시 키 재배치 문제 N개의 캐시 서버에 부하를 균등하게 나누는 방법은 해시 함수를 사용하는 것이다. 예를 들어서 hah(key0) % 4 = 1 이면 서버 1에 접속하는 것이다. 서버 풀 크기가 고정되어 있을때만 효과가 있는 방법이다. 해시 값은 변하지 않지만 키가 줄어들어… -
대규모 시스템 설계 기초 - 4장
대규모 시스템 설계 기초 - 4장
2024.01.30오랜만에 책을 펼쳐보았는데 4장 부터 시작한다 1-3장은 내용은 좀 노멀한거 같아서 스킾… 4장은 처리율 제한 장치의 설계이다. 처리율 시스템, 네트워크에서 얼만큼 처리할지 그 양을 의미한다. 그러니까 얼만큼 성능 좋은 시스템을 만들껏이냐의 얘기가 되겠다… 책에서는 클라이언트가 보내는 트래픽의 처리율 (rate) 제어하기 위한 장치로 소개되어 있다. 예시를 하나 들어주는데 사용자는 초당 2회 이상 새 글을 올릴 수 없다. 같은 ip주소로 하루에 10개 이상 계정 생성 금지 같은 디바이스로 주 5회 이상 리워드 요청 금지 이런 제한으롤 처리율 제한 장치를 설계한다. 처리율 제한 장치를 설계할 때 이렇게 제한을 두는 까닭은 몇 가지 장점이 있는듯 하다. Dos 방지 - limit이 없다면 API Call…
댓글을 사용할 수 없습니다.