복원력 있는 아키텍처 설계 (26%)

이 도메인의 성격

두 진술은 실패의 방향이 다릅니다. 2.1은 부하로 인한 실패를, 2.2는 구성 요소의 고장으로 인한 실패를 다룹니다. 문항을 읽을 때 "트래픽이 늘었다"인지 "무언가 죽었다"인지 먼저 확인하면 후보 서비스군이 절반으로 줄어듭니다.

과제 진술 2.1 · 확장 가능하고 느슨하게 결합된 아키텍처 설계

이 진술의 문항은 대체로 "트래픽이 급증하면 무엇이 먼저 무너지는가"와 "어떻게 끊어 놓을 것인가"를 묻습니다. "서버를 더 큰 것으로 바꾼다"는 선택지는 이 진술에서 거의 언제나 밀립니다.

동기 호출을 끊는다

구성 요소가 서로를 직접 호출하면 느린 쪽이 빠른 쪽을 멈춰 세웁니다. 처리 계층이 밀리면 웹 계층의 요청이 대기하다 타임아웃되고, 그 사이에 들어온 요청은 유실됩니다. 큐나 이벤트 버스를 사이에 두면 웹 계층은 접수만 하고 즉시 응답하며, 급증분은 큐에 쌓입니다.

셋을 조합하는 형태도 자주 나옵니다. SNS 주제에 여러 SQS 큐를 구독시키면 팬아웃과 완충을 동시에 얻습니다. 이 조합이 정답인 문항이 반복해서 출제됩니다.

SQS 표준 큐와 FIFO 큐

가시성 제한 시간과 배달 못 한 편지 큐

소비자가 메시지를 받으면 그 메시지는 일정 시간 동안 다른 소비자에게 보이지 않습니다. 이 시간이 가시성 제한 시간(visibility timeout)이며 기본값은 30초, 최대 12시간입니다. 처리 시간보다 짧게 잡으면 같은 메시지를 두 소비자가 처리하게 됩니다. "메시지가 중복 처리된다"는 시나리오의 첫 번째 확인 대상입니다.

반복해서 실패하는 메시지는 큐를 계속 점유합니다. 배달 못 한 편지 큐(DLQ)를 지정하고 최대 수신 횟수를 설정하면 그 횟수를 넘긴 메시지가 DLQ로 옮겨져 나머지 처리를 막지 않습니다.

확장 설계 — 수평이 기본입니다

탄력성이 요구되면 답은 수평 확장입니다. 인스턴스 타입을 키우는 수직 확장은 상한이 있고, 바꾸는 동안 중단이 필요하며, 고장 났을 때 대체할 것이 없습니다. 수평 확장의 전제는 상태 비저장 설계입니다 — 세션이나 업로드 파일을 인스턴스 로컬 디스크에 두면 인스턴스를 늘리고 줄일 수 없습니다.

스케일아웃이 트래픽 상승을 따라가지 못하는 시나리오에서는 예약 스케일링으로 미리 늘리거나 큐로 완충하는 것이 정답 방향입니다. "스케일링 정책을 더 공격적으로 바꾼다"만으로는 인스턴스가 준비되는 시간을 없앨 수 없습니다.

과제 진술 2.2 · 고가용성 및 내결함성 아키텍처 설계

이 진술의 출발점은 하나입니다. 가용성은 가용 영역의 개수에서 나옵니다. 같은 가용 영역에 인스턴스를 몇 대 두든 그 가용 영역이 무너지면 전부 사라집니다. 선택지를 볼 때 인스턴스 대수가 아니라 가용 영역이 몇 개인지부터 봅니다.

Multi-AZ와 읽기 전용 복제본 SAA 빈출

시험이 가장 집요하게 노리는 혼동입니다. Multi-AZ는 가용성, 읽기 전용 복제본은 읽기 확장입니다. 요구가 둘 다면 둘 다 구성하는 선택지가 정답입니다.

Amazon Aurora는 구조가 다릅니다. 스토리지 계층이 여러 가용 영역에 걸쳐 있고, 복제본이 읽기 처리와 장애 조치 대상의 역할을 함께 합니다. 리전 단위 요구에는 Aurora 글로벌 데이터베이스가 후보에 들어옵니다. 자세한 구조는 10장 RDS와 관계형 데이터베이스에서 다룹니다.

단일 장애점을 지운다

헬스체크와 장애 조치

Elastic Load Balancing은 대상의 헬스체크가 실패하면 그 대상으로 요청을 보내지 않습니다. Auto Scaling 그룹이 로드 밸런서의 헬스체크를 쓰도록 구성하면, 프로세스는 살아 있지만 응답하지 않는 인스턴스까지 교체 대상이 됩니다. EC2 상태 검사만 쓰면 이 경우를 놓칩니다.

리전 단위 장애 조치는 Amazon Route 53의 장애 조치 라우팅과 상태 확인으로 만듭니다. 기본 레코드의 상태 확인이 실패하면 보조 레코드로 응답이 바뀝니다. 로드 밸런서 종류 선택은 계층과 프로토콜이 기준입니다 — HTTP 라우팅은 Application Load Balancer, TCP·UDP와 고정 IP가 필요하면 Network Load Balancer, 서드파티 어플라이언스 삽입은 Gateway Load Balancer입니다.

DR 4전략과 RTO · RPO

RTO(복구 목표 시간)는 얼마나 빨리 복구해야 하는가, RPO(복구 목표 시점)는 얼마만큼의 데이터 손실을 허용하는가입니다. 네 전략은 이 두 값과 상시 가동 비용을 맞바꾼 결과입니다. 문제문이 준 RTO·RPO 요구를 만족하는 가장 단순한 전략이 정답입니다.

표에 숫자를 넣지 않은 이유가 있습니다. 각 전략의 RTO·RPO는 구성과 데이터 크기에 따라 달라지므로 고정된 값이 없습니다. 시험도 "파일럿 라이트의 RTO는 몇 분인가"를 묻지 않고, 주어진 요구를 만족하는 전략이 무엇인가를 묻습니다.

데이터 복제 수단도 함께 나옵니다. 객체는 S3 교차 리전 복제(CRR)로, 규정 준수나 로그 집계처럼 같은 리전 안의 복제가 필요하면 동일 리전 복제(SRR)로, 여러 서비스의 백업을 한곳에서 정책으로 관리하려면 AWS Backup으로 처리합니다.

판단 지점 점검표 18개

각 행의 기준을 한 문장으로 말할 수 없다면 담당 챕터로 돌아갑니다. 서비스 이름을 아는 것과 판단하는 것은 다릅니다.

이 도메인의 함정

도메인 미니 퀴즈

이 도메인의 판단 지점을 확인하는 10문항입니다. 키보드만으로 완주할 수 있습니다 — 숫자키 1~5로 선택지를 고르고 Enter로 제출합니다.

이어서 볼 곳

• 12장 · 서버리스와 애플리케이션 통합 과제 진술 2.1의 본체입니다. SQS와 SNS, EventBridge, Lambda의 동시성과 재시도를 다룹니다. 기본개념 · SAA 최우선
• 18장 · 비용 최적화·마이그레이션·재해 복구 DR 4전략과 RTO·RPO의 교환 관계를 구성 요소 단위로 뜯어봅니다. 기본개념
• 한정어 키워드 사전 MOST highly available과 MOST resilient가 각각 무엇을 가리키는지, 연습 2에서 정답이 어떻게 이동하는지. 시험 대비 · 최우선
• 보안 아키텍처 설계 (30%) 가중치가 더 큰 도메인입니다. NAT 이중화처럼 두 도메인이 겹치는 판단도 있습니다. 시험 대비 · 도메인
• 케이스 5 · 단일 AZ 설계가 장애로 전면 중단됐다 이 도메인의 첫 번째 판단 지점을 실제 사고의 형태로 따라갑니다. 아키텍처 케이스
• 헷갈리는 쌍 비교 Multi-AZ와 읽기 전용 복제본, 표준 큐와 FIFO 큐 같은 쌍을 표 하나로 모았습니다. 빠른참조

공식 문서 출처

• SAA-C03 시험 가이드 — 도메인 2의 가중치 26%와 과제 진술 2.1 · 2.2
• SAA-C03 시험 가이드 (한국어) — 과제 진술의 한국어 표현
• Amazon RDS 사용 설명서 — Multi-AZ DB 인스턴스 배포 — 대기 복제본으로의 동기식 복제와 장애 조치 동작
• Amazon RDS 사용 설명서 — 읽기 전용 복제본 사용 — 비동기 복제, 별도 읽기 엔드포인트, 교차 리전 복제본
• Amazon SQS 개발자 안내서 — FIFO 큐의 고처리량 — FIFO 큐의 초당 처리 건수와 배치 사용 시의 차이
• AWS Lambda 개발자 안내서 — 할당량 — 함수 최대 실행 시간 900초
• Amazon VPC 사용 설명서 — 보안 — 서브넷과 가용 영역 경계에 대한 서술
• AWS Well-Architected Framework (한국어) — 안정성 기둥의 정의