yaml 파일에서80으로 containerPort 를 지정하든 8080으로 지정하든 실행은 80으로 된다고 하셨는데, 이유가 궁금합니다.실행 포트를 변경하는 건 conf 파일에서 설정할 일인가요?

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

쿠버네티스 다음 강의 계획이 있으신가요?강사님 강의가 젤 귀에 잘 들어와서 입문 다음 버전도 듣고 싶습니다.계획이 있으시다면 혹시 언제쯤 들을 수 있을까요?

안녕하세요.  현재 사가패턴을 공부하고 있는 개발자입니다. 제가 알고 있는 내용과 조금 다른 내용이 있어서 궁금증에 물어봅니다.  오케스트레이션 사가를 원래 rest api로 구현하나요? 이것도 카프카 같은 브로커 사용해서 만든다고 알고 있어서요.

안녕하세요. 강사님 강의 잘 들었습니다.한가지 질문이 있습니다.주문 생성과 주문 처리api를 나누고 사용자가 결제가 되면 주문 처리 api를 호출하는걸로 알고있습니다.이때 주문 처리 api에서 Orchestartation 방식으로 OrderConfirmEvent를 발행하면 제 서비스로 예를 들면 재고, 쿠폰, 적립금 서비스에서 consume하여 처리를 하고 있습니다.그런데 주문 처리 api에서 재고는 처리되었지만 쿠폰은 실패할 경우 어떻게 보상 트랜잭션을 주어야할지 모르겠습니다.Orchestartation 방식으로 처리할거면 OrderConfirmEvent로 한번에 처리하는게 아니라 StockConfirmEvent, CouponConfirmEvent, PointConfirmEvent 이렇게 각각 보내주어야 할까요?결제가 된 주문이라 바로 보상을 하는것 보다는 dlt topic에 넣고 재처리를 하고 만약 재시도 3번을 하고 나서 실패할 경우 환불을 해줘야할까요?주문 처리 api에서는 어디가 실패한지 모르니까요 혹시 어떤식으로 해야할지 조언좀 받을수 있을까요?

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

안녕하세요. 강의 전체 수강 후 질문드립니다. Choreography Saga 패턴에서 이벤트 발행 테스트는 Embedded Kafka 없이 행동 검증(verify)만으로 충분한지 궁금합니다.  강의에서 테스트 코드에 대한 내용이 없었는데, 이벤트라는 개념이 도입되면서 테스트를 어떻게 작성해야 할지 고민이 됩니다. 찾아보니 Embedded Kafka를 많이 사용하더라고요.하지만 제 생각에 Choreography 패턴에서 중요한 것은 "이벤트가 올바르게 발행되었는가"라는 행동 검증이라고 생각합니다 그렇다면 이벤트 발행 로직을 Facade 계층으로 분리하고, 테스트에서는 InOrder와 verify()로 발행 여부만 검증하면 충분하지 않을까요? 즉, 이벤트 발행 부분을 Facade 계층으로 올리고 Embedded Kafka를 사용한 통합 테스트는 하지 않아도 된다고 생각하는데, 이 접근 방식이 적절한지 궁금합니다.(추가적으로 Orchestration 방식도 똑같이 생각하고 있습니다. 강사님의 테스트 코드에 대한 생각이 궁금해서 질문을 작성합니다. )

모든 명령어가 정상작동확인하고 크롬 시크릿탭에서 localhost:5000으로 접속하면 html 화면이 보이지 않고, welcome to nginx 화면이 보이는데 어디서 문제가 생겨서 그런걸까요?intelliJ ce 환경에서 index.html, Dockerfile, style.css, web-server-pod.yaml 파일을 작성하였습니다. 

Docker 강의와 마찬가지로 FROM openjdk:17-jdk 로 Dockerfile을 작성하면 에러가 발생합니다. Dokcer강의에서 알려주셨던것처럼 FROM eclipse-temurin:17-jdk 으로 수정해서 실습 진행하면 될까요?

안녕하세요. 11:18분쯤 전체 사용자 조회할 때 강의에서 오류가 나지 않아서 여쭈어봅니다.. apigateway 에서는 yml파일을 바라보는 파일이 ecommerce 이고, user-service에서는 user-service yml파일을 바라보고 있는데 두 개의 secret key 값이 다른데 오류가 안나는 게 정상인가요..?  코드 바뀐 부분을 영상에서 말씀을 안해주셔서 매번 이 강의 깃허브랑, yml 파일들이 들어가있는 깃허브를 확인하면서 진행하는데 깃허브 업데이트가 안된건지 .. 궁금합니다..  제가 임의로 ecommerce secret key값을 application.yml 파일과 동일하게 하니 오류는 해결되었는데.. 강사님 영상 보면서 할 때 오류가 나지 않아야 한다면 제가 잘못 한건지 궁금해요..  https://github.com/joneconsulting/new-toy-msa/blob/ch10-1/apigateway-service/src/main/resources/bootstrap.ymlhttps://github.com/joneconsulting/spring-cloud-config/blob/master/ecommerce.yml

강의를 보고 궁금한 점이 생겨서 질문드립니다.강의에서 구현된 송금 프로세스를 분석해보니,출금은 정상적으로 잔고가 차감되지만 입금 시 받는 계좌의 잔고를 증가시키는 로직이 없는 것 같습니다.예를 들어:- Choreography 방식: handleDepositSuccess() 메서드에서 SagaState만 COMPLETED로 업데이트- Orchestration 방식: Transaction Service에서 deposit 기록만 생성현재와 같이 데이터베이스가 서비스별로 분리된 상황에서,입금 성공 후 받는 계좌의 잔고를 증가시키는 로직을 어떻게 구현해야 하는지 궁금합니다.제가 생각한 방법은:1. Orchestration 방식: Transaction Service의 REST 응답이 성공하면,Account Service에서 받는 계좌의 잔고를 증가시킴2. Choreography 방식: Transaction Service에서 deposit.success 이벤트를 발행하면,Account Service에서 이벤트를 consume하여 받는 계좌의 잔고를 증가시킴이 두 가지 방식으로 접근하는 것이 맞는지,아니면 다른 권장 방법이 있는지 알려주시면 감사하겠습니다.

안녕하세요 강의를 보면서 SAGA 패턴에 대해 공부하면서 궁금한 부분이 생겼습니다코레오그래피 방식으로 주문 비지니스를 구성한다고 할때 메시지 브로커를 통해서 자신의 역할만 수행한다고 하셨는데 그러면 각 서비스가 어떻게 메시지를 설계해야하는지 궁금합니다주문서비스가 주문 요청을 받으면 재고 서비스에 주문한 상품에 대한 재고 감소를 진행하고 마지막으로 결제서비스가 결제를 진행할때 결제에 대한 금액을 결제서비스가 재고 서비스의 API를 통해 상품의 가격을 조회후 결제를 진행하는것인지 아니면 재고 서비스가 재고 감소를 실행하면서 상품의 가격 정보도 같이 재고 감소 성공 메시지에 추가하여 결제서비스가 이 메시지 정보를 통해 결제를 진행하는것인지 궁금합니다

Order 서비스에서 Command가 실행되면 ORDERS_EVENT에 이벤트가 저장되고 Query가 실행되면 ORDER_EVENT에서 이벤트를 읽어 데이터의 최종상태를 읽는다는것으로 이해했는데요..! 그렇다면 ORDERS 테이블은 실질적으로 사용되지 않는다고 이해하면될까요..?

안녕하세요. user, catalog, order 를 보면 엔티티에서 pk 대신 별도의 유니크키를 사용하고 있는데, 특별한 이유가 있을까요 ??이 별도의 유니크 키가 어그리거트 루트로 사용되는걸까요 ??

코드를 한줄 한줄 같이 치면서 학습을 하는데요, 강사님께서도 코드 한줄 한줄 같이 치신다고 하셨으나 이번 , 다음 강의에서는 yml, controller, service, vo등 모든 것이 작성이 되어있더라고요. 따로 설명 하는 부분 없이 바로 서버 실행 하시는 거 보고 당황했습니다.  코드를 직접 쳐가면서 학습을 하고 싶은데 그러지 못한거 같아 아쉽고, 어디 까지 깃허브에서 코드를 가져와서 사용해야 하나 궁금합니다.

127, 128 섹션 관련 문의드립니다.2개의 오더 마이크로서비스 각각에 연결된 데이터베이스로 인한 동기화 문제를 위해 카프카 커넥터를 활용하여 하나의 단일 디비로 문제를 처리한다고 하셨는데, 결국 2개의 오더 마이크로서비스에 카프카 커넥터를 사용하지 않고 동일한 디비 1개를 직접 연결해서 사용하면 동기화 문제가 발생하지 않는건 마찬가지아닌가요? 동일한 오더 마이크로서비스를 스케일아웃 하는 상황에서 카프카 커넥터를 사용하는게 목적에 맞는지 의아해서 질문드립니다.  

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

apiVersion: v1 kind: Pod metadata: name: spring-pod spec: containers: - name: spring-container image: spring-server ports: - containerPort: 8080 imagePullPolicy: IfNotPresentspring-pod.yaml파일을 작성을 한뒤 kubectl delete pod spring-pod 명령어로 pod를 삭제하고
kubectl apply -f spring-pod.yaml 명령어를 입력했는데 계속 사진처럼 ErrImagePull이 됩니다.이미지를 pull로 당겨오지 못해서 발생하는 오류인것 같은데 이미지는 있는것으로 확인 됩니다. 뭐가 문제인걸까요?

재시도조차 실패한 메시지들은 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 이 논블로킹으로 별도 스레드에서 진행이 된다면 순서보장이 안되는거라서 순서보장이 필요하다면 이걸 사용하면 안되는게 아닌가 싶습니다.