Resilience4j 주요기능 분석

Hyunni·2024년 11월 10일
0

마이크로서비스 환경에서 장애에 대비한 다양한 복구전략은 필수적인 요소입니다. Resilience4j는 Java 기반 애플리케이션에서 장애 회복과 서비스 안정성을 위한 패턴을 지원하는 라이브러리로, 다양한 resilience 패턴을 통해 장애 상황에 대비할 수 있습니다. 이번 포스트에서는 각 기능의 원리, 주요 사용 예제, 응용 방법을 자세히 살펴보겠습니다.

1. Circuit Breaker: 장애 탐지 및 차단

1.1 동작 원리

Circuit Breaker는 오류가 지속되면 회로를 열어 이후의 요청을 차단하는 방식으로, 과부하를 방지하고 빠르게 장애를 감지할 수 있습니다. 회로는 Closed, Open, Half-Open의 세 가지 상태로 나뉘며, 자동으로 상태가 전환됩니다.

알고리즘: 슬라이딩 윈도우(Sliding Window)

Circuit Breaker는 슬라이딩 윈도우 알고리즘을 통해 오류 비율을 계산합니다. 슬라이딩 윈도우는 최근의 호출을 일정 개수(또는 일정 시간) 단위로 그룹화하여 성공률과 실패율을 평가합니다.

  • Closed 상태에서는 모든 요청을 허용하며 오류 비율을 지속적으로 계산합니다.
  • Open 상태에서는 오류 비율이 임계치를 넘을 경우 회로가 열려 모든 요청을 차단합니다. Open 상태가 유지되는 동안 주기적으로 상태를 확인하여 회로를 Half-Open으로 전환합니다.
  • Half-Open 상태에서 일부 요청을 허용하여 장애가 해결되었는지 테스트하고, 성공적인 요청이 일정 임계치를 넘으면 다시 Closed 상태로 돌아갑니다.

주요 개념

  • 임계치 기반 상태 전환: 오류 비율이 특정 임계치를 넘으면 Open 상태로 전환됩니다.
  • 시간 기반 윈도우: 일정 시간 동안 발생한 요청의 성공률과 실패율을 기록해 오류를 감지합니다.

1.2 예제 코드: Circuit Breaker 적용

CircuitBreaker를 통해 외부 API 요청이 일정 횟수 이상 실패할 경우 이후 요청을 차단하는 코드입니다.

import io.github.resilience4j.circuitbreaker.CircuitBreaker;
import io.github.resilience4j.circuitbreaker.CircuitBreakerConfig;
import io.github.resilience4j.circuitbreaker.CircuitBreakerRegistry;

import java.time.Duration;
import java.util.function.Supplier;

public class CircuitBreakerExample {
    public static void main(String[] args) {
        CircuitBreakerConfig config = CircuitBreakerConfig.custom()
            .failureRateThreshold(50)  // 실패율이 50%를 넘으면 회로를 엽니다.
            .waitDurationInOpenState(Duration.ofSeconds(10))  // Open 상태를 10초 유지
            .slidingWindowSize(5)  // 5개의 호출을 슬라이딩 윈도우로 평가
            .build();

        CircuitBreakerRegistry registry = CircuitBreakerRegistry.of(config);
        CircuitBreaker circuitBreaker = registry.circuitBreaker("exampleService");

        // Circuit Breaker를 적용한 Supplier
        Supplier<String> decoratedSupplier = CircuitBreaker.decorateSupplier(circuitBreaker, CircuitBreakerExample::simulateExternalService);

        for (int i = 0; i < 10; i++) {
            try {
                System.out.println(decoratedSupplier.get());
            } catch (Exception e) {
                System.out.println("Request failed: " + e.getMessage());
            }
        }
    }

    private static String simulateExternalService() {
        if (Math.random() > 0.6) {
            throw new RuntimeException("Service failed");
        }
        return "Service call succeeded";
    }
}

1.3 사용 사례

  • 결제 시스템: 외부 결제 API에서 지속적인 오류가 발생할 경우 회로를 열어, 불필요한 연결 시도를 막고 빠르게 실패 처리를 통해 사용자 경험을 보호할 수 있습니다.

2. Rate Limiter: 트래픽 제어

2.1 동작 원리

Rate Limiter는 일정 시간당 요청 수를 제한합니다. 예를 들어, 초당 5개의 요청만 허용하고 나머지는 차단하여 트래픽 폭주로 인한 과부하를 방지할 수 있습니다.

알고리즘: 토큰 버킷(Token Bucket)과 누출 버킷(Leaky Bucket)

Rate Limiter는 주로 토큰 버킷과 누출 버킷 두 가지 알고리즘 중 하나를 사용합니다.

  1. 토큰 버킷(Token Bucket):

    • 일정 시간마다 버킷에 토큰을 추가하며, 요청이 들어올 때마다 토큰을 소모하여 요청을 허용합니다.
    • 한 번에 많은 요청을 순간적으로 허용할 수 있어 burst 트래픽을 관리하는 데 유리합니다.
    • 예를 들어, 버킷에 10개의 토큰이 있고, 초당 1개의 토큰을 추가하는 경우, 한 번에 최대 10개의 burst 요청이 가능하고, 이후 초당 1개씩 요청이 허용됩니다.

  2. 누출 버킷(Leaky Bucket):

    • 일정 속도로만 요청을 허용하여 요청을 천천히 처리합니다.
    • 요청이 버킷을 초과하면 거부되며, 안정적인 속도로 트래픽을 처리할 수 있습니다.

    Rate Limiter를 API Gateway가 아닌 내부 서비스의 요청 제어나 서버 보호 목적으로 사용할 수도 있습니다. 특히, 콘서트 예매 트래픽처럼 일정 시간 동안 요청이 집중될 가능성이 큰 서비스에서는 Rate Limiter를 서버 내부에 적용해 부하를 분산하거나, 특정 트래픽 폭주 상황을 제어하는 용도로 사용할 수 있습니다.

Rate Limiter를 서버 내부에서 사용하는 사례

  1. 트래픽 급증을 방지하는 용도: 특정 이벤트나 기능에서 대규모의 요청이 몰리는 경우, 서버 내부에서 Rate Limiter를 적용해 동시에 처리되는 요청 수를 제한할 수 있습니다. 예를 들어, 이벤트 개시 직후 수많은 예매 요청이 순간적으로 몰리면 데이터베이스나 서버 자원에 큰 부담이 가해질 수 있습니다. 이때, 내부 Rate Limiter를 통해 단위 시간당 요청 수를 제한하면 서버가 과부하에 걸리는 상황을 방지할 수 있습니다.

  2. 데이터베이스 보호: 콘서트 예매와 같이 다수의 요청이 데이터베이스에 접근하는 경우 Rate Limiter로 트래픽을 제한하여 데이터베이스가 순간적으로 과부하에 걸리는 것을 막을 수 있습니다. 예를 들어, Rate Limiter를 설정하여 초당 일정 수의 요청만 데이터베이스에 전달되도록 하여, 데이터베이스 연결 풀이나 자원 사용을 일정하게 유지할 수 있습니다.

  3. 요청 처리 대기 및 거부: Rate Limiter를 서버 내부에서 설정하면 일정량 이상의 요청이 들어왔을 때 대기시키거나, 허용 범위를 초과하는 요청을 거부하여 응답 시간을 유지할 수 있습니다. 이를 통해 갑작스러운 트래픽 폭주 상황에서도 사용자 경험을 최대한 보호할 수 있습니다.

고려할 점

Rate Limiter를 서버 내부에서 사용할 경우, 단순히 요청을 제한하거나 대기시키는 것 외에 요청의 누락을 방지하거나 특정 중요 요청이 항상 처리될 수 있도록 설계해야 합니다. 예를 들어:

  • Retry와 결합하여 거부된 요청을 재시도하거나,
  • 우선순위 큐를 활용해 우선 순위가 높은 요청이 제한 없이 처리될 수 있도록 하는 전략을 추가하는 것이 좋습니다.

Rate Limiter를 서버 내부에서 사용할 때의 장단점

  • 장점: 요청 수를 일정하게 유지함으로써 서버 리소스를 안정적으로 관리할 수 있습니다. 특히, API Gateway가 Rate Limiting을 처리하지 않거나, 서버 내부의 특정 서비스 또는 리소스에 대해 더 세밀한 Rate Limiting이 필요할 때 유용합니다.

  • 단점: Rate Limiter는 단순히 요청을 제한하는 방식이므로, 모든 요청이 처리되는 것을 보장하지 않습니다. 중요한 이벤트에서는 Rate Limiter와 함께 Retry나 백오프 전략을 함께 적용해야 요청이 완전히 누락되는 상황을 방지할 수 있습니다.

결론적으로, Rate Limiter를 서버 내부에서 사용하는 것은 가능하며, 특히 이벤트성 트래픽이나 데이터베이스 보호 목적으로 적절합니다. 다만 요청 누락을 최소화하려면 추가적인 패턴이나 로직을 결합하여 사용해야 합니다.

2.2 예제 코드: Rate Limiter 적용

아래 예제에서는 초당 5건의 요청을 허용하는 Rate Limiter를 설정하고, 초과 요청은 거부합니다.

import io.github.resilience4j.ratelimiter.RateLimiter;
import io.github.resilience4j.ratelimiter.RateLimiterConfig;
import io.github.resilience4j.ratelimiter.RateLimiterRegistry;

import java.time.Duration;
import java.util.function.Supplier;

public class RateLimiterExample {
    public static void main(String[] args) {
        RateLimiterConfig config = RateLimiterConfig.custom()
            .timeoutDuration(Duration.ofMillis(500))  // 요청을 기다리는 최대 시간
            .limitRefreshPeriod(Duration.ofSeconds(1))  // 새로 고침 주기
            .limitForPeriod(5)  // 주기마다 최대 5개의 요청 허용
            .build();

        RateLimiterRegistry registry = RateLimiterRegistry.of(config);
        RateLimiter rateLimiter = registry.rateLimiter("exampleService");

        Supplier<String> decoratedSupplier = RateLimiter.decorateSupplier(rateLimiter, RateLimiterExample::simulateService);

        for (int i = 0; i < 10; i++) {
            try {
                System.out.println(decoratedSupplier.get());
            } catch (Exception e) {
                System.out.println("Rate limit exceeded: " + e.getMessage());
            }
        }
    }

    private static String simulateService() {
        return "Service call succeeded";
    }
}

2.3 사용 사례

  • API 트래픽 제한: 외부 API와의 통신에 Rate Limiter를 적용하여 불필요한 트래픽을 줄이고, API 사용량을 제한할 수 있습니다.

3. Retry: 재시도

3.1 동작 원리

Retry는 일시적인 장애가 발생했을 때 지정된 횟수만큼 재시도를 수행하여 장애 회복 가능성을 높입니다. 재시도 간격을 설정해, 시스템 부하를 줄이며 트래픽을 관리할 수 있습니다.

알고리즘: 고정 대기 시간(Fixed Wait Time)과 지수 백오프(Exponential Backoff)

Retry는 주로 두 가지 방식으로 재시도 간격을 설정합니다.

  1. 고정 대기 시간 (Fixed Wait Time):

    • 재시도 간격을 일정하게 설정하여, 설정된 간격마다 실패한 요청을 다시 시도합니다.
    • 설정이 간단하고 일관성이 있으나, 트래픽이 집중될 경우 서비스에 부담을 줄 수 있습니다.

  2. 지수 백오프 (Exponential Backoff):

    • 재시도 간격이 점진적으로 늘어나는 방식으로, 요청이 실패할 때마다 대기 시간이 지수적으로 증가합니다.
    • 예를 들어, 첫 번째 실패 후 1초, 두 번째 실패 후 2초, 세 번째 실패 후 4초 대기하는 방식입니다.
    • 초기 트래픽 부담을 줄이면서도 요청의 성공 가능성을 높이는 데 유리합니다.

3.2 예제 코드: Retry 적용

아래 예제는 3번까지 재시도를 설정하고, 재시도 간격을 500ms로 지정한 코드입니다.

import io.github.resilience4j.retry.Retry;
import io.github.resilience4j.retry.RetryConfig;
import io.github.resilience4j.retry.RetryRegistry;

import java.time.Duration;
import java.util.function.Supplier;

public class RetryExample {
    public static void main(String[] args) {
        RetryConfig config = RetryConfig.custom()
            .maxAttempts(3)  // 최대 3번 재시도
            .waitDuration(Duration.ofMillis(500))  // 각 재시도 간격
            .build();

        RetryRegistry registry = RetryRegistry.of(config);
        Retry retry = registry.retry("exampleService");

        Supplier<String> decoratedSupplier = Retry.decorateSupplier(retry, RetryExample::simulateUnreliableService);

        try {
            System.out.println(decoratedSupplier.get());
        } catch (Exception e) {
            System.out.println("Request failed after retries: " + e.getMessage());
        }
    }

    private static String simulateUnreliableService() {
        if (Math.random() > 0.7) {
            throw new RuntimeException("Service failed");
        }
        return "Service call succeeded";
    }
}

3.3 사용 사례

  • 네트워크 오류 처리: 일시적인 네트워크 문제로 외부 서비스 호출에 실패하는 경우 재시도를 통해 요청을 성공할 수 있습니다.

4. Bulkhead: 격리

4.1 동작 원리

Bulkhead는 리소스 고갈을 방지하기 위해 특정 작업의 동시 실행 개수를 제한합니다. 이를 통해 한 서비스가 과부하가 걸려도 다른 서비스는 영향을 받지 않습니다.

알고리즘: 스레드 풀(Thread Pool)과 세마포어(Semaphore)

Bulkhead는 일반적으로 스레드 풀이나 세마포어를 사용하여 리소스를 격리합니다.

  1. 스레드 풀 (Thread Pool):

    • 요청에 대해 고정된 스레드 풀을 할당하여, 일정 개수 이상의 요청이 들어오면 대기 상태에 두거나 거부합니다.
    • 각 스레드 풀은 서비스별로 독립적으로 운영될 수 있어, 특정 서비스의 오버로드가 다른 서비스에 영향을 미치지 않습니다.

  2. 세마포어 (Semaphore):

    • 특정 서비스에 대해 접근할 수 있는 최대 동시 요청 수를 제한하여, 리소스를 고갈하지 않고 일정량만 사용하도록 합니다.
    • 세마포어는 스레드 풀보다 경량화된 리소스 제어 방식이며, 요청 수만 제한하여 좀 더 빠른 처리가 가능합니다.

4.2 예제 코드: Bulkhead 적용

아래 예제에서는 최대 2개의 동시 실행을 허용하는 Bulkhead를 설정합니다.

import io.github.resilience4j.bulkhead.Bulkhead;
import io.github.resilience4j.bulkhead.BulkheadConfig;
import io.github.resilience4j.bulkhead.BulkheadRegistry;

import java.util.concurrent.Callable;

public class BulkheadExample {
    public static void main(String[] args) {
        BulkheadConfig config = BulkheadConfig.custom()
            .maxConcurrentCalls(2)  // 최대 2개의 동시 요청 허용
            .maxWaitDuration(Duration.ofMillis(500))  // 대기 시간
            .build();

        BulkheadRegistry registry = BulkheadRegistry.of(config);
        Bulkhead bulkhead = registry.bulkhead("exampleService");

        Callable<String> decoratedCallable = Bulkhead.decorateCallable(bulkhead, BulkheadExample::simulateService);

        for (int i = 0; i < 5; i++) {
            try {
                System.out.println(decoratedCallable.call());
            } catch (Exception e) {
                System.out.println("Bulkhead limit exceeded: " + e.getMessage());
            }
        }
    }

    private static String simulateService() {
        return "Service call succeeded";
    }
}

4.3 사용 사례

  • 데이터베이스 연결 보호: 특정 서비스가 데이터베이스 연결을 과도하게 사용하지 않도록 동시 실행 개수를 제한할 수 있습니다.

5. Time Limiter: 시간 제한

5.1 동작 원리

Time Limiter는 비동기 작업이 지정된 시간 내에 완료되지 않으면 실패 처리하는 방식으로, 과도한 대기 시간을 방지합니다.

알고리즘: 타임아웃과 Future

Time Limiter는 주로 타임아웃 설정과 Future 객체를 사용하여 시간 제한을 관리합니다.

  1. 타임아웃 설정:

    • 요청에 타임아웃을 설정하여, 일정 시간 내에 완료되지 않으면 요청을 실패로 간주합니다.
    • 응답 시간이 너무 길어질 경우 빠르게 대체 처리를 할 수 있습니다.

  2. Future 객체:

    • 비동기 작업을 관리할 때 Future 객체를 사용하여, 일정 시간 동안만 요청을 대기하고, 시간 초과 시 실패로 간주합니다.
    • 타임아웃이 발생하면 이후 로직이 즉시 종료되어 리소스가 낭비되지 않도록 합니다.

5.2 예제 코드: Time Limiter 적용

아래 예제는 비동기 작업을 1초 내에 완료하지 않으면 실패 처리하는 코드입니다.

import io.github.resilience4j.timelimiter.Time

Limiter;
import io.github.resilience4j.timelimiter.TimeLimiterConfig;

import java.time.Duration;
import java.util.concurrent.CompletableFuture;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.function.Supplier;

public class TimeLimiterExample {
    public static void main(String[] args) {
        ExecutorService executorService = Executors.newSingleThreadExecutor();
        TimeLimiterConfig config = TimeLimiterConfig.custom()
            .timeoutDuration(Duration.ofSeconds(1))  // 1초 내에 작업이 완료되지 않으면 실패 처리
            .build();

        TimeLimiter timeLimiter = TimeLimiter.of(config);

        Supplier<CompletableFuture<String>> decoratedSupplier = TimeLimiter
            .decorateFutureSupplier(timeLimiter, () -> CompletableFuture.supplyAsync(TimeLimiterExample::simulateSlowService, executorService));

        try {
            System.out.println(decoratedSupplier.get().get());
        } catch (Exception e) {
            System.out.println("Time limit exceeded: " + e.getMessage());
        }

        executorService.shutdown();
    }

    private static String simulateSlowService() {
        try {
            Thread.sleep(2000);  // 의도적으로 2초 지연
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        return "Service call succeeded";
    }
}

5.3 사용 사례

  • 비동기 API 호출 제한: 비동기 호출이 오래 걸릴 경우 Time Limiter를 통해 일정 시간 초과 시 실패 처리할 수 있습니다.

Resilience4j의 다양한 기능을 통해 애플리케이션의 회복성을 높이고, 장애가 발생해도 서비스가 안정적으로 유지될 수 있도록 합니다.

profile
Hyunni
9년차 Fullstack Developer로 고민하고 구현하는 것들에 대해 정리하는 공간입니다.
이전 포스트

Kafka 정리 (1)

0개의 댓글