고성능 및 Elastic Compute 솔루션 설계

발행: 3일 전 (2026년 2월 7일 오후 08:19 GMT+9)

9 분 소요

원문: Dev.to

Source: Dev.to

⚡ Domain 3: 고성능 아키텍처 설계

📘 작업 명세 3.2

고성능 및 탄력적인 컴퓨트 솔루션 설계는 다음과 같은 컴퓨트를 선택하는 것을 의미합니다:

성능이 우수함
자동으로 확장됨
구성 요소를 분리하여 병목 현상을 방지함

접근 방식

먼저 컴퓨트 런타임을 선택 – EC2 vs 컨테이너 vs 서버리스.
스케일링 모델을 선택 – Auto Scaling vs 이벤트 기반 스케일링.
성능 튜닝 – 인스턴스 패밀리 / 메모리 / 동시성 / 배치.

Source: …

지식

1️⃣ 적절한 사용 사례가 있는 AWS 컴퓨트 서비스

서비스	최적 시나리오
Amazon EC2	• OS/런타임에 대한 완전한 제어 • 레거시 애플리케이션, 맞춤형 네트워킹/에이전트, 특수 드라이버 • 예측 가능한 장기 실행 서비스
AWS Lambda	• 이벤트 기반 작업 (API, SQS 처리, EventBridge, 파일 처리) • 트래픽 급증 또는 예측 불가능 • 운영 최소화
Amazon ECS / Amazon EKS (containers)	• 마이크로서비스 및 장기 실행 컨테이너 워크로드 • 표준화된 패키징 및 예측 가능한 스케일링 • Lambda 제한에 맞지 않을 때 (타임아웃, 런타임, 종속성)
AWS Fargate (serverless containers)	• EC2 인스턴스를 관리하지 않는 컨테이너 • 컨테이너화된 애플리케이션에 대한 일반적인 “고성능 + 탄력성” 솔루션
AWS Batch	• 배치 작업, 대규모 작업 큐, 컴퓨팅 집약적 처리 • 작업 실행을 위해 자동으로 컴퓨팅(주로 EC2/스팟)을 프로비저닝
Amazon EMR	• 빅데이터 처리 프레임워크 (Spark, Hadoop) • 분산 ETL/분석 워크로드 Spark/Hadoop → EMR “run 10,000 batch jobs” → Batch

2️⃣ 글로벌 인프라 및 엣지 서비스를 통한 분산 컴퓨팅 개념

멀티 AZ 아키텍처는 AZ 장애의 영향을 줄이고 스케일 아웃을 가능하게 합니다.
엣지 서비스는 최종 사용자에 대한 지연 시간을 감소시킵니다.

공통 엣지 및 글로벌 서비스

CloudFront – 캐싱 및 엣지 전달.
Global Accelerator – TCP/UDP 애플리케이션을 위한 애니캐스트 라우팅.

3️⃣ 큐잉 및 메시징 개념 (Pub/Sub)

서비스	역할
SQS	생산자/소비자를 분리; 큐 깊이에 따라 워커 스케일링.
SNS	Pub/Sub 팬아웃.
EventBridge	이벤트 라우팅.

4️⃣ 확장성 기능

EC2 Auto Scaling – Auto Scaling 그룹(ASG) 내 EC2 인스턴스를 스케일링합니다.
AWS Auto Scaling – 여러 서비스(ECS, DynamoDB, Aurora 복제본 등)에 대한 스케일링을 제공합니다.

5️⃣ 서버리스 기술 및 패턴

서비스	스케일링 메커니즘
Lambda	동시성에 따라 스케일링; 이벤트 기반 및 급증 가능.
Fargate	서버를 관리하지 않고 컨테이너를 스케일링; ECS/EKS 구성에 따라 스케일링이 결정됩니다.

6️⃣ 컨테이너 오케스트레이션

Amazon ECS (AWS‑네이티브) 개념:

클러스터 → 서비스 → 태스크
태스크 정의가 청사진입니다.

Amazon EKS (Kubernetes) 개념:

클러스터 → 디플로이먼트 → 파드

Kubernetes가 필요하지 않다면, 일반적으로 ECS가 더 간단합니다.

Skills

A️⃣ Decouple Workloads So Components Can Scale Independently

Decoupling Patterns

SQS between web tier and workers – spikes를 버퍼링하고, 재시도 및 DLQ를 처리합니다.
SNS fan‑out to multiple consumers.
EventBridge for event‑driven integration.
Step Functions for orchestration when coordination is needed.

Frontend 은 트래픽에 따라 확장되고, workers 은 큐 깊이에 따라 확장됩니다.

B️⃣ Identify Metrics & Conditions to Perform Scaling Actions

Common Scaling Signals

CPU / memory (EC2/ECS).
Request count / target response time (ALB target metrics).
Queue depth / age of oldest message (SQS‑based worker scaling).
Lambda concurrency / duration / throttles.
Custom CloudWatch metrics (비즈니스‑주도 스케일링, 예: “대기 중인 작업”).

C️⃣ Select Appropriate Compute Options & Features to Meet Business Requirements

EC2 Instance Types

Family	Typical Use
t, m	General purpose
c	Compute‑heavy
r, x	Memory‑heavy
i	Storage / IOPS‑heavy
p, g	GPU / ML / graphics

Other EC2 Options

Spot Instances – 장애 허용 워크로드 (배치, 무상태, 유연함).
Graviton (Arm) – 가격/성능 이점.

D️⃣ Select the Appropriate Resource Type & Size to Meet Business Requirements

Lambda Memory

메모리는 CPU 할당량도 결정합니다.
실행 시간이 너무 느릴 경우 메모리를 늘립니다 (대부분 성능이 향상됩니다).
throttles와 동시성 제한을 모니터링합니다.

Container Memory

작업/Pod의 CPU와 메모리를 적절히 설정합니다.
가능한 경우 단일 작업을 과다하게 크기 조정하기보다 작업 수를 늘려 확장합니다.

Cheat Sheet

Requirement	Compute
이벤트 기반, 급증하는 트래픽, 최소 운영	Lambda
서버 관리 없이 컨테이너 실행	ECS on Fargate
쿠버네티스 사용 필수	EKS
OS 제어 필요 / 레거시 앱	EC2 (+ Auto Scaling)
다수의 배치 작업 / 작업 큐 실행	AWS Batch
Spark/Hadoop 빅데이터 처리	EMR
백로그에 따라 워커 자동 확장	SQS + autoscaled consumers
전 세계 성능 향상 필요	CloudFront / Global Accelerator

Recap Checklist ✅

워크로드가 분리됨 so components can scale independently (queues/events).
컴퓨팅 선택이 런타임 요구에 맞음 (EC2 vs containers vs serverless).
스케일링 전략이 명시적임 (Auto Scaling, queue‑based, event‑based).
스케일링 메트릭이 적절히 선택됨 (CPU, requests, queue depth, concurrency).
EC2 인스턴스가 워크로드 프로파일에 따라 선택됨 (compute/memory/storage/GPU).
Lambda/컨테이너 리소스가 적정 규모로 설정됨 (memory, CPU, task count).

AWS 백서 및 공식 문서

이 문서들은 Task Statement 3.2 뒤에 있는 주요 AWS 자료입니다.

암기할 필요는 없으며, 고성능 및 탄력적인 컴퓨팅 솔루션을 설계하는 방법을 이해하는 데 활용하세요.

핵심 영역

컴퓨트 서비스
스케일링
디커플링 및 메시징
엣지 및 글로벌 성능

🚀