시험 대비 · 도메인 3

고성능 아키텍처 설계 (24%)

Design High-Performing Architectures는 과제 진술이 다섯 개로 가장 많습니다. 범위가 넓고 얕다는 뜻이고, 한 서비스를 깊이 파는 것보다 스토리지·컴퓨팅·데이터베이스·네트워크·데이터 수집 다섯 갈래에서 각각 하나씩 고르는 훈련이 점수로 이어진다는 뜻입니다.

이 페이지는 무엇을 판단해야 하는지를 정리합니다. 판단에 필요한 지식은 5장 EC2, 6장 EBS, 8장 S3, 11장 NoSQL·캐시, 14장 엣지와 DNS, 15장 데이터 분석 파이프라인이 담당합니다.

학습 목표

이 도메인의 성격

SAA-C03 도메인별 출제 비중에서 고성능 아키텍처 설계는 24%로 세 번째입니다. 과제 진술이 5개로 가장 많아 진술 하나당 비중은 네 도메인 중 가장 작습니다. 한 주제를 깊게 파기보다 다섯 갈래를 고르게 훑는 편이 유리한 근거입니다
도메인 3의 과제 진술 다섯 개와 중심 질문
과제 진술 중심 질문 주 담당 챕터
3.1 고성능·확장 가능 스토리지 데이터를 어떤 모양으로 읽는가. 블록인가 파일인가 객체인가, 그리고 어느 티어인가 6장 EBS · 8장 S3 · 9장 파일 스토리지
3.2 고성능·탄력적 컴퓨팅 부하가 늘면 무엇이 늘어나는가. 대수인가 크기인가, 그리고 무엇이 운영을 맡는가 5장 EC2 · 13장 컨테이너
3.3 고성능 데이터베이스 같은 데이터를 몇 번 읽는가. 키 설계와 캐시 계층이 중심입니다 11장 NoSQL·캐시·분석 DB · 10장 RDS
3.4 고성능·확장 가능 네트워크 사용자와 리소스 사이의 거리를 어떻게 줄이는가. 캐싱·경로·DNS 응답 14장 엣지와 DNS · 7장 로드 밸런싱
3.5 고성능 데이터 수집·변환 얼마나 빨리 반영되어야 하는가. 스트리밍인가 배치인가, 그리고 어디서 질의하는가 15장 데이터 분석 파이프라인

다섯 진술은 대상은 다르지만 질문의 형태가 같습니다. "이 워크로드의 접근 패턴은 무엇인가"를 확정하고, 그 패턴에 맞는 티어를 고르는 일입니다. 그래서 이 도메인의 오답은 서비스는 맞는데 티어가 틀린 형태가 가장 많습니다. 선택지 두 개가 같은 서비스인데 옵션만 다르면, 그 둘 중 하나가 정답일 확률이 높습니다.

과제 진술 3.1 · 고성능이고 확장 가능한 스토리지 솔루션 결정

이 진술의 첫 질문은 언제나 블록인가 파일인가 객체인가입니다. 운영체제가 디스크로 인식해야 하면 블록(Amazon EBS·인스턴스 스토어), 여러 인스턴스가 같은 디렉터리를 동시에 보아야 하면 파일(Amazon EFS·Amazon FSx), HTTP로 키를 지정해 읽으면 객체(Amazon S3)입니다.

EBS 볼륨 타입 선택 SAA 빈출

Amazon EBS 볼륨 타입과 확인된 성능 범위
볼륨 타입 분류와 범위 이것을 고르는 신호
gp3 범용 SSD. 크기 1–65,536 GiB, IOPS 3,000(기본)–80,000, 처리량 125(기본)–2,000 MiB/s 대부분의 워크로드의 기본 선택. 크기와 무관하게 성능을 따로 지정할 수 있습니다
gp2 범용 SSD. 크기 1–16,384 GiB. 성능을 따로 지정하는 파라미터가 없고 크기에 연동됩니다 구세대 구성입니다. 볼륨 타입을 지정하지 않으면 이것이 기본값입니다
io1 · io2 프로비저닝된 IOPS SSD. io1은 100–64,000 IOPS, io2는 100–256,000 IOPS 일관된 저지연과 매우 높은 IOPS가 요구될 때. 대개 대형 트랜잭션 데이터베이스입니다
st1 · sc1 처리량 최적화 HDD와 콜드 HDD. 크기 125–16,384 GiB. 부트 볼륨으로 사용 불가 순차 읽기 위주의 큰 파일. 로그 처리와 데이터 웨어하우스 같은 처리량 중심 워크로드

EBS와 인스턴스 스토어

인스턴스 스토어는 호스트에 물리적으로 붙어 있어 매우 빠르지만, 인스턴스를 중지하거나 종료하면 데이터가 사라집니다. 캐시나 임시 처리 공간처럼 잃어도 되는 데이터에만 씁니다. 문제문에 "영구적으로", "인스턴스를 교체해도 유지되어야" 같은 표현이 있으면 인스턴스 스토어는 소거합니다.

공유 파일 시스템 선택

공유 파일 시스템의 선택 기준
요구 선택 판단 기준
여러 Linux 인스턴스가 같은 디렉터리를 동시에 Amazon EFS NFS 기반이며 여러 가용 영역의 인스턴스가 함께 마운트합니다
Windows 애플리케이션의 SMB 공유 Amazon FSx for Windows File Server SMB 프로토콜과 Active Directory 통합이 결정적 신호입니다
대규모 병렬 처리와 고성능 컴퓨팅 Amazon FSx for Lustre S3와 연동해 대규모 데이터셋을 높은 처리량으로 다룹니다
단일 인스턴스에 붙는 디스크 Amazon EBS 공유가 요구되지 않으면 파일 시스템 서비스를 쓸 이유가 없습니다

Amazon S3의 성능 수단

S3 문항은 용량이 아니라 업로드·다운로드 속도를 묻습니다. 큰 객체는 멀티파트 업로드로 나누어 병렬 전송하고, 큰 객체의 일부만 필요하면 바이트 범위 요청으로 병렬 다운로드합니다. 요청이 특정 키 범위에 몰리면 접두사를 나누어 분산합니다.

지리적으로 멀리 떨어진 클라이언트의 업로드가 느리다면 S3 Transfer Acceleration이 후보입니다. 엣지 로케이션까지 최적화된 경로로 보낸 뒤 AWS 백본으로 전달하는 방식입니다. 읽기 가속이 목적이라면 Amazon CloudFront가 답입니다.

과제 진술 3.2 · 고성능이고 탄력적인 컴퓨팅 솔루션 결정

이 진술은 부하가 늘 때 무엇을 늘리는가를 묻습니다. 탄력성이 요구되면 답은 거의 언제나 수평 확장이고, 운영 부담을 줄이라는 요구가 붙으면 관리 책임이 AWS 쪽으로 넘어가는 선택지가 남습니다.

수직 확장과 수평 확장

수직 확장은 인스턴스를 더 큰 타입으로 바꾸는 것입니다. 상한이 있고, 교체하는 동안 중단이 생기며, 단일 장애점이 그대로 남습니다. 수평 확장은 Auto Scaling 그룹으로 대수를 늘리는 것이며, 상태를 인스턴스 밖에 두는 상태 비저장 설계가 전제됩니다.

시험에서 "트래픽이 급증했다"에 대한 답으로 인스턴스 타입 변경이 나오면 대개 오답입니다. 예외는 나눌 수 없는 단일 작업이 병목일 때뿐입니다.

배치 그룹

배치 그룹 세 종류와 선택 기준
전략 배치 방식 고르는 신호
클러스터 한 가용 영역 안에 물리적으로 가깝게 모읍니다 노드 간 통신 지연이 병목인 경우. 고성능 컴퓨팅과 밀결합 병렬 작업
분산 서로 다른 하드웨어로 흩어 놓습니다 소수의 중요 인스턴스를 동시 장애로부터 격리해야 하는 경우
파티션 파티션 단위로 하드웨어를 분리하고 파티션 안에 인스턴스를 둡니다 분산 데이터 플랫폼처럼 그룹 단위 장애 격리가 필요한 경우

클러스터 배치 그룹은 지연을 줄이는 대신 장애 범위를 좁은 곳에 모읍니다. 고가용성이 요구인 문항에서 클러스터를 고르면 요구와 정반대의 답이 됩니다.

컨테이너 실행 모델

먼저 층위를 정리해야 합니다. Amazon ECS와 Amazon EKS는 오케스트레이터이고, AWS Fargate는 실행 방식입니다. Fargate는 ECS와 EKS 양쪽에서 쓸 수 있습니다. 그래서 "ECS와 Fargate 중 무엇을 고르는가"라는 질문 자체가 성립하지 않습니다.

컨테이너 실행 모델의 선택 기준
요구 선택 판단 기준
Kubernetes 생태계와 기존 매니페스트를 그대로 Amazon EKS 이식성과 기존 자산이 결정적 신호입니다
AWS 안에서 단순하게 컨테이너를 운영 Amazon ECS Kubernetes 요구가 없으면 학습·운영 부담이 더 작습니다
노드를 직접 관리하고 싶지 않다 AWS Fargate 실행 LEAST operational overhead 계열 한정어의 표준 답입니다
인스턴스 타입·커널·GPU를 직접 통제해야 한다 EC2 시작 유형 호스트 수준 통제가 명시적으로 요구될 때만 고릅니다

AWS Lambda가 후보로 들어오는 경우도 있습니다. 이벤트 기반이고 실행 시간이 짧으면 Lambda가 유리하지만, 최대 실행 시간은 900초(15분)이므로 그보다 긴 작업은 컨테이너나 배치 처리로 갑니다.

과제 진술 3.3 · 고성능 데이터베이스 솔루션 결정

데이터베이스 성능 문항은 대개 두 갈래입니다. 같은 데이터를 반복해서 읽는가(캐시 문제)와 키 설계가 잘못되었는가(분산 문제)입니다. 두 갈래를 구분하지 못하면 캐시를 붙여도 해결되지 않는 문항에 캐시를 고르게 됩니다.

읽기 지연을 줄이는 선택지 SAA 빈출

읽기 지연을 줄이는 네 가지 수단과 선택 기준
수단 적용 대상 고르는 신호
Amazon ElastiCache 범용 인메모리 캐시. 관계형 데이터베이스 결과, 세션, 순위표 반복 조회가 많고 캐시 적재·무효화 로직을 애플리케이션에 넣을 수 있는 경우
Amazon DynamoDB Accelerator(DAX) Amazon DynamoDB 전용 DynamoDB 읽기를 코드 변경을 최소화하며 가속해야 하는 경우
읽기 전용 복제본 Amazon RDS · Amazon Aurora 캐시로 흡수되지 않는 다양한 조회가 많고, 읽기를 별도 엔드포인트로 보낼 수 있는 경우
Amazon CloudFront HTTP로 제공되는 콘텐츠 사용자와의 지리적 거리가 지연의 원인인 경우

ElastiCache의 엔진 선택도 함께 나옵니다. 복제와 장애 조치, 다양한 자료 구조가 필요하면 Redis 엔진이고, 단순 키-값 캐시를 노드 추가로 수평 분할하기만 하면 되면 Memcached 엔진입니다. "고가용성"이 요구에 들어가면 Memcached는 후보에서 빠집니다.

DynamoDB 파티션 키 설계

DynamoDB의 성능 문제는 대부분 키가 고르게 분산되지 않아서 생깁니다. 값의 종류가 적은 속성(예: 상태 코드, 국가 코드)을 파티션 키로 쓰면 요청이 소수의 파티션에 몰리는 핫 파티션이 생깁니다. 해결은 용량을 늘리는 것이 아니라 카디널리티가 높은 키로 설계를 바꾸는 것입니다.

선택지에 "프로비저닝된 용량을 늘린다"와 "파티션 키를 다시 설계한다"가 함께 있고 문제문이 특정 항목에 요청이 집중된다고 말했다면, 답은 후자입니다.

LSI와 GSI

DynamoDB 로컬 보조 인덱스와 글로벌 보조 인덱스 비교
항목 LSI (로컬 보조 인덱스) GSI (글로벌 보조 인덱스)
파티션 키 테이블과 같아야 합니다 테이블과 달라도 됩니다
최대 개수 5개 20개
크기 제약 파티션 키 값당 10 GB 제한 없음
처리 용량 테이블의 용량을 함께 씁니다 인덱스 자체의 읽기·쓰기 용량을 따로 가집니다
고르는 신호 같은 파티션 키 안에서 다른 정렬 기준이 필요합니다 완전히 다른 속성으로 조회해야 합니다

용량 모드

온디맨드 모드는 요청 단위로 처리하고, 프로비저닝된 모드는 읽기·쓰기 용량을 미리 지정합니다. 모드는 나중에 변경할 수 있습니다. 트래픽을 예측할 수 없거나 급증이 잦으면 온디맨드가, 안정적이고 예측 가능한 부하면 프로비저닝된 모드와 오토 스케일링 조합이 유리합니다.

과제 진술 3.4 · 고성능이고 확장 가능한 네트워크 아키텍처 결정

이 진술은 사용자와 리소스 사이의 거리를 다룹니다. 거리를 줄이는 방법은 세 가지입니다 — 콘텐츠를 가까이 두거나(캐싱), 경로를 최적화하거나, 응답할 대상을 DNS에서 고르는 것입니다.

CloudFront와 Global Accelerator

Amazon CloudFront와 AWS Global Accelerator 비교
항목 Amazon CloudFront AWS Global Accelerator
동작 방식 엣지에서 콘텐츠를 캐싱합니다 고정 애니캐스트 IP로 받아 AWS 백본 경로로 전달합니다
프로토콜 HTTP 계열 TCP와 UDP
고정 IP 제공하지 않습니다 고정 IP 주소를 제공합니다
고르는 신호 정적·동적 웹 콘텐츠 가속, 오리진 부하 감소 비HTTP 프로토콜, 고정 IP 요구, 빠른 리전 간 장애 조치

CloudFront 문항에는 오리진 보호가 자주 함께 나옵니다. S3 오리진을 비공개로 유지하면서 CloudFront만 접근하게 하려면 오리진 액세스 제어(Origin Access Control, OAC)를 쓰고 버킷 정책으로 배포를 허용합니다. "버킷을 퍼블릭으로 만든다"는 선택지는 요구를 위반합니다.

Route 53 라우팅 정책 8종 SAA 빈출

Amazon Route 53 라우팅 정책 여덟 가지와 고르는 신호
정책 응답을 결정하는 기준 고르는 신호
단순 레코드 하나로 그대로 응답합니다 분기 요구가 없습니다
가중치 기반 레코드마다 지정한 비율 카나리 배포, 점진적 전환, 트래픽 비율 조정
지연 시간 기반 측정된 지연이 가장 낮은 리전 성능이 목적입니다
장애 조치 기본과 보조를 정하고 상태 확인 결과로 전환 재해 복구용 대기 사이트
지리적 위치 질의가 어디서 왔는가 규정·저작권·언어로 콘텐츠를 갈라야 합니다
지리 근접 리소스의 위치와 편향(bias) 값 리소스 쪽 위치를 기준으로 트래픽 비중을 조정합니다
다중값 응답 여러 레코드를 거의 무작위로 함께 반환 정상 대상 여러 개에 요청을 흩뿌립니다
IP 기반 클라이언트 IP가 속한 CIDR 컬렉션 특정 네트워크 대역을 지정한 엔드포인트로 보냅니다

단순 라우팅을 제외한 모든 정책은 레코드를 구분하는 식별자를 필요로 합니다. 시험에서 가장 자주 뒤집히는 것은 지연 시간 기반과 지리적 위치입니다. 성능 요구인지 규정 요구인지를 문제문에서 먼저 확정하십시오.

ALB와 NLB와 GWLB

Elastic Load Balancing 세 종류의 계층과 프로토콜
로드 밸런서 계층과 프로토콜 고르는 신호
Application Load Balancer L7 · HTTP, HTTPS 경로·호스트 헤더 기반 라우팅, 리다이렉트, 고정 세션
Network Load Balancer L4 · TCP, TLS, UDP, TCP_UDP, QUIC 비HTTP 프로토콜, 고정 IP 주소, 초저지연
Gateway Load Balancer L3/L4 · GENEVE 방화벽·침입 탐지 같은 서드파티 가상 어플라이언스 삽입

과제 진술 3.5 · 고성능 데이터 수집·변환 솔루션 결정

이 진술의 판단 축은 지연 요구입니다. "실시간" 또는 "거의 실시간"이 문제문에 있으면 배치 도구는 후보에서 빠집니다. 반대로 "매일 밤", "주기적으로"가 있으면 스트리밍을 고를 이유가 없습니다.

스트리밍 수집

스트리밍 수집 서비스의 선택 기준
서비스 성격 고르는 신호
Amazon Kinesis Data Streams 샤드에 레코드를 보관하고 소비자가 각자 읽습니다 여러 소비자가 같은 스트림을 읽거나, 일정 기간 안에서 재처리가 필요한 경우
Amazon Data Firehose 버퍼링해 대상으로 전달하는 관리형 배달 경로 Amazon S3나 Amazon OpenSearch Service 같은 대상으로 코드 없이 적재하는 경우
Amazon MSK 관리형 Apache Kafka 기존 Kafka 자산·클라이언트를 그대로 옮기는 경우
AWS Glue 서버리스 ETL과 데이터 카탈로그 스키마를 발견하고 변환 작업을 실행하는 경우. 저지연 수집 도구가 아닙니다

선택 규칙은 단순합니다. 소비자를 직접 구현하고 스트림을 다시 읽을 필요가 있으면 Data Streams이고, 목적지가 정해져 있고 그냥 넣어 주기만 하면 되면 Firehose입니다. "운영 부담 최소"라는 한정어가 붙으면 후자 쪽으로 기웁니다.

질의와 분석

분석 서비스의 선택 기준
요구 선택 판단 기준
S3에 있는 데이터를 그대로 SQL로 조회 Amazon Athena 서버가 없고 적재 과정이 필요 없습니다. 임시 분석의 표준 답입니다
정형 데이터에 대한 대규모 반복 분석 Amazon Redshift 데이터 웨어하우스가 필요하고 복잡한 조인·집계가 반복됩니다
Spark·Hadoop 기반 대규모 처리 Amazon EMR 기존 빅데이터 프레임워크를 그대로 써야 합니다
로그·문서의 전문 검색과 시각화 Amazon OpenSearch Service 검색과 대시보드가 목적입니다
스키마 발견과 변환 파이프라인 AWS Glue 데이터 카탈로그가 필요하거나 형식을 바꿔 적재해야 합니다

Athena와 Redshift가 함께 선택지에 있으면 빈도와 준비 비용으로 가릅니다. 가끔 조회하고 적재 과정을 두고 싶지 않으면 Athena, 같은 분석을 반복해서 빠르게 돌려야 하면 Redshift입니다.

판단 지점 점검표 18개

아래는 이 도메인에서 반드시 판단할 수 있어야 하는 지점입니다. 각 행을 읽고 기준을 한 문장으로 말할 수 없다면 담당 챕터로 돌아갑니다.

도메인 3 고성능 아키텍처 설계의 판단 지점과 담당 챕터
번호 판단 지점 기준 담당 챕터
1 EBS 볼륨 타입 선택 IOPS 중심인가 처리량 중심인가. gp3 상한은 2025년 9월에 상향되었습니다 6장
2 EBS와 인스턴스 스토어 인스턴스 스토어는 중지·종료 시 소실됩니다 6장
3 공유 파일 시스템 선택 Linux 다중 마운트는 EFS, Windows SMB는 FSx for Windows File Server, 고성능 컴퓨팅은 FSx for Lustre 9장
4 Amazon S3 성능 수단 접두사 분산, 멀티파트 업로드, 바이트 범위 요청, Transfer Acceleration 8장
5 읽기 지연을 줄인다 범용 캐시는 ElastiCache, DynamoDB 전용은 DAX, 다양한 조회는 읽기 전용 복제본 11장
6 CloudFront로 콘텐츠 가속과 오리진 보호 거리로 인한 지연이면 CloudFront. 오리진은 OAC로 비공개 유지 14장
7 Global Accelerator와 CloudFront TCP·UDP와 고정 IP면 Global Accelerator, HTTP 캐싱이면 CloudFront 14장
8 Route 53 라우팅 정책 8종 성능이면 지연 시간 기반, 규정·위치면 지리적 위치, 리소스 위치 조정이면 지리 근접 14장
9 DynamoDB 파티션 키 설계 카디널리티가 낮은 키는 핫 파티션을 만듭니다. 용량 증설로 해결되지 않습니다 11장
10 LSI와 GSI 파티션 키가 테이블과 같아야 하는가. 상한은 5개와 20개 11장
11 DynamoDB 용량 모드 예측 불가면 온디맨드, 안정적이면 프로비저닝과 오토 스케일링. 모드는 변경 가능 11장
12 수직 확장과 수평 확장 탄력성이 요구면 수평. 상태 비저장 설계가 전제입니다 5장 · 7장
13 배치 그룹 선택 저지연은 클러스터, 장애 격리는 분산, 그룹 단위 격리는 파티션 5장
14 실시간 스트리밍 수집 다중 소비자·재처리는 Data Streams, 대상 적재는 Firehose, Kafka 자산은 MSK 15장
15 서버리스 분석과 데이터 웨어하우스 S3 위 임시 SQL은 Athena, 반복 대규모 분석은 Redshift, 프레임워크 이식은 EMR 15장
16 ETL과 데이터 카탈로그 스키마 발견과 변환은 AWS Glue. 저지연 수집 도구가 아닙니다 15장
17 컨테이너 실행 모델 오케스트레이터(ECS·EKS)와 실행 방식(EC2·Fargate)은 별개의 선택입니다 13장
18 ALB와 NLB와 GWLB 계층과 프로토콜이 기준. 고정 IP는 NLB, GENEVE는 GWLB 7장

이 도메인의 함정

도메인 미니 퀴즈

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

이어서 볼 곳

공식 문서 출처