[Spring Boot] 외부 서비스 장애에 대비하는 동기 호출의 생존 전략 - 1

백엔드 작업을 하다보면 외부 API를 불러서 사용하는 기능들이 점점 많아질 것입니다. 그런데 갑자기 이 외부 서비스들이 갑자기 느려지는 장애가 걸리면 우리는 어떻게 될까?! 만약 우리가 동기 방식으로 호출하는 경우, 이러한 문제들은 우리의 서비스의 장애를 일으킬 것입니다.

이번 기회에 이와 같은 문제가 발생할 수 있는 문제점들을 살펴보고, 해결하기 위한 핵심 전약인 타임아웃 설정, 벌크헤드 패턴, 그리고 서킷 브레이커 패턴에 대해 알아보도록 하겠습니다.

1. 외부 서비스 장애: 조용한 암살자

오늘날 대부분의 시스템은 외부 API나 서드파티 서비스(결제, 인증, 주소 검색, 번역, 날씨 정보 등등)에 의존해 동작하고 있음을 가정해봅시다. 잘 되고 있다면 상관이 없겠지만, 만약 응답이 지연되기 시작하면 어떤 일이 발생할까요?

1. 쓰레드(또는 커넥션)가 묶인다.
   • 외부 API 응답을 기다리는 동안, 해당 요청을 처리하던 서버의 쓰레드가 블로킹 상태에 빠집니다.
   • 이는 곧 서버의 처리 가능 요청수가 줄어드는 것을 의미합니다.
2. 응답 대기 자원 증가.
   • 블로킹된 쓰레드가 점점 늘어나고, 동시에 들어오는 요청은 처리되지 않고 대기열에 쌓이게 됩니다.
   • 이로 인해 평균 응답 시간도 전체적으로 지연되기 시작합니다.
3. 자원 고갈 (리소스 Exhaustion)
   • 커넥션 풀, 쓰레드 풀, DB 커넥션 등이 고갈 됩니다.
   • 서버는 내부 요청 조차 처리할 수 없게 된다면, 결국 서비스의 전체 장애로 이뤄질 수 있습니다.
4. 성능저하.
   • 가용 자원이 줄들며 전체적인 서비스 응답솓도가 느려지고, 처리량이 감소합니다.
   • 마치 작은 균열에서 시작된 도미노 붕괴와 같습니다.

---

그림 이와 같은 문제를 해결하기 위해서 어떤 방법들이 있을까요?

첫번째, 타임아웃 설정.

타임아웃 설정은 외부 서비스 장애나 지연에 우리 시스템이 무한정 끌려가지 않도록 막는 가장 기본적이고 중요한 방어선입니다.

타임아웃(TimeOut)은 요청을 보낸 후, 지정된 시간 내에 응답을 받지 못하면 요청을 중단하고 예외를 발생시키는 것을 의미합니다.

Connection Timout

클라이언트가 외부 서버에 TCP 연결을 수립하려고 시도할 때, 그 시도가 얼마나 오래 걸릴 수 있는지를 제한하는 시간입니다. 즉, 서버가 꺼져 있거나 너무 멀거나 방화벽이 막고 있어도, 무한히 기다리지 않고 정해진 시간까지만 연결을 시도합니다.

[Client] ─── TCP SYN ──► [Server] (응답 없음)  
         ◄── timeout (예: 3초)

Read Timeout

서버로부터 응답(헤더가 아니라 본문!)이 언제 도착할지 모를 때, 기다릴 수 있는 최대 시간입니다. 연결은 되었고, 요청도 잘 전송되었지만, 서버가 응답을 느리게 하거나 멈춘 상황에 대비합니다.

[Client] ─── request ──► [Server]
                         (서버가 너무 느리게 응답함)
                         ◄── timeout (예: 5초)

Write Timeout

클라이언트가 서버로 POST나 PUT 요청 시 body 데이터를 전송할 때, 얼마나 오래 걸릴 수 있는지를 제한합니다. 보통 이미지, 대용량 JSON 등 큰 바디를 보내는 경우 해당됩니다.

[Client] ───(보내는 중)──► [Server]
         ◄── timeout (예: 10초)

 

 

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

• Connection Timout 값 설정
  • TCP 연결을 맺을 때는 3단계의 핸드 세이크가 필요합니다.
    1. Client → Server : SYN 전송
    2. Server → Client : SYN/ACK 응답
    3. Client → Server : ACK 전송
    → 이 과정 중 어떤 단계에서든 패킷 유실(loss)가 발생할 수 있습니다.
  • TCP는 최초로 패킷(SYN)을 보낼 때, 상대 서버까지 왕복하는 데 걸리는 시간(RTT)을 아직 알수가 없습니다. 그래서 임시로 고정된 값인 InitRTO를 사용합니다.
  • 만약 첫번째 SYN가 유실된다면, 1초 후 재전송 합니다. 이때도 실패하면 2초뒤 재전송 하고, 그래도 실패하면 4초 뒤 재전송 하게됩니다. (즉 타임아웃 시간은 2의 제곱형태로 증가합니다.)

  // 재전송 주기
  1초 → 2초 → 4초 ...

  • initRTO 값을 3초로 설정하는 것이 가장 실용적이라고 한다 왜일까?, 답은 3초는 대부분의 네트워크 환경에서 1~2번의 패킷 손실까지는 복구 지속적 장애 상황에서는 빠르게 실패를 감지할 수 있는 값이기 때문입니다. (하지만 이 또한 서비스의 환경에 따라서 조절이 필요하다.)
• Read Timeout 값 설정
  • TCP는 데이터를 전송한 후 RTT(Round-Trip-Time) 를 측정하여 RTO(재전송 타임아웃)을 계산합니다. RTO의 최솟값은 200ms이며 RTT에 기반하여 변할 수 있습니다.
  • 즉 리드 타임 아웃 은 실제 외부 서비스 처리 시간(Processing Time)과 RTT, RTO에 함께 고려해서 정해야 하는 골치아픈 일입니다.

사용하는 HTTP 클라이언트 라이브러리가 커넥션 타임아웃과 리드 타임아웃을 개별적으로 설정할 수 있도록 지원하는지 확인해야 합니다. 중요한 것은 타임아웃의 의미를 정확히 이해하고 서비스 특성에 맞춰서 설정하는 것입니다.

 

 

다음은 벌크헤드 패턴, 그리고 서킷 브레이커 패턴에 대해서 알아보도록 하겠습니다.