본문 바로가기
Cloud Native/AWS: Architecture

16. AWS의 컨테이너 : ECS, Fargate, ECR 및 EKS

by jys275 2025. 9. 8.

 

 

Docker 소개

 

 

애플리케이션을 여러 개 배포하려고 할 때 : 컨테이너 기술을 활용하면 운영체제/환경에 상관없이 동일한 방식으로 실행 가능 : 호환성 문제를 해결하고 유지보수를 단순화 : 특히 마이크로서비스 아키텍처와 잘 맞음

Docker란?
소프트웨어 개발 플랫폼 : 앱을 '컨테이너'라는 단위로 패키징 : 컨테이너 특징 : 어떤 OS에서도 실행 가능 : 예측 가능 → 동작이 일정해 운영 부담 감소 : 언어/OS/기술에 독립적 : 사용 사례 : 마이크로서비스 아키텍처 : 온프레미스 → 클라우드 마이그레이션 (Lift & Shift) : 어디서든 컨테이너 실행

Docker 동작 방식
서버(예: EC2 인스턴스) 위에서 Docker Agent를 실행하면 : 도커 컨테이너 시작 가능 : 다수의 컨테이너 동시 실행 가능 : 예 : Java 앱 컨테이너 + Node.js 앱 컨테이너 : 심지어 MySQL 같은 DB도 컨테이너에서 실행 가능 : 서버 관점 : 전부 동일한 컨테이너 프로세스로 보임 : 서버 관점에선 모두 도커 컨테이너로 보임

Docker 이미지와 저장소
컨테이너 실행 = Docker 이미지 기반 : 이미지 저장 위치?

- Docker Hub : 퍼블릭 저장소 (Ubuntu, MySQL 등 기본 이미지 존재)

- Amazon ECR : 프라이빗 저장소, 퍼블릭 갤러리도 제공

Docker vs 가상 머신
- 가상 머신(VM) : 인프라 → Host OS → Hypervisor → Guest OS → App : 각 VM은 독립적 → 보안 강력하지만 무겁고 리소스 많이 사용 : 즉, EC2의 원리임 : 다시 말해 EC2 머신은 하이퍼바이저에 실행되는 가상 머신과도 같음 : 그래서 Amazon이 EC2 인스턴스를 다양한 소비자에게 제공할 수 있으며 가상 머신의 EC2 인스턴스는 각자 분리되어 있음 : 리소스를 공유하지 않는 것

- Docker 컨테이너 : 인프라 → Host OS → Docker Daemon → Containers : Host OS 리소스 공유 → 가벼움, 빠른 배포 : VM보다 덜 안전하지만 밀집 실행 가능

Dockerfile → Image → Container
Dockerfile 작성 → Build → Docker Image 생성 : 이미지를 Repository(Docker Hub, Amazon ECR)에 Push : 필요할 때 Pull 받아 실행 → Container가 됨 : 컨테이너 실행 시, Dockerfile에 정의된 코드 동작

AWS에서의 Docker 관리
Amazon ECS (Elastic Container Service) : AWS의 전용 Docker 관리 서비스
Amazon EKS (Elastic Kubernetes Service) : 관리형 Kubernetes (오픈소스)
AWS Fargate : 서버리스 컨테이너 실행 (ECS/EKS와 연계)
Amazon ECR : 컨테이너 이미지 저장소

요약
Docker = 경량화된 컨테이너 플랫폼 : 호환성·배포 용이성 극대화 : AWS에서는 ECS, EKS, Fargate, ECR로 관리·저장·실행

 

 

 

 

Amazon ECS

 

 

 

애플리케이션을 여러 개 배포하려고 할 때 : 컨테이너를 관리할 수 있는 플랫폼 필요 : AWS는 Amazon ECS (Elastic Container Service)를 제공 : 컨테이너 실행 방식(EC2 vs Fargate), IAM 역할, 로드밸런서, 데이터 지속성까지 전반적으로 이해해야 함

 

ECS 시작 유형 (Launch Types) - EC2 Launch Type

인프라 : EC2 시작 유형으로 EC2 클러스터를 사용할 때는 인프라를 직접 프로비저닝하고 유지해야 함 : 즉, Amazon ECS 및 ECS 클러스터가 여러 EC2 인스턴스로 구성되겠지 : 이때 ECS 인스턴스는 특별하게 각각 ECS 에이전트(Agent)를 실행해야 함 : ECS Agent가 각각의 EC2 인스턴스를 Amazon ECS 서비스와 지정된 ECS 클러스터에 등록함 : 이후에 ECS 태스크를 수행하기 시작하면 AWS가 컨테이너를 시작하거나 멈출 것 : ECS 태스크 실행 시 : 컨테이너가 EC2 인스턴스에 지정되는 것

  • 장점 : 인프라 제어 가능
  • 단점 : 관리 부담 (EC2 프로비저닝, 패치, 확장 등)

ECS 시작 유형 (Launch Types) - Fargate Launch Type

인프라를 프로비저닝하지 않아 서버리스 방식 : 인프라 관리 불필요 : 관리할 EC2 인스턴스가 없음 : 태스크 정의에서 CPU, RAM만 지정하면 → AWS가 ECS 태스크를 자동으로 실행

  • 확장 시 : 단순히 태스크 개수만 늘리면 됨
  • 포인트 : 서버리스 : 컨테이너 실행은 Fargate

ECS IAM 역할

1. EC2 Instance Profile

  • ECS를 EC2 Launch Type으로 실행할 때 필요(Fargate는 아님)
  • EC2 인스턴스 위에서 돌아가는 ECS Agent만이 사용함
  • ECR 이미지 Pull, CloudWatch Logs 전송, Secrets Manager/SSM Parameter Store 접근
  • 즉, 인스턴스 자체 운영에 필요한 권한을 주는 것

2. ECS Task Role

  • 태스크별로 지정 (EC2든 Fargate든 모두 가능)
  • 예 : Task A → S3 접근 : Task B → DynamoDB 접근
  • 태스크마다 다른 권한 설정 가능
  • 즉, 컨테이너 안에서 실행되는 애플리케이션이 AWS 리소스에 접근할 때 쓰는 권한

ECS와 로드 밸런서 통합

  • ALB (Application Load Balancer) : 기본 옵션, HTTP/HTTPS 엔드포인트에 적합, Fargate와 호환
  • NLB (Network Load Balancer) : 초고성능, 고처리량, PrivateLink 연계 시 사용
  • ELB (Classic) : 구세대, 기능 부족, Fargate 미지원 → 권장되지 않음

ECS 데이터 지속성

ECS 태스크에 영구 스토리지가 필요할 경우 : Amazon EFS 사용 : 장점 : EC2 & Fargate 모두 지원 : 다중 AZ에서 공유 가능 : 서버리스 방식 → 관리 불필요 : 사용 사례 : 여러 ECS 태스크 간 공유 파일 시스템 필요할 때 : 주의 : Amazon S3는 ECS 태스크에 파일 시스템처럼 마운트 불가

 

요약

  • ECS Launch Type : EC2 (직접 관리) vs Fargate (서버리스)
  • IAM 역할 : EC2 Instance Profile vs Task Role 구분
  • 로드밸런서 : ALB가 일반적, NLB는 특수 상황, ELB는 비권장
  • 데이터 지속성 : EFS 활용 (S3는 마운트 불가)

 

 

Amazon ECS - 오토 스케일링

 

 

배경
애플리케이션을 여러 개 배포하려고 할 때 : 트래픽이 일정하지 않음 : 낮은 부하 시 비용 절감, 높은 부하 시 성능 확보 필요 : ECS 서비스는 오토 스케일링(Auto Scaling)으로 자동 확장 및 축소 가능

 

ECS 서비스 오토 스케일링 핵심

자동 확장 대상 지표 (3가지)

  1. CPU 사용률
  2. 메모리 사용률 (RAM)
  3. ALB 지표 (타겟당 요청 수)

스케일링 방식

  • 대상 추적 스케일링(Target Tracking Scaling) : 특정 지표를 목표값으로 유지 (예: CPU 50%)
  • 단계 스케일링(Step Scaling) : 지표 변화 폭에 따라 단계적으로 확장/축소
  • 예약 스케일링(Scheduled Scaling) : 특정 시간/예약된 패턴에 맞춰 확장/축소

시작 유형별 차이

  1. Fargate 시작 유형
    서버리스 방식 → EC2 인스턴스 관리 불필요 : 오토 스케일링은 태스크 수 조정만 하면 됨
    포인트 : Fargate = 관리 부담 X, 오토 스케일링 간단
  2. EC2 시작 유형
    태스크 확장과 EC2 클러스터 확장은 별개 : 백엔드에 EC2 인스턴스가 부족하면 태스크가 실행되지 못하게 되겠지

EC2 확장 방법

  1. Auto Scaling Group (ASG)
    CPU 사용률 등 지표에 따라 EC2 인스턴스 자동 추가 : 전통적 방식
  2. ECS Capacity Provider (추천)
    ASG와 연계 → ECS가 자동으로 클러스터 확장 : 새 태스크 실행에 필요한 CPU/RAM이 부족하면 즉시 EC2 인스턴스 추가 : 더 지능적이고 최신 방식

동작 예시
서비스 A : 태스크 2개 실행 중 : 갑자기 트래픽 급증 → CPU 사용률 상승 : CloudWatch 지표가 상승 감지 → CloudWatch 알람 발동 : 알람이 ECS 오토 스케일링 트리거 → ECS 서비스 희망 용량 증가 → 새 태스크 생성 : 만약 EC2 시작 유형일 경우 : Capacity Provider가 EC2 인스턴스를 자동으로 확장

 

요약
오토 스케일링 핵심 지표 : CPU, 메모리, ALB 타겟당 요청 수
Fargate : 서버리스, 태스크 확장만 신경 쓰면 됨
EC2 시작 유형 : Capacity Provider로 클러스터 확장 추천
CloudWatch + Auto Scaling = ECS 서비스 확장 트리거

 

 

Amazon ECS - 솔루션 아키텍트

 

 

배경
애플리케이션을 여러 개 배포하려고 할 때 : 단순히 컨테이너 실행만이 아니라 이벤트 기반 처리, 스케줄링, 메시지 큐 통합 등 다양한 시나리오 필요 : ECS는 EventBridge, SQS 등과 함께 아키텍처를 구성할 수 있음 : 아키텍쳐 패턴은 아래와 같음

 

1. EventBridge에 의해 호출된 ECS 태스크

  • 구성 : S3 버킷 + EventBridge 규칙 + ECS(Fargate) + DynamoDB
  • 동작 : 사용자가 S3에 객체 업로드 → EventBridge가 이벤트 캡처 → ECS 태스크 실행 → 컨테이너가 S3 객체를 처리 후 DynamoDB에 결과 저장
  • 특징 : 완전 서버리스 아키텍처, ECS 태스크 역할(IAM Role)로 S3 및 DynamoDB 접근 제어

2. EventBridge Schedule을 이용한 아키텍처 (ECS 태스크)

  • 구성 : EventBridge Schedule + ECS(Fargate)
  • 동작 : EventBridge가 1시간마다 규칙 실행 → ECS 클러스터 내 새로운 태스크 실행 → 태스크가 주기적 작업(예: S3 배치 처리) 수행
  • 특징 : 완전 서버리스, 정기적·주기적 작업에 적합

3. SQS Queue에 호출된 ECS 서비스

  • 구성 : SQS Queue + ECS 서비스 + ECS 서비스 오토 스케일링
  • 동작 : 애플리케이션이 SQS Queue에 메시지 전송 → ECS 서비스 태스크가 메시지 수신·처리 → 메시지 양 증가 시 오토 스케일링으로 태스크 수 확장
  • 특징 : 메시지 기반 비동기 처리, 확장성 높음

4. EventBridge를 사용하여 ECS 클러스터 이벤트 모니터링 후 가로채기

  • 구성 : ECS 클러스터 + EventBridge + SNS
  • 동작 : ECS 태스크 상태 변화(STOPPED 등) 발생 → EventBridge 이벤트 생성 → SNS 토픽으로 전달 → 이메일 알림 등 관리자 통보
  • 특징 : ECS 클러스터 라이프사이클 이벤트 추적 및 알림 가능

요약
EventBridge 연계 : 이벤트 기반 태스크 실행, 주기적 작업, ECS 상태 모니터링 가능
SQS 연계 : 메시지 기반 처리 및 오토 스케일링에 적합
ECS 태스크 역할 : S3, DynamoDB 등 AWS 리소스 접근 시 필수
패턴 활용 : 서버리스 데이터 처리, 배치 작업, 메시지 큐 소비, 상태 모니터링 등

 

 

 

 

Amazon ECR

 

 

컨테이너 기반 애플리케이션을 배포하려면 도커 이미지를 안전하게 저장하고 관리할 저장소 필요 : 기존에는 Docker Hub 같은 퍼블릭 저장소 활용 : AWS 환경에서는 Amazon ECR(Elastic Container Registry) 사용

 

핵심 개념

  • Amazon ECR : AWS에서 제공하는 도커 이미지 저장·관리 서비스
  • 저장 방식 : Amazon S3에 백그라운드로 저장
  • IAM 통합 : 모든 접근은 IAM 정책으로 제어

옵션

  • 프라이빗 리포지토리 : 계정 단위 혹은 여러 계정 공유 가능
  • 퍼블릭 리포지토리 : Amazon ECR Public Gallery를 통해 공개 배포

ECS와의 통합

Amazon ECS와 완전 통합 : EC2 인스턴스에서 도커 이미지를 끌어오기 위해 IAM 역할 부여 필요 : 이미지 pull 후 컨테이너 실행 : ECS에서 컨테이너를 실행하고 싶읃데, 기존에 Docker Hub에서 사용하고 있던 이미지를 계속해서 가져와서 사용하고 싶을 때 매우 효율적 : 이를 통해 애플리케이션의 배포와 관리를 간소화할 수 있음

Was this content relevant to you?

부가 기능

이미지 취약점 스캐닝 지원 : 버저닝 및 태그 관리 : 수명 주기 정책으로 이미지 관리 자동화

 

요약
Amazon ECR은 AWS 환경에서 안전하고 효율적으로 도커 이미지를 저장·관리할 수 있는 서비스 : ECS와 원활히 연동되며 IAM으로 보안 제어 : 시험 대비 포인트로 반드시 기억

 

 

 

 

Amazon EKS

 

 

컨테이너 실행을 자동화하고 확장·관리하기 위한 오픈 소스 플랫폼 Kubernetes : 여러 클라우드 제공자가 사용하므로 표준화 기대 가능 : AWS에서는 Amazon EKS(Elastic Kubernetes Service)로 관리형 Kubernetes 클러스터 제공

 

핵심 개념

  • Amazon EKS : 관리형 Kubernetes 서비스
  • 컨테이너 실행 목적은 ECS와 유사하지만 API가 다름
  • ECS : AWS 독자 서비스 / EKS : 오픈 소스 Kubernetes 기반

실행 모드

  • EC2 시작 모드 : EC2 인스턴스에 작업자 노드를 배포
  • Fargate 모드 : 서버리스 방식으로 컨테이너 실행, 노드 관리 불필요

사용 사례

  • 기업이 온프레미스나 클라우드에서 Kubernetes API 사용 중일 때 클러스터 관리 목적으로 EKS 사용
  • Kubernetes는 클라우드 애그노스틱으로 Azure, Google Cloud 등 모든 클라우드에서 지원됨 : 따라서 클라우드 또는 컨테이너 간 마이그레이션을 실행하는 경우 Amazon EKS가 간단한 솔루션이 될 수 있음

노드 유형

  • 관리형 노드 그룹 : AWS가 EC2 노드 및 오토 스케일링 그룹 관리, 온디맨드 및 스팟 인스턴스 지원
  • 자체 관리형 노드 : 사용자가 직접 생성·관리, 제어 범위 넓음, EKS 최적화 AMI 사용 가능
  • Fargate 모드 : 노드 불필요, 완전 서버리스

스토리지

  • 컨테이너 스토리지 인터페이스(CSI) 드라이버 사용 : Amazon EKS 클러스터에 데이터 볼륨을 연결하려면 EKS 클러스터에 스토리지 클래스 매니페스트를 지정해야 함 : 컨테이너 스토리지 인터페이스(CSI)라는 규격 드라이버를 활용해야함
  • Amazon EBS 지원
  • Amazon EFS : Fargate 모드와 함께 사용 가능
  • Amazon FSx for Lustre, Amazon FSx for NetApp ONTAP 지원

포인트

  • Kubernetes = 클라우드 애그노스틱, 멀티 클라우드 호환
  • Pod = Kubernetes에서 실행 단위
  • EKS 스토리지 클래스 : CSI, EFS와의 통합

요약
Amazon EKS는 AWS 관리형 Kubernetes 서비스 : EC2 모드와 Fargate 모드 제공 : 멀티 클라우드·하이브리드 환경에서 Kubernetes 기반 애플리케이션 실행에 적합

 

 

 

 

AWS App Runner

 

 

웹 애플리케이션과 API를 빠르게 배포하고 싶은 경우 : 인프라, 컨테이너, 소스 코드 빌드 과정을 몰라도 실행 가능 : 완전 관리형 서비스

 

핵심 개념

  • App Runner : 웹 앱·API 배포 자동화 서비스
  • 입력 : 소스 코드 또는 Docker 컨테이너 이미지
  • 설정 : vCPU, 메모리 크기, 오토 스케일링, 상태 확인 등 기본 옵션만 지정
  • 출력 : 자동으로 컨테이너 생성 및 배포, URL로 바로 액세스 가능

특징

  • 오토 스케일링 지원 : 트래픽에 따라 자동 확장·축소
  • 고가용성 : 서비스 중단 최소화
  • 로드 밸런싱 및 HTTPS 암호화 기본 제공
  • VPC 연결 가능 : 데이터베이스, 캐시, 메시지 큐 서비스와 연동

사용 사례

빠른 프로덕션 배포가 필요한 웹 애플리케이션 : 경량 API 서버 : 마이크로서비스 실행

 

포인트

  • App Runner = 서버리스 웹 앱/API 배포 플랫폼
  • 복잡한 ECS, EKS 설정 불필요
  • 단순하고 빠른 배포 목적에 적합

요약
App Runner는 컨테이너·코드 기반 웹 앱과 API를 자동으로 빌드하고 배포하는 AWS의 완전 관리형 서비스 : 오토 스케일링, 보안, VPC 연결까지 지원 : 빠른 배포에 최적

 

 

AWS App2Container (A2C)

 

 

배경
온프레미스에서 실행 중인 Java 또는 .NET 웹 애플리케이션을 코드 수정 없이 클라우드로 옮기고 싶을 때 : 리프트 앤 시프트 마이그레이션을 자동화하는 CLI 도구

 

핵심 개념

  • App2Container (A2C) : Java·.NET 앱을 Docker 컨테이너로 변환
  • 방식 : 코드 변경 없음 → 기존 앱을 그대로 컨테이너화
  • 산출물 : Docker 이미지, 배포 아티팩트, CloudFormation 템플릿

주요 동작

  • 앱 검색 및 분석 (CLI 사용)
  • 앱을 추출하고 컨테이너화
  • Amazon ECR에 Docker 이미지 저장
  • CloudFormation 템플릿 자동 생성 (컴퓨팅, 네트워크, ECS/EKS/App Runner 정의 포함)
  • ECS, EKS, App Runner로 배포 가능
  • 사전 구축된 CI/CD 파이프라인 지원

포인트

  • 키워드 : Java, .NET 웹 애플리케이션, 리프트 앤 시프트, 컨테이너화, 코드 변경 없음
  • 컨테이너 배포 대상 : ECS, EKS, App Runner
  • 배포 아티팩트 : ECR 이미지 + CloudFormation 템플릿

요약
AWS App2Container는 Java·.NET 웹 애플리케이션을 코드 변경 없이 Docker 컨테이너로 변환해 AWS 클라우드(ECS, EKS, App Runner)에 배포하는 CLI 기반 마이그레이션 도구 : 현대화를 빠르고 간단히 지원

저작자표시 (새창열림)

'Cloud Native > AWS: Architecture' 카테고리의 다른 글

18. 서버리스 솔루션 아키텍처 토론  (0) 2025.09.09
17. 솔루션 설계자 관점의 서버리스 개요  (0) 2025.09.08
15. 디커플링 애플리케이션 : SQS, SNS, Kinesis, Active MQ  (0) 2025.09.04
14. AWS 스토리지 추가 기능  (0) 2025.09.02
13. CloudFront 및 AWS 글로벌 액셀러레이터  (0) 2025.09.02

관련글

티스토리툴바