AWS Resilience Hub 장애 시험: 알림이 끊겨도 업무는 끝날까

다운로드와 이메일을 한 덩어리로 묶었을 때

월말 보고서를 만드는 서비스를 생각해 보자. 사용자는 보고서 생성 버튼을 누르고, 완성된 파일을 내려받으며, 이메일로도 완료 알림을 받는다. 파일 저장은 정상인데 이메일 API가 응답하지 않는다면 어떤 화면이 나와야 할까?

팀이 정한 약속이 “파일은 바로 내려받고 이메일은 늦어질 수 있다”라면, 이메일 장애가 다운로드를 막아서는 안 된다. 그런데 코드가 파일 저장 뒤 이메일 응답까지 기다린다면 두 기능은 함께 멈춘다. 설계 문서의 선택적인 의존성이 실제 실행에서는 필수 경로가 된 것이다. 반대로 이메일 수신 자체가 업무 완료인 서비스라면 지연을 허용한다는 가정부터 바꿔야 한다.

AWS는 2026년 10월 26일 차세대 Resilience Hub의 권장 복원력 시험을 소개했다. 서비스의 자원·의존성·정책을 바탕으로 AWS Fault Injection Service(FIS) 실험을 구성하고 결과를 평가한다. 이 글은 그중 Dependency validation, 즉 의존성을 차단해 서비스의 반응을 보는 시험에 집중한다. 발표는 차세대 Resilience Hub가 지원되는 AWS 상용 리전에서 이용 가능하다고 설명한다. 모든 리전·컴퓨팅 환경을 지원한다는 뜻은 아니다. AWS 공식 발표

이 변화의 실무적 의미는 장애를 넣는 작업과 서비스의 성공 조건을 한 시험에 묶는다는 데 있다. 무엇을 성공으로 볼지는 여전히 팀의 몫이다. 여기서는 가상의 보고서 내보내기 서비스로 그 판단을 설계한다. 실제 AWS 계정에서 실행한 결과나 콘솔 사용기는 아니며, 수치도 뒤에서 밝힌 가정에 따른 계산이다.

“계속 된다”와 “제시간에 돌아온다”는 다른 시험이다

권장 시험을 선택하기 전에 서비스가 약속한 동작을 한 문장으로 써야 한다. “장애에 강하다”보다 “알림 서버가 응답하지 않아도 새 보고서 파일을 내려받을 수 있다”가 시험 가능한 문장이다.

Resilience Hub의 판정에는 두 종류가 있다. Dependency validation과 Multi-Region isolation은 장애 중에도 성공 경보가 계속 OK여야 하는 지속형 시험이다. AZ recovery와 Multi-Region recovery는 정책의 RTO 안에 성공 경보가 OK로 돌아오고 시험 동작 종료까지 유지되어야 하는 복구형 시험이다. RTO는 복구에 허용한 목표 시간이다. 시험 설정과 성공 조건

우리 팀의 질문	맞는 시험의 성격	늦게 정상으로 돌아왔다면
알림 API가 끊겨도 파일 다운로드가 계속 되는가?	지속형: 차단 중 업무 유지	중간에 성공 경보가 깨졌다면 지속형 통과가 아님
한 가용 영역이 손상되어도 목표 시간 안에 서비스가 회복되는가?	복구형: 정해진 시간 안에 회복	RTO 충족과 이후 유지 여부를 함께 봄

따라서 보고서 서비스에서 “5분 뒤 알림이 다시 됐으니 성공”이라는 결론은 질문을 바꿔 버린다. 이번 시험의 핵심은 알림 장애 동안 다운로드가 계속 됐는지다. 알림 적체를 나중에 해소하는 일은 별도의 후속 조건으로 남는다.

공식 문서는 시험 템플릿, 설정된 시험, 한 번의 실행을 구분한다. 템플릿은 동작과 매개변수를 정하고, 팀의 시험에는 성공 조건과 중단 조건이 붙으며, 실행마다 현재 자원을 대상으로 결과가 생긴다. 같은 설정을 다시 실행해도 배포 버전이나 자원이 달라졌다면 같은 상황을 반복한 것으로 단정할 수 없다. 시험의 구성과 실행

성공을 측정할 곳은 사용자의 완료 지점이다

보고서 사례의 핵심 업무를 “새 요청으로 생성한 파일을 읽을 수 있음”으로 정하자. HTTP 상태 코드가 200이어도 빈 파일이나 예전 보고서가 내려오면 실패다. 다음은 이 글에서 제안하는 시험 설계다. AWS가 제공하는 기본 경보 이름이나 보편적인 수치 기준이 아니다.

역할	보고서 서비스에서 볼 신호	판정에 쓰는 방식
성공 경보	새 작업 ID로 요청한 파일의 완성·다운로드·예상 내용 확인	사용자 업무가 유지됐는지 판정
추가 관측	알림 API 호출 시도·연결 오류, 미전송 알림 수와 가장 오래된 대기 시간	실제 의존 호출과 부수 효과를 조사
중단 조건	시험과 무관한 업무의 오류 급증, 감당하지 못할 지연	허용 범위를 넘으면 시험 종료

Resilience Hub의 추가 경보는 관측용으로 결과에 나타나지만 통과·실패에 영향을 주지 않는다. 중단 조건은 CloudWatch 경보가 임계값을 넘으면 시험을 멈추는 별도 설정이다. 설정 문서

이 구분을 잘못하면 시험이 스스로 모순된다. 끊으려는 이메일 API의 정상 응답을 성공 조건에 넣으면, 다운로드가 멀쩡해도 실패한다. 반대로 서버의 단순 생존 확인만 넣으면 사용자가 파일을 받지 못해도 녹색일 수 있다. 성공 조건은 이번에 지키려는 약속을 가리켜야 한다.

시험 트래픽도 약속에 맞춰 만든다. 예를 들어 캐시된 파일만 내려받지 말고 매번 새 작업 ID로 보고서를 생성해 그 ID의 결과를 확인한다. 알림을 보내지 않는 테스트 전용 경로만 호출하면 알림 장애를 시험한 것이 아니다. 정상 상태에서 먼저 이 경로가 알림 호출까지 이어지는지 확인하고, 차단 중에도 호출 시도와 오류가 보이는지 대조한다.

표본 수와 결측 처리도 적어 둔다. 요청이 전혀 없는데 성공률만 녹색으로 유지되는 경보라면 업무가 지속됐다는 자료가 없다. 어떤 시간 구간에 몇 건을 시도했는지, 관측이 빠지면 어떻게 판단할지를 시험 계획에 포함해야 한다. 이는 측정 설계에 대한 제안이며 Resilience Hub가 자동으로 모든 트래픽 공백을 찾아준다는 설명이 아니다.

같은 녹색 결과에도 다음 행동은 달라진다

다음 네 경우는 직접 만든 예상 시나리오다. 실제 관측값이나 제품 벤치마크가 아니다. 공통 조건은 알림 API 연결을 차단하고 보고서 생성부터 다운로드까지 새 요청을 넣는 것이다.

사례	예상되는 신호	이 시험에서 할 판단
파일 저장 뒤 알림 응답을 기다림	알림 연결 오류와 함께 다운로드 성공 경보도 깨짐	업무가 알림에 묶였다. 호출 순서와 대기 시간을 조사
다운로드 경로와 알림 처리를 분리함	알림 오류·적체 증가, 새 파일 다운로드는 유지	시험한 구간의 업무 유지 근거. 알림 후처리는 따로 확인
시험 경로가 알림 API를 호출하지 않음	다운로드는 정상, 알림 시도·오류도 없음	차단의 영향이 미확인. 실제 알림을 만드는 입력으로 재설계
차단 중 기존 ECS 태스크가 교체됨	새 태스크에서는 다운로드·알림이 모두 정상일 수 있음	교체 이후까지 장애가 유지됐는지 확인. 같은 시험 범위로 합치지 않음

마지막 경우는 제품 문서가 명시하는 제약과 연결된다. Dependency validation은 선택한 의존성에 패킷 손실을 넣지만, 상태 확인 실패로 ECS 태스크 등이 교체되면 교체 태스크에 손실 동작이 다시 적용되지 않으며 동작이 실패로 보고될 수도 있다. DNS로 해석되지 않는 대상도 동작 실패 조건이다. 의존성 시험의 주의점

이를 읽는 순서는 “녹색인가” 하나가 아니라 대상과 동작이 유효했는가 → 의도한 업무가 실제로 실행됐는가 → 업무 조건이 유지됐는가다. 결과 화면의 상태를 임의로 덮어쓰라는 뜻은 아니다. 원래 결과를 보존하면서 그 결과가 답할 수 있는 범위를 붙인다.

특히 세 번째 경우를 필수 의존성이 사라졌다는 증거로 해석하면 잘못된 단순화로 이어진다. 캐시가 대신 답했거나, 아직 자격 증명이 유효하거나, 특정 고객 유형만 그 API를 쓸 수도 있다. 이들은 추가로 비교할 가설이다. 반복해서 같은 초록 화면을 얻는 것보다 빠진 업무 경로를 한 번 더 시험하는 편이 판단에 도움이 된다.

파일이 완성돼도 알림 적체는 남는다

두 번째 시나리오처럼 핵심 업무가 유지돼도 지연된 알림은 사라지지 않는다. 이를 정량적으로 생각하기 위해 다음과 같이 가정하자.

• 정상적으로 분당 2건의 보고서가 생성되고, 각각 알림 한 건이 생긴다.
• 알림 장애는 10분 동안 지속되며 이때 발송은 0건이다.
• 복구 후 성공적으로 처리할 수 있는 알림은 분당 6건이고 새 알림은 계속 분당 2건 들어온다.
• 시작 적체는 0건이며, 중복·유실·실패 재시도는 이 단순 계산에서 제외한다.

장애 중 적체는 2 × 10 = 20건이다. 복구 뒤 적체를 줄이는 순처리량은 6 − 2 = 4건/분이므로, 기존 적체를 비우는 데 20 ÷ 4 = 5분이 필요하다. 전체 처리량 6으로 나누면 새로 들어오는 업무를 빼먹는다.

반대로 복구 후 처리량이 분당 2건이면 새 유입과 같아 적체가 줄지 않는다. 분당 1건이면 오히려 늘어난다. 이 계산은 균일한 유입과 일정한 성공 처리량을 둔 유체 모델이다. 로컬에서 산술을 확인했을 뿐 실제 큐의 처리 순서·메일 수신 시각·AWS 성능을 측정하지 않았다.

이 모델에서 얻을 다음 행동은 “다운로드 시험 통과”와 “알림 후처리 종료”를 별도 완료 조건으로 쓰는 것이다. 시험 계획에는 미전송 작업이 보존되는지, 복구 후 줄어드는지, 오래된 작업이 고착되지 않는지도 남긴다. 알림을 분리하는 구현이 필요하다면 트랜잭셔널 아웃박스의 전송 의도와 중복 처리로 이어서 볼 수 있다. 이번 글은 그 저장 구조를 구현하거나 검증하지 않았다.

도입 전 확인할 범위와 실행 뒤 남길 자료

Dependency validation의 현재 문서는 EC2 인스턴스, ECS 태스크(EC2·Fargate), EC2 기반 EKS 파드의 트래픽 차단을 설명한다. 이 목록만으로 Lambda 등 다른 실행 환경의 장애까지 검증됐다고 볼 수 없다. 대상 유형과 맞는 자원이 없으면 해당 동작은 건너뛴다. 지원 대상과 동작

권한도 자원 구성을 읽는 역할과 장애 주입에 필요한 권한을 구분한다. 특히 EKS의 클러스터 내부 설정은 시험 생성·시작 시 검증되지 않아 실행 중 권한 오류로 드러날 수 있다. 따라서 시험이 시작됐다는 기록만으로 장애가 주입됐다고 판단하지 않는다. IAM 및 EKS 설정 조건

실제로 적용할 팀이라면 먼저 허용된 시험 환경과 단일 의존성으로 범위를 정하고, 정상 업무 신호와 중단 기준을 확인한다. 중단 조건에 걸린 FIS 실험은 다시 이어서 실행할 수 없다. 중단 이유와 남은 업무 상태를 확인한 뒤 새로운 실행을 계획해야 한다. FIS 중단 조건

실행 결과에는 시험 상태, 시각, 성공 경보, 동작 타임라인 등을 남길 수 있다. 하지만 다운로드할 보고서는 서비스에 S3 보고서 목적지를 설정한 경우에 생성된다. 목적지가 없으면 보고서가 생성되지 않는다는 상세 가이드의 조건을 확인해야 한다. 같은 문서는 Resilience Hub 복원력 시험의 보고서에 별도 요금이 없다고 설명한다. 실행 결과와 보고서

시험 실행 비용은 FIS 동작 시간 기준이다. 전체 시험의 벽시계 시간만 보고 견적을 내기보다 어떤 동작이 얼마나 실행되고 몇 계정을 대상으로 하는지 확인해야 한다. 일반 FIS의 선택형 실험 보고서 요금과 Resilience Hub 시험 보고서의 조건도 구분한다. 시험 과금 기준, FIS 가격표

다음 시험에 가져갈 한 장

의존성 장애 시험 설계표 내려받기

이 양식은 위 가상 사례와 빈 입력란을 함께 담았다. AWS에 가져오는 설정 파일이나 실행 스크립트가 아니다. 팀에서 업무 이름과 완료 약속을 먼저 정리할 때 쓸 수 있다.

이번에 지킬 업무 / 늦어져도 되는 부수 업무:
차단할 의존성 / 정상 때 실제로 호출하는 입력:
성공 경보 / 표본 수와 평가 구간 / 결측 처리:
장애 도달을 확인할 관측 / 대상 자원과 배포 버전:
중단 경보 / 중단 뒤 상태를 확인할 담당자:
건너뛴 동작·교체 자원·시험하지 못한 경로:
복구 뒤 남은 작업 / 적체 해소와 최장 대기 확인:
실행 ID·시각 / 경보 타임라인·로그·보고서 위치:
결론의 적용 범위 / 다음에 바꿔 시험할 한 조건:

알림을 기다리는 시간이 문제라면 API 타임아웃과 전체 마감 설계를 다음으로 읽으면 된다. 장애가 난 뒤 호출을 더 반복하는 것이 해결인지, 핵심 업무에서 분리할 수 있는지 판단할 기준을 제공한다.

이번 서비스에서 먼저 정할 문장은 “알림이 끊겨도 무엇은 끝나야 하는가”다. 그 문장에 맞는 입력과 성공 신호가 있어야 자동으로 나온 통과·실패가 운영 결정에 쓸 수 있는 결과가 된다. 다음 설계 때 다시 쓸 양식은 글 저장으로 남기고, 후속 분석은 인프라 주제 모음과 RSS에서 이어 볼 수 있다.