AWS 클라우드 따라잡기 10장

이번 장은 컨테이너를 다룬다.

AWS 10장 개념도

컨테이너는 애플리케이션과 실행 환경을 하나로 묶는 기술이다.

Docker로 대표되며, "내 컴퓨터에서는 되는데 서버에서는 안 된다"는 문제를 없앤다.

이 장의 목표는 다음과 같다.

컨테이너와 이미지의 개념을 잡는다.
ECR, ECS, Fargate, EKS의 역할을 구분한다.
언제 컨테이너를 선택하는지 안다.

1. 컨테이너란

컨테이너는 앱과 그 앱이 필요로 하는 라이브러리, 설정을 한 상자에 담은 것이다.

어디서 실행하든 똑같이 동작한다.
가상 머신보다 가볍고 빠르게 뜬다.
이미지(image)로 만들어 배포한다.

이미지는 컨테이너의 밑그림이고, 컨테이너는 그 이미지를 실행한 것이다.

(EC2의 AMI-인스턴스 관계와 비슷하다.)

2. ECR — 이미지 저장소

ECR은 Elastic Container Registry의 약자다.

내가 만든 컨테이너 이미지를 저장하는 AWS의 창고다.

Docker Hub의 AWS 버전이라고 보면 된다.

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

# ECR에 로그인하고 푸시
aws ecr get-login-password | docker login --username AWS --password-stdin <계정ID>.dkr.ecr.ap-northeast-2.amazonaws.com
docker tag my-app:latest <계정ID>.dkr.ecr.ap-northeast-2.amazonaws.com/my-app:latest
docker push <계정ID>.dkr.ecr.ap-northeast-2.amazonaws.com/my-app:latest

3. ECS — 컨테이너 오케스트레이션

ECS는 Elastic Container Service의 약자다.

여러 컨테이너를 어디에 얼마나 띄울지 관리(오케스트레이션)한다.

핵심 개념은 다음과 같다.

태스크 정의(Task Definition): 어떤 이미지를, 얼마의 CPU/메모리로 실행할지 적은 청사진.
태스크(Task): 실행 중인 컨테이너 묶음.
서비스(Service): 태스크를 원하는 개수로 유지하고, ALB와 연결한다.

4. Fargate — 서버 없는 컨테이너

ECS로 컨테이너를 돌릴 때, 그것을 실행할 곳을 두 가지 중에 고른다.

EC2 시작 유형: 내가 EC2 인스턴스를 준비하고 그 위에서 컨테이너를 돈다. 세밀한 제어와 비용 최적화가 가능하지만 서버 관리가 필요하다.
Fargate: 서버를 내가 관리하지 않는다. 컨테이너에 필요한 CPU/메모리만 지정하면 AWS가 알아서 실행한다.

Fargate는 컨테이너판 서버리스다.

인스턴스를 신경 쓰기 싫다면 Fargate가 편하다.

5. EKS — 관리형 쿠버네티스

EKS는 Elastic Kubernetes Service의 약자다.

쿠버네티스(Kubernetes)는 컨테이너 오케스트레이션의 업계 표준이다.

ECS는 AWS 전용으로 단순하다.
EKS는 쿠버네티스라 표준적이고 강력하지만 더 복잡하다.

이미 쿠버네티스를 쓰고 있거나 멀티 클라우드를 고려한다면 EKS,

AWS 안에서 단순하게 가고 싶다면 ECS를 고른다.

6. 컴퓨팅 선택 정리

지금까지 배운 컴퓨팅 방식을 비교하면 이렇다.

방식	관리 부담	적합한 경우
EC2	높음	세밀한 제어, 특수 환경
ECS/EKS on EC2	중간	컨테이너 + 비용 최적화
Fargate	낮음	컨테이너 + 서버 관리 회피
Lambda	최소	짧은 이벤트 기반 작업

정답은 없다. 워크로드 성격과 운영 역량으로 고른다.

정리

컨테이너는 앱과 환경을 묶어 어디서나 똑같이 실행한다.
ECR은 이미지 저장소, ECS는 컨테이너 오케스트레이션 서비스다.
Fargate는 서버를 관리하지 않는 컨테이너 실행 방식이다.
표준 쿠버네티스가 필요하면 EKS, 단순하면 ECS를 쓴다.

다음 장에서는 이 모든 인프라를 코드로 관리하는 IaC와 CI/CD를 다룬다.