안녕하세요, 현재 Window 11 환경에서 실습을 진행하는데 실습 중 문제가 발생하여 문의드립니다. 49. 구독매니저 YAML 구조 강의의 02:09 때 kubectl apply -f . 명령어를 사용한 후에 계속해서 Pod 생성 시에 ImagePullBackOff, CrashLoopBackOff 가 발생합니다. 문제가 발생한 POD 는 다음과 같고, 문제를 일으키는 문제들은 공통적으로 아래와 같은 메시지를 갖고 있었습니다. (kubectl describe 사용) 

안녕하세요, 강의 들으면서 실습을 따라하던 중에 흐름이 끊기는 부분이 생겨서 문의드립니다. 섹션6 > sm-subs 강의 에서 04:52 에 나오는 python test/api_test.py 를 성공시키려면 일단 sm-user container 를 실행시켜야 하는데, 해당 컨테이너를 run 하는 부분이 섹션6 > sm-user 강의에 없는 거 같습니다. 일단은 아래처럼 명령어를 실행해서 진행하고 있는데 맞을까요?cd sm-user docker build -t sm-user . docker run -d -p 5000:5000 --name=sm-user --network=sm-network -e DB_HOST=sm-db sm-user  

안녕하세요, 실습을 진행하던 중 문제가 발생하여 문의드립니다. 미리 말씀드리지만 저는 현재 Window 11 환경에서 실습을 진행중입니다. "서비스와 DNS" 목차에서 03:57 즈음에 알져주시는 명령어를 그대로 입력해봤습니다.사용 명령어: kubectl run -it --rm --image=devwikirepo/ipbot debug -n hr -- /bin/bash그랬더니 아래와 같은 에러가 발생했습니다.pod 생성 중에 문제가 생긴거 같아서 kubectl describe 명령어로 상태를 조회해봤습니다.ToastBread → kubectl describe pod debug -n hr Name: debug Namespace: hr Priority: 0 Service Account: default Node: easykube-worker3/172.22.0.3 Start Time: Wed, 31 Dec 2025 14:57:42 +0900 Labels: run=debug Annotations: <none> Status: Pending IP: 10.244.3.4 IPs: IP: 10.244.3.4 Containers: debug: Container ID: Image: devwikirepo/ipbot Image ID: Port: <none> Host Port: <none> Args: /bin/bash State: Waiting Reason: ImagePullBackOff Ready: False Restart Count: 0 Environment: <none> Mounts: /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-pd54v (ro) Conditions: Type Status PodReadyToStartContainers True Initialized True Ready False ContainersReady False PodScheduled True Volumes: kube-api-access-pd54v: Type: Projected (a volume that contains injected data from multiple sources) TokenExpirationSeconds: 3607 ConfigMapName: kube-root-ca.crt Optional: false DownwardAPI: true QoS Class: BestEffort Node-Selectors: <none> Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300s node.kubernetes.io/unreachable:NoExecute op=Exists for 300s Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 2m2s default-scheduler Successfully assigned hr/debug to easykube-worker3 Normal BackOff 24s (x5 over 116s) kubelet Back-off pulling image "devwikirepo/ipbot" Warning Failed 24s (x5 over 116s) kubelet Error: ImagePullBackOff Normal Pulling 6s (x4 over 2m2s) kubelet Pulling image "devwikirepo/ipbot" Warning Failed 3s (x4 over 116s) kubelet Failed to pull image "devwikirepo/ipbot": rpc error: code = NotFound desc = failed to pull and unpack image "docker.io/devwikirepo/ipbot:latest": no match for platform in manifest: not found Warning Failed 3s (x4 over 116s) kubelet Error: ErrImagePull 맨끝에 Events 를 보니 ImagePullBackOff 보고 처음에는 이미지 이름의 철자를 틀렸나 생각했지만,해당 이름을 그대로 복사해서 docker hub 에서 검색해보니 잘나왔습니다.좀 더 알아보니 no match for platform in manifest 이라는 문구가 눈에 들어와서 이게 CPU 아키텍처가 호환이 안되는 걸 알아냈습니다.  linux/amd64Window 환경에서도 실행할 수 있는 AMD64 도 지원해주실 수 있을까요??

TCC 구현하기(10) - Retry 를 활용하여 일시적인 오류에 대처하기 에서 spring retry를 사용하여 재시도를 적용하는 부분이 있습니다. 이에의존성 추가@EnableRetry 어노테이션 추가아래 코드 추가@Retryable( retryFor = { Exception.class }, noRetryFor = { HttpClientErrorException.BadRequest.class, HttpClientErrorException.NotFound.class }, maxAttempts = 3, backoff = @Backoff(delay = 500) )를 했었습니다. 하지만 스프링 프레임워크 7.0, 스프링 부트 4.0 버전부터는 spring retry가 spring core 패키지로 편입되어 아래와 같이 retry를 적용해야 합니다.별도 의존성 추가 필요없음@EnableRetry 어노테이션 대신 @EnableResilientMethods 어노테이션 추가아래 코드 추가@Retryable( includes = Exception.class, excludes = { HttpClientErrorException.BadRequest.class, HttpClientErrorException.NotFound.class }, maxRetries = 3, delay = 500 ) 위와 같은 방식으로 적용하시면 됩니다. 자주 쓰던 spring retry가 왜 안되나 싶어서 이유를 한참 찾았네요 허헛 참고https://docs.spring.io/spring/reference/7.0-SNAPSHOT/core/resilience.html

안녕하십니까 상용님. MSA에 대한 학습이 처음이라 정말 흥미진진하게 잘 보고 있습니다. 다름이 아니라 TCC 구현하기의 마지막 수업인 11화에서주문 도중 문제 발생 시 다음과 같이 일정 시간 동안 RESERVED 상태인 product들을 스케줄러가 따로 처리한다고 하셨는데 여기서 말하신 product는 product_reservation 엔티티를 말하신 것인지 궁금합니다. 감사합니다. 

안녕하십니까 상용님. 수업 잘 듣고 있습니다. 다름이 아니라 TCC에서 PointService의 tryReserve 구현 시 Point 클래스에 reserve 메서드를 정의 하셨는데 이때public void reserve(Long reserveAmount) { long reservableAmount = this.amount - reserveAmount; if (reservableAmount < reserveAmount) { throw new RuntimeException("금액이 부족합니다."); } reservedAmount+=reserveAmount; }이렇게 reservableAmount가 reserveAmount를 빼는 것이 아니라public void reserve(Long reserveAmount) { long reservableAmount = this.amount - this.reservedAmount; if (reservableAmount < reserveAmount) { throw new RuntimeException("금액이 부족합니다."); } reservedAmount+=reserveAmount; }이렇게 reservedAmount를 빼주어야 하지 않나요? 감사합니다.

안녕하세요.CRQS 패턴 5:33에표에는읽기 모델을 조회 최적화하여 성능 향상 하는 방법라고 나와있는데질문 1섞여있으면 최적화를 못하나요?질문 2분리를 함으로써 가능한 최적화 방법이 어떤게 있는건가요..?

주문에 대한 멱등성과 동시성 처리 완료List<ProductReservation> exists = productReservationRepository.findByRequestId(command.requestId()); // 같은 requestId에 대해서 멱등성을 보장(주문 단위) if (!exists.isEmpty()) { long totalPrice = exists.stream().mapToLong(ProductReservation::getReservedPrice).sum(); log.info("이미 처리된 예약 건 입니다. requestId: {}", command.requestId()); return new ProductReserveResult(totalPrice); } 이 후, 상품에 대한 동시성을 위해서 낙관락을 사용하셨는데요, 주문이 많이 들어오는 서비스에 대해서는,낙관락보다는 비관락이 더 유리한게 맞을까요? 질문도 질문이지만, 강사님 강의 정말 잘듣고 있습니다! 감사합니다!

안녕하세요!강의를 모두 학습하고, 실습도 진행하면서 오케스트레이션 방식을 적용해보고 있는데 궁금한 점이 있어 질문드립니다. 현재 실습 환경에서는 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로 가시는지 궁금합니다.도커 허브에서도 카프카 이미지를 제공하는거 같은데 뭔가 스타일이 달라지시니 따라가기 힘듭니다..