[MSA] 2편 – Resilience: 장애를 막는 것이 아니라 버티는 설계

1. 문제 상황 복습 (SPOF와 장애 전파)

이전 글에서 살펴본 것처럼 MSA 환경에서는 서비스 간 호출이 필수적이며,
특히 동기 호출 구조에서는 특정 서비스의 장애가 다른 서비스로 전파되는 문제가 발생할 수 있습니다.

예를 들어, Hub Service가 장애를 일으킬 경우 이를 호출하는 Order Service가 정상적인 응답을 받지 못하게 되고,
결과적으로 Gateway까지 타임아웃이 발생하며 최종적으로 Client 요청 실패로 이어집니다.

이러한 구조는 하나의 장애가 전체 시스템 장애로 확산되는 Cascade Failure를 유발하게 됩니다.

 

2. Resilience(회복성)란?

Resilience란 장애 상황에서도 서비스가 완전히 중단되지 않고,
일정 수준의 기능을 유지하며 안정적으로 동작할 수 있도록 하는 설계 능력을 의미합니다.

즉, 장애를 “막는 것”이 아니라, 장애가 발생하더라도 “버틸 수 있도록 설계하는 것”입니다.

 

3. 왜 Resilience가 필요한가?

MSA 환경에서는 다음과 같은 이유로 Resilience가 필수적입니다.

• 서비스 간 의존성 증가
• 네트워크 호출 기반 구조 (불안정성 존재)
• 부분 장애가 전체 장애로 확산될 가능성

따라서 장애 자체를 없애는 것은 불가능하며,
장애 상황에서도 시스템 전체가 영향을 받지 않도록 설계하는 것이 중요합니다.

 

4. Resilience 핵심 패턴

1) Timeout

외부 서비스 호출 시 일정 시간 이상 응답이 없으면 요청을 종료합니다.

효과:

• 무한 대기 방지
• 리소스 낭비 방지

 

2) Retry

일시적인 장애에 대해 일정 횟수 재시도합니다.

효과:

• 일시적인 네트워크 오류 대응

 

3) Circuit Breaker

지속적인 실패가 발생하면 일정 시간 동안 요청을 차단합니다.

효과:

• 장애 확산 방지
• 시스템 보호

 

4) Fallback

서비스 호출 실패 시 대체 응답을 제공합니다.

효과:

• 사용자 경험 유지

 

5. 동작 흐름

다음은 Resilience 패턴이 적용된 흐름입니다.

요청 → Timeout 발생 → Retry → 계속 실패 → Circuit Breaker OPEN → Fallback 응답

이러한 흐름을 통해 장애가 전체 시스템으로 확산되는 것을 방지할 수 있습니다.

 

6. 프로젝트 적용 예시

현재 프로젝트에서도 다음과 같은 방식으로 Resilience를 적용할 수 있습니다.

• FeignClient 호출 시 Timeout 설정
• Circuit Breaker 적용 (Resilience4j)
• Fallback 메서드 구현
• Retry 정책 설정

예를 들어, Hub Service 호출이 실패할 경우 기본 데이터 또는 캐시 데이터를 반환하도록 fallback을 구성할 수 있습니다.

 

7. 정리

MSA 환경에서는 장애가 발생하는 것이 자연스러운 상황이며, 중요한 것은 장애를 완전히 제거하는 것이 아니라
장애 상황에서도 시스템이 버틸 수 있도록 설계하는 것입니다.

Resilience는 이러한 설계를 위한 핵심 개념이며, SPOF로 인해 발생하는 장애 전파 문제를 해결하는 중요한 전략입니다.