안녕하세요! 백엔드 취업 준비생입니다.포트폴리오를 위해 프로젝트를 진행하고 있는데, 강의처럼 EC2 한 대에서 포트만 다르게 설정하여 브로커 3개를 기동해도 괜찮은 지 궁금합니다.운영 환경과 다르다는 지적을 받을 수 있는지 혹은 실습 환경에서는 충분히 이해 가능한 접근이라고 받아들여질지 궁금합니다.실제 현업에서는 어떻게 판단하시는지 의견을 들을 수 있다면 큰 도움이 될 것 같습니다.감사합니다.

선생님 스타일은 보통 로컬에서 연습하고 그다음 배포 하고 실습 하는 스타일이셨는데 왜 카프카 수업은 바로 aws로 가시는지 궁금합니다.도커 허브에서도 카프카 이미지를 제공하는거 같은데 뭔가 스타일이 달라지시니 따라가기 힘듭니다..

회사에서 realtime 음성 인식기 구현할 일이 생겼는데, 음성의 청크 단위 큐를 어떤식으로 관리하는지 찾아보다가 kafka 를 알게되어서요. 10~50명 정도의 동시접속자라고 한다면 어떤방식을 사용해야하는지 궁금합니다.

재시도조차 실패한 메시지들은 dlt 로 이동하게 되고 이 메시지들에 대한 처리를 위해 @KafkaListner 를 사용해서 처리하는 방법을 보여주셨는데요. 리서치를 하다보니 @DltHandler 기능이 있는걸 알게됐습니다.  dlt 를 처리한다는 부분에서 @DltHandler 가 좀 더 어울릴거 같은 느낌인데 @KafkaListener 로 처리하신 특별한 이유가 있으실까요?

kafka @RetryableTopic 에 대해 알아보다보니 궁금한점이 생겨 질문 드립니다. @RetryableTopic 가 없어도 retry 는 기본적으로 진행하는거 같은데요. 제가 알아본 바로는 아래와 같은 차이점이 있는것 같았습니다. @RetryableTopic 을 사용하지 않으면 'dlt' 로 메시지가 이동되지 않는다.@RetryableTopic 을 사용하면 'dlt' 토픽이 없는 경우 자동으로 만들어주고 dlt 토픽으로 메시지를 이동시켜준다.@RetryableTopic 을 사용하지 않으면 재시도는 하지만 재시도동안에는 partition 을 blocking 한다 (= 블로킹).@RetryableTopic 을 사용하면 재시도 하기전에 retry 토픽으로 이동시키고 consumer 의 스레드를 blocking 하지 않고 별도 스레드에서 retry 를 진행한다. (= 논블로킹)강좌에서는 retry 중에는 partition 이 blocking 된다고 하셨는데, 그 부분과 좀 다른거 같아서 문의 드립니다..! 만약 @RetryableTopic 이 논블로킹으로 별도 스레드에서 진행이 된다면 순서보장이 안되는거라서 순서보장이 필요하다면 이걸 사용하면 안되는게 아닌가 싶습니다.

예제에서는 StringSerializer 와 StringDeserializer 를 사용하도록 설정하고 ObjectMapper 를 통해 직렬화/역직렬화를 해주셨는데요. 혹시 JsonSerializer 와 JsonDeserializer 를 사용하지 않는 이유가 있을까요? 그리고, JsonDeserializer 를 사용하든 StringDeserializer 를 사용하든 역직렬화를 할 때 실패하게 되면 offset commit 이 되지 않고 재시도를 하는동안 해당 message 의 partition 은 blocking 된다고 이해하고 있는데 맞을까요?  이 경우에도 retry 이후, 해결 안되면 dlt topic 으로 이동하는게 맞을까요?

리서치를 하다보니 실무에서는 auto.create.topics.enable=false 설정을 사용하는게 좋다는 글을 많이 보게 되었습니다. 네이밍 컨벤션이나 예상치 못한 topic 의 생성 등을 방지하기 위함으로 이해했는데요. 그럼, xxx.dlt 와 같은 topic 들도 직접 생성을 해줘야 하는지 궁금합니다. 그리고, 실제로 실무에서 해당 설정을 많이 사용하는지 또한 궁금합니다 🙂

consumer 쪽에서 이메일 발송 로직 대신 Thread.sleep(3000) 을 써주셨는데요.이 말은, consumer 쓰레드 자체에서 이메일 보내는 로직을 실행한다고 가정해서 그런거라고 이해했습니다. 개인적으로 consumer 는 message 를 consume 만 하고, 실제 비즈니스 로직 (email send) 는 별개의 쓰레드로 async 하게 동작하는게 더 효율적이라고 생각이 되는데요. email 발송 로직을 별개의 쓰레드로 할 때와 현재처럼 consumer 쓰레드에서 할 때 차이점 및 주의해야할 점 (ex. offset 수동 커밋 등) 이 있을까요?

concurrency 관련하여 궁금한점이 있습니다. 하나의 topic (ex. email.send) 에 5개의 파티션이 있다고 가정. 같은 groupId 로 지정된 consumer 2 (A, B)개가 있고 각각 concurrency=3 으로 설정이 되어 있다고 가정 이런 경우, 같은 groupId 내의 컨슈머는 같은 partition 을 consume 할 수 없으니 1개의 thread 는 동작하지 않게 된다고 보면 될까요?A-1 thread ===> partition 1 A-2 thread ===> partition 2 A-3 thread ===> partition 3 B-1 thread ===> partition 4 B-2 thread ===> partition 5 B-3 thread (동작안함) ====> x추가로 실무에서는 일반적으로 concurrency 옵션을 사용하는지 궁금합니다.

하나의 consumer 에서 concurrency 옵션을 통해 멀티 쓰레드로 동작이 되는지 테스트를 해봤는데 강좌화면에서처럼 consumer 가 멀티스레드로 동작하지 않는것 같습니다. partition : 3개concurrency : 3partitional.class: org.apache.kafka.clients.producer.RoundRobinPartitional 로그 : 로그를 봐서는 roundrobin 으로 설정을 했음에도 하나의 partition 으로 메시지가 들어가는것 같습니다. 그리고, consumer 도 하나의 스레드로 message 를 consume 하는것으로 보입니다.2025-10-15T16:01:15.466+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.OrderService : Received message {"name":"Product-4","price":4000} 2025-10-15T16:01:17.473+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.Refresher : Done processing order.. 2025-10-15T16:01:17.474+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.OrderService : Received message {"name":"Product-8","price":8000} 2025-10-15T16:01:19.480+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.Refresher : Done processing order.. 2025-10-15T16:01:19.481+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.OrderService : Received message {"name":"Product-16","price":16000} 2025-10-15T16:01:21.485+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.Refresher : Done processing order.. 2025-10-15T16:01:21.486+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.OrderService : Received message {"name":"Product-15","price":15000} 2025-10-15T16:01:23.491+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.Refresher : Done processing order.. 2025-10-15T16:01:23.491+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.OrderService : Received message {"name":"Product-5","price":5000} 2025-10-15T16:01:25.494+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.Refresher : Done processing order.. 2025-10-15T16:01:25.495+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.OrderService : Received message {"name":"Product-18","price":18000} 2025-10-15T16:01:27.499+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.Refresher : Done processing order.. 2025-10-15T16:01:27.501+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.OrderService : Received message {"name":"Product-3","price":3000} 2025-10-15T16:01:29.510+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.Refresher : Done processing order.. 2025-10-15T16:01:29.510+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.OrderService : Received message {"name":"Product-9","price":9000} 2025-10-15T16:01:31.514+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.Refresher : Done processing order.. 2025-10-15T16:01:31.515+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.OrderService : Received message {"name":"Product-13","price":13000} 2025-10-15T16:01:33.522+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.Refresher : Done processing order.. 2025-10-15T16:01:33.522+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.OrderService : Received message {"name":"Product-1","price":1000} 2025-10-15T16:01:35.527+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.Refresher : Done processing order.. 2025-10-15T16:01:35.529+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.OrderService : Received message {"name":"Product-11","price":11000} 2025-10-15T16:01:37.532+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.Refresher : Done processing order.. 2025-10-15T16:01:37.532+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.OrderService : Received message {"name":"Product-19","price":19000} 2025-10-15T16:01:39.538+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.Refresher : Done processing order.. 2025-10-15T16:01:39.538+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.OrderService : Received message {"name":"Product-7","price":7000} 2025-10-15T16:01:41.539+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.Refresher : Done processing order.. 2025-10-15T16:01:41.539+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.OrderService : Received message {"name":"Product-6","price":6000} 2025-10-15T16:01:43.543+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.Refresher : Done processing order.. 2025-10-15T16:01:43.544+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.OrderService : Received message {"name":"Product-20","price":20000} 2025-10-15T16:01:45.554+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.Refresher : Done processing order.. 2025-10-15T16:01:45.555+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.OrderService : Received message {"name":"Product-10","price":10000} 2025-10-15T16:01:47.560+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.Refresher : Done processing order.. 2025-10-15T16:01:47.560+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.OrderService : Received message {"name":"Product-14","price":14000} 2025-10-15T16:01:49.566+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.Refresher : Done processing order.. 2025-10-15T16:01:49.566+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.OrderService : Received message {"name":"Product-17","price":17000} 2025-10-15T16:01:51.568+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.Refresher : Done processing order.. 2025-10-15T16:01:51.568+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.OrderService : Received message {"name":"Product-2","price":2000} 2025-10-15T16:01:53.575+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.Refresher : Done processing order.. 2025-10-15T16:01:53.577+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.OrderService : Received message {"name":"Product-12","price":12000} 2025-10-15T16:01:55.581+09:00 INFO 11736 --- [kafka-practice] [ntainer#0-2-C-1] c.w.kafkapractice.service.Refresher : Done processing order.. github 소스코드 : https://github.com/writer0713/kafka-practice/blob/4cee9e560b2459c4bcbb6b183f3791d70cddd3d1/src/main/kotlin/com/writer0713/kafkapractice/service/OrderService.kt#L34

만약 카프카를 사용하고 있고 처리 실패하는 경우 retry 큐로 보내서 재시도 하는 방식을 사용하고 있다고 가정하겠습니다. 만약 서버가 메시지를 받아서 처리하던 중에 리밸런싱이 발생했습니다. 메시지를 성공적으로 처리했고 커밋을 하려했지만 리밸런싱이 발생해 커밋을 하지 못했습니다. 그럼 그 메시지는 다른 컨슈머가 다시 받아서 중복으로 처리할 수 있을것 같은데 어떻게 방지를 할 수 있나요..? 찾아보니 인박스 패턴이라는것이 있던데 메시지를 받았을 때 상태를 저장하고 이후에 재시도를 해도 상태값이 있다면 패스하는 방식으로 이해를 했습니다. 하지만 위에 상황에서 첫 컨슘에서 메시지를 처리하고 있다가 리밸런싱이 발생했고 이후에 다시 처리할 때 상태값이 있어서 패스 했습니다. 하지만 이후에 첫 컨슘에서 처리중에 예외가 발생했다면 어떻게 처리를 해야할까요...?

이론 부분을 제가 이해를 잘 못해서 질문드리는 것 같은데요,Kafka와 Debezium 까지의 전반적인 그림은 그려지는데temporal(acitivity나 workFlow클래스 등) 까지 합쳐졌을 때의 플로우가 잘 이해가 가지 않는데구상하신 아키텍처를 모두 합친 플로우가 궁금합니다!

교육을 듣다보니 Temporal에 대해서 더 알고 싶은데Temporal 공식 사이트는 너무 방대하고, 사용법 위주로 설명되어 있어서, 혹시 내부 아키텍처 같은 내용을 참고할 수 있는 자료가 있을까요?

컨슈머 서버가 3대 떠있을때 점진적 배포를 어떤식으로 진행하시나요? 기존 서버군을 죽이면 리밸런싱 되겠지만, 신규 배포에 문제가 생겼다고 판단될때 즉각적인 롤백이 안될것 같은데요. 어떤식으로 하시나요?

자료를 다운로드 하면, 윈도우에서는 대부분의 압축파일 내에 파일이 없다고 나옵니다. Mac에서 작업하셔서 그런 것 같은데 확인 부탁드립니다. 

안녕하세요이번에 수강하려고 하는데 코틀린 한 번도 안 해봤는데 이 수업은 무리일까요?계속 자바만 사용했던 상태이고 아직 코틀린 배울 생각은 없는데 이 수업은 듣고 싶어서 여쭤봅니다 ㅠㅠ감사합니다.

이 에러가 자꾸 뜨는데 어떻게 해결해야 할지 감이 안 잡혀 질문 들빈다.서버를 다시 키고 해도 똑같은 에러가 계속 발생합니다.

안녕하세요 강사님 질문을 자주올리는것같아 죄송하고 답변달아주셔서 감사합니다.pdf에 나온것처럼 프로듀서가 보내는 메시지량은 120하나의 쓰레드가 처리하는 메세지량 0.3 을기준으로토픽의 파티션을 400개로 생성했을때어플리케이션 서비스의 max 스레드가 기본값 200이라 가정하에 파티션 400개를 처리하려면 스레드가 200개가 더 필요하니 대부분 실무에서는 200 스레드 기준으로 2개의 컨슈머 서비스를 구동시키나요?추가로 부하테스트 강의에도 지금 강의에 설명되는 파트가 ( 카프카 파티션구하기 관련? ) 따로 있는지도 궁금합니다

안녕하세요 강사님지금은 샘플 프로젝트라 하나의 컨슈머 서버에서파티션3개를 처리하고있는데만약 email.send topic기준으로 파티션을 5개 생성했을때 컨슈머 서버도 5개를 띄우는게 일반적인가요?실무기준으로 궁금합니다추가로 하나의 컨슈머에서 지금은 email.send 토픽만 구독하고있는데 만약 토픽이 slack.send , telegram.send 등 여러가지가 있을경우 컨슈머 어플리케이션에서 카프카리스너를 다중으로 등록하는게 일반적인가요 아니면 각 토픽마다 서비스를 띄우는게 일반적인가요?만약 각 토픽마다 서비스를 띄운다가정했을때email.send topic 파티션 5개 => 서비스 5개 구동 필요slack.send topic 파티션 3개 => 서비스 3개 구동 필요총 8개가 띄워지는게 일반적인건지 .. 실무기준으로 궁금합니다

aws 인스턴스 종료를 하는 경우 퍼블릭 ip가 바뀌어 proeprties내용을 변경해야하는 상황이 계속 발생하는데 도커로 진행해도 강의 수강에 지장없을까요?