dependency가 실패할 때의 graceful degradation이란 무엇인가요?

Question

IT Interview Practice · Accepted Answer

**graceful degradation**(우아한 성능 저하)은 dependency가 실패할 때, 시스템이 오류를 반환하는 대신 축소되거나 부분적인 경험을 제공하여 **핵심 흐름을 계속 동작**시키는 것을 의미합니다. 목표는 hard fail이 아니라 **soft fail**입니다: 저하된 페이지가 500보다 낫습니다.

## 기법

- **Fail soft** — dependency가 다운되면 오류를 내는 대신 **캐시된, 부분적인, 또는 기본** 데이터를 제공. stale하지만 존재하는 결과가 보통 아무것도 없는 것보다 낫습니다.
- **비핵심 경로를 feature-flag로 끄기** — 추천, analytics, 화려한 위젯을 꺼서 그곳의 실패가 메인 페이지를 망가뜨리지 못하게 함.
- **Timeout + fallback** — 느린 dependency를 영원히 기다리지 말 것; 타임아웃하고 fallback 값이나 경로로 전환.
- **실패 격리(bulkhead)** — dependency별로 자원(thread pool, connection pool)을 분할하여, 하나의 실패한 서비스가 모든 것을 고갈시켜 나머지를 끌어내리지 못하게 함.
- **핵심 흐름 보호** — 반드시 동작해야 하는 경로(둘러보기, 결제)를 식별하고, 비필수 기능이 절대 그것을 다운시키지 못하게 보장.

## 예: 검색 백엔드 다운

```text
나쁨  (fail hard):
  search() → backend timeout → throw → 사용자에게 HTTP 500 (페이지 전체 사망)

좋음 (fail soft):
  result = search()
         catch timeout → cached_results 반환 또는 빈 결과 + 안내
  페이지 렌더링:
    [ "최근 결과를 표시 중 — 실시간 검색은 일시적으로 사용할 수 없습니다." ]
    + 캐시된 목록, 동작하는 nav, 동작하는 결제
  → 사용자는 계속 둘러봄; 핵심 흐름 유지
```

죽은 페이지 대신 사용자는 캐시된 결과와 작은 안내를 받고, navigation과 결제는 계속 동작합니다. 실패는 하나의 기능에 국한됩니다.

## 왜 중요한가

dependency는 *반드시* 실패합니다 — 서드파티 API, 검색 클러스터, 추천 서비스. graceful degradation이 없으면 단 하나의 실패가 전면 장애로 cascade됩니다. soft fail로 설계하고(캐시/부분/기본 데이터), 비핵심 경로를 flag로 끄고, fallback과 함께 타임아웃하며, bulkhead로 실패를 격리하면 부분 실패 중에도 제품을 사용 가능하게 유지합니다 — 이것이 사소한 일시 장애와 대형 인시던트의 차이입니다.

기법

예: 검색 백엔드 다운

왜 중요한가

관련 질문