안녕하세요!강의를 모두 학습하고, 실습도 진행하면서 오케스트레이션 방식을 적용해보고 있는데 궁금한 점이 있어 질문드립니다. 현재 실습 환경에서는 service_1이 단일 진입점 역할을 하면서 Account 관련 로직까지 함께 처리하고 있습니다.그런데 실무에서는 이 두 역할을 분리하는 것이 맞는지 고민되고 있습니다. 제가 생각하기로는, 명확한 Orchestrator 서비스가 존재하지 않으면 각 서비스가 상황에 따라 오케스트레이션 역할을 맡게 되고, 시간이 지나면서 구조가 복잡해지고 유지보수에 많이 불리할 것 같습니다. 그래서 실제 운영 환경에서는 다음과 같은 구조가 더 적절한지 여쭙고 싶습니다.orchestration-service → account-service → ... 즉, 오케스트레이션만 담당하는 서비스를 별도로 두고, 각 도메인 서비스는 자신의 책임만 수행하도록 설계하는 것이 맞을까요? 좋은 강의 감사합니다! 많이 배우고 있습니다!

안녕하세요 강의 열심히 보고 분산트랜잭션에 대해 배워가고 있습니다. 우선 좋은 강의 만들어주셔서 감사합니다. 강의를 보다가 OrchestrationService 소스 코드 설명해주시는 부분에서 궁금증이 생겨 질문드렸습니다. 현재 하나의 트랜잭션 내에서 출금처리에 대한 로컬 트랜잭션 처리 + 입금 서비스 REST 호출 + 입금 서비스 응답이후 SAGA 상태 업데이트 까지 처리하고 있는 것으로 보입니다. 이 경우에 입금 서비스에서 응답이 지연된다면 출금계좌에 대한 락은 지연시간만큼 대기를 하게 되고 트래픽이 몰리는 상황에서는 처리 성능이 떨어질것 같다고 판단했습니다. 그래서 제 생각에는 입금 서비스 호출 이전, 입급 서비스 호출 후 응답값에 대한 saga 업데이트, 출금 서비스 보상 처리 이렇게 3개의 로직을 각각 별개의 트랜잭션으로 선언해야 하지 않나 싶은데, 강사님의 의견이 궁금합니다!

안녕하세요! 궁금증이 생겨 문의 드립니다.common 공통 모듈은 서비스간 통신 데이터 구조를 표준화해서 통일성 있게 사용하기 위해서 사용한다고 이해하였습니다. 현재, 멀티모듈로 작성된 프로젝트라서 common 모듈을 작성된 것 같은데, 각각 독립적인 repository 로 운영된다면 이를 극복하기 위해 Nexus 같은 repository 에 관리하여 공통 dto 를 관리하는 방법은 어떤지 문의 드립니다. 적다 보니, 분산 환경에 대한 질문은 아니라서 죄송합니다...

protoc --go_out=. --go_opt=paths=source_relative \ --go-grpc_out=. --go-grpc_opt=paths=source_relative \ proto/shopping.proto protoc-gen-go: program not found or is not executable Please specify a program using absolute path or make sure the program is available in your PATH system variable --go_out: protoc-gen-go: Plugin failed with status code 1.위 처럼 강사님이 주신 명령어를 입력하니깐 플러그인을 설치하라고 나오더라구요! sudo go install google.golang.org/protobuf/cmd/protoc-gen-go@latest sudo go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@latest처럼 설치하고!sudo go env GOPATH // Go_경로 sudo cp Go_경로/bin/protoc-gen-go /usr/local/bin/ sudo cp Go_경로/bin/protoc-gen-go-grpc /usr/local/bin sudo chmod +x /usr/local/bin/protoc-gen-go sudo chmod +x /usr/local/bin/protoc-gen-go-grpc하고 하니깐 되더라구요!!강의 잘 보고 있습니다 :)

안녕하세요!과거에, MSA 학습용으로 모의 주식 투자 서비스(?)를 만들어본 사람입니다. 당시에, 주식 매수의 기능을, 2개의 service 로 운영했었고, 이때 각 요청의 순서는 이벤트 기반으로 처리하였습니다.client -> stock service -> kafka-> payment service(이벤트 구독)이때, 특정 문제에 대한 트랜잭션 보장을, 보장 로직을 통해 구현하였었습니다.이때, kafka pub/sub 이벤트를 동기적으로 처리되었는지 확인하도록 구성해놓았었습니다. 주식 거래와 같은 일관성이 매우 중요한 서비스에서 어떤 방향성이 더 올바른(?) 방향이라고 생각하고, 어떤 생각을 가지고 계신지 궁금합니다. 현재 생각으로는, 2pc 를 채택하는게 더 올바른 선택이었다고 생각이 듭니다.

안녕하세요.강의가 업데이트 되면서 다시 한번 강의 듣고 있네요 감사합니다.업데이트 된 강의자료(PDF, PPT)파일을 다운 받고 싶은데 어디서 다운 받아야 하나요?답변 부탁드립니다.감사합니다.수고하세요.

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 대신 별도의 유니크키를 사용하고 있는데, 특별한 이유가 있을까요 ??이 별도의 유니크 키가 어그리거트 루트로 사용되는걸까요 ??