안녕하세요 강사님. 강의 잘 듣고 있습니다. 이번 시간에 강사님께서 Spring WebFlux와 Spring Web MVC를 혼용해서 사용하는 경우, 결국에는 Web MVC의 기본 스레드인 톰캣 스레드를 사용해서 스레드 고갈이 될 수 있다고 하셨습니다. 따라서 내부적으로는 WebFlux의 이벤트 루프 스레드가 아닌 톰캣 스레드를 사용해서 블로킹되는 현상이 발생한다로 해석하면 될까요? 저는 혼용할 경우, Mono/Flux 타입 응답에 한해서는 동시 요청 발생 시 이벤트 루프 스레드를 사용하여 IO 작업을 대기하지 않고 해당 스레드가 다른 일을 처리하러 가는 것으로 알고 있었습니다. 혹시 이러한 상황에서 어떤 스레드를 사용하는지 테스트 해볼만한 좋은 방식이 있을까요? 감사합니다.
안녕하세요. 강사님 강의 잘 들었습니다. 한가지 질문이 있습니다. 주문 생성과 주문 처리api를 나누고 사용자가 결제가 되면 주문 처리 api를 호출하는걸로 알고있습니다. Orchestaration 방식으로 처리할 때 OrderConfirmEvent를 발행하면 제 서비스로 예를 들면 재고, 쿠폰, 적립금 서비스에서 consume하여 처리를 하고 있습니다. 그런데 주문 처리 api에서 재고는 처리되었지만 쿠폰은 실패할 경우 어떻게 보상 트랜잭션을 주어야할지 모르겠습니다. 결제가 된 주문이라 바로 보상을 하는것 보다는 dlt topic에 넣고 재처리를 하고 만약 재시도 3번을 하고 나서 실패할 경우 환불을 해줘야할까요? 주문 처리 api에서는 어디가 실패한지 모르니까요 혹시 어떤식으로 해야할지 조언좀 받을수 있을까요?
안녕하세요. 강의 잘 들었습니다. 분산 시스템이 맞는지는 모르겠지만,, 다른 회사의 API들을 여러개 사용할때에 궁금증이 있어서 질문 드립니다. 문제 상황은 아래와 같습니다. 우리 쪽에서는 이미 사용자가 토큰 기반으로 인증된 상태 이며, 이 사용자의 요청을 대신해 외부(회사1, 회사2)의 API를 호출 해야 하는 상황입니다. 또한, 사용자가 버튼을 눌렀을 때 새 브라우저 창을 띄워 회사2의 웹 애플리케이션으로 이동 해야 하는데, 이때 로그인 과정을 생략하고 자동으로 접속(SSO) 되도록 만들고 싶습니다. 질문 1⃣ API 인증 전파 관련 우리 서버가 회사1·2 서버로 요청을 보낼 때, 상대 서버에서는 “이 요청이 실제 인증된 사용자로부터 온 것”임을 어떻게 검증하는 게 일반적인가요? 2⃣ 브라우저 SSO 관련 새 탭을 열어 회사2 웹 서비스로 이동 시, 재로그인 없이 자동으로 인증(Single Sign-On) 되게 하려면 어떤 방식이 많이 사용되나요?
안녕하세요. 주문 처리에 관련해서 질문 있습니다!! 고민하다가 질문드려요 ㅠ! 중복 주문을 해결하기 위해 주문 생성 API , 주문 처리 API를 나누는걸로 이해하고 있습니다. 만약 쇼핑몰에서 사용자가 주문을 할때 주문 생성 API를 요청하고 결제처리 (PG사) 성공하면 주문 처리 API(재고차감 등등) 를 하는걸로 알고 있습니다. 하지만 주문 생성 API에서 수량을 검증한다고 하더라도 결제를 완료하고 주문 처리를 할때 다른 사용자에 의해서 재고가 부족할수 있는 상황이 있다고 생각합니다. 이럴때는 실무에서 어떻게 해결하는지가 궁금합니다!!!! 비동기적으로 보상해준다고 하면 뭔가 사용자입장에서 결제까지 했는데 재고가 부족해서 주문처리가 실패하여 환불까지된다?.... 이게 좀 비효율적이라 생각해서요!! 답변 부탁드립니당 실무에서는 어떻게 사용하나요 ! 궁금해요 ㅠㅁㅠ
안녕하세요 준형님! 우선, 강의 정말 잘 들었습니다. 정말 정말 많이 배웠습니다 🙇🏻🙇🏻🙇🏻 다름이 아니라, 데이터 버저닝 파트에서 컨슈머의 멱등성을 보장하기 위해 주문 서비스가 재고 차감 이벤트에 version을 담고, 상품 서비스에서는 JPA가 관리하는 상품 version과 이를 동등성 비교하여 중복 소비를 방지하는 방식에 대해 질문드리고 싶습니다. 이 접근 방식에서 많은 인사이트를 얻었지만, 상품의 version을 주문 서비스가 반드시 알아야 한다는 점은 조금 와닿지 않았습니다. 테스트에서는 version = 0부터 시작하니 문제가 없어 보였으나, 여러 이유로 두 version 값이 어긋나면 오히려 소비해야 할 이벤트까지 멱등 처리되어 버릴 수 있다고 생각했습니다. 그렇다고 이를 해결하기 위해 주문 서비스가 상품 서비스로부터 version 이벤트를 직접 받아 관리하는 것도 과한 방식처럼 느껴지는데요, 이 부분에 대해 준형님의 의견을 들을 수 있다면 좋을 것 같습니다. 시간 편하실 때 부담없이 답변 주시면 감사하겠습니다 🙂
안녕하세요. 먼저 좋은 강의 감사드립니다. 데이터 버저닝에서 이해가 가지 않는 부분이 있어서 질문 드립니다. 낙관적 락을 사용하는걸 봤습니다. 결과적으로 발행시와 소비시의 버전이 같아야 하는데, 대규모 시스템에서 장애가 발생하지 않으려면 프로듀서에 아이디 1인 상품 발행하고 나서 컨슈머에서 처리하기 전까지 절대 새로운 이벤트를 발행하면 안되는거 아닌가요? 만약 컨슈머에서 처리하기 전에 이벤트를 발행하면 똑같은 버전이 후에 계속 들어와서 이 재고 업데이트는 무시되는게 아닌가 해서 질문드립니다. 맞다면 재고 감소 멱등성은 어떻게 해결하면 좋을지 고견 듣고 싶습니다. 감사합니다.
현재 서버(A 서버)에서 서킷 브레이커가 OPEN 되었을 때, 다른 B, C 서버에 서킷 브레이커 OPEN 전파를 해야할 때 그럼 Actuator를 활용해서 전파를 하시는 편이신가요? 또 만약 전파를 하신다면, 어떤 상황에 전파를 하신 경험이 있으신지 사례가 궁금합니다 선생님!!
Resilience4j - circuitbreaker를 보며 공부 중에 feign 에 Resilience4j의 cb나 bulkhead를 적용하게 되면 feignfallbackfactory 동작 시, throwable이 wrapping 되는 현상이 나타납니다. (ex. ExecutionException) 예를 들어, 4xx대의 에러, 즉 FeignException.BadRequest에 대한 분기 처리를 하려면 fallbackfactory 에서 throwable에 대한 원본 cause 를 추출하는 방법 밖에는 없을까요? (ex, throwable.getcause().getcause())
Riot API Limit을 보면 이렇게 Rate Limit이 있다고 설명되어 있는데요. 이를 위해서 CustomCircuitBreaker를 아래와 같이 개발해봤습니다. @Bean(name = "shortTermCircuitBreaker") public CircuitBreaker shortTermCircuitBreaker(CircuitBreakerRegistry registry) { return registry.circuitBreaker("shortTermBreaker", CircuitBreakerConfig.custom() .slidingWindowType(CircuitBreakerConfig.SlidingWindowType.TIME_BASED) .failureRateThreshold(1) .slidingWindowSize(1) .waitDurationInOpenState(Duration.ofSeconds(1)) // open -> half open까지 기다리는 시간 .automaticTransitionFromOpenToHalfOpenEnabled(true) // open 상태에서 자동으로 half open으로 전환 .build() ); } @Bean(name = "longTermCircuitBreaker") public CircuitBreaker longTermCircuitBreaker(CircuitBreakerRegistry registry) { return registry.circuitBreaker("longTermBreaker", CircuitBreakerConfig.custom() .slidingWindowType(CircuitBreakerConfig.SlidingWindowType.TIME_BASED) .failureRateThreshold(1) .slidingWindowSize(120) .waitDurationInOpenState(Duration.ofMinutes(2)) // open -> half open까지 기다리는 시간 .automaticTransitionFromOpenToHalfOpenEnabled(true) // open 상태에서 자동으로 half open으로 전환 .build() ); } 제가 궁금한 점은 slidingWindowType을 TIME_BASED로 했을 경우, slidingWindowSize에 들어가는 값의 단위가 초 단위인가 하는 것입니다. 공식 문서에는 이렇게 나와있는데 애매한 것 같아서요.
안녕하세요 🙂 Resilience4J 를 학습한 후 실무에 적용해보려 하는 주니어 백엔드 개발자입니다. 제가 생각하는 예시가 서킷 브레이커를 도입하기 적절한 예시인지 궁금해서 질문을 남깁니다! 현재 제가 고려하는 상황입니다. A 서버 혹은 B 서버로 요청을 보내도 되는 상황 (A서버로 요청 보내는 것이 비용이 저렴하기 때문에 기본적으로 A사 요청) A사로 요청을 보냈지만 장애 발생 -> 서킷 OPEN 상태로 변경 서킷이 OPEN일 때 B 서버로 요청 HALF OPEN일 때 A서버로 요청을 보냄 A서버에서 정상적인 응답이 올 경우 서킷 CLOSE 이러한 방식으로 Resilience4J를 도입하려고 하는데, resilience4J가 개발된 의도에 맞게 사용하는걸까요? 혹시 아니라면, 다른 어떤 방법을 사용하면 좋을지 궁금해서 질문 남기게 되었습니다
안녕하세요 강사님. 너무 좋은 강의 감사합니다! 일반적인 모놀리틱 서비스(spring cloud 사용 X)의 상황에서, scale out 환경에서 서킷의 상태를 변경하는 것에 대해 질문을 드리고 싶습니다. 예를 들어 aws의 로드밸런서 & 오토 스케일링 그룹을 통해 스케일 아웃이 자동으로 진행되는 환경에서, 모든 서버를 api 호출을 통해 상태를 바꾸는 것이 가능할까를 고려해 보았을 때 조금 어려움이 있을 것 같았습니다. (사실 잘 모르는 부분이 많아, 이게 가능할지도 의문입니다..) 이런 경우에는 굳이 api 호출을 사용하기보다는, redis 나 kafka 등의 pub/sub을 활용하여 상태를 변경하도록 하는 것이 좋을까요?
안녕하세요 백엔드 A -> 백엔드 B로 호출하는 상황이라고 가정합니다. 백엔드 B에서 발생하는 CustomException을 CircuitBreaker에서 카운팅하지 않게 하기 위해서 ignoreExceptions에 추가한다고 하는 상황입니다. 그럼 이때 application.yml의 ignoreExceptions에 CustomException을 추가한다고 한다면 CustomException 정보는 백엔드 B에 있으니 백엔드 B의 설정에 추가를 하는 게 맞나요?
