소개
#Kafka #Streaming #DataEngineer
- 카카오 데이터 엔지니어(전: SK플래닛)
- 저서
- 아파치 카프카 애플리케이션 프로그래밍 with 자바
- 예스24: https://bit.ly/3uFmhpF
- 교보문고: https://bit.ly/39Pk0Ak
- 알라딘: https://bit.ly/3a3Xa7T
- 실시간 데이터 파이프라인 아키텍처
- 예스24: https://bit.ly/3JjY96j
- 교보문고: http://bit.ly/3WEcgGJ
- 알라딘: https://bit.ly/3Hcbwmz
- 아파치 카프카 애플리케이션 프로그래밍 with 자바
강의
전체2로드맵
전체1수강평
- 강의가 깔끔 합니다 !
씽쌩쏭
2024.07.18
0
- 빠르게 살펴 볼수 있어 좋네요!
Hyeong-su Mun
2024.06.02
0
- 카프카 기초 설명을 들을 수 있어 좋았습니다.
jgw8647
2024.05.31
0
게시글
질문&답변
2024.07.22
특정 브로커에 파티션이 쏠리는 현상
안녕하세요! 파티션이 특정 브로커에 몰리는 현상은 여러 원인이 있을 수 있는데요. 가장 흔히 발생하는 원인 중 하나는 브로커의 개수 변경에 의한 부분입니다. 예를 들어, 브로커3대에 파티션6개의 토픽이 생성된다고 가정한다면, 다음과 같이 파티션들이 분배될 것입니다. 파티션 0 -> 브로커 0 파티션 1 -> 브로커 1 파티션 2 -> 브로커 2 파티션 3 -> 브로커 0 파티션 4 -> 브로커 1 파티션 5 -> 브로커 2 이후에 브로커를 5개로 늘리면 해당 파티션들(리더)이 자동적으로 0부터 4까지 5개 브로커에 분배되지 않습니다. 그대로 유지되기 때문에 이런 현상이 반복되다 보면 일부 브로커에 리더 파티션 개수가 몰릴 가능성이 있습니다. 그리고 리더 파티션의 쏠림 현상 여부는 브로커로부터 JMX와 같은 지표를 통해 각 브로커당 가지고 있는 리더 파티션 개수를 알아낼 수 있습니다. 상세한 모니터링 관련 부분은 아래 내용을 참고하세요 https://docs.confluent.io/platform/current/kafka/monitoring.html#partitioncount
- 0
- 2
- 48
질문&답변
2024.07.09
consumer 재배포시 리밸런싱 이슈
안녕하세요~ 컨슈머를 재배포할 경우 리밸런싱이 발생하는 것이 맞습니다. 그러나 리밸런싱이 일어나는 것은 전혀 문제되는 일이 아닐 수 있으며, 배포시에는 반드시 발생할 수 밖에 없습니다. 다만, 이 리밸런싱이 과도하게 일어나서 데이터의 지연이 발생하거나 로직상 데이터 유실이 발생하는 것이 문제가 될 수 있습니다. 말씀하신 대로 컨슈머와 실제 로직을 따로 돌리는 서버를 운영할 수도 있으나, 만약에 저라면 그렇게 운영하지 않을 것 같습니다. 왜냐하면 그만큼 네트워크 비용이 발생하기 때문이고, 리밸런싱은 배포 외에는 일어나는 일이 거의 없기 때문입니다. 다만, 아키텍처상 필요에 따라 분리하는 경우도 발생할 수 있을것 같네요.
- 0
- 2
- 80
질문&답변
2024.07.09
카프카 스트림즈 애플리케이션이 죽는 경우가 발생하는지
안녕하세요~ 카프카 스트림즈를 사용한 데이터 파이프라인 처리에 대한 질문을 남겨주셨는데, 답변드리겠습니다. 혹시 이렇게 자바 코드로 작성한 스트림즈 애플리케이션이 죽는 상황이 있나요? (부하 또는 기타 문제로...) 스트림즈 애플리케이션은 부하 또는 기타 문제로 인해 언제든지 죽을 수 있습니다. 제대로된 내부 로직 관리가 되지 않는 다면 대표적으로 OOM(Out of Memory)와 같은 상황으로 인해 프로세스가 종료될 가능성이 있습니다. 있을 경우 대비를 한다면 스트림즈 애플리케이션을 자바 코드가 아닌 따로 프로젝트를 만들어(WAS를 따로 생성) 운영을 해야할까요? 스트림즈의 이슈 때문이 아니라 자바 로직으로 인한 장애는 프로젝트를 따로 만들더라도 여전히 장애가 발생할 수 있습니다. 다만, 말씀대로 프로젝트를 기존 로직과 분리하는 경우 장애에 대비하기 쉬워지고 리소스 관리 측면에서 더욱 유용하므로 분리하는 것을 추천드립니다. 스트림즈 애플리케이션이 죽는 경우는 어느정도의 부하(초당 몇 바이트정도인지.. 보통..)가 있어야 죽는 경우가 발생하나요? (CPU성능, 메모리 등 PC스펙이 충분하다고 할 경우에요..) CPU, 메모리 성능이 데이터 처리량에 비해 충분할 경우 죽지 않는다고 볼 수 있습니다. 다만, 잘못된 로직으로 인해 메모리가 관리가 되지 않는다면 성능과 무관하게 자바 프로세스는 죽을 수 있습니다. 만약 WAS를 따로 만들어서 운영해야 한다면, WAS를 보통 여러 개 정도 두나요? 아니면WAS를 1개만 만들고 WAS 내 스트림즈 스레드를 여러 개로 만들어서 운영하나요? 아니면 여러개 WAS에 여러개 스레드를 띄우나요? 따로 스트림즈 애플리케이션을 만들어 운영할 경우 1개 애플리케이션당 스레드 개수는 1개씩 운영하는 것이 가장 효율적입니다. 다만, 파티션 개수가 많을 경우 프로세스 개수가 너무 많아질 가능성이 있으므로 상황에 따라 프로세스당 카프카 스트림즈 스레드 개수 다르게 운영하는 것이 좋습니다. WAS를 여러개 두는 경우, 1개 WAS가 죽으면 자동으로 fail over 가 되나요? 안된다면 어떻게 fail over가 되도록 구현해야 하나요? 카프카 스트림즈 애플리케이션의 경우 여러개 프로세스로 돌릴 때, 일부 프로세스가 죽으면 나머지 프로세스에 리밸런싱 과정을 통해 지속적으로 데이터가 처리되도록 구현되어 있습니다.
- 0
- 2
- 127
질문&답변
2024.06.30
연결 브로커 지정
안녕하세요~ 프로듀서가 토픽에 레코드를 전송할 때, bootstrap.servers 에는 100개 브로커중 아무 브로커 2개만 적어도 됩니다. 왜냐면 최초로 통신을 할 때 meta data 를 sync하게 되는데, 이 때 필요한 정보들(리더 파티션이 위치한 브로커의 ip 등)을 가져오기 때문입니다. bootstrap.servers 에는 일반적으로 2개 이상 브로커 정보를 적는 것이 일반적입니다.
- 0
- 2
- 95
질문&답변
2024.06.23
auto_commit_interval_ms_config 질문
안녕하세요~ 카프카 컨슈머가 오토 커밋으로 설정되어 있을 경우 커밋이 수행되는 시점은 해당 시간이 지난 뒤 poll()이 호출될 때 입니다. 즉, 커밋을 한 뒤 일정 시간이 지나고 time이 expire되면 내부적으로 커밋을 수행하고 그런 뒤에 ConsumerRecords를 반환합니다. /** * If auto-commit is enabled, and the auto-commit interval has expired, this will generate and * enqueue a request to commit all consumed offsets, and will reset the auto-commit timer to the * interval. The request will be sent on the next call to {@link #poll(long)}. * * If the request completes with a retriable error, this will reset the auto-commit timer with * the exponential backoff. If it fails with a non-retriable error, no action is taken, so * the next commit will be generated when the interval expires. * * This will not generate a new commit request if a previous one hasn't received a response. * In that case, the next auto-commit request will be sent on the next call to poll, after a * response for the in-flight is received. */ public void maybeAutoCommitAsync() { if (autoCommitEnabled() && autoCommitState.get().shouldAutoCommit()) { OffsetCommitRequestState requestState = createOffsetCommitRequest( ...생략 관련 코드와 주석은 아래 링크에서 확인하실 수 있습니다. https://github.com/apache/kafka/blob/8a109d87d1673d1540054b1202ad94789ac5cea4/clients/src/main/java/org/apache/kafka/clients/consumer/internals/CommitRequestManager.java#L261
- 0
- 2
- 86