소개 아래 글은 https://resilience4j.readme.io/docs/ratelimiter 사이트의 Introduction 원문입니다. Rate limiting is an imperative technique to prepare your API for scale and establish high availability and reliability of your service. But also, this technique comes with a whole bunch of different options of how to handle a detected limits surplus, or what type of requests you want to limit. You can simply declin..

소개 Resilience4j는 동시 수행의 제한을 두기 위해 두 가지 bulkhead pattern을 제공합니다. SemaphoreBulkhead FixedThreadPoolBulkhead SemaphoreBulkhead 동시 요청 수를 제한을 두고 요청 수에 도달한 이후 요청에 대해서는 BulkheadFullException이 발생한다. FixedThreadPoolBulkhead 시스템 자원과 별도로 thread pool을 설정하고 설정된 thread pool은 서비스를 제공하기 위한 용도로만 사용한다. 그리고 thread pool과 별도로 waiting queue를 설정할 수 있다. 만약 thread pool과 waiting queue 가 full 인 경우 BulkheadFullException이 발..

resilience4j-retry 예제를 작성하기 전에 한 가지 시나리오를 생각해 보자. 사용자가 주문을 할때 가장 중요한 부분은 결제 일 것이다. 그런데 시스템 운영 중 중요한 오류가 있어서 서버에 소스를 반영하고 재기동해야 한다고 하면 그 시간 동안 회사는 많은 손해가 발생할 것입니다. 만약 소스를 반영하고 서버 재기동 까지 1분 안에 가능하다고 한다면 사용자가 주문이 잠시 느려지더라도 결제까지 정상적으로 실행할 수 있을 것이다. 이렇게 되면 서비스 제공자 입장에서는 정상적으로 서비스를 제공하면서 큰 문제를 막을 수 있을 것이다. 극단적인 시나리오 일수 있겠지만 실제로 서비스를 운영하다 보면 저러한 문제들이 있을 것입니다. Retry는 이러한 문제를 해결 하기에 적합하다는 생각이 듭니다. 소스는 아래..

Resilience4j의 CircuitBreaker에서 Count-based sliding window 예제를 통하여 어떻게 동작하는지 알아보도록 하겠습니다. 예제 프로그램은 order-service에서 payment-service 호출 시 CircuitBreaker의 상태 변화를 알아보도록 하겠습니다. 소스는 아래 사이트에서 받으실 수 있습니다. https://github.com/roopy1210/spring-boot-resilience4j GitHub - roopy1210/spring-boot-resilience4j Contribute to roopy1210/spring-boot-resilience4j development by creating an account on GitHub. github.co..

resilience4j 사이트 내용을 간단히 정리한 후 예제를 통하여 CircuitBreaker에 대해 알아보자. 소개 CircuitBreaker는 정상적인 3가지 상태(CLOSED, OPEN, HALF_OPEN)와 특정한 2가지 상태(DISABLED, FORCED_OPEN)를 가진다. CircuitBreaker는 sliding window를 사용하여서 호출 결과를 집계하고 저장한다. CircuitBreaker 방식은 count-based sliding window 방식과 time-based sliding window 방식을 선택할 수 있다. count-based sliding window 방식은 마지막 N번의 호출 결과를 집계한다. time-based sliding window 방식은 마지막 N초의 호..