외부 서비스 장애, 내 서비스까지 마비될 순 없다! 장애 전파 막는 백엔드 생존 전략

이동휘·2025년 5월 16일
백엔드시리즈
0

매일매일 블로그

목록 보기
12/49

백엔드 시스템을 개발하다 보면 필연적으로 외부 서비스와 연동하게 됩니다. 그런데 만약 우리가 의존하는 외부 서비스가 갑자기 느려지거나 장애가 발생한다면 어떻게 될까요? 동기 방식으로 호출하는 경우, 외부 서비스의 문제는 고스란히 우리 서비스의 성능 저하와 장애로 이어질 수 있습니다.

이 글에서는 동기 방식 외부 서비스 호출 시 발생할 수 있는 문제점들을 살펴보고, 이를 해결하기 위한 핵심 전략인 타임아웃 설정, 벌크헤드 패턴, 그리고 서킷 브레이커 패턴에 대해 깊이 있게 알아보겠습니다.

1. 외부 서비스 장애: 조용한 암살자, 내 서비스 성능을 노린다!

동기 방식으로 외부 API를 호출하는 상황을 가정해 봅시다. 정상적인 상황에서는 문제없지만, 만약 외부 서비스의 응답이 지연되기 시작하면 어떤 일이 벌어질까요?

  • 응답 대기 자원 증가: 외부 API 응답을 기다리는 스레드나 커넥션 같은 자원들이 우리 서버 내부에 점점 쌓이게 됩니다.
  • 성능 저하: 가용 자원이 줄어들면서 전체적인 서비스 응답 속도가 느려지고, 처리량이 감소합니다.
  • 자원 고갈 및 장애 전파: 심한 경우, 스레드 풀이나 커넥션 풀이 고갈되어 외부 서비스와 관련 없는 다른 기능까지 마비시키고, 결국 서비스 전체 장애로 이어질 수 있습니다.

가장 기본적인 해결책: 타임아웃 설정!

이러한 문제를 막기 위한 가장 기본적인 방어선은 바로 타임아웃(Timeout) 설정입니다. 외부 서비스 호출 시 무한정 기다리지 않고, 일정 시간 내에 응답이 없으면 연결을 중단하거나 읽기를 포기하도록 설정하는 것입니다. 주요 타임아웃 종류는 다음과 같습니다.

  • 커넥션 타임아웃 (Connection Timeout): 외부 서비스와 TCP 연결을 맺는 데까지 허용되는 최대 시간입니다. 이 시간 내에 연결되지 않으면 실패로 간주합니다.
  • 리드 타임아웃 (Read Timeout): 연결이 성공적으로 맺어진 후, 외부 서비스로부터 데이터를 읽어오는 데까지 허용되는 최대 시간입니다. (소켓 타임아웃이라고도 불림)
  • HTTP 커넥션 풀 타임아웃: HTTP 클라이언트 라이브러리가 관리하는 커넥션 풀에서 사용 가능한 커넥션을 가져오는 데까지 허용되는 최대 시간입니다.

타임아웃 설정, 어떻게 하는 것이 좋을까? 🤔

무작정 짧게 설정하면 정상적인 상황에서도 타임아웃이 발생할 수 있고, 너무 길게 설정하면 장애 상황을 늦게 인지하게 됩니다. 적절한 타임아웃 값을 설정하기 위한 기준은 다음과 같습니다.

  1. 네트워크 패킷 유실은 언제든 발생할 수 있다: 네트워크는 100% 완벽하지 않으므로, 간헐적인 패킷 유실을 고려해야 합니다.
  2. 네트워크 문제는 가능한 빨리 인지해야 한다: 장애 발생 시 신속한 대응을 위해 불필요한 대기 시간을 줄여야 합니다.

기준: "한 번의 패킷 유실 정도는 재전송을 통해 복구될 수 있는 수준의 타임아웃"

  • 커넥션 타임아웃 값 설정:
    • TCP 3-way handshake 과정(SYN → SYN/ACK → ACK)에서 패킷 유실이 발생할 수 있습니다.
    • 최초 연결 시도(SYN 패킷 전송 후 응답 대기)에는 RTT(Round Trip Time)를 알 수 없어 InitRTO라는 고정된 타임아웃 값(Linux 기본 1초)이 사용됩니다.
    • SYN 또는 SYN/ACK 패킷이 한 번 유실되면 최소 1초 이상의 지연이 발생합니다. InitRTO는 실패 시 2의 제곱으로 증가(1초 → 2초 → 4초...)합니다.
    • 따라서 3초 정도로 설정하면, 한 번의 주요 패킷 유실(SYN 또는 SYN/ACK)은 커버하고, 두 번 이상의 연속적인 유실(네트워크 문제 가능성 높음) 발생 시에는 타임아웃을 통해 빠르게 실패를 인지할 수 있습니다. (물론 이는 일반적인 가이드이며, 서비스 환경에 따라 조절 필요)
  • 리드 타임아웃 값 설정:
    • 연결이 맺어진 후에는 실제 RTT를 기반으로 계산된 RTO(Retransmission Timeout) 값이 패킷 재전송에 사용됩니다. RTO의 최소값은 보통 200ms입니다.
    • 리드 타임아웃은 RTO 외에도 실제 RTT와 외부 서비스의 처리 시간(Processing Time)을 함께 고려해야 합니다.
    • 만약 외부 서비스의 평균 처리 시간이 300ms이고 RTT가 10ms라면, 정상적인 응답 시간은 약 310ms입니다. 여기에 한 번의 패킷 유실(최대 RTO 200ms 가정)을 고려하면 약 510ms가 소요될 수 있습니다.
    • 따라서 외부 서비스의 SLA(Service Level Agreement) 및 평균 응답 시간을 기준으로, 약간의 네트워크 지연과 한 번 정도의 패킷 유실을 감안하여 1초 또는 그 이상(단, 서비스 특성에 맞게)으로 설정하는 것을 고려해볼 수 있습니다. (단, 처리 시간 자체가 1초를 넘는다면 이 값은 의미가 없으므로, 외부 서비스 응답 시간 P95, P99 등을 기준으로 설정)

중요! 사용하는 HTTP 클라이언트 라이브러리가 커넥션 타임아웃과 리드 타임아웃을 개별적으로 설정할 수 있도록 지원하는지 확인해야 합니다. 하나의 Timeout 값으로 통합 관리하는 경우도 있습니다. 가장 중요한 것은 "그냥 남들이 하니까"가 아니라, 타임아웃의 의미를 정확히 이해하고 서비스 특성에 맞는 기준을 세워 설정하는 것입니다.

2. 벌크헤드 패턴 (Bulkhead Pattern): 장애 격리를 통한 서비스 안정성 확보

타임아웃 설정만으로는 부족한 경우가 있습니다. 특히 여러 외부 서비스를 동시에 호출하거나, 하나의 자원(예: HTTP 커넥션 풀, 스레드 풀)을 여러 기능이 공유할 때 문제가 발생할 수 있습니다.

🤔 이런 상황, 어떡하죠?

  1. 서비스 A, B, C를 호출하는 로직이 하나의 HTTP 커넥션 풀을 공유합니다.
  2. 이때, 서비스 A에 장애가 발생하여 응답이 매우 느려집니다.
    • 커넥션 풀에서 서비스 A 호출에 사용된 커넥션들이 반환되지 않고 점유됩니다.
    • 점점 풀에 남은 가용 커넥션이 줄어듭니다.
    • 새로운 요청이 풀에서 커넥션을 얻기 위해 대기하는 시간이 증가합니다.
    • 결국, 정상적인 서비스 B와 C를 호출하려는 요청마저 커넥션을 할당받지 못해 함께 지연되거나 실패합니다. (장애 전파!)

이러한 장애 전파(Cascading Failure)를 막기 위한 강력한 패턴이 바로 벌크헤드 패턴(Bulkhead Pattern)입니다.

◼️ 벌크헤드 패턴이란?

선박의 격벽(Bulkhead)에서 유래한 용어입니다. 선박은 내부에 여러 격벽을 설치하여 특정 구획에 물이 차더라도 다른 구획으로 침수가 확산되는 것을 막아 배 전체의 침몰을 방지합니다.

이와 마찬가지로, 벌크헤드 패턴은 애플리케이션의 리소스를 기능별 또는 외부 서비스별로 격리하여, 일부 컴포넌트나 외부 서비스에 문제가 발생하더라도 그 영향이 시스템 전체로 퍼지지 않도록 막아주는 아키텍처 패턴입니다.

◼️ 적용 예시: 외부 서비스별 HTTP 커넥션 풀 분리

위 예시 상황에서, 서비스 A, B, C를 호출할 때 각각 별도의 HTTP 커넥션 풀을 사용하도록 구성하는 것이 벌크헤드 패턴의 적용입니다.

  • 서비스 A 호출: 커넥션 풀 A 사용
  • 서비스 B 호출: 커넥션 풀 B 사용
  • 서비스 C 호출: 커넥션 풀 C 사용

이렇게 하면, 서비스 A에 장애가 발생하여 커넥션 풀 A의 자원이 모두 소진되더라도, 서비스 B와 C를 호출하는 데 사용되는 커넥션 풀 B와 C는 영향을 받지 않습니다. 따라서 서비스 A의 장애가 서비스 B, C로 전파되는 것을 효과적으로 차단할 수 있습니다.

◼️ 다양한 리소스에 적용 가능

벌크헤드 패턴은 HTTP 커넥션 풀뿐만 아니라 다음과 같은 다양한 리소스에 적용될 수 있습니다.

  • 스레드 풀 분리: 특정 외부 서비스 호출이나 특정 유형의 작업을 처리하는 스레드 풀을 분리합니다. (예: Apache POI를 사용한 엑셀 생성 기능처럼 메모리 집약적인 작업은 별도 스레드 풀에서 제한된 동시 요청만 처리)
  • 세마포어(Semaphore)를 이용한 동시 요청 제어: 물리적으로 풀을 분리하지 않고, 특정 기능에 대한 동시 실행 수를 세마포어를 통해 제한하여 리소스 고갈을 방지합니다.
  • 메시지 큐 분리: 특정 유형의 메시지나 특정 소비자 그룹을 위한 큐를 분리합니다.

핵심 아이디어는 "리소스 격리를 통한 장애 격리"입니다.

◼️ Apache POI 엑셀 생성 기능 장애 격리 사례

최근 대용량 데이터를 Apache POI를 사용하여 엑셀 파일로 생성하여 사용자에게 제공하는 기능을 개발했습니다. Apache POI는 큰 데이터를 다룰 때 OutOfMemoryError(OOM) 발생 가능성이 있다는 점을 인지했고, 만약 엑셀 생성 중 OOM이 발생하면 전체 서버가 다운될 수 있는 심각한 문제였습니다.

이상적인 해결책은 해당 기능을 별도의 서비스로 분리하여 물리적으로 장애를 격리하는 것이지만, 일정과 운영 비용을 고려했을 때 이는 오버 엔지니어링이라고 판단했습니다. 대신, 기존 서비스 내에 기능을 구현하되 벌크헤드 패턴을 적용하여 동시에 엑셀 생성을 요청할 수 있는 최대 스레드 수를 제어하기로 결정했습니다. Resilience4j 라이브러리의 벌크헤드 기능을 사용하여, 엑셀 생성 작업 전용으로 최대 동시 호출 수를 제한하는 세마포어 기반 벌크헤드를 설정했습니다. 이를 통해 특정 사용자의 대용량 엑셀 요청이 다른 핵심 기능에 영향을 미치지 않도록 방지할 수 있었습니다.

(참고: Apache POI 사용 시 메모리 문제를 완화하기 위해 스트리밍 방식의 SXSSFWorkbook 구현체를 사용하는 것이 좋습니다.)

◼️ Resilience4j를 활용한 벌크헤드 구현 (간단 예시)

Java 생태계에서는 Resilience4j와 같은 라이브러리를 사용하면 어노테이션이나 설정을 통해 손쉽게 벌크헤드 패턴을 적용할 수 있습니다.

  1. 의존성 추가:

    implementation("io.github.resilience4j:resilience4j-spring-boot2:2.2.0") // 버전은 최신으로

  2. 설정 (application.yml 또는 application.properties):

    resilience4j:
  bulkhead:
    instances:
      myExternalService: # 벌크헤드 이름
        maxConcurrentCalls: 5 # 최대 동시 호출 수
        maxWaitDuration: 0ms   # 추가 요청 대기 시간 (0ms는 즉시 실패)

  3. 애플리케이션 코드 적용:

    import io.github.resilience4j.bulkhead.annotation.Bulkhead;
import org.springframework.stereotype.Service;
import org.springframework.web.client.RestTemplate;

@Service
public class ExternalServiceClient {

    private final RestTemplate restTemplate = new RestTemplate();

    @Bulkhead(name = "myExternalService", type = Bulkhead.Type.SEMAPHORE) // 또는 THREADPOOL
    public String callExternalService() {
        // Thread.sleep(10000); // 외부 서비스 지연 시뮬레이션
        return restTemplate.getForObject("http://external-service/api", String.class);
    }
}

    maxConcurrentCalls를 초과하는 동시 요청이 발생하면 BulkheadFullException이 발생하여 더 이상 해당 리소스를 점유하지 못하도록 막습니다.

3. 서킷 브레이커 패턴 (Circuit Breaker Pattern): 반복되는 장애로부터 시스템 보호

타임아웃과 벌크헤드 패턴을 적용했음에도 불구하고, 외부 서비스 장애가 지속적으로 발생한다면 어떻게 될까요?

  • 타임아웃으로 인해 우리 서비스에서는 계속해서 오류가 발생합니다.
  • 장애가 발생한 외부 서비스로 불필요한 요청을 계속 보내게 되어, 우리 서버의 자원을 낭비하고 응답 시간을 저해합니다.
  • 외부 서비스 입장에서도 이미 장애 상황인데 계속해서 요청을 받으면 부하가 가중되어 복구가 더 늦어질 수 있습니다.

이러한 문제를 해결하기 위한 패턴이 바로 서킷 브레이커(Circuit Breaker)입니다. 전기 회로의 차단기(Circuit Breaker)에서 아이디어를 얻은 패턴으로, 오류가 일정 횟수 이상 지속되면 일정 시간 동안 해당 외부 서비스로의 요청을 자동으로 차단합니다.

◼️ 서킷 브레이커의 3가지 상태

  • CLOSED (닫힘): 정상 상태. 외부 서비스로의 모든 요청이 허용됩니다. 오류 발생 시 실패 횟수를 카운트합니다.
  • OPEN (열림): 장애 상태. 일정 시간 동안 또는 일정 횟수 이상 오류가 발생하면 서킷이 열립니다. 이 상태에서는 외부 서비스로 실제 요청을 보내지 않고 즉시 실패(Fast-Fail)를 반환합니다. 이를 통해 불필요한 자원 낭비를 막고, 외부 서비스에 가해지는 부하를 줄여 복구할 시간을 줍니다.
  • HALF-OPEN (반열림): 복구 시도 상태. OPEN 상태에서 일정 시간이 지나면 서킷이 HALF-OPEN 상태로 전환됩니다. 이 상태에서는 제한된 수의 테스트 요청만 외부 서비스로 보내 정상 응답 여부를 확인합니다.
    • 테스트 요청이 성공하면 서킷을 CLOSED 상태로 전환합니다.
    • 테스트 요청이 실패하면 다시 OPEN 상태로 돌아가 대기 시간을 갖습니다.

◼️ 서킷 브레이커의 장점

  • 빠른 실패(Fast-Fail): 외부 서비스 장애 시 불필요한 대기 시간 없이 즉시 오류를 반환하여 사용자 경험 저하를 최소화하고, 호출 측 시스템의 자원 고갈을 방지합니다.
  • 장애 전파 방지: 반복적인 오류 요청을 차단하여 외부 서비스의 장애가 내 서비스로 전파되는 것을 효과적으로 막습니다.
  • 자동 복구 감지: HALF-OPEN 상태를 통해 외부 서비스의 복구 여부를 자동으로 감지하고, 정상화되면 다시 요청을 허용합니다.

Resilience4j, Hystrix(Netflix, 유지보수 모드) 등의 라이브러리를 사용하면 서킷 브레이커 패턴도 손쉽게 구현할 수 있습니다.

결론: 장애 상황에서도 살아남는 견고한 백엔드 시스템 구축하기

동기 방식으로 외부 서비스와 연동하는 것은 편리하지만, 외부 서비스의 장애는 언제든 발생할 수 있으며 이는 우리 시스템에 치명적인 영향을 미칠 수 있습니다.

  1. 타임아웃 설정은 외부 서비스 지연으로부터 우리 시스템을 보호하는 가장 기본적인 방어선입니다.
  2. 벌크헤드 패턴은 특정 기능이나 외부 서비스의 장애가 시스템 전체로 전파되는 것을 막는 효과적인 격리 전략입니다.
  3. 서킷 브레이커 패턴은 반복되는 외부 서비스 장애로부터 우리 시스템을 보호하고, 빠른 실패와 자동 복구 메커니즘을 제공합니다.

이러한 장애 대응 패턴들을 서비스의 특성과 요구사항에 맞게 적절히 조합하여 적용함으로써, 예측 불가능한 외부 환경 변화에도 흔들리지 않는 견고하고 안정적인 백엔드 시스템을 구축할 수 있을 것입니다. 단순히 코드를 작성하는 것을 넘어, 장애 상황까지 고려한 방어적인 프로그래밍이야말로 진정한 프로의 자세가 아닐까요?

profile
이동휘
이전 포스트

백엔드 개발자를 위한 필수 지식: 로그와 메트릭, 그리고 효과적인 로깅 전략

다음 포스트

DBMS 완전 정복 (1) : 데이터베이스, 어디까지 알고 계신가요? OLTP부터 Elasticsearch, 공간 DB까지 완전 정복

0개의 댓글