f8b21af4be
10_Wiki/Topics 대규모 정리: - 오류 캡처/미완성 stub 문서 227개 제거 - 교차폴더 중복 43클러스터 병합 (63파일 → redirect) - 링크명 정규화: 깨진 링크 수정·redirect 직결·개념 매핑 ~2,400건 - 카테고리 MOC 6개 신규 생성 - Graph 섹션 미해결 related-keyword 링크 10,058건 제거 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
4.4 KiB
4.4 KiB
id, title, category, status, canonical_id, aliases, source_trust_level, confidence_score, created_at, updated_at, last_reinforced, verification_status, applied_in, tags
| id | title | category | status | canonical_id | aliases | source_trust_level | confidence_score | created_at | updated_at | last_reinforced | verification_status | applied_in | tags | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| system-resilience-and-fault-tolerance | System Resilience and Fault Tolerance | 10_Wiki/Topics | verified | self |
|
A | 0.95 | 2026-05-11 | 2026-05-11 | 2026-05-11 | applied |
|
|
System Resilience and Fault Tolerance
Tip
시스템 회복 탄력성은 단순히 에러가 나지 않는 것이 아니라, 에러가 발생했을 때 어떻게 우아하게 복구(Graceful Recovery)하느냐의 문제입니다.
📌 한 줄 통찰 (The Karpathy Summary)
분산 시스템과 외부 API 의존도가 높은 현대 소프트웨어에서 안정성은 '완벽한 차단'이 아닌, 지수 백오프(Backoff)와 서킷 브레이커(Circuit Breaker)를 통한 격리된 실패 제어와 자동화된 자가 치유(Self-healing) 능력에 의해 결정된다.
📖 핵심 개념 (Synthesized Content)
1. 지수 백오프 (Exponential Backoff)
실패한 요청을 즉시 재시도하는 대신, 재시도 간격을 지수적으로 늘려나가는 전략입니다. 이는 네트워크 부하를 방지하고 일시적인 장애(Transient Failure)가 해소될 시간을 벌어줍니다.
2. 서킷 브레이커 (Circuit Breaker)
외부 서비스 장애가 시스템 전체로 전파되는 것을 막기 위해, 특정 임계값 이상의 실패가 발생하면 요청을 즉시 차단(OPEN)하는 패턴입니다. 일정 시간 후 시범 요청(HALF_OPEN)을 통해 복구 여부를 확인합니다.
3. 격리된 자동 재시작 (Orchestrated Restart)
애플리케이션 계층에서 해결되지 않는 하부 서비스(백엔드 브릿지 등)의 장애를 감지했을 때, 격리된 방식으로 해당 서비스를 리셋하고 세션을 복구하는 최후의 복구 수단입니다.
💻 코드 패턴 (Implementation Patterns)
Circuit Breaker 상태 관리
let circuit = {
status: 'CLOSED', // CLOSED, OPEN, HALF_OPEN
failureCount: 0,
lastFailureTime: Date.now()
};
function updateCircuit(isSuccess: boolean) {
if (isSuccess) {
circuit.status = 'CLOSED';
circuit.failureCount = 0;
} else {
circuit.failureCount++;
if (circuit.failureCount >= 3) circuit.status = 'OPEN';
}
}
지수 백오프 기반 재시도
const delays = [5000, 15000, 45000]; // 5초, 15초, 45초
const retryDelay = delays[consecutiveErrors - 1];
setTimeout(() => processNext(), retryDelay);
🤔 의사결정 기준
| 상황 | 권장 접근법 |
|---|---|
| 일시적 네트워크 타임아웃 | 3단계 내외의 지수 백오프 재시도 |
| 인증 만료 및 세션 오류 | 즉시 자동 복구(Re-auth) 시도 후 실패 시 일시정지 |
| 외부 서비스 연속 실패 | 서킷 브레이커 OPEN 하여 리소스 소모 차단 |
| 백엔드 프로세스 응답 없음 | 프로세스 격리 재시작(Bridge Restart) 오케스트레이션 |
❌ 안티패턴
- 무한 재시도 (Infinite Retry Loop): 종료 조건 없는 재시도는 서버 리소스를 고갈시키고 로그 폭증을 유발합니다.
- Immediate Retry: 실패 즉시 재시도하는 것은 'Self-DDOS' 행위이며, 장애 상황을 악화시킵니다.
- 이중 카운팅 (Double Counting Errors): 서킷 브레이커와 엔진의 백오프 카운터가 독립적으로 소진되어, 실제 재시도 기회를 낭비하는 것을 경계해야 합니다.
🧪 검증 상태 (Validation)
- 상태: verified
- 출처 신뢰도: A (Datacollector_MAC 실구현체 기반)
- 적용 사례:
Datacollector_MAC프로젝트의engine.ts와diagnostics.ts에서 검증됨.
🔗 지식 연결 (Graph)
- Parent: Software_Architecture_Patterns
- Related: Runtime_Validation, Autonomous_Queue_Processing_Engine
🕓 변경 이력 (Changelog)
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|---|---|---|---|
| 2026-05-11 | Datacollector_MAC 엔진 리뷰를 기반으로 최초 생성 | CREATE | A |