안녕하세요 카프카 관련하여 질문드립니다.카프카로 DB Insert 요청을 비동기 처리할 경우 트래픽이 급증하면 데이터베이스가 감당할 수 있는 QPS를 초과하여 과부하가 발생할 수 있습니다. 실무에서는 이러한 상황을 어떻게 대응하는지 궁금합니다.감사합니다.

제가 아직 신입이다 보니 타임아웃에 대하여 어떻게 테스트하고 어떻게 결정을 하지에 관하여 터득하지 못하여서실무에서는 어떤식으로사용하나 궁금합니다감사합니다

안녕하세요. 강의 잘 들었습니다.분산 시스템이 맞는지는 모르겠지만,, 다른 회사의 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를 활용해서 전파를 하시는 편이신가요? 또 만약 전파를 하신다면, 어떤 상황에 전파를 하신 경험이 있으신지 사례가 궁금합니다 선생님!!

보상 트랜잭션 예제 소스에 createOrderAndStockDecreaseEvent 메서드에 Transactional선언되어 있고 주석에 하나의 트랜잭션으로 묶는다고 명시하신거 보면 트랜잭션되게 하시려고 한거 같은데요근데 자기호출로 프록시 안타서 트랜잭션으로 안묶이는데 혹시 예제라서 그냥 해놓으신건가요?

섹션 4 - 23. 백엔드 개발자가 알아야할 카프카 주요 설정6분대부터 쭉 보고있는데 편집 순서가 일부 뒤집힌게 있는 것 같습니다.

과거 컨퍼런스에서 발표했던 내용 PDF 에서 자료를 받아서 강의를 보고 있는데 강의내용에 나오는 PDF랑 좀 다른것 같아서요

Foo님 안녕하세요.간단한 질문 드립니다!recordException을 지정하지 않으면 서킷 브레이커 설정을 해도 동작을 안하는 걸까요? 아니면 기본적으로 RuntimeException과 Error만을 체크하는 걸까요? 감사합니다.

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가 개발된 의도에 맞게 사용하는걸까요?혹시 아니라면, 다른 어떤 방법을 사용하면 좋을지 궁금해서 질문 남기게 되었습니다

안녕하세요. 강의에서 사용한 ppt 자료 어디서 받을 수 있는지 궁금합니다. 감사합니다.

안녕하세요 강사님.너무 좋은 강의 감사합니다!일반적인 모놀리틱 서비스(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의 설정에 추가를 하는 게 맞나요?

안녕하세요예를 들어백엔드 서버 A -> 백엔드 서버 B와 같은 구조가 있을 때백엔드 서버 B에 문제가 생기면 Circuitbreaker 상태가 OPEN으로 바뀔텐데그럼 이 Circuitbreaker 상태를 OPEN으로 바꾸는건백엔드 서버 A가 하는 건가요? 아니면 백엔드 서버 B가 하는건가요??

안녕하세요resilience4j의 Retry는 보통 MSA 내에서백엔드(Spring boot) 서버 <-> 백엔드(Spring boot) 서버 간의 통신에서만 사용할까요? 아니면 백엔드 서버 <-> 카프카 서버, 백엔드 서버 <-> 엘라스틱서치 서버와 같은 경우에도 자주 사용하나요?

slow call 관련 옵션 설정이 필수인 것 같은데 해당 옵션은 무시하도록 설정하는 방법이 있나요?외부 api 호출 구간에서 500 에러가 발생할 때만 서킷 동작하게 하고 싶은데 옵션을 끄는 기능은 따로 제공이 되지 않은 것 같습니다. api 호출 시 어차피 지연되면 read time out, connection time out 등이 발생하면서 500에러를 내려 줄 거라 slow 옵션은 무시하고 싶은데 따로 방법이 있을까요? 제가 못 찾는 것일 수도 있지만 slow call exceed 이벤트가 발생할 때 일어나는 exception 이 따로 있는 것 같지 않아 ignoreException 으로 등록하는 것도 어려운 것 같습니다.  혹시 방법이 있는지 궁금합니다.