AWS 기술 블로그
단일 Amazon Elastic Container Service(ECS) 클러스터에서 15,000개 이상의 태스크들로 확장하기
이 글은 AWS Container Blog에 게시된 Scale to 15,000+ tasks in a single Amazon Elastic Container Service (ECS) cluster, by Ugur Kira and Abhishek Nautiyal을 한국어로 번역 및 편집하였습니다.
소개
Amazon Elastic Container Service (Amazon ECS)는 컨테이너 애플리케이션의 배포, 관리 및 확장을 간소화하는 완전관리형 컨테이너 오케스트레이션 서비스입니다. Amazon ECS는 AWS 서비스와 깊게 통합되어 있으며, 모범 사례가 내장되어 있어 복잡한 컨트롤 플레인 관리 없이 클라우드나 온프레미스에서 애플리케이션을 실행하고 확장할 수 있습니다. AWS Fargate는 Amazon ECS에서 이용할 수 있는 서버리스 컴퓨팅 엔진으로, 이를 사용하면 서버 관리, 용량 확장, 인프라의 보안 및 규정 준수에 대해 걱정할 필요 없이 애플리케이션을 구축하고 확장하는 데 집중할 수 있습니다.
비즈니스가 성장하고 고객 수요가 증가함에 따라 애플리케이션의 확장성은 비지니스의 성공을 위해 매우 중요한 역할을 하게 됩니다. 이 게시물에서는 AWS Fargate와 함께 Amazon ECS를 사용하여 새 AWS 계정에서 애플리케이션을 15,000개 이상의 태스크들로 원활하게 확장할 수 있는 강력하고 간편한 방법을 보여 드리겠습니다. 이와 같이 대규모로 운영할 때 발생하는 한도, 해결 방법 및 권장 사항에 대해서도 설명하겠습니다. 간략한 요약을 보시려면, 핵심 내용 항목을 참조하시기 바랍니다.
둘러보기
이 실습에서는 다양한 확장 차원을 보여주기 위해, 네 개의 마이크로서비스로 구성된 웹 애플리케이션을 배포했습니다. 다음은 각 서비스의 구성 세부 정보입니다.
- ecsdemo-frontend – 애플리케이션의 frontend 구성 요소입니다. Amazon ECS 서비스 검색으로 구성되며 퍼블릭 애플리케이션 로드 밸런서 (ALB) 를 통해 사용자에게 노출됩니다. 서비스 내 각 태스크에는 vCPU 1개와 메모리 2GB가 할당됩니다. ALB와 컨테이너의 상태 및 가용성을 보장하기 위해, 이 서비스에 대해 ALB 상태 확인과 컨테이너 상태 확인이 모두 활성화되어 있습니다.
- ecsdemo-auth-no-sd – 이 서비스는 공개적으로 노출되는 인증 API를 제공합니다. 모든 사용자 통신을 라우팅할 수 있도록 상태 점검이 활성화된 ALB가 있습니다. 각 태스크에는5vCPU와 1GB의 메모리가 할당됩니다.
- ecsdemo-backend – 웹 애플리케이션의 backend를 담당하는 Java 애플리케이션입니다. 각 태스크에는 vCPU 1개와 메모리 2GB가 할당됩니다.
- ecsdemo-payment-api – 이 서비스는 웹 애플리케이션에 대한 결제 처리를 담당합니다. 각 태스크에는25vCPU와 500MB의 메모리가 할당됩니다.
위와 같이 각각의 애플리케이션 서비스의 특징에 대한 정의를 알아보았습니다. 이를 기반으로 새롭게 생성한AWS 계정에서 AWS Fargate 기반의 Amazon ECS 규모를 원활하게 조정한 결과에 대해서 공유하는 것으로부터 논의를 시작하고자 합니다. 이를 통해 후술할 규모 조정 경험에 대하여 단계별로 기술적인 세부 사항을 설명할 수 있습니다 . 위의 차트는 Amazon ECS 클러스터를 이번 조정 과정에서 원하는 태스크 수 (16,000개) 까지 확장한 과정을 보여줍니다. Amazon ECS는 동일한 클러스터 내에서 15,000개 이상의 태스크들을 성공적으로 스케쥴링하고 실행했습니다. 또한 Amazon ECS 서비스가 ALB 및 서비스 검색 등록을 포함하여 1,000개의 실행 태스크를 달성하는 데 약 15분, 5,000개의 실행 태스크 규모를 달성하는 데 약 40분이 걸렸습니다. 네 가지 서비스 모두 동시에 확장되었다는 점은 주목할 만합니다. frontend 서비스에서는 1,000개의 실행 태스크들이 있었고 나머지 3개 서비스는 서비스당 최대 실행 가능한 태스크 제한인 5,000개에 도달했습니다.
참고 : 실제 성능은 컨테이너 이미지 크기, 이미지 캐싱, 로드 밸런서 상태 점검, 애플리케이션의 실제 성능 등 여러 요인에 따라 달라질 수 있습니다. 성능 권장 사항은 Amazon ECS 모범 사례 안내서를 참조하십시오.
결과를 살펴봤으니, Amazon ECS로 이러한 규모를 달성할 수 있는 방법을 자세히 살펴보겠습니다.
기본 준비
운영 오버헤드를 최소화하면서 서비스를 더 빠르게 배포하기 위해, 모범 사례와 잘 설계된 아키텍처 패턴을 코드화한 Amazon ECS Blueprints를 사용했습니다.
AWS Fargate 기반의 Amazon ECS의 태스크는 awsvpc 네트워크 모드에서 실행된다는 점을 인지하는 것이 중요합니다. 이 모드에서는 각 태스크마다 탄력적 네트워크 인터페이스 (ENI) 와 기본 프라이빗 IPv4 주소가 할당됩니다. 이 요구 사항을 수용하기 위해, 다음과 같이 각각 4,091개의 사설 IPv4 주소를 제공하는 6개의 /20 서브넷을 구성했습니다.
서브넷의 프라이빗 IPv4 주소가 충분하지 않으면, Amazon ECS가 규모를 확장하여 더 많은 태스크들을 실행할 수 없다는 점을 이해하는 것은 매우 중요합니다. 네트워크 구성이 원하는 규모를 지원하는지 반드시 확인할 필요가 있습니다.
Amazon ECS의 강력한 단순성을 보여주기 위해 기본 한도가 있는 새 AWS 계정을 사용했습니다. 이를 통해 실질적인 관점을 제시하고 기본 계정 한도의 제약 내에서의 Amazon ECS 기능을 확인할 수 있습니다.
ecs-demo-frontend의 1,000개의 태스크들
첫 번째 실험은 서비스 검색이 활성화 되어있고 ALB와 연결된 frontend 서비스의 원하는 태스크 수(desired count)를 1,000개로 설정하여, 실행 중인 태스크를 1개에서 1,000개로 확장하는 것이었습니다. 서비스가 확장되는 과정에서 다음과 같은 내용을 확인할 수 있었습니다.
태스크 시작 속도: Amazon ECS는 약 10초마다 80개의 태스크를 시작하려고 시도하는데, 이는 AWS Fargate 기반의 태스크 시작 속도 할당량인 분당 500개의 태스크 시작과 일치합니다.
실행 중인 태스크 수가 약 280개가 실행되어 실험 목표치의 약 28%에 도달하자, frontend 서비스에서 AWS Fargate vCPU 기반 할당량에 대해 다음과 같은 오류를 보고하기 시작했습니다.
이 서비스 이벤트 메시지는 AWS Fargate 온디맨드 vCPU 리소스 값 제한에 도달했음을 나타냅니다. 이 값은 현재 리전 내에서 계정에서 Fargate 온디맨드를 동시에 실행할 수 있는 AWS Fargate vCPU의 수를 나타냅니다. 이 서비스 이벤트 메시지를 처리하기 위해 AWS 서비스 할당량 콘솔을 사용하여 한도 증가를 요청했습니다.
Fargate 온디맨드 vCPU 리소스 수에 대한 한도 증가 요청을 제출하고 승인이 되면 AWS 콘솔 또는 AWS 명령줄 인터페이스 (AWS CLI) 를 통해 새 한도를 확인할 수 있습니다. 실험에서는 한도 상향 조정이 적용되는 데 하루가 걸렸습니다. 따라서 이 한도를 미리 높이는 것이 좋습니다.
Fargate 온디맨드 vCPU 리소스 수와 관련하여, 새 AWS 계정의 경우 처음에는 할당량이 더 낮을 수 있으며, 이 값은 시간이 지남에 따라 증가할 수 있다는 점에 유의해야 합니다. AWS Fargate는 각 리전의 계정 사용량을 지속적으로 모니터링하고 사용량에 따라 할당량을 자동으로 조정합니다. 다양한 서비스 할당량 및 한도에 대한 자세한 내용은 Amazon ECS 서비스 할당량을 참조하십시오.
AWS Fargate 온디맨드 vCPU 리소스 수를 10,000개로 늘린 뒤, frontend 서비스는 예상대로 추가 태스크를 계속 스케쥴링 했고 서비스는 다음 스크린샷에서 볼 수 있듯이 1,000개의 태스크를 실행했습니다.
2023-06-01T17:40 UTC에 원하는 태스크 수가 1,000개로 업데이트 되었으며, frontend 서비스는 2023-06-01T17:54 UTC에 1,000개의 태스크들이 실행되는 안정된 상태에 도달했습니다. 서비스가 다음과 같은 ALB 및 서비스 검색 등록을 포함하여 1,000개의 태스크 실행을 달성하는 데 약 15분이 걸렸습니다.
최대 5,000개까지 태스크 확장
1,000개의 실행 태스크라는 첫 번째 목표를 달성하고, Amazon ECS 서비스가 단일 서비스당 최대 5,000개의 실행 태스크들을 가질 수 있다는 점을 감안하여 서비스의 원하는 태스크 수를 5,000개로 설정하고 서비스 동작을 관찰하기 시작했습니다.
frontend 서비스는 리전별 대상 그룹당 최대 대상 수 (기본값 1,000개)에 근접하자 다음 오류를 보고하기 시작했습니다.
대시보드를 통해 Elastic Load Balancing (ELB) 의 서비스 할당량을 확인한 결과, 리전별 대상 그룹당 대상 할당량(Targets per Target Group per Region)이 1,000으로 설정된 것을 확인했습니다.
Service Quotas → AWS services → Elastic Load Balancing (ELB) → Targets per Target Group per Region
이 서비스 메시지를 해결하고 확장을 계속하기 위해 서비스 할당량을 통한 두 번째 한도 상향 조정을 요청하여, 이번에는 다음과 같이 한도 증가를 5,000으로 요청하였습니다.
대상 그룹당 대상을 늘린 후 frontend 서비스가 원하는 수인 5,000개에 도달하도록 새 태스크를 계속 스케쥴링 할 것으로 예상했지만, 서비스의 태스크가 반복적으로 RUNNING 상태로 들어가지 못함 (PENDING 상태에서 STOPPED 상태로 바로 진행)을 나타내는 다음 서비스 메시지가 표시되기 시작했습니다. Amazon ECS 서비스 스로틀 로직이 작동하기 시작했습니다.
AWS 콘솔을 통해 스케쥴링 된 태스크를 확인한 결과, 실제로 태스크가 RUNNING 상태로 전환되지 않고 다음과 같이 즉시 중지 상태로 전환된 것을 확인할 수 있었습니다.
중지된 태스크를 분석하기 위해 AWS 콘솔의 태스크(Tasks) 탭의 드롭다운 메뉴에서 STOPPED을 선택했습니다. 태스크들이 Amazon ECS 서비스 검색의 한 부분인 AWS Cloud Map에 등록할 수 없었기 때문에, 태스크가 RUNNING 상태로 전환될 수 없다는 것을 알게 되었고 다음과 같은 오류 메시지가 보고되었습니다.
서비스 검색의 기반이 되는 AWS Cloud Map의 서비스당 최대 인스턴스 한도에 도달했기 때문에, frontend 서비스가 새 태스크를 등록할 수 없었습니다. 그러나 리전별 대상 그룹당 대상 수 와 Fargate 온디맨드 vCPU 리소스 수와 같이 이전에 증가된 제한과 달리 서비스당 인스턴스 한도는 조정할 수 없으며 할당량 증가를 요청할 수 없습니다.
여기서는 AWS Cloud Map 기반 Amazon ECS 서비스 검색이 활성화된 Amazon ECS 서비스에서 이러한 동작이 예상되며 다음과 같이 Amazon ECS 서비스 할당량 공개 문서에 명시되어 있습니다.
서비스 검색을 표시하는 frontend 서비스의 구성은 다음 세부 정보에 나와 있습니다.
1,000개의 실행 태스크들을 통해 서비스가 안정된 상태에 도달하면, 이 규모 조정 과정의 첫 번째 규모 조정 목표를 달성한 것입니다.
규모 조정 과정의 다음 섹션으로 넘어가기 전에, Amazon ECS에서 서비스 검색과 서비스 메시를 모두 사용하여 서비스 간 통신을 관리하는 Amazon ECS Service Connect는 다음 세부 정보에 설명된 대로 서비스당 태스크가 1,000개로 제한된다는 점에 주의해야 합니다.
ecs-auth-alb-no-sd의 5,000개의 태스크들
frontend 서비스를 통해 얻은 교훈을 바탕으로 1,000개의 실행 태스크 규모에 도달한 후, Amazon ECS 서비스당 최대 태스크 수인 5,000개의 실행 태스크를 달성하려고 노력했습니다.
이를 위해 다음 구성에서 볼 수 있듯이 ALB가 있지만 AWS Cloud Map 기반 Amazon ECS 서비스 검색이 비활성화된 상태에서 auth-no-sd 서비스를 사용했습니다.
이 서비스로 규모 조정 테스트를 시작하기 위해 원하는 태스크 수를 5,000개로 설정하고 서비스의 규모 조정 동작을 관찰하기 시작했습니다. 처음에 서비스는 예상대로 약 10초마다 80개의 새 태스크들을 일괄 처리하기 시작했습니다. 이는 다음 스크린샷에서 볼 수 있습니다.
그러나 서비스가 1,000개의 태스크들이 실행 중인 상태에 도달했을 때 다음과 같은 서비스 메시지가 표시되기 시작했고 일부 태스크는 중지 상태로 전환되었습니다.
중지된 태스크의 세부 정보를 개별적으로 살펴본 결과, Amazon ECS 스케줄러가 스케쥴링된 태스크를 ALB에 등록할 수 없다는 것을 알게 되었습니다. 스케줄러가 ELB에 대상을 등록하지 못했다는 오류 메시지와 함께 태스크가 실패했습니다.
다음 스크린샷에 표시된 대시보드를 통해 ELB에 대한 서비스 할당량을 확인한 결과, ALB당 대상 제한이 기본적으로 1,000으로 설정되어 있기 때문에 auth-no-sd 서비스가 등록 실패에 대한 서비스 이벤트 메시지를 올바르게 내보낸 것을 확인했습니다.
Service Quotas → AWS services → Elastic Load Balancing (ELB) → Targets per Application Load Balancer
확장 과정을 계속하기 위해 이전에 5,000으로 증가된 리전별 대상 그룹당 한도 외에 서비스 할당량을 통해 두 번의 새로운 한도 상향 조정을 요청했습니다. 이와 관련하여 애플리케이션 로드 밸런서당 대상 수와 애플리케이션 로드 밸런서당 대상을 등록할 수 있는 횟수 모두 5,000으로 설정되었습니다. 이제 세 가지 제한이 모두 5,000으로 설정되었습니다.
ALB 및 ALB 대상과 관련된 세 가지 한도가 모두 5,000으로 업데이트된 다음, auth-no-sd 서비스는 예상대로 추가 태스크를 계속 스케쥴링 했습니다. 다음 스크린샷과 같이 서비스가 5,000개의 태스크 실행에 성공적으로 도달했습니다.
2023-06-09T13:18 UTC에 원하는 태스크 수가 5,000개로 설정되었고 auth-no-sd 서비스가 2023-06-09T13:55 UTC에 5,000개의 태스크를 실행하고 안정적인 상태에 도달했다는 점을 고려하면, Amazon ECS가 5,000개의 실행 태스크 규모를 달성하는 데 약 37분이 걸렸습니다. 다음 스크린샷과 같이 이번 규모 확대에는 ALB에 등록하는 데 걸리는 시간이 포함되었습니다.
이번 auth-no-sd 서비스의 확장 과정을 통해 단일 Amazon ECS 서비스에 대해 5,000개의 태스크들을 실행하는 두 번째 확장 목표를 달성했습니다.
이제 Amazon ECS 클러스터에서 auth-no-sd와 frontend 두 서비스에 걸쳐 총 6,000개의 태스크들을 실행하고 있습니다.
단일 클러스터에서 15,000개 이상의 태스크 수행
우리의 마지막 목표는 Amazon ECS 클러스터에서 총 16,000개의 태스크들을 처리할 수 있도록 서비스를 확장하는 것이었습니다. 이를 위해 Amazon ECS 서비스 검색이 활성화되지 않았거나 관련 ALB가 없는, backend 서비스와 결제 API 서비스를 사용했습니다.
다음 스크린샷과 같이 2023-06-01T13:16 UTC에 backed 서비스의 원하는 태스크 수를 5,000개로 설정한 후, 서비스가 2023-06-01T13:55 UTC에 5,000개의 태스크 실행에 도달하는 데 약 39분이 걸렸습니다.
auth-no-sd(태스크 5,000개), frontend(태스크 1,000개), backend(태스크 5,000개) 등 세 가지 Amazon ECS 서비스에 걸쳐 Amazon ECS 클러스터에서 총 11,000개의 태스크들이 실행되고 있습니다.
이제 네 번째이자 마지막 Amazon ECS 서비스인 payment-api로 이동하여 원하는 태스크 수를 5,000개로 업데이트합니다. 그런 다음 스케줄링과 규모 조정을 관찰합니다.
backend 서비스를 사용한 이전 경험과 마찬가지로, 2023-06-01T14:10 UTC에 원하는 payment-api 서비스 개수를 5,000개의 태스크로 설정한 후, 다음 스크린샷과 같이 2023-06-01T14:52 UTC에 서비스가 5,000개의 태스크에 도달하는 데 약 42분이 걸렸습니다.
이제 다음 스크린샷에서 볼 수 있듯이, auth-no-sd, frontend, backend, payment-api의 네 가지 서비스에 걸쳐 단일 Amazon ECS 클러스터에서 16,000개의 태스크들을 실행한다는 최종 목표를 달성했습니다.
핵심 사항
- awsvpc 네트워크 모드에서는 각 태스크마다 프라이빗 IPv4 주소를 하나씩 요구하고 할당하기 때문에, AWS Fargate를 사용할 때는 서브넷 내에 충분한 프라이빗 IPv4 주소를 확보하는 것이 중요합니다.
- Amazon ECS는 기본적으로 강력한 스케쥴링 성능과 태스크 시작 속도를 제공합니다. 자세한 내용은 다음을 참조하십시오. 자세히 알아보기: Amazon Elastic Container Service와 AWS Fargate 태스크 시작 속도 높이기
- AWS Fargate는 vCPU 기반 할당량을 사용하므로 규모 조정 요구 사항에 따라 올바른 값과 한도를 설정하는 것이 중요합니다.
- AWS Cloud Map 기반 Amazon ECS 서비스 검색를 사용하도록 구성된 Amazon ECS 서비스는 서비스당 1,000개의 태스크로 제한됩니다. 이는 서비스당 인스턴스 수에 대한 AWS Cloud Map 서비스 할당량 때문입니다. 이는 변경 불가능한 제한입니다.
- Amazon ECS를 사용하면 단일 클러스터에서 5,000개의 서비스를 실행할 수 있으며, 각 Amazon ECS 서비스는 5,000개의 태스크를 실행할 수 있습니다. 이 규모 덕분에 단일 클러스터에서 수천 개의 태스크를 실행할 수 있습니다.
- ALB의 할당량을 고려하는 것도 중요합니다. 위의 규모 조정 과정에서 리전별 대상 그룹당 대상, 애플리케이션 로드 밸런서당 대상, 애플리케이션 로드 밸런서당 대상 등록 가능 횟수는 5,000으로 설정되었습니다.
- 워크로드 요구 사항이 변경 불가능한 한도를 초과하는 경우 셀 기반 아키텍처를 사용하여 워크로드를 분할하는 것을 고려해야 합니다. 자세한 내용은 AWS의 셀 기반 아키텍처 지침을 참조하십시오.
Amazon EC2 시작 유형을 사용하는 Amazon ECS
AWS Fargate를 시작 유형으로 사용한 확장 경험에서 배운 많은 교훈을, Amazon Elastic Compute Cloud (Amazon EC2) 시작 유형에도 적용할 수 있습니다. 하지만 다음 고려 사항은 Amazon EC2를 사용하는 Amazon ECS 시작 유형에만 해당됩니다.
- 태스크를 확장할 때는, 태스크를 수행하는 데 필요한 Amazon EC2 인스턴스 용량이 충분한지 확인하는 것이 중요합니다. Amazon ECS 용량 공급자를 사용하여 애플리케이션 수요에 따라 기본 인스턴스를 자동으로 조정해야 합니다.
- awsvpc 네트워크 모드를 사용하는 각 Amazon ECS의 태스크는 Amazon EC2 인스턴스에 연결된 자체 ENI를 사용한다는 점에 유의하십시오. Amazon EC2 Linux 인스턴스에 연결할 수 있는 네트워크 인터페이스 수에는 기본 할당량이 있습니다.
- Amazon ECS 워크로드를 확장하면서 Amazon EC2 또는 AWS Fargate 시작 유형과 함께 awsvpc 네트워크 모드를 사용할 때마다 다음 두 가지 중요한 할당량을 고려하십시오.
- 리전별 네트워크 인터페이스 할당량은 AWS 리전 내 사용자 계정의 최대 네트워크 인터페이스 수입니다.
- 리전당 탄력적 IP 주소 할당량은 AWS 리전의 최대 탄력적 IP 주소 수입니다.
결론
이 게시물에서는 애플리케이션을 원활하게 배포하고 확장할 수 있는 AWS Fargate기반의 Amazon ECS의 강력한 단순성에 대해서 말씀드렸습니다. Amazon ECS에서 기본 인프라를 계획하고 관리할 필요 없는 AWS Fargate를 사용하여 새로 생성한 계정에서 수천 개의 태스크들로 애플리케이션을 빠르게 확장할 수 있는 방법을 보여드렸습니다. Amazon ECS를 사용한 대규모 운영에 대한 추가 지침은 다음 리소스를 참조하십시오.