Amazon SOA-C02: 컴퓨팅 및 Auto Scaling — 학습 가이드

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

다음의 일부입니다: AWS SysOps Administrator Associate SOA-C02 — 학습 가이드. 검증된 답안으로 연습하기: Amazon 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

이 도메인은 EC2 인스턴스 및 Auto Scaling을 관리하여 안정적이고 비용 효율적인 컴퓨팅 용량을 제공하는 방법을 다룹니다. 인스턴스 수명 주기 운영, 확장 전략, 로드 밸런서 통합, 성능 및 복원력을 위한 배치, 가용성 및 상태에 영향을 미치는 유지 관리/종료 동작에 중점을 둡니다. 운영 전문성이란 올바른 인스턴스 유형, 시작 구성 패턴, 확장 정책, 상태 확인 통합을 선택하여 비용을 제어하면서 SLA를 충족하는 것을 의미합니다.

EC2 인스턴스 수명 주기 및 관리

EC2 수명 주기 관리는 시작 구성 시점부터 시작됩니다. 시작 템플릿(Launch Templates)(aws ec2 create-launch-template / 콘솔)을 사용하여 AMI, 인스턴스 유형, IAM 인스턴스 프로파일, 사용자 데이터, 네트워크 인터페이스, EBS 매핑, 메타데이터 옵션을 캡처합니다. 템플릿은 버전 관리를 지원하여 불변 배포(immutable deploy)를 간단하게 만듭니다. 불변 배포는 새 시작 템플릿 버전을 사용하거나 새 시작 템플릿을 사용하여 새 Auto Scaling 그룹을 생성하거나, ASG 인스턴스 새로 고침(instance refresh)을 사용하여 인스턴스를 교체합니다. 변경 사항이 부팅 시간 동작이나 AMI 수준 패치에 영향을 미치는 경우, 실행 중인 인스턴스의 인플레이스(in-place) 업그레이드를 피해야 합니다.

운영 CLI/콘솔 패턴에는 일회성 시작을 위한

undefined

와 ASG 기반 시작을 위한

undefined

가 포함됩니다. 부팅 시간을 기준으로 AMI 베이킹(Packer/CodeBuild)과 사용자 데이터 시작 스크립트 중 하나를 결정합니다. 부팅 시간을 줄이려면 무거운 종속성은 AMI에 베이킹하고, 환경별 연결 작업에는 사용자 데이터를 사용합니다. 임시 스토리지의 경우, 인스턴스 스토어 볼륨은 종료 시 손실된다는 점을 기억하십시오. 인스턴스 종료 후에도 EBS의 영속성이 필요하다면 루트 및 데이터 볼륨을 DeleteOnTermination=false로 구성해야 합니다.

Auto Scaling 그룹, 정책 및 수명 주기 후크

Auto Scaling 그룹(ASG)은 시작 템플릿 또는 시작 구성으로 설정되며, 여러 가용 영역에 걸쳐 원하는 용량/최소/최대 용량을 제어합니다. On-Demand와 Spot 인스턴스를 인스턴스 유형 목록과 혼합하여 비용에 최적화된 플릿을 구성하려면 시작 템플릿 + MixedInstancesPolicy를 선택합니다. 예측 가능한 용량을 확보하려면 인스턴스 가중치(instance weighting) 및 용량 최적화 할당 전략(capacity-optimized allocation strategies)을 사용합니다. 배포 시에는 불변 패턴을 선호해야 합니다. 즉, 기존 인스턴스를 재구성하는 대신 새 시작 템플릿 버전을 생성하고 ASG 인스턴스 새로 고침 또는 블루/그린 교체를 수행합니다.

확장 정책은 다음과 같이 표현됩니다:

대상 추적(Target tracking) (PolicyType=TargetTrackingScaling): ALB RequestCountPerTarget 또는 ASG 평균 CPU와 같은 사전 정의된 지표와 목표값을 설정하면 ASG가 자동으로 조정을 처리합니다.
단계 조정(Step scaling) (PolicyType=StepScaling): 위반 심각도에 따라 특정 조정 단계(예: +2, +4)를 트리거하는 CloudWatch 경보를 정의합니다. 폭주성(bursty) 워크로드에 유용합니다.
단순 조정(Simple scaling) (레거시): 쿨다운(cooldown)이 있는 단일 단계 조정으로, 일반적으로 대상 추적 또는 단계 조정으로 대체되었습니다.

수명 주기 후크(

undefined

)를 사용하여 인스턴스 종료/시작을 일시 중지합니다. 수명 주기 후크를 사용하면 완료 전에 연결을 드레이닝하고, 상태를 복제(S3/RDS로)하거나, SNS/SQS/Lambda를 통해 오케스트레이션 시스템에 알릴 수 있습니다. 교착 상태(stuck state)를 피하려면 항상 HeartbeatTimeout과 기본 작업을 설정해야 합니다.

Elastic Load Balancing 유형 및 상태 확인

트래픽 패턴에 따라 로드 밸런서 유형을 선택합니다. 콘텐츠 기반 라우팅 및 호스트/경로 규칙을 사용하는 HTTP/HTTPS 트래픽에는 Application Load Balancer (ALB), 최고의 성능과 고정 IP가 필요한 TCP/UDP 트래픽에는 Network Load Balancer (NLB), 레거시 스택에만 **Classic Load Balancer (CLB)**를 사용합니다.

undefined

와

undefined

를 사용하여 ALB와 대상 그룹을 생성합니다. 자동 수명 주기 상태 통합을 위해 ASG의 대상 그룹 연결을 사용하여 ASG 대상을 등록합니다.

상태 확인 통합을 위해서는 ASG와 ELB의 상태 확인을 일치시켜야 합니다. ASG의 HealthCheckType을 ELB로 설정(

undefined

)하여, 로드 밸런서가 해당 대상을 정상으로 표시한 후에만 인스턴스가 정상으로 간주되도록 합니다. 상태 확인 유형 및 영향:

ALB/NLB 대상 그룹 상태 확인: HTTP/HTTPS/TCP를 지원하며 애플리케이션 수준의 준비 상태를 측정합니다. 웹 앱에 권장됩니다.
ASG 상태 확인만 사용: 간단한 호스트 수준 확인(예: EC2 상태 확인)에 사용합니다.
HealthCheckGracePeriod: 새 인스턴스가 부팅하고, 사용자 데이터를 실행하며, 앱 수준 확인을 통과할 시간을 줍니다.

고정성(Stickiness)의 영향: ALB 대상 그룹 고정성은 애플리케이션 쿠키 기반 선호도(기간 기반)를 사용하며, 이는 세션 선호도를 향상시킬 수 있지만 균등한 분산을 저해하고 롤링 업데이트를 복잡하게 만듭니다. NLB는 클라이언트 IP 선호도를 지원합니다. 고정성은 세션 상태를 외부화할 수 없는 경우에만 사용해야 합니다.

인스턴스 배치, 용량 계획 및 스케일링 지표

배치 결정은 지연 시간(latency)과 장애 도메인(failure domain)에 영향을 미칩니다: 배치 그룹(placement group)은 클러스터(낮은 지연 시간 네트워크), 분산(중요 인스턴스를 위해 랙당 하나의 인스턴스), 파티션(장애 격리 파티션) 전략을 제공합니다. ASG는 기본적으로 AZ에 걸쳐 인스턴스 균형을 맞춥니다. 단일 AZ 핫스팟을 피하기 위해 AZ를 고려한 용량 계획을 선호해야 합니다. CLI:

undefined

용량 계획은 인스턴스 유형, 구매 옵션 및 지표를 고려합니다:

인스턴스 유형: 워크로드에 따라 CPU/메모리/네트워크에 최적화된 패밀리(M/C/R/T/D/I)를 선택하고, 대표적인 부하 테스트로 측정합니다.
구매: 예측 가능성을 위해 On-Demand, 정상 상태(steady-state) 비용 절감을 위해 Reserved 또는 Savings Plans, 일시적인 비용 효율성을 위해 Spot을 사용합니다. 유형과 구매 옵션을 결합하려면 MixedInstancesPolicy를 사용합니다.
스케일링 지표: 기본 ASG 지표는 그룹 전체의 평균 CPU를 사용합니다. 대상 추적(target tracking)을 위해 ALB RequestCountPerTarget 또는 사용자 지정 CloudWatch 지표(예: 대기열 깊이)와 같은 애플리케이션 수준 지표를 사용하는 것이 좋습니다. 일반적인 패턴:
인스턴스당 일정한 수의 요청이 필요할 때 ALB/request-count-per-target을 사용한 대상 추적을 사용합니다.
정의된 복구 단계가 있는 갑작스럽고 큰 스파이크에는 단계 스케일링(step scaling)을 사용합니다.
매일 주기적인 워크로드에는 예측 스케일링(Predictive Scaling)을 고려합니다.

인스턴스 복구, 종료 동작 및 유지 관리

하드웨어 문제에 대한 자동 복구(EC2 Recover 작업이 있는 CloudWatch 경보)를 활성화하고 예약된 이벤트(describe-instance-status)를 처리하여 인스턴스 장애 및 유지 관리를 계획합니다. 볼륨 수명 주기를 제어하기 위해 instance-initiated-shutdown-behavior 및 EBS DeleteOnTermination 플래그를 구성합니다. 조정하려면

undefined

를 사용합니다.

ASG의 종료 동작: ASG 종료 정책은 어떤 인스턴스를 먼저 종료할지 결정합니다(Default: 가장 오래된 시작 구성 또는 인스턴스 상태 및 AZ 밸런싱 휴리스틱). 중요한 운영 세부 정보:

로컬 상태는 임시적(ephemeral)입니다: 인스턴스 스토어 볼륨과 인 메모리 캐시는 종료 시 손실됩니다. 교체 시 로컬 상태가 보존된다고 가정하지 마십시오. 중요한 데이터는 EBS(적절한 스냅샷/백업 포함), S3 또는 외부 캐시(ElastiCache)에 영구 저장해야 합니다.
수명 주기 후크(lifecycle hooks)를 사용하여 종료 전에 트래픽을 드레이닝하고 상태를 오프로드합니다.
유지 관리를 위해 인스턴스 새로 고침(instance refresh) 또는 블루/그린(blue/green)을 사용하여 인스턴스를 안전하게 교체합니다.

undefined

일반적인 함정과 결정 기준

기본 재사용 대기시간(cooldown) 및 CPU 전용 지표에 의존: 애플리케이션 동작에 맞는 지표(ALB RequestCountPerTarget, 대기열 깊이)를 선택하고, 시작 시간을 수용하도록 재사용 대기시간을 설정하고, 진동(oscillation)을 피하기 위해 HealthCheckGracePeriod를 설정합니다.
정상적인 종료를 위해 수명 주기 후크를 사용하지 않음: 후크가 없으면 진행 중인 요청과 로컬 캐시가 손실됩니다. SNS/SQS/Lambda로 후크를 구현하여 상태를 드레이닝하고 영구 저장합니다.
인스턴스 교체 시 로컬 상태가 보존된다고 가정: 로컬 인스턴스 스토어와 인 메모리 캐시는 임시적입니다. 상태 비저장(stateless) 인스턴스를 설계하거나 내구성 있는 스토어에 상태를 복제합니다.
고정성(stickiness)의 과도한 사용: 고정성은 불균등한 로드 분산을 증가시키고 스케일링 및 업데이트를 복잡하게 만듭니다. 스케일 아웃을 위해 외부 세션 스토어(ElastiCache, DynamoDB)를 선호합니다.
AZ 밸런싱 및 배치 그룹 무시: 한 AZ 또는 클러스터 그룹에 너무 많은 인스턴스를 배치하면 단일 장애 지점(single point of failure)이 생길 수 있습니다. ASG 다중 AZ 배포 및 적절한 배치 그룹 전략을 사용합니다.
상태 확인 통합의 잘못된 구성: ASG health-check-type은 ELB/대상 그룹 상태 확인과 일치해야 하며, HealthCheckGracePeriod는 앱 초기화에 충분히 길어야 합니다. 그렇지 않으면 정상 인스턴스가 종료됩니다.

실용적인 문제: 사용 사례 시나리오

StreamingCo는 매일 트래픽 급증을 겪는 비디오 썸네일 API를 운영하고 있으며 EC2 인스턴스에서 로컬 디스크 캐시를 사용합니다. 최근 스케일 업이 느리고 종료된 인스턴스가 캐시를 잃어 응답 시간이 저하되는 문제가 발생했습니다.

시작 구성을 시작 템플릿(Launch Template)으로 마이그레이션하고 런타임 종속성이 포함된 경량 AMI를 만듭니다(bake). 불변 배포(immutable deploy)를 위해

undefined

및 버전 관리를 사용합니다. 2. 여러 인스턴스 유형과 Spot + On-Demand 할당을 나열하는 MixedInstancesPolicy로 ASG를 구성하여 비용과 용량의 균형을 맞춥니다. 3. ALB를 연결하고 애플리케이션의 부트스트랩 시간에 맞춰 HealthCheckGracePeriod가 설정된 ALB RequestCountPerTarget 지표에 TargetTrackingScaling을 사용합니다. 4. ASG 종료 시 수명 주기 후크를 구현하여 연결을 드레이닝하고, 종료 전에 필요한 캐시 키를 ElastiCache 또는 S3에 영구 저장하는 Lambda/SNS 플로우를 실행합니다. 5. 세션 및 캐시 상태를 ElastiCache 또는 S3로 외부화하고, 배치 그룹/AZ 배포를 사용하여 지연 시간 및 장애 도메인 요구 사항을 충족합니다.

근거: 시작 템플릿과 불변 배포를 사용하면 부팅 변동성이 줄어듭니다. ALB 대상의 대상 추적은 스케일링을 CPU가 아닌 요청 부하에 연결합니다. 수명 주기 후크는 종료 시 데이터 손실을 방지합니다. 캐시를 외부화하면 임시 로컬 상태에 대한 의존성이 제거되어 혼합 인스턴스/구매 전략을 통해 빠르고 안전한 스케일링과 비용 절감이 가능해집니다.

← 스토리지 및 데이터 관리 · 모든 도메인 · 데이터베이스 및 캐싱 →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →