Microservices Communication Patterns (Saga, Circuit Breaker) · 강의

재시도 로직을 적용한 회로 차단기

최적의 오류 처리와 복구를 위해 회로 차단기와 재시도 메커니즘이 상호 작용하는 방식을 이해합니다.

재시도 로직을 적용한 회로 차단기은(는) CoddyKit의 무료 Microservices Communication Patterns (Saga, Circuit Breaker) 강의입니다. 이것은 4개 중 2번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 Microservices Communication Patterns (Saga, Circuit Breaker) 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. Microservices Communication Patterns (Saga, Circuit Breaker) 강의에는 총 4개의 강의가 포함되어 있습니다.

이 강의의 일부는 아직 번역되지 않았으며 영어로 표시됩니다.

Combining Circuit Breaker & Retry

In distributed systems, failures are inevitable. We've learned about the Retry Pattern for transient issues and the Circuit Breaker for persistent ones.

But how do these powerful patterns work together? Combining them effectively is key to building truly resilient microservices.

Recap: The Retry Pattern

The Retry Pattern automatically re-attempts an operation that has failed due to a temporary, transient error.

Use case: Network glitches, temporary service unavailability, database deadlocks.
Goal: Overcome momentary hiccups without user intervention.
Mechanism: Usually involves a delay between retries (e.g., exponential backoff).

Recap: The Circuit Breaker

A Circuit Breaker prevents an application from repeatedly invoking a service that is likely to fail. It "trips" the circuit to stop calls when too many errors occur.

Use case: Service is down, overloaded, or consistently returning errors.
Goal: Fail fast, prevent cascading failures, give the failing service time to recover.
States: Closed, Open, Half-Open.

Synergy: CB and Retry

Imagine a service experiencing a brief network blip. Retry can handle this gracefully. But what if the service is completely offline for an extended period?

Without a Circuit Breaker, retries would continuously hammer the unresponsive service, wasting resources and prolonging the problem. This is where their combined power shines!

Order of Operations

When combining these patterns, a critical design decision is: which one wraps the other?

Does the Retry Pattern wrap the Circuit Breaker, or does the Circuit Breaker wrap the Retry Pattern?

The order significantly impacts how your system responds to different types of failures.

Retry Wrapping Circuit Breaker

If the Retry Pattern wraps the Circuit Breaker:

Retry attempts the operation.
The Circuit Breaker is engaged.
If the CB opens, the first attempt fails, and retry might try again, hitting the already open CB.
This can lead to retries hitting a fast-failing CB, not allowing the CB to fully protect the system initially.

This setup is generally less effective.

Circuit Breaker Wrapping Retry

If the Circuit Breaker wraps the Retry Pattern:

The Circuit Breaker monitors the entire retry operation.
If the initial call fails, retry attempts again.
Only if all retries fail within the configured attempts, does the Circuit Breaker count it as a single failure.
If enough such "all-retry-failed" attempts occur, the CB opens.

This is the recommended approach.

CB Protecting Retry Logic

Here's a conceptual Java example showing how a Circuit Breaker would wrap an operation that includes retry logic. Notice the Circuit Breaker's decision to open or close is based on the final outcome of the retried call.

Try running this example:

import java.util.concurrent.atomic.AtomicInteger;

public class Main {
    // Simulate a dependency that sometimes fails
    private static AtomicInteger serviceCallCount = new AtomicInteger(0);

    public static boolean unreliableServiceCall() {
        System.out.println("  Attempting service call...");
        int currentCount = serviceCallCount.incrementAndGet();
        if (currentCount % 3 == 0) { // Fails every 3rd call
            System.out.println("  Service call FAILED temporarily.");
            return false;
        }
        System.out.println("  Service call SUCCESS.");
        return true;
    }

    public static boolean executeWithRetry() {
        int maxRetries = 2;
        long delayMillis = 100;
        for (int i = 0; i <= maxRetries; i++) {
            try {
                if (unreliableServiceCall()) {
                    return true; // Success after retry
                }
            } catch (Exception e) {
                // Log exception, continue retry
            }
            if (i < maxRetries) {
                System.out.println("  Retrying in " + delayMillis + "ms...");
                try { Thread.sleep(delayMillis); } catch (InterruptedException e) { Thread.currentThread().interrupt(); }
            }
        }
        return false; // All retries failed
    }

    // Conceptual Circuit Breaker logic for demonstration
    private static boolean circuitOpen = false;
    private static int failureCount = 0;
    private static final int FAILURE_THRESHOLD = 2; // Open after 2 consecutive failures
    private static final long RESET_TIMEOUT_MILLIS = 500; // Try to close after 0.5s
    private static long lastFailureTime = 0;

    public static boolean executeWithCircuitBreakerAndRetry() {
        if (circuitOpen) {
            if (System.currentTimeMillis() - lastFailureTime > RESET_TIMEOUT_MILLIS) {
                System.out.println("Circuit Breaker: Attempting HALF-OPEN state...");
                circuitOpen = false; // Move to half-open (for demo, just close)
                failureCount = 0; // Reset count
            } else {
                System.out.println("Circuit Breaker: OPEN! Failing fast.");
                return false; // Fail fast if open
            }
        }

        boolean success = executeWithRetry(); // Execute the retry logic

        if (!success) {
            failureCount++;
            lastFailureTime = System.currentTimeMillis();
            if (failureCount >= FAILURE_THRESHOLD) {
                circuitOpen = true;
                System.out.println("Circuit Breaker: OPENED due to repeated failures!");
            } else {
                System.out.println("Circuit Breaker: Failure detected, count=" + failureCount);
            }
        } else {
            failureCount = 0; // Reset failure count on success
            System.out.println("Circuit Breaker: Success, failure count reset.");
        }
        return success;
    }

    public static void main(String[] args) {
        System.out.println("--- Scenario: CB wrapping Retry ---");
        for (int i = 0; i < 7; i++) { // Simulate multiple requests
            System.out.println("\nRequest " + (i + 1) + ":");
            boolean overallSuccess = executeWithCircuitBreakerAndRetry();
            System.out.println("Overall result for Request " + (i + 1) + ": " + (overallSuccess ? "SUCCESS" : "FAILURE"));
            try { Thread.sleep(100); } catch (InterruptedException e) { Thread.currentThread().interrupt(); }
        }
    }
}

Why This Order is Best

Placing the Circuit Breaker around the Retry Pattern offers several advantages:

Efficient Failure Detection: The CB only opens after a series of genuinely failed operations (i.e., all retries failed), distinguishing transient issues from persistent outages.
Reduced Load: Once the CB is open, it prevents any further retry attempts, protecting the downstream service from being overwhelmed during a prolonged failure.
Faster Failures: When the service is truly down, the CB opens quickly, allowing your application to fail fast instead of waiting for all retries to exhaust.

Check Your Understanding

Consider a microservice that experiences intermittent network glitches (transient failures) and occasionally goes completely offline for maintenance (persistent failures).

You are implementing both the Retry Pattern and the Circuit Breaker Pattern to handle these scenarios. Which setup is generally recommended for optimal resilience?

Lesson Summary

We've explored the powerful synergy between the Circuit Breaker and Retry Patterns. While both enhance resilience, their combined effectiveness hinges on their interaction.

Remember, the best practice is to have the Circuit Breaker wrap the Retry Pattern. This allows retries to handle transient faults, while the Circuit Breaker steps in to protect against persistent failures, preventing cascading issues and improving overall system stability.

Keep building robust systems!

자주 묻는 질문

“재시도 로직을 적용한 회로 차단기” 강의는 무료인가요?

네 — “재시도 로직을 적용한 회로 차단기” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 Microservices Communication Patterns (Saga, Circuit Breaker) 강의 전체를 잠금 해제할 수 있습니다. Microservices Communication Patterns (Saga, Circuit Breaker) 강의에는 총 4개의 강의가 포함되어 있습니다.

“재시도 로직을 적용한 회로 차단기”에서 뭘 배우나요?

최적의 오류 처리와 복구를 위해 회로 차단기와 재시도 메커니즘이 상호 작용하는 방식을 이해합니다. 브라우저에서 직접 실행하는 실습 코드로 Microservices Communication Patterns (Saga, Circuit Breaker)을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

Microservices Communication Patterns (Saga, Circuit Breaker)을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 Microservices Communication Patterns (Saga, Circuit Breaker)은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 2번째 강의입니다.

“재시도 로직을 적용한 회로 차단기” 강의는 얼마나 걸리나요?

대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.

이 Microservices Communication Patterns (Saga, Circuit Breaker) 강의에서 코드를 작성하고 실행할 수 있나요?

네. 모든 Microservices Communication Patterns (Saga, Circuit Breaker) 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.

이 강의의 모든 강의

← Microservices Communication Patterns (Saga, Circuit Breaker)(으)로 돌아가기