[AWS] AWS의 컨테이너 : ECS, Fargate, ECR, EKS

Docker 기초

VM vs Container:

VM (무거움):
[App A] [App B]
[Guest OS] [Guest OS]
[Hypervisor]
[Host OS]
[Hardware]

Container (가벼움):
[App A] [App B]
[Docker Engine]
[Host OS]
[Hardware]

• 일관된 환경

• 빠른 시작 (초 단위)

• 격리성

• 이식성

Dockerfile 예시

# 베이스 이미지
FROM python:3.9-slim

# 작업 디렉토리
WORKDIR /app

# 의존성 복사 및 설치
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# 애플리케이션 코드 복사
COPY . .

# 포트 노출
EXPOSE 8000

# 실행 명령
CMD ["python", "app.py"]

기본 명령어

# 이미지 빌드
docker build -t my-app:v1 .

# 컨테이너 실행
docker run -d -p 8000:8000 --name my-app my-app:v1

# 실행 중인 컨테이너 확인
docker ps

# 로그 확인
docker logs my-app

# 컨테이너 중지
docker stop my-app

# 컨테이너 삭제
docker rm my-app

Amazon ECR (Elastic Container Registry)

[개발자] → docker push → [ECR] → docker pull → [ECS/EKS]

• 프라이빗 레지스트리

• IAM 통합

• 이미지 스캔 (취약점 검사)

• 수명 주기 정책

사용 방법

# 1. ECR 저장소 생성
aws ecr create-repository --repository-name my-app

# 2. 로그인
aws ecr get-login-password --region us-east-1 | \
  docker login --username AWS --password-stdin \
  123456789012.dkr.ecr.us-east-1.amazonaws.com

# 3. 이미지 태그
docker tag my-app:v1 \
  123456789012.dkr.ecr.us-east-1.amazonaws.com/my-app:v1

# 4. 푸시
docker push \
  123456789012.dkr.ecr.us-east-1.amazonaws.com/my-app:v1

# 5. 풀
docker pull \
  123456789012.dkr.ecr.us-east-1.amazonaws.com/my-app:v1

수명 주기 정책

{
  "rules": [
    {
      "rulePriority": 1,
      "description": "Keep last 10 images",
      "selection": {
        "tagStatus": "any",
        "countType": "imageCountMoreThan",
        "countNumber": 10
      },
      "action": {
        "type": "expire"
      }
    }
  ]
}

Amazon ECS (Elastic Container Service)

[ECS Cluster]
├─ Task Definition (컨테이너 정의)
├─ Service (실행 및 관리)
└─ Task (실행 중인 컨테이너)

핵심 개념

1. 클러스터 (Cluster)

aws ecs create-cluster --cluster-name my-cluster

2. 태스크 정의 (Task Definition)

{
  "family": "my-app",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "256",
  "memory": "512",
  "containerDefinitions": [
    {
      "name": "my-app",
      "image": "123456789012.dkr.ecr.us-east-1.amazonaws.com/my-app:v1",
      "portMappings": [
        {
          "containerPort": 8000,
          "protocol": "tcp"
        }
      ],
      "environment": [
        {"name": "ENV", "value": "production"}
      ],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/my-app",
          "awslogs-region": "us-east-1",
          "awslogs-stream-prefix": "ecs"
        }
      }
    }
  ]
}

aws ecs register-task-definition \
  --cli-input-json file://task-definition.json

3. 서비스 (Service)

aws ecs create-service \
  --cluster my-cluster \
  --service-name my-service \
  --task-definition my-app:1 \
  --desired-count 3 \
  --launch-type FARGATE \
  --network-configuration '{
    "awsvpcConfiguration": {
      "subnets": ["subnet-12345678", "subnet-87654321"],
      "securityGroups": ["sg-12345678"],
      "assignPublicIp": "ENABLED"
    }
  }' \
  --load-balancers '[{
    "targetGroupArn": "arn:aws:elasticloadbalancing:...",
    "containerName": "my-app",
    "containerPort": 8000
  }]'

Launch Types

EC2 Launch Type

[ECS Cluster]
├─ [EC2 Instance] - ECS Agent
│   ├─ Task 1
│   └─ Task 2
└─ [EC2 Instance] - ECS Agent
    ├─ Task 3
    └─ Task 4

• 인스턴스 관리 필요

• 저렴한 비용

• 더 많은 제어

Fargate Launch Type (권장)

[ECS Cluster]
├─ [Fargate Task] (서버 없음)
├─ [Fargate Task]
└─ [Fargate Task]

• 서버 관리 불필요

• 사용한 만큼만 과금

• 간편함

ECS 실습

1. 간단한 웹 앱 배포

# 1. 클러스터 생성
aws ecs create-cluster --cluster-name web-cluster

# 2. Task Definition 등록
cat > task-def.json << EOF
{
  "family": "nginx-app",
  "requiresCompatibilities": ["FARGATE"],
  "networkMode": "awsvpc",
  "cpu": "256",
  "memory": "512",
  "containerDefinitions": [{
    "name": "nginx",
    "image": "nginx:latest",
    "portMappings": [{
      "containerPort": 80
    }]
  }]
}
EOF

aws ecs register-task-definition --cli-input-json file://task-def.json

# 3. 서비스 생성
aws ecs create-service \
  --cluster web-cluster \
  --service-name nginx-service \
  --task-definition nginx-app:1 \
  --desired-count 2 \
  --launch-type FARGATE \
  --network-configuration '{
    "awsvpcConfiguration": {
      "subnets": ["subnet-xxx", "subnet-yyy"],
      "securityGroups": ["sg-xxx"],
      "assignPublicIp": "ENABLED"
    }
  }'

2. ALB와 통합

[ALB]
  ↓ Target Group
[ECS Service]
├─ Task 1 (Dynamic Port)
├─ Task 2 (Dynamic Port)
└─ Task 3 (Dynamic Port)

• ECS가 자동으로 포트 할당

• ALB가 자동으로 라우팅

3. Auto Scaling

# Service Auto Scaling 설정
aws application-autoscaling register-scalable-target \
  --service-namespace ecs \
  --resource-id service/web-cluster/nginx-service \
  --scalable-dimension ecs:service:DesiredCount \
  --min-capacity 2 \
  --max-capacity 10

# 스케일링 정책 (CPU 기반)
aws application-autoscaling put-scaling-policy \
  --service-namespace ecs \
  --resource-id service/web-cluster/nginx-service \
  --scalable-dimension ecs:service:DesiredCount \
  --policy-name cpu-scaling \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration '{
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ECSServiceAverageCPUUtilization"
    },
    "TargetValue": 70.0
  }'

Amazon EKS (Elastic Kubernetes Service)

[EKS Control Plane] (AWS 관리)
    ↓
[Worker Nodes]
├─ [EC2] 또는 [Fargate]
├─ Pod (컨테이너)
└─ Pod (컨테이너)

ECS vs EKS

• AWS 전용, 간단함 → ECS

• Kubernetes 경험, 멀티 클라우드 → EKS

EKS 클러스터 생성

# eksctl로 간편 생성
eksctl create cluster \
  --name my-cluster \
  --version 1.28 \
  --region us-east-1 \
  --nodegroup-name standard-workers \
  --node-type t3.medium \
  --nodes 3 \
  --nodes-min 1 \
  --nodes-max 4

# kubectl 설정
aws eks update-kubeconfig \
  --region us-east-1 \
  --name my-cluster

# 확인
kubectl get nodes

Kubernetes 기본

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

---
# service.yaml
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  type: LoadBalancer
  selector:
    app: nginx
  ports:
  - port: 80
    targetPort: 80

# 배포
kubectl apply -f deployment.yaml
kubectl apply -f service.yaml

# 확인
kubectl get pods
kubectl get services

EKS with Fargate

# Fargate 프로파일 생성
eksctl create fargateprofile \
  --cluster my-cluster \
  --name my-app \
  --namespace default

AWS App Runner

[Source Code] → [App Runner] → [Running App]
       또는
[Container Image]

• 인프라 관리 없음

• 자동 스케일링

• HTTPS 자동 설정

• CI/CD 내장

사용

# GitHub 연결로 배포
aws apprunner create-service \
  --service-name my-app \
  --source-configuration '{
    "CodeRepository": {
      "RepositoryUrl": "https://github.com/user/repo",
      "SourceCodeVersion": {
        "Type": "BRANCH",
        "Value": "main"
      },
      "CodeConfiguration": {
        "ConfigurationSource": "API",
        "CodeConfigurationValues": {
          "Runtime": "PYTHON_3",
          "BuildCommand": "pip install -r requirements.txt",
          "StartCommand": "python app.py",
          "Port": "8000"
        }
      }
    }
  }' \
  --instance-configuration '{
    "Cpu": "1 vCPU",
    "Memory": "2 GB"
  }'

실전 시나리오

시나리오 1: 마이크로서비스 아키텍처 (ECS)

[ALB]
├─ /api/users → [ECS Service: User API]
│               ├─ Task 1
│               └─ Task 2
├─ /api/orders → [ECS Service: Order API]
│                ├─ Task 1
│                └─ Task 2
└─ /api/products → [ECS Service: Product API]
                   ├─ Task 1
                   └─ Task 2

각 서비스:
- Fargate Launch Type
- Auto Scaling (CPU 70%)
- CloudWatch Logs

시나리오 2: 배치 처리 (ECS)

[EventBridge] (매일 새벽 2시)
    ↓ 트리거
[ECS Task] (Fargate)
    ├─ S3에서 데이터 읽기
    ├─ 데이터 처리
    └─ 결과를 S3에 저장
    ↓ 완료 후 자동 종료

시나리오 3: 하이브리드 (EKS)

[EKS Cluster]
├─ [Fargate Pods] - Stateless 앱
│   ├─ Web Frontend
│   └─ API Gateway
└─ [EC2 Nodes] - Stateful 앱
    ├─ Database (StatefulSet)
    └─ Caching (Redis)

모범 사례

1. 이미지 최적화

# ❌ 나쁜 예: 큰 이미지
FROM ubuntu:latest
RUN apt-get update && apt-get install -y python3

# ✅ 좋은 예: 작은 이미지
FROM python:3.9-slim

# 멀티 스테이지 빌드
FROM node:16 AS build
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build

FROM nginx:alpine
COPY --from=build /app/dist /usr/share/nginx/html

2. 헬스 체크

{
  "containerDefinitions": [{
    "healthCheck": {
      "command": ["CMD-SHELL", "curl -f http://localhost/health || exit 1"],
      "interval": 30,
      "timeout": 5,
      "retries": 3,
      "startPeriod": 60
    }
  }]
}

3. 로깅

{
  "logConfiguration": {
    "logDriver": "awslogs",
    "options": {
      "awslogs-group": "/ecs/my-app",
      "awslogs-region": "us-east-1",
      "awslogs-stream-prefix": "ecs"
    }
  }
}

4. 시크릿 관리

{
  "secrets": [
    {
      "name": "DB_PASSWORD",
      "valueFrom": "arn:aws:secretsmanager:region:account:secret:db-password"
    }
  ]
}

비용 최적화

ECS Fargate

비용 요소:
- vCPU: $0.04048/시간
- 메모리: $0.004445/GB/시간

예시 (0.25 vCPU, 0.5GB):
- 시간당: ~$0.012
- 월간 (24/7): ~$9

최적화:
1. 적절한 크기 선택
2. Spot Fargate (70% 할인)
3. Savings Plans

EKS

비용:
- Control Plane: $0.10/시간 (~$73/월)
- Worker Nodes: EC2 비용

최적화:
1. Fargate for Kubernetes (관리 불필요)
2. Spot Instances (Worker Nodes)
3. Cluster Autoscaler

Spot 활용

# ECS Fargate Spot
aws ecs create-service \
  --capacity-provider-strategy '[
    {
      "capacityProvider": "FARGATE_SPOT",
      "weight": 2
    },
    {
      "capacityProvider": "FARGATE",
      "weight": 1
    }
  ]'

AWS Snow Family - 물리적 데이터 전송

100TB를 인터넷으로 전송:
- 100Mbps: 120일 소요
- 비용: 매우 높음

Snow 디바이스:
- 전체 과정: 1주일
- 비용: 훨씬 저렴

제품 비교

선택 가이드

< 10TB → Snowcone
10-80TB → Snowball Edge
> 80TB → Snowmobile

엣지 컴퓨팅 필요 → Snowball Edge Compute Optimized

Amazon FSx - 관리형 파일 시스템

1. FSx for Windows File Server

• SMB 프로토콜

• Active Directory 통합

• Windows ACL

# 생성
aws fsx create-file-system \
  --file-system-type WINDOWS \
  --storage-capacity 300 \
  --subnet-ids subnet-12345678

2. FSx for Lustre

• 초고성능 (수백 GB/s)

• S3와 자동 동기화

• Linux 전용

# S3 연동
aws fsx create-file-system \
  --file-system-type LUSTRE \
  --storage-capacity 1200 \
  --lustre-configuration '{
    "ImportPath": "s3://my-data-bucket/",
    "DeploymentType": "PERSISTENT_1"
  }'

FSx 선택

Windows 애플리케이션 → FSx for Windows
HPC/ML 학습 → FSx for Lustre
엔터프라이즈 NAS → FSx for NetApp ONTAP

Storage Gateway - 하이브리드 클라우드

1. File Gateway

온프레미스 앱 (NFS/SMB)
    ↓
[File Gateway]
    ├─ 로컬 캐시
    ↓
[S3] - 모든 데이터

2. Volume Gateway

• 전체 데이터 온프레미스

• S3에 비동기 백업

• 전체 데이터 S3

• 자주 쓰는 데이터만 로컬

3. Tape Gateway

# File Gateway 생성
aws storagegateway create-gateway \
  --gateway-name my-gateway \
  --gateway-type FILE_S3

DataSync - 자동 데이터 전송

주요 특징

• 최대 10 Gbps 속도

• 증분 전송 (변경분만)

• 메타데이터/권한 보존

• 스케줄링 가능

설정

# 1. Agent 배포 (온프레미스)
aws datasync create-agent \
  --activation-key ABCD-1234

# 2. 위치 생성
aws datasync create-location-nfs \
  --server-hostname 192.168.1.100 \
  --subdirectory /data

aws datasync create-location-s3 \
  --s3-bucket-arn arn:aws:s3:::my-bucket

# 3. 작업 생성 (매일 새벽 2시)
aws datasync create-task \
  --source-location-arn arn:...:location/src \
  --destination-location-arn arn:...:location/dest \
  --schedule 'cron(0 2 * * ? *)'

DataSync vs Storage Gateway

실전 시나리오

시나리오 1: 온프레미스 → AWS 마이그레이션

1. Snowball Edge × 3대 주문 (80TB씩)
2. 병렬 복사
3. 반송 → S3 업로드
4. DataSync로 증분 동기화
5. Cutover

비용: ~$1,000
시간: 2주

시나리오 2: 하이브리드 파일 공유

[온프레미스]
└─ File Gateway (로컬 캐시 10TB)
    ↓
[S3] (전체 100TB)
    ↓ Lifecycle
[Glacier] (1년 후)

월 비용: ~$2,400

시나리오 3: ML 학습

[S3] (1PB 데이터셋)
    ↓ DataSync
[FSx for Lustre] (100TB 캐시)
    ↓ 수백 GB/s
[EC2 GPU 클러스터]
    ↓
학습 시간: 10시간 → 1시간 (90% 단축)

서비스 선택 가이드

데이터 전송

< 10TB, 좋은 인터넷 → DataSync
10-100TB → Snowball
> 100TB → Snowmobile

파일 시스템

Windows 애플리케이션 → FSx for Windows
HPC/ML → FSx for Lustre
Linux 공유 파일 시스템 → EFS
하이브리드 액세스 → Storage Gateway

스토리지 타입

블록 스토리지 → EBS (EC2), Storage Gateway Volume
파일 스토리지 → EFS, FSx, Storage Gateway File
객체 스토리지 → S3

핵심 포인트

• 대용량 데이터는 물리적 전송이 빠르고 저렴

• Snowcone(14TB) → Snowball(80TB) → Snowmobile(100PB)

• Windows → FSx for Windows

• HPC/ML → FSx for Lustre (S3 연동)

• 하이브리드 클라우드의 핵심

• File Gateway (일상 접근) vs DataSync (마이그레이션)

• 자동화된 동기화

• 온프레미스 ↔ AWS, AWS ↔ AWS

비용 최적화 팁

1. 적절한 전송 방법 선택
• 100TB 인터넷 전송: $9,000
• DataSync: $1,250
• Snowball: $900

2. FSx 배포 타입
• Lustre Scratch: 저렴, 임시 처리
• Lustre Persistent: 비쌈, 장기 워크로드

3. Storage Gateway 캐시
• 캐시 히트율 80% 이상 유지
• 자주 쓰는 데이터만 로컬에

4. S3 Lifecycle 연동
• Storage Gateway → S3 → Glacier
• 자동 아카이빙으로 비용 절감