title, source_type, status, confidence, tags, related_projects, last_reviewed
| title |
source_type |
status |
confidence |
tags |
related_projects |
last_reviewed |
| concept / Fail-Open & Fail-Closed |
llm-generated |
reviewed |
high |
| concept |
| ca-tmpl |
| architecture |
| spring-boot |
| circuit-breaker |
|
|
2026-06-15 |
concept / Fail-Open & Fail-Closed
Summary
장애가 발생했을 때 시스템이 취하는 두 가지 상반된 처리 모델.
- Fail-Open (실패 개방): 외부 시스템/인프라 장애 시 요청을 통과시키거나 대체 수단(Cache-Miss 등)으로 우회하여 핵심 비즈니스 기능을 계속 수행한다.
- Fail-Closed (실패 폐쇄): 외부 시스템/인프라 장애 발생 시 즉시 시스템 전체 또는 해당 기능을 중단하고 예외를 전파하여 불완전한 상태에서의 처리를 강력히 차단한다.
Standard (공식 정의)
공식적인 소프트웨어 및 인프라 설계 기법(SRE 및 분산 아키텍처)에 따르면 두 모델의 정의는 다음과 같다.
- Fail-Open: 보안 게이트웨이나 캐시 계층 같은 비핵심 인프라가 먹통이 되었을 때, 인프라 부재 상태를 '허용'하여 전체 서비스 가용성을 최대화하는 모델. 예컨대 캐시 서버가 죽으면 DB를 조회(Cache-miss로 취급)하도록 하여 기능 정지를 막는다.
- Fail-Closed: 원격 트랜잭션, 아웃박스 발행기 등 데이터 정합성이 극도로 중요한 구간에서 하위 시스템이 오류를 뱉으면 호출자에게 오류를 전파하고 전체 처리를 롤백하는 모델.
한계 / 주의점
- Fail-Open의 함정: 가용성은 유지되나 백엔드 DB에 트래픽이 폭증(Cache Stampede)하거나, 장애가 전파되어 전체 시스템이 도미노처럼 무너질 위험이 있다. 따라서 반드시 서킷 브레이커, Rate Limiter 같은 보호막이 함께 작동해야 한다.
- Fail-Closed의 함정: 가용성이 급격히 떨어진다. 단 하나의 마이크로서비스나 인프라 장애로 인해 전체 서비스가 5xx 에러를 뿜으며 중단될 수 있다.
Project Application
- wiki/explainer/adapter-outbound.md
FailOpenCacheStore에서는 캐시 인프라 장애 시 예외를 삼키고 캐시 미스로 처리하는 Fail-Open을 적용함.KafkaOutboxMessagePublishAdapter는 아웃박스 이벤트 유실 방지를 위해 Fail-Closed를 적용하여 예외를 반드시 상위로 전파함.
Claim-backed Knowledge
| Knowledge Point |
Supporting Claims |
Confidence |
Notes |
| 캐시 붕괴 시 DB 조회 등으로 가용성을 지키는 것 |
raw/official-docs/cache-aside-vs-write-through-aws.md |
high |
AWS 캐시 아키텍처 가이드라인 |
| Fail-Open 구조에서 유실되지 않아야 할 이벤트 처리 |
raw/official-docs/event-sourcing-vs-outbox-microservices-io.md |
high |
마이크로서비스 트랜잭션 보장 기법 |
내가 설명할 수 있어야 하는 것
- Fail-Open과 Fail-Closed의 극명한 결정 기준은 무엇인가? (가용성 우선 vs 정합성/안전성 우선)
- 우리 프로젝트의 캐시 스토어와 아웃박스 발행기는 각각 어떤 모델을 따르며 그 이유는 무엇인가?
- Fail-Open 적용 시 백엔드 DB 보호를 위해 어떤 추가 장치가 필요한가?
Interview Questions
- Redis 캐시 서버가 갑자기 중단되었을 때, 귀하의 시스템은 어떻게 동작하며 이를 위해 어떤 resilience 패턴을 적용했습니까?
- 메시지 발행 실패 시 예외를 상위로 전파하는 구조(Fail-Closed)와 삼켜버리는 구조(Fail-Open)의 아키텍처적 트레이드오프를 설명하십시오.
Do Not Overclaim
- "Fail-Open을 적용했으므로 인프라가 죽어도 시스템에 아무런 영향이 없다"고 과장해서는 안 된다. 캐시가 없으면 DB 부하가 치솟으므로 성능 저하와 2차 장애 위험이 상존함을 인정해야 한다.
Sources
