장애 주입으로 검증하는 회복탄력성: Resilience 테스트 설계
노드 다운, 네트워크 분할, DB 리더 장애를 실제로 일으켜 시스템이 SLO 안에서 복구되는지 확인하는 Resilience 테스트의 설계 원칙과 도구, Kubernetes·DB·DR 사례.
2026-08-12 · 최초 발행 2025-12-22
부하 테스트를 통과하고 코드 리뷰도 끝난 시스템이 실제 장애 앞에서 무너지는 경우가 있다. 정상 동작을 확인하는 것과 "일부가 망가졌을 때도 버티는가"를 확인하는 것은 전혀 다른 질문이기 때문이다. Resilience(가용성/장애대응) 테스트는 구성요소의 부분적 실패, 성능 열화, 의존성 장애 상황을 의도적으로 만들어 시스템이 목표 수준의 서비스 연속성을 유지·복구하는지 검증하는 활동이다. 분산 아키텍처가 확산되면서 "장애는 일어난다"는 전제 위에서 설계하고 검증하는 접근이 필수가 됐다.
허용 다운타임부터 계산해야 실험 강도가 정해진다
Resilience 테스트를 설계하기 전에 먼저 SLO와 Error Budget부터 확정해야 한다. 월 30일 기준으로 계산하면 가용성 99.95%의 허용 다운타임은 21.6분(30×24×60×(1−0.9995)), 99.9%는 43.2분이다. 각 실험이 이 Error Budget을 초과하지 않도록 가드레일을 설정하는 것이 테스트 설계의 출발점이다. RTO(복구 시간 목표)와 RPO(복구 시점 목표)는 DR/Failover 검증의 핵심 지표로, 실험 결과를 이 두 지표에 대응시켜 판정한다.
시나리오는 리스크 기반으로 고른다
모든 장애를 다 시험할 수는 없으므로 FMEA(장애 모드 영향 분석)와 FTA(장애나무분석)로 고위험 시나리오를 먼저 추린다. 각 시나리오에는 목표 SLO, 실패 조건, 중단 기준(Abort Rule)을 명시해둔다. 결함 주입은 인프라(노드 다운, 디스크 I/O 지연), 네트워크(패킷 손실/지연/격리), 애플리케이션(스레드 데드락, OOM), 데이터베이스(리더 장애, 복제 지연) 등 여러 계층에 걸쳐 카탈로그화하고, Blast Radius(영향 범위)와 실험 강도, 지속 시간을 파라미터로 관리해 반복 가능하게 만든다.
실시간 판정은 P50/P95 지연, 오류율, 성공 QPS, 소비자 지표, 로그, 트레이싱을 기반으로 한다. 중단 조건의 예로는 오류율이 2%를 넘어 2분 지속되거나, P95 지연이 평소의 2배를 초과하거나, 대기열 길이가 임계값을 돌파하는 경우를 든다.
CI/CD 파이프라인과 통합하면 사전 검증(Pre-prod)에서 시작해 점진적으로 프로덕션 실험으로 넘어가는 순서를 강제할 수 있다. 승인·스케줄링·권한·감사 로깅을 자동화하고, 실험 전후 헬스체크와 자동 롤백을 내장해두는 것이 사고를 실험이 아닌 장애로 만들지 않는 핵심이다. 복구 검증에서는 복구 시간(RTT)과 정상화 경로(자가치유/오케스트레이터/런북)뿐 아니라 트랜잭션 일관성, 중복/유실 여부, 재시도·멱등성까지 함께 확인해야 데이터 안전성을 보장할 수 있다.
접근법마다 검증 범위가 다르다
혼돈 공학(Chaos Engineering)은 가드레일을 지키면 영향이 낮고 서비스/플랫폼 레벨 동작을 검증하기 쉽지만 가용성 중심이라 일관성 검증은 제한적이다. 결함 주입(Fault Injection)은 시나리오별로 영향이 달라지지만 트랜잭션·재시도·멱등성까지 검증할 수 있다. 장애조치(Failover) 연습은 전환 구간에서 지연 스파이크가 날 수 있고 데이터 상태 검증을 전제로 강한 일관성 확인이 가능하다. DR 모의훈련은 영향도가 크고 복잡하지만 RPO/RTO를 직접 검증한다. 용량/과부하 테스트는 QPS와 리소스를 압박해 수평 확장 한계를 파악하는 데 쓰인다.
| 접근법 | 성능(영향) | 확장성 검증 | 일관성 | 안정성(운영 리스크) | 운영 편의 |
|---|---|---|---|---|---|
| 혼돈 공학(Chaos Engineering) | 낮음~중간(가드레일 준수 시) | 서비스/플랫폼 레벨 동작 검증 용이 | 제한적(가용성 중심) | 중간(프로덕션 실험 시 주의) | 도구 생태계 풍부, 자동화 용이 |
| 결함 주입(Fault Injection) | 시나리오별 상이(지연/오류율 영향) | 네트워크·시스템 계층 병목 확인 | 트랜잭션·재시도·멱등성 검증 가능 | 중간 | 설정 복잡도 존재, 반복성 높음 |
| 장애조치(Failover) 연습 | 전환 구간 지연/스파이크 가능 | 클러스터/리전 레벨 | 강함(데이터 상태 검증 전제) | 중간~높음(영향 범위 큼) | 표준 절차·런북 필요 |
| DR 모의훈련 | 높음(대규모 전환) | 리전/멀티클라우드 | RPO/RTO 직접 검증 | 높음(넓은 영향도) | 복잡, 다부서 협업 필수 |
| 용량/과부하 테스트 | 높음(QPS·리소스 압박) | 수평 확장 한계 파악 | 비즈니스 일관성 간접 검증 | 중간 | 자동화·스케줄링 용이 |
계층별로 시나리오는 이렇게 다르다
Kubernetes 마이크로서비스 환경에서는 PDB/Readiness/Liveness 설정, HPA/Cluster Autoscaler 동작, 사이드카/Service Mesh(Istio)의 Fault Filter를 검증 대상으로 삼는다. Pod OOMKill, Node Drain, 네트워크 지연/패킷 손실, ConfigMap/Secret 롤링, Downstream 5xx 유발이 대표 시나리오이며, P95 지연·오류율·서킷브레이커 Open 비율·큐 길이·스레드풀 고갈을 관측한다. 오류율이 2%를 넘어 2분 지속되거나 HPA 스케일이 불가능하거나 큐 길이가 임계를 초과하면 중단한다. 도구로는 Chaos Mesh/LitmusChaos, Istio Fault Injection, AWS FIS·Azure Chaos Studio, ToxiProxy·tc netem을 쓴다.
데이터베이스/스토리지에서는 리더 장애, 복제 지연, WAL/트랜잭션 대기, 스토리지 I/O 지연을 대상으로 리더 선출 지연, 네트워크 분할로 인한 스플릿 브레인 방지 확인, 스냅샷 복구 연습을 수행한다. 쓰기 지연, 레플리카 라그, 트랜잭션 재시도율, 읽기/쓰기 오류율, 체크섬/무결성을 관측하며 RPO가 위협받으면 즉시 중단하고 프롬프트 페일백한다. Patroni/pg_auto_failover, pgbench/sysbench, HAProxy/LB 연결 드레인이 대표 도구다.
DR/네트워크/플랫폼 영역에서는 DNS/트래픽 매니저, 메시지 브로커, 비동기 워크플로우, IaC 스택을 대상으로 리전 단절·DNS Failover, 브로커 파티션 지연·순서 보장 검증, IaC 재구성 시간·불일치 탐지를 시험한다. RTO/RPO, 메시지 적체, 재처리·중복 소비, 플레이북 타임라인 준수를 관측하고 페일오버 실패나 데이터 불일치가 탐지되면 즉시 롤백한다.
안전장치 없이 프로덕션에서 실험하지 않는다
Blast Radius를 최소화하고 점진적으로 확대하며, 다중 승인과 가드레일 임계를 지정한다. 프로덕션 실험은 저트래픽 윈도우와 카나리아 대상으로 제한하는 것이 원칙이다. 데이터 보호를 위해 멱등성·재시도·사전 백업을 검증하고, Read-only 플래그나 Feature Flag로 쓰기를 억제하는 옵션을 마련해둔다. 성능·정합·사용자 경험 지표는 단일 대시보드로 통합해 알람 소유권을 명확히 하고, CI에 가용성 회귀 테스트를 포함시켜 실험 실패 시 배포 게이트를 차단한다. 실험 강도를 올릴수록 사용자 영향 위험도 커지므로, 프로덕션 신뢰성 검증과 위험, 테스트 속도와 커버리지 사이의 균형을 매번 다시 잡아야 한다.
기대할 수 있는 효과
정량적으로는 MTTR 20~40% 단축, RTO 달성률 90% 이상, DR 전환 성공률 95% 이상을 기대할 수 있고, 장애 상황에서 P95 지연 상승폭을 30% 이내로, 오류 예산 소모율을 50% 이하로 통제할 수 있다. 정성적으로는 런북 품질이 올라가고 서비스 간 계약(경계면)이 명확해지며, 팀 간 공통 상황 인식이 강화된다. 자동화된 자가치유 역량이 조직에 내재화되고 변화 관리·보안 거버넌스도 함께 정착된다.
Resilience 테스트는 가용성과 복구 가능성을 수치로 관리하는 체계다. 리스크 기반 설계와 SLO 연동, 관측성·가드레일·자동화를 축으로 작은 범위에서 안전하게 시작해 반복적으로 확대하는 것이 정답이다.