장애를 확산시키지 않는 시스템 설계
이 글은 「대용량 트래픽 제어하기」 시리즈 3편이다.
1편과 2편에서 확장과 리소스 관점에서의 한계를 살펴봤다면, 3편에서는 관점을 전환한다. 대용량 트래픽 환경에서 가장 위험한 것은 “부족함”이 아니라 장애가 전파되는 구조다. 이 글에서는 장애를 빠르게 감지하고, 넓게 퍼지기 전에 차단하는 설계에 대해 다룬다.
장애는 왜 시스템 전체로 퍼질까
장애는 보통 하나의 지점에서 시작된다.
- 느려진 외부 API
- 응답하지 않는 인증 서버
- 일시적으로 멈춘 DB
하지만 실제 피해는 이 지점보다 훨씬 넓게 발생한다.
이유는 요청이 멈추지 않기 때문이다.
요청이 계속 들어오고, 처리되지 못한 요청이 쌓이면서 다음 현상이 연쇄적으로 발생한다.
- 스레드 점유
- 커넥션 풀 고갈
- 타임아웃 증가
- Retry 폭증
이 과정을 장애 전파(cascading failure) 라고 한다.
느리게 실패하는 시스템의 위험성
많은 시스템은 장애 상황에서도 최대한 응답하려고 한다.
- 오래 기다리다 타임아웃
- 여러 번 재시도
- 내부적으로 처리 시도 반복
이 구조는 겉보기에는 “버티는 것처럼” 보이지만, 실제로는 가장 위험하다.
느리게 실패하는 시스템의 특징은 다음과 같다.
- 리소스를 오래 점유
- 실패 요청이 누적
- 정상 요청까지 영향을 받음
결국 전체 시스템이 동시에 무너진다.
빠르게 실패하는 시스템이란 무엇인가
대용량 트래픽 환경에서 안정적인 시스템은 빠르게 실패한다.
빠르게 실패한다는 것은 다음을 의미한다.
- 복구 불가능한 요청은 즉시 차단
- 더 이상의 리소스 소모 중단
- 실패를 명확하게 드러냄
이 전략의 핵심은 “살릴 수 없는 요청을 빨리 포기하는 것”이다.
Retry는 언제 도움이 되고, 언제 독이 되는가
Retry는 일시적인 오류를 복구하는 데 유용하다.
- 네트워크 순간 장애
- 일시적인 부하 스파이크
하지만 장애가 지속되는 상황에서는 Retry가 문제를 키운다.
- 실패 요청 수 증가
- 외부 시스템 부하 가중
- 장애 복구 시간 지연
Retry는 반드시 제한된 조건에서만 사용되어야 한다.
서킷 브레이커의 역할
서킷 브레이커는 반복되는 실패를 감지해 호출 자체를 차단한다.
이 패턴의 핵심 역할은 다음과 같다.
- 실패 요청의 추가 유입 차단
- 리소스 보호
- 장애 범위 격리
서킷 브레이커는 장애를 숨기지 않고, 관리 가능한 상태로 만든다.
서킷 브레이커의 상태 전환 의미
서킷 브레이커는 보통 다음 상태를 가진다.
- Closed
- 정상 호출
- Open
- 호출 즉시 실패
- 외부 시스템 보호
- Half-Open
- 제한된 호출로 복구 여부 판단
이 구조를 통해 시스템은 “지금 시도해도 되는지”를 스스로 판단한다.
Retry와 서킷 브레이커의 올바른 조합
대용량 트래픽 환경에서 두 패턴은 함께 사용되어야 한다.
기본적인 흐름은 다음과 같다.
- 요청 수행
- 제한된 Retry 적용
- 실패율 증가 감지
- 서킷 브레이커 Open
- 이후 요청 즉시 실패
이 조합을 통해 장애 전파를 효과적으로 차단할 수 있다.
타임아웃이 반드시 필요한 이유
타임아웃은 요청 하나의 최대 대기 시간을 제한한다.
타임아웃이 없으면 다음 문제가 발생한다.
- 스레드 장기 점유
- 커넥션 반환 지연
- 장애 확산 가속
타임아웃은 빠른 실패를 가능하게 하는 가장 기본적인 장치다.
Scale Out 환경에서 장애 제어가 더 중요한 이유
Scale Out은 요청 처리 능력을 늘린다.
하지만 장애 상황에서는 다음 문제가 발생한다.
- 더 많은 Pod가 실패 요청을 보냄
- Retry 요청 폭증
- 외부 시스템에 부하 집중
즉, 확장은 장애를 더 빠르게 증폭시킬 수 있다.
이때 필요한 것이 제어 장치다.
장애를 격리한다는 것의 의미
장애 격리는 다음 질문에 답하는 것이다.
- 이 실패가 어디까지 영향을 미쳐야 하는가
- 어디에서 반드시 차단해야 하는가
격리가 되지 않으면, 작은 장애도 전체 장애로 확대된다.
대용량 트래픽 제어의 관점 정리
3편까지의 내용을 관통하는 핵심은 하나다.
- 확장은 처리량을 늘린다
- 제어는 시스템을 살린다
대용량 트래픽 환경에서 중요한 것은 “얼마나 많이 처리하느냐”가 아니라
“어디까지 허용하고, 어디서 멈출 것이냐”다.
시리즈 전체 요약
- 1편
- 트래픽 증가의 본질과 Scale Out의 한계
- 2편
- 리소스, HPA, JVM 메모리로 인한 실패 지점
- 3편
- 장애 전파를 막는 설계와 빠른 실패 전략
이 세 가지가 함께 고려되어야 대용량 트래픽을 제어할 수 있다.
정리
대용량 트래픽 환경에서 장애는 피할 수 없다. 중요한 것은 장애를 없애는 것이 아니라, 장애가 시스템 전체로 확산되지 않도록 제어하는 것이다. Retry, 타임아웃, 서킷 브레이커는 이를 위한 핵심 도구다. 확장 이후의 시스템을 안정적으로 운영하려면, 반드시 “빠르게 실패하는 구조”를 설계해야 한다.