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

By Laurynas Brazys · 1 August 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

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

EC2 인스턴스 설계, 스토리지, 네트워킹

EC2 인스턴스 설계는 워크로드 특성을 인스턴스 패밀리와 일치시키는 것에서 시작하며, vCPU, 메모리, 네트워크, 로컬 스토리지 간의 균형을 맞춥니다. 프로파일링을 기반으로 컴퓨팅 최적화(C), 메모리 최적화(R/X), 스토리지 최적화(I/D) 또는 GPU(P/G) 유형을 선택합니다. 높은 네트워크 처리량과 짧은 지연 시간을 위해 Nitro 기반 인스턴스와 ENA/SR-IOV를 활용합니다. 지연 시간에 민감하거나 높은 IOPS의 임시 데이터가 필요한 경우, I3/I4 또는 Nitro SSD의 인스턴스 스토어(임시)를 고려하고, 영구 블록 스토리지가 필요하면 Provisioned IOPS(io2/io2 Block Express)를 사용하는 EBS를 사용하고 키 관리를 위해 KMS로 EBS 암호화를 활성화합니다. 인스턴스가 Application Load Balancer 뒤의 VPC에 있을 때, 인터넷 연결 ALB는 퍼블릭 서브넷에 배치하고 대상은 프라이빗 서브넷에 위치하도록 해야 합니다. ALB를 잘못 배치하거나 보안 그룹을 잘못 구성하는 것은 흔한 함정입니다. 배치에 영향을 주기 위해 Placement Groups(짧은 지연 시간의 HPC를 위한 클러스터, 대규모 분산 상태 저장 시스템을 위한 파티션, 장애 격리를 위한 분산)를 사용하되 트레이드오프를 감수해야 합니다. 클러스터는 최고의 성능을 제공하지만 AZ 수준의 내결함성은 감소합니다. 전송 중 데이터 암호화를 위해 ALB에서 TLS를 종료하거나 NLB 패스스루를 사용한 엔드투엔드 TLS를 사용합니다. 의사 결정 기준은 비용 대비 성능을 비교 평가합니다. 밀도가 높은 인스턴스 유형은 비용을 절감하지만 장애 영향 반경과 라이선스 비용을 증가시킬 수 있습니다. 경험적 규칙보다는 CloudWatch, AWS Compute Optimizer, 부하 테스트를 통해 적정 규모 조정을 하는 것을 선호합니다.

Auto Scaling 그룹, 정책 및 수명 주기 관리

Auto Scaling Groups(ASG)는 시작 템플릿, 혼합 인스턴스 정책, 수명 주기 후크, 조정 정책의 조합을 사용하여 탄력성, 복원성, 비용 효율성을 위해 설계해야 합니다. 시작 템플릿을 사용하여 AMI, 인스턴스 유형 재정의, EBS 구성 및 사용자 데이터를 버전 관리합니다. 용량 최적화 스팟 할당 전략이나 다각화된 전략을 사용하는 혼합 인스턴스는 중단 위험을 줄이고 비용을 낮춥니다. 조정 동작의 경우, 예측 가능한 지표(CPU, 대상당 요청 수)에는 대상 추적 정책을 선호하고, 임계값 기반의 다단계 조치가 필요할 때는 단계 조정을 사용합니다. 예측 조정은 알려진 일일 패턴에 대비하여 용량을 미리 프로비저닝할 수 있습니다. 수명 주기 후크를 구현하여 종료 전에 사용자 지정 초기화 또는 드레이닝 작업을 실행합니다. 웜 풀을 결합하여 서비스 제공 시간을 줄이고, 업무 시간 기준선을 위해 예약된 조정을 사용합니다. 상태 확인은 조기 교체를 피하기 위해 ELB 및 EC2 상태 확인을 통합해야 합니다. 공격적인 휴지 시간으로 인한 스케일인 시의 잦은 교체, 혼합 ASG에서의 부적절한 인스턴스 가중치, 애플리케이션 준비 시간을 고려하지 않는 것과 같은 함정에 유의해야 합니다. 상태 저장 서비스의 경우, 인메모리 캐시를 잃게 되는 빠른 스케일인을 피해야 합니다. 비용 대비 복원력 측면에서, On-Demand를 예비로 사용하는 스팟 기반 용량은 비용 절감을 제공하지만 중단 처리가 필요하며, 100% On-Demand는 더 높은 비용으로 예측 가능성을 극대화합니다.

컨테이너 및 오케스트레이션: ECS, EKS, Fargate 선택

Amazon ECS, EKS, Fargate 중 하나를 선택하는 것은 운영 모델, 제어 요구사항, 워크로드 패턴에 따라 달라집니다. Fargate는 노드 관리를 제거하여 운영 단순성을 우선시하는 팀에 이상적이지만, vCPU당 가격이 더 높고 임시 스토리지 제한이 있습니다. 비용 절감을 위해 Fargate Spot을 지원합니다. ECS는 Kubernetes의 복잡성 없이 컨테이너 오케스트레이션을 원하는 고객에게 긴밀한 AWS 통합과 단순성을 제공합니다. EKS는 Kubernetes 생태계, 이식성 또는 고급 스케줄링이 필요할 때 적합합니다. 동적 적정 규모 조정을 위해 관리형 노드 그룹 또는 Self-Managed + Karpenter를 고려하십시오. 네트워크 제한(ENI/파드 밀도) 및 CNI 동작은 파드 밀도와 노드 크기 조정에 영향을 미칩니다. EKS에서는 서비스 계정용 IAM 역할(IAM Roles for Service Accounts)과 영구 볼륨을 위한 EBS CSI를 사용하여 자격 증명 확산을 줄이고 파드별 스토리지를 활성화합니다. 공유 파일 시스템의 경우, 처리량 및 지연 시간 요구에 따라 EFS(NFS) 또는 FSx(Lustre)를 사용합니다. 높은 메타데이터 작업을 위해 NFS 기반 컨테이너는 피하고, 워크로드에 맞게 처리량 모드가 조정된 EFS를 선호해야 합니다. 노드 조정을 위해 클러스터 오토스케일러 또는 Karpenter를 구현하고, ALB/ECS 서비스 지표를 사용하여 서비스 오토 스케일링을 구현합니다. 흔한 함정으로는 파드 중단 예산(pod disruption budgets)을 무시하거나, Kubernetes 컨트롤 플레인 할당량을 과소평가하거나, 빈 패킹(bin-pack) 전략을 사용하는 대신 노드를 과도하게 프로비저닝하는 것 등이 있습니다. 제어, 비용, 운영 오버헤드 간의 트레이드오프를 고려하여 선택을 결정해야 합니다.

서버리스 컴퓨팅 패턴, Lambda 제약 조건 및 이벤트 기반 설계

서버리스는 운영 오버헤드를 줄여주지만, 동시성, 상태, 다운스트림 시스템의 한계를 해결하기 위한 아키텍처 패턴이 필요합니다. Lambda는 수명이 짧은 이벤트 기반 작업, API Gateway 또는 ALB를 통한 API 백엔드, SQS 또는 SNS를 사용한 비동기 처리에 매우 적합합니다. 오래 실행되는 워크플로를 오케스트레이션하려면 Step Functions를 사용하고, 데이터베이스 연결 폭주(connection storm)를 완화하기 위한 데이터베이스 액세스에는 DynamoDB 또는 RDS Proxy를 사용하십시오. ENI 생성으로 인해 발생하는 Lambda VPC 콜드 스타트 오버헤드에 유의해야 합니다. 지연 시간에 민감한 엔드포인트에는 프로비저닝된 동시성(provisioned concurrency)으로 이를 완화하거나, VPC 엔드포인트와 RDS Proxy를 사용하여 연결 수를 제한하십시오. SNS + SQS를 통해 팬아웃/팬인(fan-out/fan-in)을 구현하거나, 순서가 중요한 스트림 처리를 위해 Kinesis/MKS를 사용하십시오. 재시도 및 중복을 관리하려면 SQS 데드 레터 큐(dead-letter queue)와 멱등성 핸들러(idempotent handler)를 사용하십시오. 연쇄적인 장애(cascading failures)를 피하기 위해 동시성 한도, 예약된 동시성(reserved concurrency), 스로틀링을 계획해야 합니다. 스로틀, 지터(jitter)를 사용한 재시도, 서킷 브레이커(API Gateway 또는 사용자 지정)를 사용하여 백프레셔(backpressure)를 위한 설계를 하십시오. 비용-성능 트레이드오프는 명확합니다. Lambda는 트래픽이 급증하고 실행 시간이 짧은 작업에 비용 효율적이며, Fargate나 EC2는 지속적인 고CPU 사용량 또는 장기 실행 작업에 더 적합합니다. 흔히 저지르는 실수로는 다운스트림 시스템에 과부하를 주는 동기식 재시도에 의존하거나, 영속성을 기대하며 로컬 /tmp에 상태를 저장하거나, 지연 시간에 중요한 플로우에서 콜드 스타트에 대비한 프로비저닝을 하지 않는 것 등이 있습니다.

실제 문제: NovaTel Enterprise 컨택 센터 마이그레이션

시나리오: NovaTel Enterprise는 온프레미스 통화 라우팅과 AWS로의 Direct Connect를 갖춘 하이브리드 컨택 센터를 운영하고 있습니다. 이들은 두 개의 가용 영역(Availability Zone)에서 EC2에 세션 브로커를 실행 중이며, 온프레미스 PBX와 클라우드 서비스 간의 고가용성과 예측 가능한 지연 시간을 보장하는 AWS 관리형 컨택 센터로 마이그레이션하고자 합니다.

과제: SIP 트래픽을 위한 짧은 지연 시간의 연결, 스팟 인스턴스 중단을 견딜 수 있는 음성 처리를 위한 확장 가능한 컴퓨팅 계층, 그리고 운영 복잡성을 증가시키지 않으면서 여러 리전(Region)에 걸친 DR 전략이 필요합니다.

권장 접근 방식:

컨택 센터 기능을 위해 Amazon Connect를 프로비저닝하고, 짧은 지연 시간의 SIP 트렁킹을 위해 AWS Transit Gateway와 함께 Site-to-Site VPN 또는 Direct Connect를 사용합니다. 이 연결은 세션 브로커 앞단의 NLB에서 TLS 패스스루(passthrough)로 종단됩니다.
세션 처리 구성 요소는 용량 최적화(capacity-optimized) 스팟 인스턴스와 온디맨드 인스턴스를 예비로 사용하는 시작 템플릿(launch template)을 갖춘 혼합 Auto Scaling Group으로 실행하고, 중요한 브로커의 장애 격리를 위해 배치 그룹(Placement Group, 분산)을 사용합니다.
임시의 짧은 지연 시간 스토리지가 필요한 상태 저장(stateful) 통화 미디어의 경우, 미디어 버퍼링을 위해 인스턴스 스토어 기반 인스턴스(Nitro)를 사용하고 세션 메타데이터를 다중 AZ 복제가 구성된 DynamoDB 또는 ElastiCache에 복제합니다. 영구 데이터에는 리전 간 읽기 전용 복제본(read replica)을 DR에 활용하는 RDS(다중 AZ) 또는 Aurora Global DB를 사용합니다.
브로커의 콜드 스타트를 최소화하기 위해 수명 주기 후크(lifecycle hook)와 웜 풀(warm pool)을 구현하고, 리전 간 DR을 위해 Route 53 가중치 기반 장애 조치(weighted failover)를 사용하며, 경고 및 자동화된 장애 조치 런북을 위해 CloudWatch + SNS/SQS를 구현합니다.

근거: 관리형 컨택 센터 서비스를 사용하면 운영 부담이 줄어들고, 스팟 인스턴스를 포함한 혼합 ASG는 비용을 최적화합니다. 임시 미디어를 인스턴스 스토어에 격리하여 성능을 유지하고, DynamoDB/ElastiCache로의 영구 상태 복제와 다중 AZ RDS/Aurora는 전문적인 아키텍처 모범 사례에 부합하는 복원력과 빠른 장애 조치를 제공합니다.

← 보안 · 모든 도메인 · 스토리지 및 데이터 관리 →

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