컨테이너

컨테이너가 해결하는 문제

컨테이너는 애플리케이션과 그 실행에 필요한 라이브러리를 하나의 이미지로 묶습니다. 같은 이미지가 개발 노트북에서도 운영 환경에서도 같은 방식으로 실행되므로, "내 환경에서는 되는데"라는 문제가 배포 단계에서 사라집니다.

그러나 이미지를 만드는 것과 수십 개의 컨테이너를 여러 서버에 배치하고 상태를 유지하는 것은 전혀 다른 일입니다. 어느 서버에 몇 개를 띄울지, 죽으면 어디에 다시 띄울지, 새 버전을 어떻게 무중단으로 교체할지를 관리하는 것이 오케스트레이션이고, AWS에서 그 역할을 하는 서비스가 Amazon ECS와 Amazon EKS입니다.

Amazon ECS — 구성요소와 시작 유형

클러스터 · 태스크 정의 · 태스크 · 서비스

태스크를 한 번만 실행하고 끝내는 배치 작업이라면 서비스가 필요 없습니다. 반대로 항상 떠 있어야 하는 웹 애플리케이션은 서비스로 만들어야 장애 시 자동 복구와 로드 밸런서 연동이 동작합니다.

EC2 시작 유형과 AWS Fargate SAA 빈출

같은 태스크 정의를 두 방식으로 실행할 수 있습니다. AWS API 문서는 EC2 시작 유형이 "클러스터에 등록된 Amazon EC2 인스턴스에서 태스크를 실행"하고, Fargate 시작 유형이 "Fargate 온디맨드 인프라에서 태스크를 실행"한다고 설명합니다. 차이는 기능이 아니라 누가 인스턴스를 책임지는가입니다.

네트워크 모드

태스크 정의의 networkMode가 컨테이너의 네트워크 방식을 정합니다. AWS API 문서는 지정하지 않으면 기본값이 bridge이며, Fargate에서는 awsvpc가 필수라고 명시합니다.

awsvpc 모드의 태스크는 VPC 안의 리소스와 같은 방식으로 통신하므로 보안 그룹과 서브넷 설계가 3장 VPC 네트워킹 기초의 규칙을 그대로 따릅니다. 프라이빗 서브넷에 둔 태스크가 인터넷으로 나가야 하면 NAT 게이트웨이가, AWS 서비스에만 접근하면 되면 VPC 엔드포인트가 필요합니다.

서비스 스케줄링 전략

서비스에는 두 가지 스케줄링 전략이 있습니다.

• REPLICA — 원하는 개수만큼의 태스크를 클러스터 전체에 배치하고 유지합니다. AWS 문서는 기본적으로 가용 영역에 걸쳐 태스크를 분산한다고 명시합니다. 다중 가용 영역 배치가 기본 동작이라는 뜻이며, 이것이 컨테이너 워크로드의 고가용성 기반입니다.
• DAEMON — 배치 제약을 만족하는 모든 컨테이너 인스턴스에 정확히 하나씩 배포합니다. 로그 수집이나 모니터링 에이전트처럼 노드마다 하나가 필요한 워크로드에 씁니다. 원하는 개수를 지정하지 않고, 서비스 오토스케일링도 쓰지 않습니다.

aws ecs create-service \
  --cluster app-cluster \
  --service-name web \
  --task-definition web:7 \
  --desired-count 4 \
  --launch-type FARGATE \
  --network-configuration 'awsvpcConfiguration={
      subnets=[subnet-0123456789abcdef0,subnet-0abcdef1234567890],
      securityGroups=[sg-0123456789abcdef0],
      assignPublicIp=DISABLED}' \
  --health-check-grace-period-seconds 60

--health-check-grace-period-seconds는 태스크가 처음 시작된 뒤 로드 밸런서와 컨테이너 상태 확인 실패를 무시하는 기간입니다. 지정하지 않으면 기본값은 0이므로, 부팅이 느린 애플리케이션은 준비되기도 전에 비정상으로 판정되어 반복해서 교체될 수 있습니다.

태스크 역할과 태스크 실행 역할 SAA 빈출

이름이 비슷해서 가장 많이 혼동되는 지점이고, 그래서 시험이 자주 노립니다. 두 역할은 서로 다른 주체가 서로 다른 시점에 씁니다.

{
  "family": "web",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "512",
  "memory": "1024",
  "taskRoleArn": "arn:aws:iam::123456789012:role/WebTaskRole",
  "executionRoleArn": "arn:aws:iam::123456789012:role/WebTaskExecutionRole",
  "containerDefinitions": [
    {
      "name": "web",
      "image": "123456789012.dkr.ecr.ap-northeast-2.amazonaws.com/web:1.4.0",
      "essential": true,
      "portMappings": [{ "containerPort": 8080, "protocol": "tcp" }],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/web",
          "awslogs-region": "ap-northeast-2",
          "awslogs-stream-prefix": "ecs"
        }
      }
    }
  ]
}

Amazon ECR — 이미지 레지스트리

Amazon Elastic Container Registry(ECR)는 컨테이너 이미지를 저장하는 관리형 레지스트리입니다. ECS · EKS와 같은 계정 · 리전 안에 있으므로 이미지를 받아오는 경로가 짧고, 접근 제어를 IAM으로 통일할 수 있습니다.

서비스 오토스케일링과 로드 밸런서 연동

서비스 오토스케일링

ECS 서비스의 태스크 개수는 Application Auto Scaling이 조절합니다. 조절 대상(확장 가능 차원)은 ecs:service:DesiredCount이며, 정책 유형은 대상 추적 · 단계별 · 예측이 있습니다. Auto Scaling 그룹과 개념이 같으므로 7장 로드 밸런싱과 오토스케일링에서 배운 판단이 그대로 적용됩니다.

여기서 EC2 시작 유형에는 확장 축이 두 개라는 점이 중요합니다.

• 태스크 개수 — 서비스 오토스케일링이 조절합니다.
• 컨테이너 인스턴스 개수 — Auto Scaling 그룹이나 용량 공급자가 조절합니다. 태스크를 늘리려 해도 인스턴스에 빈 자리가 없으면 태스크는 대기 상태로 남습니다.

Fargate에는 두 번째 축이 없습니다. 태스크 개수만 조절하면 끝입니다. 이것이 "운영 부담이 적다"는 말의 구체적인 내용입니다.

aws application-autoscaling register-scalable-target \
  --service-namespace ecs \
  --scalable-dimension ecs:service:DesiredCount \
  --resource-id service/app-cluster/web \
  --min-capacity 4 \
  --max-capacity 40

aws application-autoscaling put-scaling-policy \
  --service-namespace ecs \
  --scalable-dimension ecs:service:DesiredCount \
  --resource-id service/app-cluster/web \
  --policy-name cpu-target-50 \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration file://target-tracking.json

Application Load Balancer 연동

서비스에 로드 밸런서를 붙이면 태스크가 뜨고 질 때마다 대상 그룹에 자동으로 등록되고 해제됩니다. AWS 문서는 로드 밸런서를 쓰는 서비스의 태스크는 실행 중이면서 로드 밸런서가 정상으로 보고할 때만 정상으로 간주된다고 명시합니다.

로드 밸런서 세 종류의 계층과 프로토콜 차이는 7장에서 정리했습니다.

Amazon EKS — 관리형 Kubernetes

컨트롤 플레인과 노드

EKS는 Kubernetes 컨트롤 플레인을 관리형으로 제공합니다. AWS API 문서는 컨트롤 플레인이 AWS가 관리하는 계정에서 실행되고, 여러 가용 영역에 걸쳐 프로비저닝되며 Network Load Balancer가 앞에 놓인다고 설명합니다. 노드는 우리 계정에서 실행되며 컨트롤 플레인에 연결됩니다.

즉 EKS에서도 컴퓨팅 계층의 선택은 남아 있습니다. 관리형 노드 그룹으로 EC2 인스턴스를 쓰거나, Fargate 프로파일을 만들어 파드를 Fargate에서 실행합니다. Fargate 프로파일은 선택기(selector)로 어떤 파드를 Fargate에서 실행할지 선언하며, AWS 문서는 프로파일마다 선택기를 최대 5개까지 둘 수 있고 각 선택기에 네임스페이스가 필수라고 명시합니다.

언제 ECS 대신 EKS인가

ECS · EKS · Fargate · Lambda — 선택 기준 SAA 빈출

이 판단은 두 단계로 나누면 흔들리지 않습니다. 먼저 "컨테이너가 필요한가 함수로 충분한가"를 가르고, 그다음 "무엇이 오케스트레이션하고 어디에 올릴 것인가"를 정합니다.

흔한 오해

시험 포인트 정리

확인 문제

이 장의 핵심을 확인하는 10문항입니다. 키보드만으로 완주할 수 있습니다 — 숫자키 1~5로 선택지를 고르고 Enter로 제출합니다.

학습용 유형 연결형과 순서 배열 문항이 섞여 있을 수 있습니다. 이 두 유형은 암기 확인에 효율이 좋아 기본개념 확인 문제에만 넣었으며, 실제 SAA-C03 시험에는 출제되지 않습니다.

이어서 볼 곳

• 12장 · 서버리스와 애플리케이션 통합 컨테이너 대신 함수를 고르는 기준과, 컨테이너 앞뒤에 놓이는 큐와 이벤트 버스를 다룹니다. 기본개념 · SAA 최우선
• 7장 · 로드 밸런싱과 오토스케일링 서비스에 붙이는 로드 밸런서의 선택 기준과 스케일링 정책이 여기 있습니다. 컨테이너에도 그대로 적용됩니다. 기본개념 · SAA 최우선
• 2장 · IAM과 자격 증명 태스크 역할이 왜 액세스 키보다 나은지, 신뢰 정책이 어떻게 생겼는지의 근거입니다. 기본개념 · SAA 최우선
• 실습 9 · ECS Fargate 서비스 배포 태스크 정의와 두 역할의 분리, 서비스 오토스케일링을 직접 구성해 봅니다. 실습
• 복원력 있는 아키텍처 설계 (26%) 다중 가용 영역 배치와 상태 비저장 설계라는 전제가 컨테이너에서도 같다는 점을 확인합니다. 시험 대비
• 서비스 빠른참조 ECS · EKS · Fargate · ECR의 한 줄 정의와 선택 기준을 다른 서비스와 나란히 놓고 봅니다. 빠른참조

공식 문서 출처

이 장의 동작 서술은 모두 아래 문서에서 확인했습니다.

• Amazon ECS 개발자 안내서 — 애플리케이션 아키텍처 — 클러스터 · 태스크 정의 · 태스크 · 서비스의 관계
• Amazon ECS 개발자 안내서 — 시작 유형 — EC2 시작 유형과 Fargate 시작 유형의 차이
• Amazon ECS 개발자 안내서 — AWS Fargate — Fargate가 서버리스 컴퓨팅 엔진이라는 정의
• Amazon ECS 개발자 안내서 — Fargate 용량 공급자 — Fargate Spot을 쓰려면 용량 공급자 전략이 필요하다는 서술
• Amazon ECS API 레퍼런스 — CreateService — REPLICA 전략이 기본적으로 가용 영역에 걸쳐 분산한다는 서술, DAEMON 전략의 동작, 상태 확인 유예 기간의 기본값 0
• Amazon ECS API 레퍼런스 — RegisterTaskDefinition — taskRoleArn과 executionRoleArn의 정의, networkMode의 기본값과 Fargate의 awsvpc 요구
• Amazon ECS 개발자 안내서 — 태스크의 IAM 역할 — 컨테이너 안의 코드가 쓰는 권한이라는 점
• Amazon ECS 개발자 안내서 — 태스크 실행 IAM 역할 — ECS 에이전트가 이미지를 받고 로그를 보낼 때 쓰는 권한이라는 점
• Amazon ECS 개발자 안내서 — 태스크 네트워킹 — awsvpc 모드에서 태스크마다 네트워크 인터페이스가 할당된다는 서술
• Amazon ECS 개발자 안내서 — 서비스 로드 밸런싱 — 대상 그룹 등록과 로드 밸런서 상태 확인이 태스크의 정상 판정에 쓰인다는 서술
• Amazon ECS 개발자 안내서 — 서비스 오토스케일링 — Application Auto Scaling이 서비스의 원하는 태스크 개수를 조절한다는 서술
• Amazon ECR 사용 설명서 — 리포지토리 — 이미지 저장 단위와 접근 제어
• Amazon ECR 사용 설명서 — 수명 주기 정책 — 오래되거나 태그 없는 이미지를 자동으로 정리하는 규칙
• Amazon ECR 사용 설명서 — 이미지 스캔 — 취약점 검사 동작
• Amazon ECR 사용 설명서 — 리포지토리 정책 — 다른 계정에 풀 권한을 부여하는 리소스 기반 정책
• Amazon EKS 사용 설명서 — 클러스터 기능 — 컨트롤 플레인이 AWS 관리 계정에서 여러 가용 영역에 걸쳐 실행되고 노드는 고객 계정에서 실행된다는 구조
• Amazon EKS 사용 설명서 — Fargate 프로파일 — 선택기로 파드를 Fargate에 배치하는 방식과 파드 실행 역할
• Amazon EKS 사용 설명서 — 관리형 노드 그룹 — 노드를 EC2 인스턴스로 운영하는 방식