[MSA] MSA 환경에서 장애 전파를 막기 위한 전략 (Tracing, Circuit Breaker, Rate Limit)

🧐 들어가기전

모놀리틱 아키텍처에서 벗어나 서비스 단위로 쪼개진 마이크로 서비스 아키텍처에 들어서게 되면 모놀리틱의 단점을 보완할 수 있다. 모놀리틱은 모든 기능이 하나의 application에 집중 되어 있기 때문에 하나의 기능에서 발생한 장애가 서비스 전체로 이어질 여지가 있다. 반면 MSA 환경은 서비스들 간의 독립성이 유지되기에 장애를 격리 시킬 수 있다.

 

하지만 과연 정말 장애를 격리시킬 수 있을까에 대한 고민을 해봐야한다.

 

MSA

위와 같이 클라이언트가 서비스 A를 통해서 요청과 응답을 받고 서비스 A는 client의 요청을 서비스 B로 전달해 B로부터 온 응답을 client에게 전해준다고 가정하자.

 

그렇다면 위에서 만약 서비스 B의 장애가 발생하면 어떻게 될까?

서비스 B 장애 발생

서비스 B에 장애가 발생한다면 생기는 경우의 수는 두 가지이다.

1. 서비스 B에서 A로 error 메시지를 전달한다.
2. 서비스 A가 타임아웃될 때 까지 서비스 B의 응답을 기다린다.

전자의 경우에는 서비스 B가 죽어있는 동안에 계속해서 error 메시지를 받을 것이다.

그러나, 후자의 경우에는 서비스 B가 죽어있는동안 서비스 A는 계속해서 쓰레드를 사용해가며 서비스 B에 대한 응답을 받기 위해 요청을 계속 날리고 기다리고를 반복할 것이다. 그리고 이러한 반복은 결국 쓰레드의 고갈로 이어져 서비스 A에도 장애가 발생할 것이다.

 

이것이 바로 MSA 환경에서 일어날 수 있는 장애 전파 현상이다.

 

아마존 부사장인 버너 보겔스가 말했듯이, "실패하지 않는 시스템을 만드는 것은 불가능하다"

그러므로 장애 전파를 막기 위해서는 빠르게 실패하고 에러메시지를 던져주는 것이 최선이다. (Fail-Fast)

 

따라서 어떻게 하면 빠르게 실패할 수 있는지, 장애 전파를 막기 위한 전략에는 무엇이 있는지 살펴볼 예정이다.

---

🔸분산 환경 모니터링

분산 환경에서는 여러 서비스가 협력하여 하나의 요청을 처리한다. 따라서 특정 요청이 어떤 경로를 거쳤고, 어느 부분에서 지연이 발생했으며, 오류가 발생했다면 어느 서비스에서 문제가 생겼는지를 알아내는 것이 중요하다. 이를 가능하게 하는 기술이 분산 트레이싱(distributed tracing) 이다.

 

분산 트레이싱을 통해 각 요청의 흐름을 시각적으로 확인하고, 병목 구간을 분석하며, 장애 발생 시 빠르게 대응할 수 있다. 대표적인 분산 트레이싱 도구로는 Jaeger, Zipkin, OpenTelemetry 등이 있으며, 이러한 도구를 활용하면 마이크로서비스 환경에서도 체계적인 모니터링과 디버깅이 가능하다.

 

이 중 트위터에서 사용하는 분산 환경 시스템인 Zipkin에 대해 살펴보고자 한다.

🔹Zipkin

https://brunch.co.kr/@springboot/58

Zipkin은 마이크로서비스 간의 요청 흐름을 추적하는 분산 트레이싱 시스템이다.

아래는 Zipkin을 활용한 마이크로서비스 모니터링 구조이다

• Microservice A, B, C: 각각 독립적인 Spring Boot 기반의 마이크로서비스
• Collector: 각 마이크로서비스에서 발생한 트레이싱 데이터를 수집하는 역할
• DB: 수집된 트레이싱 데이터를 저장하여 분석 가능하도록 함
• Query Service: 저장된 데이터를 검색하여 추적 결과를 제공하는 서비스
• WebUI: 트레이싱 데이터를 시각적으로 제공하는 인터페이스

각 마이크로서비스에서 발생하는 요청 및 응답 정보는 Trace ID와 Span ID를 포함하여 Zipkin의 Collector로 전송된다. Collector는 이 데이터를 저장소(DB)에 저장하고, 사용자는 Query Service와 WebUI를 통해 트레이싱 정보를 조회할 수 있다. 이를 통해 요청이 어떤 마이크로서비스를 거쳤는지, 어느 단계에서 지연이 발생했는지를 시각적으로 분석할 수 있다.

 

🔹Tracing

https://brunch.co.kr/@springboot/58

이 그림에서는 하나의 요청이 여러 개의 서비스(Service 1, 2, 3, 4)를 거쳐 가는 과정에서 Trace ID와 Span ID가 어떻게 관리되는지를 보여준다.

- Trace ID : 이벤트 chain의 id
- Span ID : 현재 이벤트의 id
     - Parent Span ID : 나를 호출한 Span ID

💡Trace ID와 Span ID를 통해서 call chain의 순서를 알 수 있다.

1. Service 1에서 클라이언트 요청을 받으면 처음에는 Trace ID와 Span ID가 없는 상태이다.
2. Service 1이 요청을 처리한 후, Trace ID = X와 Span ID = A를 생성하여 하위 서비스로 전달한다.
3. Service 2는 Service 1에서 전달된 Trace ID를 유지하면서 새로운 Span ID = B, C를 생성하여 트랜잭션을 세분화한다.
4. Service 3과 Service 4도 Trace ID를 유지한 채 새로운 Span ID를 추가하면서 요청을 처리한다.

이러한 방식으로 Zipkin은 마이크로서비스 간 호출 관계를 시각적으로 분석할 수 있도록 지원하며 지연이 발생한 구간을 식별하고 문제 해결을 용이하게 한다.

---

🔸서킷 브레이커 패턴 (Circuit Breaker Pattern)

서킷 브레이커 패턴:
서킷 브레이커 패턴은 마이크로서비스 아키텍처에서 장애 확산을 방지하기 위해 사용되는 보호 메커니즘이다.
서비스 간 호출이 실패하면 추가적인 요청을 차단하여 시스템이 과부하 상태에 빠지는 것을 방지한다.

서킷 브레이커 패턴이 바로 장애 전파를 막기 위한 전략 중 하나이다.

 

https://martinfowler.com/bliki/CircuitBreaker.html

서킷 브레이커의 동작 방식은 다음과 같다.

1. Closed (정상 상태): 서비스 요청이 정상적으로 처리되며, 실패율이 낮은 경우 서킷 브레이커는 닫힌 상태를 유지한다.
2. Open (차단 상태): 서비스 실패율이 설정된 임계값을 초과하면 서킷이 열리고, 추가적인 요청을 차단하여 시스템을 보호한다. => 즉시 실패 처리
3. Half-Open (테스트 상태): open 상태 이후 일정 시간이 지난 후, 서킷이 반쯤 열려 일부 요청을 허용한다. 만약 요청이 성공하면 다시 Closed 상태로 전환하고, 실패하면 Open 상태를 유지한다.

https://rdg.kr/%EC%84%9C%ED%82%B7-%EB%B8%8C%EB%A0%88%EC%9D%B4%EC%BB%A4-%ED%8C%A8%ED%84%B4-circuit-braker-pattern-%EC%9A%94%EC%95%BD/

위의 그림처럼 장애가 발생한 서비스에 대해서는 회로를 차단함으로써 장애가 발생한 서비스에 대한 불필요한 호출을 방지하여 성능을 유지할 수 있고, 과부하로 인해 시스템 전체가 다운되는 것을 방지한다.

 

그렇다면 서킷 브레이커는 이때 외부 장애를 어떻게 판단할까?

 

장애 판단 기준은 다음과 같다.

• slow call : 기준 시간보다 오래 걸렸을 때
• failure call : 실패 or 오류를 응답 받았을 때

이를 통해 다음과 같은 규칙을 만들 수 있다.

closed 조건
- 특정 요청이 n번 연속 실패했을 경우
- 특정 요청이 n번 연속 k초 이상 시간초과 할 경우

half-open => open 조건
- 차단 했던 요청이 n번 연속 성공했을 경우

---

🔹 서킷 브레이커 패턴 실습

GitHub - JHZLO/circuit-breaker-pattern: MSA 환경에서 장애 전파를 막기 위한 전략 (Circuit Breaker)

(상세한 실습은 깃허브에 정리해두었다)

 

서킷 브레이커의 구현 도구로는 대표적으로 다음과 같다.

• Resilience4j: Spring Boot에서 가장 널리 사용되는 서킷 브레이커 라이브러리.
• Hystrix: Netflix에서 개발한 라이브러리로, 현재는 유지보수가 중단되었지만 여전히 일부 프로젝트에서 사용됨.

이 중 Resilience4j를 통한 서킷 브레이커 예제를 다뤄보고자 한다.

    @Test
    fun failureRateThreshold() {

        val circuitBreaker = of(
            "circuit-breaker", CircuitBreakerConfig.custom()
                .minimumNumberOfCalls(10)
                .failureRateThreshold(10f)
                .slidingWindowType(CircuitBreakerConfig.SlidingWindowType.TIME_BASED)
                .build()
        )

        var successCount = 0
        var failureCount = 0
        val logicCnt = AtomicInteger()

        for (i in 1..100) {
            try {
                val circuitLogic = decorateConsumer(circuitBreaker, Consumer<AtomicInteger> { someLogic(it) })
                circuitLogic.accept(logicCnt)
                successCount++
            } catch (e: Exception) {
                failureCount++
            }
        }

        println("logic trigger 횟수 ${logicCnt.get()}")
        println("성공-$successCount 실패-$failureCount")
    }

    /**
     * 30% 확률로 error 발생 시킴.
     * */
    fun someLogic(cnt: AtomicInteger) {
        cnt.getAndIncrement()
        if (ThreadLocalRandom.current().nextLong(100) < 30) {
            throw RuntimeException("error")
        }
    }

- minimumNumberOfCalls(10): 최소 10번의 요청이 있어야 서킷 브레이커가 동작
- failureRateThreshold(10f): 실패율이 10% 이상이면 서킷 브레이커가 열림 (이후 요청을 차단)
- slidingWindowType(CircuitBreakerConfig.SlidingWindowType.TIME_BASED): 시간 기반으로 실패율을 계산

1️⃣ 테스트 반복 실행

var successCount = 0
var failureCount = 0
val logicCnt = AtomicInteger()

for (i in 1..100) {
    try {
        val circuitLogic = decorateConsumer(circuitBreaker, Consumer<AtomicInteger> { someLogic(it) })
        circuitLogic.accept(logicCnt)
        successCount++
    } catch (e: Exception) {
        failureCount++
    }
}

• 1부터 100까지 루프를 돌면서 someLogic()을 실행
• 서킷 브레이커가 적용된 로직을 실행(decorateConsumer)
• 성공하면 successCount++, 실패하면 failureCount++

 

2️⃣ 서킷 브레이커가 적용된 로직 실행

fun someLogic(cnt: AtomicInteger) {
    cnt.getAndIncrement()
    if (ThreadLocalRandom.current().nextLong(100) < 30) {
        throw RuntimeException("error")
    }
}

• someLogic()이 호출될 때마다 cnt 값을 증가
• 30% 확률로 예외 발생 (ThreadLocalRandom.current().nextLong(100) < 30)

 

3️⃣ 실행 결과

logic trigger 횟수 10
성공-8 실패-92

• someLogic()이 실행된 총 횟수(logicCnt) = 10
• 서킷 브레이커가 차단한 후 성공/실패 횟수를 출력

minimumNumberOfCalls 10에 도달 하자마자 10%까지의 오류만 허용하기 때문에 서킷이 열리고 나머지는 전부 실패로 처리한다.

 

---

🔸Rate Limiting

Rate Limiting:
단위 시간당 처리량을 제한하여 시스템의 안정성을 높이는 방법이다.
이를 통해 서비스가 과부하로 인해 응답하지 못하는 상황을 방지할 수 있다

서비스 A의 안정적인 서비스를 제공하기 위한 트래픽의 제한이 1000이라고 가정해보자.

이때, 만약 1000보다 이상인 트래픽이 들어오게 되면 서비스가 불안정하고 더 몰릴 경우에는 서비스의 장애로 이어질 수 있다.

 

안정적인 서비스를 제공할 수 있는 트래픽에 제한을 걸어 이보다 높은 트래픽이 들어오는 경우에도 서비스가 장애로 이어지지 않도록 하는 전략이 바로 Rate Limiting 방식이다.

 

일반적으로 외부 API(Slack, OpenAI API 등)를 호출할 때 과도한 요청으로 차단되지 않도록 요청 횟수를 제한할 때 사용된다.(Third-Party API 호출)

 

이러한 트래픽 제한 방식에는 일반적으로 다음과 같이 두 가지로 나뉠 수 있다.

• Global Limit: 모든 요청을 중앙 저장소(DB, Redis 등)에서 카운트하여 제한
• Local Limit: 각 Pod(서비스 인스턴스)에서 독립적으로 요청 횟수를 카운트하여 제한

---

🔹대표적인 알고리즘

1️⃣ Token Bucket

일정량의 토큰을 버킷에 저장하고, 요청이 들어올 때마다 토큰을 사용하여 요청을 허용한다

토큰이 없으면 요청을 차단하고, 주기적으로 토큰을 다시 채워주는 방식이다.

2️⃣ Leakage Bucket

물 양동이에 구멍을 뚫어 일정한 속도로 물이 흐르는 것과 같은 개념이다.

단위 시간당 갑작스러운 요청 증가를 방지하고, 요청을 일정한 속도로 처리할 수 있도록 조절하는 알고리즘이다.

---

🔹Rate Limit 실습

    @Test
    fun failureRateThreshold() {

        val rateLimiter = RateLimiter.of(
            "ratelimiter-breaker", RateLimiterConfig.custom()
                .limitForPeriod(1) // 단위 시간당 처리량
                .timeoutDuration(Duration.ofMillis(10)) // throttle 걸렸을때 대기시간
                .limitRefreshPeriod(Duration.ofSeconds(10)) //token 채우는 주기
                .build()
        )

        var successCount = 0
        var failureCount = 0
        val logicCnt = AtomicInteger()

        for (i in 1..100) {
            try {
                val limiterLogic = decorateConsumer(rateLimiter, Consumer<AtomicInteger> { someLogic(it) })
                limiterLogic.accept(logicCnt)
                successCount++
            } catch (e: Exception) {
                failureCount++
            }
        }

        println("logic trigger 횟수 ${logicCnt.get()}")
        println("성공-$successCount 실패-$failureCount")
    }


    fun someLogic(cnt: AtomicInteger) {
        cnt.getAndIncrement()
    }

- limitForPeriod(1) : 단위 시간(10초) 동안 최대 1개의 요청만 허용한다
- timeoutDuration(Duration.ofMillis(10)) : 만약 Rate Limiter가 동작하여 요청이 차단되었을 때, 최대 10ms 동안 대기 후 실패 처리한다
- limitRefreshPeriod(Duration.ofSeconds(10)) : 10초마다 토큰이 갱신되어 새로운 요청을 받을 수 있도록 한다

 

1️⃣ 테스트 반복 실행

var successCount = 0
var failureCount = 0
val logicCnt = AtomicInteger()

for (i in 1..100) {
    try {
        val limiterLogic = decorateConsumer(rateLimiter, Consumer<AtomicInteger> { someLogic(it) })
        limiterLogic.accept(logicCnt)
        successCount++
    } catch (e: Exception) {
        failureCount++
    }
}

• 1부터 100까지 루프를 돌면서 someLogic()을 실행
• limiter logic이 적용된 로직을 실행(decorateConsumer)
• 성공한 요청이면 successCount++, 실패하면 failureCount++.

 

limitForPeriod(1)로 인해 10초에 한 번만 요청이 성공한다.

 

2️⃣RateLimit 로직

fun someLogic(cnt: AtomicInteger) {
    cnt.getAndIncrement()
}

실제 비즈니스 로직을 실행하는 대신 단순히 실행 횟수 카운트한다.

 

3️⃣ 실행 결과

logic trigger 횟수 1
성공-1 실패-99

10초에 1개만 허용하였기 때문에 한 번만 성공한다.

---

📙 출처

<Kurt Farm 스터디>