SAA-C03 시험에서 컴퓨팅 성능 문제는 전체 출제 비중의 약 26%를 차지하는 설계(Design) 영역에 속합니다. "이 워크로드에 어떤 EC2 인스턴스가 맞는가?", "어떻게 자동으로 용량을 늘리고 줄이는가?" 를 묻는 문제가 반복적으로 등장합니다.
EC2 인스턴스 패밀리란 무엇인가요?
자동차를 생각해 보세요. 가족 나들이에는 SUV, 경주에는 스포츠카, 이사할 때는 트럭이 필요합니다. EC2도 마찬가지입니다. 워크로드 종류에 따라 최적화된 인스턴스 유형이 있습니다.
M계열 — 패밀리 세단 (범용)
일반적인 웹 서버, 앱 서버, 소규모 데이터베이스에 씁니다. CPU와 메모리 비율이 균형 잡혀 있어 어떤 용도에도 무난하게 맞습니다. 딱히 특별한 요구 사항이 없다면 M계열부터 시작합니다.
C계열 — 스포츠카 (컴퓨팅 최적화)
CPU가 특별히 중요한 워크로드에 씁니다. 과학 계산, 동영상 인코딩, 게임 서버, 고성능 웹 서버가 여기에 해당합니다. 같은 비용에 더 강력한 CPU를 얻을 수 있습니다.
R/X계열 — 화물 밴 (메모리 최적화)
화물 밴은 짐을 많이 실을 수 있도록 설계되었습니다. R/X계열은 메모리가 엄청나게 많이 필요한 워크로드용입니다. 인메모리 데이터베이스, 실시간 빅데이터 분석, 대형 캐시 서버에 씁니다.
P/G계열 — 특수 트럭 (가속 컴퓨팅)
GPU가 필요한 특수 작업에 씁니다. 머신러닝 모델 훈련, 딥러닝 추론, 3D 그래픽 렌더링이 대표적입니다. 일반 작업에는 오버스펙이지만, GPU가 필요한 순간에는 대체재가 없습니다.
I/D계열 — 고속 물류 창고 (스토리지 최적화)
디스크 읽기/쓰기 속도가 중요한 워크로드에 씁니다. 데이터 웨어하우스, 대규모 로그 처리, NoSQL 데이터베이스 서버에 활용합니다.
Auto Scaling — 명절 백화점의 알바 직원 채용
Auto Scaling을 이해하는 가장 좋은 방법은 백화점 비유입니다. 명절 전날 백화점에는 손님이 몰려듭니다. 미리 아르바이트 직원을 더 뽑아야 합니다. 명절이 끝나면 다시 줄여야 하죠. 하지만 평소에도 한 명은 항상 있어야 합니다. Auto Scaling이 이 역할을 자동으로 합니다.
Auto Scaling Group의 세 가지 숫자가 핵심입니다.
Minimum: 항상 유지해야 할 최소 인스턴스 수. "가게 문을 열려면 최소 직원 1명" Desired: 현재 운영하고 싶은 인스턴스 수. "평소에는 3명이 적당해" Maximum: 아무리 바빠도 이 수 이상은 늘리지 않음. "최대 10명까지만 고용"
Auto Scaling 정책 — 어떤 기준으로 늘리고 줄이나요?
Target Tracking (목표 추적 정책)
가장 단순하고 일반적입니다. "CPU 사용률을 50%로 유지해줘"라고 목표를 정하면, AWS가 알아서 인스턴스를 추가하거나 제거합니다. 에어컨 자동 온도 조절기와 같습니다.
Step Scaling (단계별 정책)
CPU가 60~70%이면 2개 추가, 70~80%이면 4개 추가처럼 구간별로 다르게 대응합니다. Target Tracking보다 세밀한 제어가 필요할 때 씁니다.
Scheduled Scaling (예약 정책)
매일 오전 9시에 인스턴스를 10개로 늘리고, 자정에는 2개로 줄이는 등 시간표대로 용량을 조정합니다. 트래픽 패턴이 예측 가능한 경우에 씁니다.
Predictive Scaling (예측 정책)
AWS가 과거 트래픽 패턴을 머신러닝으로 분석해서 미리 용량을 늘립니다. "내일 오전 11시에 트래픽이 몰릴 것 같으니 미리 준비해"라고 작동합니다.
EC2 Placement Group — 서버를 어디에 배치할까요?
인스턴스를 물리적으로 어디에 배치하느냐에 따라 성능과 가용성이 크게 달라집니다.
Cluster Placement Group — 한 사무실의 책상들
모든 직원이 한 방에 모여 앉으면 서로 대화하기 가장 빠릅니다. Cluster는 인스턴스들을 같은 AZ 안의 가까운 하드웨어에 배치합니다. 네트워크 지연 시간이 최소화됩니다. HPC(고성능 컴퓨팅), 대용량 데이터 처리, 긴밀한 노드 간 통신이 필요한 워크로드에 씁니다. 단점: 같은 하드웨어 랙에 있으므로 랙 장애 시 모두 영향받습니다.
Spread Placement Group — 층마다 책상 하나씩
각 직원을 서로 다른 층에 배치하면 한 층에 불이 나도 나머지는 안전합니다. Spread는 인스턴스를 서로 다른 물리적 하드웨어에 분산합니다. 가용성이 가장 중요한 소수의 중요 인스턴스에 씁니다. 제한: AZ당 최대 7개 인스턴스.
Partition Placement Group — 별도의 방들
회사를 여러 팀(파티션)으로 나누고 각 팀이 별도의 방을 씁니다. 같은 파티션 안에서는 랙을 공유하지만, 다른 파티션과는 하드웨어를 완전히 분리합니다. Hadoop, Kafka, Cassandra처럼 파티션 인식(partition-aware) 분산 시스템에 씁니다.
!EC2 배치 그룹: Cluster, Spread, Partition
AWS Batch와 EMR — 대규모 배치 처리
AWS Batch
"이 계산 작업 1만 개를 처리해줘"라고 요청하면, AWS Batch가 자동으로 적절한 EC2 인스턴스를 준비하고, 작업을 나눠 실행하고, 끝나면 인스턴스를 종료합니다. 배치 큐와 컴퓨팅 환경을 정의하면 나머지는 AWS가 알아서 합니다.
Amazon EMR
Hadoop, Spark, Hive 같은 오픈소스 빅데이터 프레임워크를 EC2 클러스터 위에서 쉽게 실행할 수 있게 해줍니다. 대규모 로그 분석, 데이터 변환(ETL), 머신러닝 전처리에 씁니다.
시험 핵심 정리
"CPU 집약, 과학 계산, 게임 서버" -- C계열 (컴퓨팅 최적화)
"인메모리 DB, 대용량 메모리 필요" -- R/X계열 (메모리 최적화)
"GPU, 머신러닝 훈련, 딥러닝" -- P/G계열 (가속 컴퓨팅)
"특별한 요구 없는 범용 워크로드" -- M계열 (범용)
"CPU를 특정 목표값으로 유지" -- Target Tracking Auto Scaling
"구간별 다른 대응, 세밀한 제어" -- Step Scaling
"예정된 시간에 용량 변경" -- Scheduled Scaling
"과거 패턴 기반 사전 확장" -- Predictive Scaling
"HPC, 낮은 지연, 긴밀한 노드 통신" -- Cluster Placement Group
"소수 중요 인스턴스, 하드웨어 분산" -- Spread Placement Group
"Hadoop/Kafka, 파티션 인식 분산 시스템" -- Partition Placement Group
"대규모 배치 작업 자동 스케줄링" -- AWS Batch
"Hadoop/Spark 빅데이터 클러스터" -- Amazon EMR