Fargate용 Amazon ECS 태스크 정의의 차이점

Fargate를 사용하려면 태스크 정의를 Fargate 런치 타입으로 구성해야 해요. 그리고 Fargate를 쓸 때는 몇 가지 추가로 알아둬야 할 사항이 있답니다.

출처: 문서

본문

태스크 정의 파라미터

Fargate를 사용하는 태스크는 Amazon ECS 태스크 정의 파라미터를 전부 지원하지 않아요. 어떤 파라미터는 아예 지원되지 않고, 또 다른 파라미터는 Fargate 태스크에서 다르게 동작합니다.

다음 태스크 정의 파라미터는 Fargate 태스크에서 유효하지 않아요:

disableNetworking
dnsSearchDomains
dnsServers
dockerSecurityOptions
extraHosts
gpu
ipcMode
links
placementConstraints
privileged
maxSwap
swappiness

다음 태스크 정의 파라미터는 Fargate 태스크에서 유효하지만, 알아둬야 할 제한 사항이 있습니다:

linuxParameters – 컨테이너에 적용하는 Linux 전용 옵션을 지정할 때는, capabilities에서 추가할 수 있는 기능이 CAP_SYS_PTRACE뿐이에요. devices, sharedMemorySize, tmpfs 파라미터는 지원되지 않습니다. 자세한 내용은 Linux 파라미터(Linux parameters)를 참고하세요.
volumes – Fargate 태스크는 바인드 마운트 호스트 볼륨만 지원하므로 dockerVolumeConfiguration 파라미터는 지원되지 않아요. 자세한 내용은 볼륨(Volumes)을 참고하세요.
cpu – AWS Fargate의 Windows 컨테이너에서는 값이 1 vCPU보다 작을 수 없습니다.
networkConfiguration – Fargate 태스크는 항상 awsvpc 네트워크 모드를 사용해요.

태스크 정의가 Fargate에서 사용할 수 있도록 검증되게 하려면, 태스크 정의를 등록할 때 다음을 지정할 수 있어요:

AWS Management Console에서 Requires Compatibilities 필드에 FARGATE를 지정합니다.
AWS CLI에서 --requires-compatibilities 옵션을 지정합니다.
Amazon ECS API에서 requiresCompatibilities 플래그를 지정합니다.

운영 체제 및 아키텍처

AWS Fargate용 태스크 정의와 컨테이너 정의를 구성할 때는 컨테이너가 실행될 운영 체제(Operating System) 를 지정해야 해요. AWS Fargate에서 지원하는 운영 체제는 다음과 같습니다:

Amazon Linux 2 — Linux 컨테이너는 호스트 운영 체제의 커널과 커널 구성만 사용해요. 예를 들어 커널 구성에는 sysctl 시스템 컨트롤이 포함됩니다. Linux 컨테이너 이미지는 어떤 Linux 배포판의 파일과 프로그램을 담고 있는 베이스 이미지로 만들 수 있어요. CPU 아키텍처만 맞다면 어떤 Linux 컨테이너 이미지를 어떤 운영 체제에서도 실행할 수 있습니다.
Windows Server 2019 Full
Windows Server 2019 Core
Windows Server 2022 Full
Windows Server 2022 Core

AWS Fargate에서 Windows 컨테이너를 실행할 때는 X86_64 CPU 아키텍처를 사용해야 해요.

AWS Fargate에서 Linux 컨테이너를 실행할 때는 X86_64 CPU 아키텍처나 ARM 기반 애플리케이션용 ARM64 아키텍처를 사용할 수 있습니다. 자세한 내용은 64비트 ARM 워크로드용 Amazon ECS 태스크 정의(Amazon ECS task definitions for 64-bit ARM workloads)를 참고하세요.

태스크 CPU와 메모리

AWS Fargate용 Amazon ECS 태스크 정의는 태스크 수준에서 CPU와 메모리를 지정하도록 요구해요. 대부분의 사용 사례는 태스크 수준에서만 이러한 리소스를 지정하면 충분합니다. 다음 표는 유효한 태스크 수준 CPU와 메모리 조합을 보여줘요. 태스크 정의에서 메모리 값은 MiB 또는 GB 단위의 문자열로 지정할 수 있어요. 예를 들어 메모리 값을 MiB 기준 3072 또는 GB 기준 3 GB로 지정할 수 있죠. CPU 값은 JSON 파일에서 CPU 단위 또는 가상 CPU(vCPU) 단위의 문자열로 지정할 수 있어요. 예를 들어 CPU 값을 CPU 단위 기준 1024 또는 vCPU 기준 1 vCPU로 지정할 수 있습니다.

CPU 값	메모리 값	AWS Fargate 지원 운영 체제
256 (.25 vCPU)	512 MiB, 1 GB, 2 GB	Linux
512 (.5 vCPU)	1 GB, 2 GB, 3 GB, 4 GB	Linux
1024 (1 vCPU)	2 GB, 3 GB, 4 GB, 5 GB, 6 GB, 7 GB, 8 GB	Linux, Windows
2048 (2 vCPU)	4 GB ~ 16 GB (1 GB 단위)	Linux, Windows
4096 (4 vCPU)	8 GB ~ 30 GB (1 GB 단위)	Linux, Windows
8192 (8 vCPU) — 참고: 이 옵션은 Linux 플랫폼 1.4.0 이상이 필요해요.	16 GB ~ 60 GB (4 GB 단위)	Linux
16384 (16 vCPU) — 참고: 이 옵션은 Linux 플랫폼 1.4.0 이상이 필요해요.	32 GB ~ 120 GB (8 GB 단위)	Linux
32768 (32 vCPU) — 참고: 이 옵션은 Linux 플랫폼 1.4.0 이상이 필요해요.	60 GB, 120 GB, 244 GB	Linux

태스크 네트워킹

AWS Fargate용 Amazon ECS 태스크는 각 태스크에 탄력적 네트워크 인터페이스를 제공하는 awsvpc 네트워크 모드를 사용해야 해요. 이 네트워크 모드로 태스크를 실행하거나 서비스를 만들 때는 네트워크 인터페이스를 연결할 서브넷 하나 이상과 네트워크 인터페이스에 적용할 보안 그룹 하나 이상을 지정해야 합니다.

퍼블릭 서브넷을 사용한다면 네트워크 인터페이스에 퍼블릭 IP 주소를 제공할지 결정해야 해요. 퍼블릭 서브넷의 Fargate 태스크가 컨테이너 이미지를 가져오려면 태스크의 탄력적 네트워크 인터페이스에 퍼블릭 IP 주소가 할당되고, 인터넷으로의 라우팅 또는 NAT 게이트웨이로의 라우팅이 있어야 해요. 프라이빗 서브넷의 Fargate 태스크가 컨테이너 이미지를 가져오려면 서브넷에 인터넷으로 요청을 라우팅하는 NAT 게이트웨이가 필요합니다. 컨테이너 이미지를 Amazon ECR에 호스팅하면 Amazon ECR이 인터페이스 VPC 엔드포인트를 사용하도록 구성할 수 있어요. 이 경우 이미지 풀에는 태스크의 프라이빗 IPv4 주소가 사용됩니다. Amazon ECR 인터페이스 엔드포인트에 대한 자세한 내용은 Amazon Elastic Container Registry 사용자 가이드의 Amazon ECR 인터페이스 VPC 엔드포인트(AWS PrivateLink)를 참고하세요.

다음은 Fargate 서비스의 networkConfiguration 섹션 예시입니다:

"networkConfiguration": {
   "awsvpcConfiguration": {
      "assignPublicIp": "ENABLED",
      "securityGroups": [ "sg-12345678" ],
      "subnets": [ "subnet-12345678" ]
   }
}

태스크 리소스 제한

AWS Fargate의 Linux 컨테이너용 Amazon ECS 태스크 정의는 컨테이너의 리소스 제한을 정의하는 ulimits 파라미터를 지원해요.

AWS Fargate의 Windows용 Amazon ECS 태스크 정의는 컨테이너의 리소스 제한을 정의하는 ulimits 파라미터를 지원하지 않습니다.

Fargate에 호스팅된 Amazon ECS 태스크는 nofile 리소스 제한 파라미터를 제외하고 운영 체제가 설정한 기본 리소스 제한 값을 사용해요. nofile 리소스 제한은 컨테이너가 사용할 수 있는 열린 파일의 개수에 제한을 둡니다. Fargate에서 기본 nofile 소프트 제한은 65535, 하드 제한은 65535예요. 두 제한의 값을 최대 1048576까지 설정할 수 있습니다.

다음은 nofile 제한을 두 배로 설정하는 사용자 지정 예시 태스크 정의 스니펫입니다:

"ulimits": [
    {
       "name": "nofile",
       "softLimit": 2048,
       "hardLimit": 8192
    }
]

조정할 수 있는 다른 리소스 제한에 대한 자세한 내용은 리소스 제한(Resource limits)을 참고하세요.

로깅

이벤트 로깅

Amazon ECS는 수행하는 작업을 EventBridge로 기록해요. Amazon ECS events for EventBridge를 사용하면 Amazon ECS 클러스터, 서비스, 태스크의 현재 상태에 대한 거의 실시간 알림을 받을 수 있어요. 또한 이러한 이벤트에 응답하는 작업을 자동화할 수도 있습니다. 자세한 내용은 EventBridge를 사용한 Amazon ECS 오류 대응 자동화(Automate responses to Amazon ECS errors using EventBridge)를 참고하세요.

태스크 수명 주기 로깅

Fargate에서 실행되는 태스크는 태스크를 태스크 수명 주기의 여러 상태로 추적하기 위한 타임스탬프를 게시해요. AWS Management Console의 태스크 세부 정보와 AWS CLI 및 SDK에서 태스크를 describe할 때 타임스탬프를 확인할 수 있어요. 예를 들어 타임스탬프를 사용해 태스크가 컨테이너 이미지를 다운로드하는 데 얼마나 시간을 썼는지 평가하고, 컨테이너 이미지 크기를 최적화할지 또는 Seekable OCI 인덱스를 사용할지 결정할 수 있습니다.

Seekable OCI(SOCI)를 사용한 컨테이너 이미지 지연 로딩

Linux 플랫폼 버전 1.4.0을 사용하는 Fargate의 Amazon ECS 태스크는 Seekable OCI(SOCI)를 사용해 태스크 시작을 더 빠르게 할 수 있어요. SOCI를 사용하면 컨테이너는 이미지 풀에 몇 초만 소비한 뒤 시작할 수 있으며, 이미지가 백그라운드에서 다운로드되는 동안 환경 설정과 애플리케이션 인스턴스화를 위한 시간을 제공합니다. 이를 지연 로딩(lazy loading)이라고 해요. Fargate가 Amazon ECS 태스크를 시작할 때, 태스크의 이미지에 대한 SOCI 인덱스가 존재하는지 자동으로 감지하고 전체 이미지가 다운로드될 때까지 기다리지 않고 컨테이너를 시작합니다.

SOCI 인덱스 없이 실행되는 컨테이너의 경우 컨테이너 이미지는 컨테이너가 시작되기 전에 완전히 다운로드됩니다. 이 동작은 Fargate의 다른 모든 플랫폼 버전과 Amazon EC2 인스턴스의 Amazon ECS 최적화 AMI에서도 동일해요.

Seekable OCI(SOCI)는 AWS가 개발한 오픈소스 기술로, 컨테이너 이미지를 지연 로딩해 컨테이너를 더 빠르게 시작할 수 있게 합니다. SOCI는 기존 컨테이너 이미지 내 파일의 인덱스(SOCI Index)를 만들어 작동합니다. 이 인덱스는 컨테이너를 더 빠르게 시작할 수 있게 하여, 전체 이미지를 다운로드하기 전에 컨테이너 이미지에서 개별 파일을 추출할 수 있는 기능을 제공합니다. SOCI 인덱스는 컨테이너 레지스트리의 이미지와 같은 리포지토리에 아티팩트로 저장되어야 합니다. 인덱스는 이미지 내용의 권위 있는 소스이므로 신뢰할 수 있는 출처의 SOCI 인덱스만 사용해야 해요.

자세한 내용은 컨테이너 이미지 지연 로딩을 위한 Seekable OCI 소개(Introducing Seekable OCI for lazy loading container images)를 참고하세요.

SOCI를 사용하려는 고객은 SOCI 인덱스 매니페스트 v2만 사용할 수 있어요. 이전에 Fargate에서 SOCI를 사용한 기존 고객은 SOCI 인덱스 매니페스트 v1을 계속 사용할 수 있지만, 일관된 배포를 보장하기 위해 SOCI 인덱스 매니페스트 v2로 마이그레이션할 것을 강력히 권장합니다. SOCI 인덱스 매니페스트 v2는 컨테이너 이미지와 그 SOCI 인덱스 사이에 명시적 관계를 만들어 일관된 배포를 보장합니다.

고려 사항

Fargate가 태스크의 컨테이너 이미지를 지연 로딩하기 위해 SOCI 인덱스를 사용하도록 하려면 다음을 고려하세요:

SOCI 인덱스는 Linux 플랫폼 버전 1.4.0에서 실행되는 태스크만 사용할 수 있어요. Fargate에서 Windows 컨테이너를 실행하는 태스크는 지원되지 않습니다.
X86_64 또는 ARM64 CPU 아키텍처에서 실행되는 태스크가 지원됩니다.
태스크 정의의 컨테이너 이미지는 호환되는 이미지 레지스트리에 저장되어야 해요. 호환되는 레지스트리 목록은 다음과 같습니다:
- Amazon ECR 프라이빗 레지스트리.
gzip 압축을 사용하거나 압축되지 않은 컨테이너 이미지만 지원됩니다. zstd 압축을 사용하는 컨테이너 이미지는 지원되지 않아요.
SOCI 인덱스 매니페스트 v2의 경우, SOCI 인덱스에 대한 주석을 추가하므로 SOCI 인덱스 매니페스트를 생성하면 컨테이너 이미지 매니페스트가 수정됩니다. 이로 인해 새 컨테이너 이미지 다이제스트가 생깁니다. 컨테이너 이미지의 파일 시스템 레이어 내용은 변경되지 않습니다.
SOCI 인덱스 매니페스트 v2의 경우, SOCI 인덱스가 생성된 후 컨테이너 이미지가 이미 컨테이너 이미지 리포지토리에 저장되어 있다면 컨테이너 이미지를 다시 푸시(repush)해야 해요. 컨테이너 이미지를 다시 푸시해도 파일 시스템 레이어를 복제해 스토리지 비용이 늘어나지 않으며, 새 매니페스트 파일만 업로드됩니다.
압축된 크기가 250 MiB보다 큰 컨테이너 이미지로 지연 로딩을 시도할 것을 권장합니다. 더 작은 이미지는 로딩 시간 단축 효과를 보기 어렵습니다.
지연 로딩은 태스크가 시작되는 데 걸리는 시간을 바꿀 수 있으므로, Elastic Load Balancing 상태 확인 유예 기간 같은 다양한 타임아웃을 변경해야 할 수 있어요.
컨테이너 이미지가 지연 로딩되는 것을 방지하려면, SOCI 인덱스가 연결되지 않은 채 이미지를 다시 푸시해야 합니다.

Seekable OCI 인덱스 만들기

컨테이너 이미지를 지연 로딩하려면 컨테이너 이미지 리포지토리에 컨테이너 이미지와 함께 저장된 SOCI 인덱스(메타데이터 파일)가 생성되어야 해요. SOCI 인덱스를 만들고 푸시하려면 GitHub의 오픈소스 soci-snapshotter CLI 도구를 사용할 수 있습니다. 또는 CloudFormation AWS SOCI Index Builder를 배포할 수 있어요. 이는 컨테이너 이미지가 Amazon ECR에 푸시될 때 SOCI 인덱스를 자동으로 만들고 푸시하는 서버리스 솔루션입니다. 솔루션과 설치 단계에 대한 자세한 내용은 GitHub의 CloudFormation AWS SOCI Index Builder를 참고하세요. CloudFormation AWS SOCI Index Builder는 SOCI를 시작하는 것을 자동화하는 방법이고, 오픈소스 soci 도구는 인덱스 생성 주변에 더 많은 유연성과 CI/CD 파이프라인에 인덱스 생성을 통합하는 기능을 제공합니다.

참고: 이미지에 대한 SOCI 인덱스가 생성되려면 이미지가 soci-snapshotter를 실행하는 컴퓨터의 containerd 이미지 저장소에 존재해야 해요. 이미지가 Docker 이미지 저장소에 있으면 찾을 수 없습니다.

태스크가 지연 로딩을 사용했는지 확인

태스크가 SOCI를 사용해 지연 로딩되었는지 확인하려면 태스크 안에서 태스크 메타데이터 엔드포인트를 확인하세요. 태스크 메타데이터 엔드포인트 버전 4를 쿼리하면, 쿼리하는 컨테이너의 기본 경로에 Snapshotter 필드가 있습니다. 또한 /task 경로의 각 컨테이너에 Snapshotter 필드가 있습니다. 이 필드의 기본값은 overlayfs이며, SOCI가 사용되면 soci로 설정됩니다.

컨테이너 이미지에 SOCI 인덱스 매니페스트 v2가 연결되어 있는지 확인하려면 AWS CLI를 사용해 Amazon ECR에서 이미지 인덱스를 검색할 수 있어요:

IMAGE_REPOSITORY=r
IMAGE_TAG=latest

aws ecr batch-get-image \
    --repository-name=$IMAGE_REPOSITORY \
    --image-ids imageTag=$IMAGE_TAG \
    --query 'images[0].imageManifest' --output text | jq -r '.manifests[] | select(.artifactType=="application/vnd.amazon.soci.index.v2+json")'

컨테이너 이미지에 SOCI 인덱스 매니페스트 v1이 연결되어 있는지 확인하려면 OCI Referrers API를 사용할 수 있어요:

ACCOUNT_ID=111222333444
AWS_REGION=us-east-1
IMAGE_REPOSITORY=nginx-demo
IMAGE_TAG=latest
IMAGE_DIGEST=$(aws ecr describe-images --repository-name $IMAGE_REPOSITORY --image-ids imageTag=$IMAGE_TAG --query 'imageDetails[0].imageDigest' --output text)
ECR_PASSWORD=$(aws ecr get-login-password)

curl \
    --silent \
    --user AWS:$ECR_PASSWORD \
    https://$ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/v2/$IMAGE_REPOSITORY/referrers/$IMAGE_DIGEST?artifactType=application%2Fvnd.amazon.soci.index.v1%2Bjson | jq -r '.'

더 알아보기 (Learn more)

Amazon ECS 스토리지 옵션
Amazon EFS 볼륨 사용