일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- JPA 공부
- 카프카
- K8S
- 기술면접공부
- 스프링공부
- Flutter
- 코테공부
- 자료구조공부
- 스프링부트
- JPA예제
- 플러터 개발
- JPA
- 코테준비
- 플러터 공부
- 프로그래머스
- DDD
- nestjs
- 기술공부
- 스프링부트공부
- 스프링
- 알고리즘공부
- nestjs공부
- 자바공부
- Kafka
- nestjs스터디
- JPA스터디
- querydsl
- Axon framework
- 스프링 공부
- JPA공부
- Today
- Total
목록카프카 (13)
DevBoi
카프카 토픽을 사용할때 가장많이 사용하는 도구이다. 프로듀서 애플리케이션을 개발해서, 토픽에 메시지를 발행하고 일반적인 환경에서는 Producer 애플리케이션을 개발해서 토픽에 메시지를 넣는다. 카프카의 데이터는 시작점이 프로듀서이다. 프로듀서 애플리케이션은 카프카에 필요한 데이터를 선언하고 브로커의 특정 토픽의 파티션에 전송한다. 프로듀서는 리더 파티션이 있는 브로커와 통신하게 된다. 즉 프로듀서는 토픽의 리더파티션을 가지고있는 브로커와 통신하고 다른 팔로워 파티션은 이를 복제한다. 또한 이런 애플리케이션이 자바가 아닌 라이브러리를 사용하면, 공식적으로 지원하는 라이브러리가 아니기떄문에 문제가 발생할 수 있다. 따라서 자바로 개발하는게 좋다. 파티셔너,배치생성 단계를 거치고 데이터를 브로커로 전송하게 ..
컨슈머 그룹에 대한 걸 알아보자. 컨슈머 그룹으로 생성된 컨슈머로 해당 토픽에 대한 데이터를 가져갔다. 컨슈머 그룹은 따로 생성하는 명령을 날리지 않고 컨슈머를 동작할 때 컨슈머 그룹이름을 지정하면 새로 생성된다. 또한 어떤 컨슈머 그룹이 어떤 토픽을 대상으로 레코드를 가져갔는지 그리고 상태와 오프셋 컨슈머 렉 컨슈머 ID,호스트 등을 알 수 있다. (컨슈머 렉 - 현재 레코드의 오프셋과 마지막 레코드의 차이이다 ,즉 컨슈머가 읽지않은 데이터라고 이해하면 된다.) 컨슈머의 상태를 조회할때도 유용하다. 또한 컨슈머그룹의 오프셋을 리셋할 수 있다. 오프셋의 리셋은 처음부터 시작되는 것만은 아니다. 특정 오프셋으로 이동할 수 있는 것이다. 순차처리가 필요없는 경우, 최신의 데이터로 오프셋을 이동할 수 있다는 ..
hello.kafka 토픽에 데이터를 넣을수 있는 명령어를 실행해보자 키보드로 문자를 작성하고 엔터키를 누르면 별다른 응답없이 메시지 값이 전송된다. kafka-console-producer.sh 쉡 스크립트를 사용하면 된다. 그리고, 메시지를 보낼때 separator를 선언하면, 메시지키를 구분자로 사용할 수 있다. 메시지 키를 동일하게 쓰면, 같은 파티션으로 들어가게 된다. 즉 동일한 메시지키를 쓰면, 같은 파티션으로 들어가게 된다. 메시지 키가 Null인 경우, 라운드 로빈으로 전송한다. 즉 여러 파티션에 들어가게 된다. 실습 해보자 bin/kafka-console-producer.sh --bootstrap-server my-kafka:9092 --topic hello.kafka 이렇게 하는 경우 ..
1. 카프카 바이너리 파일 다운로드 https://kafka.apache.org/downloads Apache Kafka Apache Kafka: A Distributed Streaming Platform. kafka.apache.org 2.디렉토리 구조확인 kafka 2.8버전을 받았다. 2.12는 스칼라 버전이다. bin은 바이너리나 쉘 스크립트가 포함되어있다. config에는 설정에 필요한 여러 설정파일들이 libs 브로커를 실행할떄 필요한 라이브러리가 있다. 해당 폴더 내에 추가로 data 디렉토리를 생성한다. 이는 데이터를 적재하기 위함이다. 3. 내용 살펴보기 config/server.properties는 브로커를 실행할때 필요한 설정 들이다. # Licensed to the Apache So..
카프카 클라이언트는 메타데이터를 요청하고 응답받는다. 클러스터는 브로커가 여러개일 수있다. 리더 파티션이 몇번 브로커에 있는지 알수있는 메타데이터를 요청하고 전달 받는다. 카프카 프로듀서 메타데이터 옵션 -metadata.max.age.ms : 메타데이터를 강제로 리프래시하는 간격, 기본 5분이다. -metadata.max.idle.ms : 프로듀서가 유휴 상태일 경우, 메타데이터를 캐시에 유지하는 기간이다. 카프카 클라이언트는 반드시 리더파티션과 통신해야한다. 그게 아니라면, Exception이 발생된다. 대부분, 메타데이터 리프래쉬 이슈로발생하고, 해당 리프레쉬 기간에 대한 재설정이 필요하다. 파티션과 리더파티션의 개념을 살짝 추가로 얘기하면 아래와 같다. 브로커는 파티션으로 이루어져있고, 이 파티션..
토픽 이름에는 제약조건이 있다. -빈문자열은 지원하지 않는다. -마침표나 마침표둘로 생성될수는 없다. -토픽이름은 영어대소문자 0~9 마침표언더파,하이픈 조합으로 생성가능하다. -동일한 이름으로는 생성이 불가능하다 -마침표와 언더바가 동시에 들어가면 안된다.(워닝 발생됨) 의미있는 토픽이름을 작명하는 법 모호하게 작성하면 망한다. 토픽 이름 변경이 안된다. 아래의 방법으로, 생성하는 것을 추천한다고 한다. 되도록이면 이런식으로 최대한 세분화하여, 토픽이름에 데이터를 넣도록 하자. 예시로는 .json을 넣을수가 있는데 이는 컨슈머가 데이터를 받아서 역직렬화를 할떄, 유용하게 사용된다. json이던 뭐든 데이터타입을 포맷에 적게되면 해당 사용시에 유용하다.
카프카의 레코드의 구조는 아래와 같다. 프로듀서가 생성한 레코드가 브로커로 전송되면 오프셋과 타임스탬프가 지정되어 저장된다. 전송할때는 당연히 지정하여 보내는 것이 아니다. 1. 타임스탬프 타임스탬프는 스트림 프로세싱에서 활용하기 위한 시간을 저장하는 용도로 사용된다. Unix timstamprk 포함되며 프로듀서에서 따로 설정하지 않으면 기본값으로 ProducerRecord 의 생성 시간이 들어간다. 적재시간으로 변경할 수도있다. 2. 레코드 - 오프셋 프로듀서가 생성한 레코드에는 존재하지 않는다. 프로듀서가 전송한 레코드가 브로커에 적재될때 오프셋이 지정된다. (0부터 1씩 증가한다.) 컨슈머는 오프셋을 기반으로 처리가 완료된 데이터와 앞으로 처리해야할 데이터를 구분한다. 각 메시지는 파티션별 고유한..
토픽이라는 개념과 파티션이라는 개념이 있다. 토픽은 한개이상의 파티션으로 이루어져있고, 각각의 파티션은 큐 형태로 들어가있다. 위 그림 처럼 프로듀서에서 레코드의 값이 파티션으로 들어가게 되면, 각각의 파티션의 큐에 해당 데이터가 쌓이게 된다. 컨슈머가 데이터를 가져가도, 데이터가 삭제 되지않는다. 토픽 생성시 파티션이 배치되는 방법은 아래와 같다. 브로커 3개에서 토픽이 생성되는 것을 예시로 들어보자 기본 라운드로빈 방식으로, 순차적으로 리더 파티션이 분배된다. 프로듀서가 각각의 리더파티션과 통신을 할때 한개의 브로커에 몰리는것이 아니라, 브로커를 균등하게 나눠서 통신할 수 있는것이 장점이 된다. 데이터가 많아지더라도, 한개의 브로커와 통신하는 것이 아닌 선형 확장되는 것을 알 수 있다. 리더 파티션이..
ISR은 리더 파티션과 팔로워 파티션이 모두 싱크가 된 상태를 뜻한다. 싱크는 : 오프셋의 개수가 같다는 뜻이다. 즉 리더파티션의 데이터가 모두 팔로워 파티션의 데이터에 복제가 되었다는 것을 뜻한다. ISR 장애 상황에서 중요하다. 리더 파티션이 장애가 나고 ISR이 되기 전에 새로운 리더가 선출이 되면 아직 리더 파티션 의 데이터가 복제가 다 되지 않는 상태에서 리더 파티션이 바뀌게 되고 이는 곧 데이터 유실이 된다. 따라서 해당 ISR이후에 리더 선출에 대한 옵션은 중요하다. unclean.leader.election.enable=true -> 유실을 감수함, 복제가 안된 팔로워 파티션을 리더로 승급 unclean.leader.election.enable=false -> 유실을 감수하지 않음 해당 브..
데이터 복제는 카프카를 장애 허용시스템으로 동작하도록 하는 원동력이다. 복제의 이유는 클러스터로 묶인 브로커 중 일부에 장애가 발생하더라도 데이터를 유실하지 않고 안전하게 사용하기 위함이다. 카프카의 데이터 복제는 파티션 단위로 이루어진다. 브로커에서 장애가 발생하면 데이터 유실이 발생될 것으로 예상되는데 각각의 데이터를 브로커의 파티션 단위로 복제를 하여, 장애가 나더라도, 데이터를 유실하지 않게 된다. 토픽을 생성할때, replication factor도 같이 설정이 되는데, 이를 설정하지 않으면 브로커에서 설정한 기본값으로 따라간다. 최소값은 1 이고 최대값은 브로커의 개수만큼 설정할 수 있다. 2~3으로 대게 설정한다. 3으로 설정하는 경우, 위와 같고, 파티션이 1개가 되고, 2개가 팔로워로 복..