예제에서는 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 옵션을 사용하는지 궁금합니다.
안녕하세요 강사님 질문을 드리고 싶은 부분이 있는데요 MSA 아키텍쳐로 개발할 때 각각의 서비스 마다 단일 배포할 수 있다는 장점이 있다고 들었는데 그러면 MSA 아키텍쳐로 개발을 진행할 때 보여주신 것 처럼 하나의 큰 프로젝트 안에 각각의 마이크로 서비스를 넣어서 만드나요? (모노레포?) 혹은 각각의 마이크로 서비스를 독립적으로 만드는건가요? (폴리레포?) 만약 둘 다 사용한다면 주로 사용하는 방식은 어떤 방식인가요?
윈11에 docker desktop과 wsl 을 연동하여 쓰고 있습니다. 리눅스 명령어가 더 익숙해서.. 수업 내용대로 다 잘 따라했습니다. deployment, service, pod 모두 정상적으로 작동이 됩니다. 하지만 localhost:30000으로 접속시 연결 거부가 뜨고, kubectl port-forward service/spring-service 30000:8080 으로 직접적으로 포트 포워딩을 해준 후에야 localhost:30000이 접속이 됩니다. 어떻게 해야 포트 포워딩 작업 없이 바로 서비스에 접근 가능할까요..? 뭘 설정해야 하는지 모르겠습니다
안녕하세요! 덕분에 아키텍처에 대한 큰 그림을 그려보며 강의를 듣고 있습니다. MSA 전환 시점 관련해서 질문 드립니다. 모놀리식 아키텍처에서 MSA로 전환하는 적절한 시점은 어떤 기준으로 잡는게 좋을까요? 물론 상황마다 다르겠지만, 강사님은 어떤 기준을 가장 중요하게 생각하시는지 궁금합니다. 예를 들어, Scale-out 한계, 빌드&배포 시간 증가, 혹은 서비스 크기와 복잡성 같은 요소들.. 이 있을 것 같은데 제가 미처 생각 못한 부분이 있다면 덧붙여 답변 부탁드립니다. 감사합니다!
안녕하세요 강사님 카프카에서 컨슈머가 메시지를 읽은 후 처리 과정에서 실패했을 때 재처리 전략을 어떻게 잡으면 좋은지 궁금합니다. consume 이후 비즈니스 로직 실행중에 예외가 발생하여 실패한 경우 OOM 등의 이유로 서버가 비정상적으로 종료되어 실패한 경우 위의 두가지 상황에서 일반적으로 어떻게 처리하는지 궁금합니다.
안녕하세요! 시스템 개발 및 설계 과정에서 '대규모 시스템', '분산 환경', '분산 데이터 모델링'과 같은 개념들을 본격적으로 고려하고 도입해야 하는 시점은 언제일까요? 실무에서 경험해보지 못해서 '대규모' 라는 말이 막연해서 실무에서 어떤 것을 기준으로 고려하는지 혹은 지표 같은 것을 측정하는 방법이 있는지 궁금해서 질문 드립니다!
안녕하세요. 강의 잘 듣고 있습니다! 강의 2개째 듣고 있는데 항상 초보자들이 이해하기 쉽게 잘 설명해주시는 것 같아요! 그리고 질문을 드리자면, 카프카 적용 전에는 다음과 같은 프로세스로 진행됐었죠. 그리고 동시에 3.활동 점수 부여에서 실패하면 1,2에 보상트랜잭션을 적용하는 saga패턴을 사용했었는데요. 포인트 차감 게시글 저장 활동 점수 부여 근데 카프카를 적용하면서, 만약에 3. 활동 점수 부여(=consumer) 에서 에러가 발생하면 producer쪽인 board-service에서는 이를 감지할 수 없기때문에, 기존에 작성했던 SAGA 패턴이 의도한대로 동작을 안할 것 같은데... 제가 이해한게 맞을까요? 카프카 이점을 도입하기위해 어쩔 수 없이 SAGA 패턴의 이점을 뒤로 미루도록 설계한 것인지가 궁금합니다! 제가 놓친부분이나 잘 못 이해한 부분이 있거든 답변 부탁드리겠습니다! 남은 연휴 잘 보내시길 바라겠습니다 감사합니다 😃
우선 좋은 강의 정말 잘 들었습니다. 감사합니다. 그동안 파편화되어 있던 "어떻게 도메인을 분리하는가"에 대한 질문이 강의를 토대로 많이 깔끔해질 수 있었습니다. 말씀 주신 방식을 토대로 현재 신규 도입하고 있는 서비스를 이벤트 스토밍을 토대로 구체화해 보고 있는데요. 아무래도 강의가 제작되고 나서 시간이 좀 흐른 만큼, 현재에도 해당 방식을 토대로 설계를 해 가시고 계신지, 뭔가 더 좋은 방식이 추가되셨을지 궁금합니다!
안녕하세요. 강의 재밌게 잘 듣고있습니다. 섹션 2 - 12 목차가 Modular Monolithic Architecture 소개로 되어있는데, 실제 강의 내용이 Layered Architecture 관련 내용인 것 같습니다. 목차 명이 의도하신 것이 맞는지 궁금해서 질문드립니다!
예시로 들었던 '게시판 별 게시글' 같은 인덱스 테이블에서 B Tree 인덱스를 사용하면 된다는 식으로 말씀하셨습니다. 근데 전통적인 RDBMS에는 샤딩 기능조차 존재하지 않는데, 분산된 데이터베이스에서도 테이블 수준의 B Tree 인덱스처럼 동작하는 것처럼 말씀하신 것 같아, 이것이 맞는지 문의 드립니다.
