AWS 스팟 인스턴스에 확장 가능한 API 구축

안녕하세요 여러분! 제 이름은 Kirill이고 Adapty의 CTO입니다. 우리 아키텍처의 대부분은 AWS에 있는데, 오늘은 프로덕션 환경에서 스팟 인스턴스를 사용하여 서버 비용을 3배 절감한 방법과 Auto Scaling을 설정하는 방법에 대해 이야기하겠습니다. 먼저 작동 방식에 대한 개요를 설명한 다음 시작하기 위한 자세한 지침을 설명합니다.

스팟 인스턴스란 무엇입니까?

점 인스턴스는 현재 유휴 상태인 다른 AWS 사용자의 서버이며 큰 할인을 받고 판매됩니다(Amazon은 최대 90%까지 기록하며 경험상 최대 3배는 지역, AZ 및 인스턴스 유형에 따라 다름). 일반 제품과의 주요 차이점은 언제든지 끌 수 있다는 것입니다. 따라서 오랫동안 우리는 이를 처녀 환경이나 계산 작업에 사용하고 중간 결과를 S3나 데이터베이스에 저장하지만 판매용으로는 사용하지 않는 것이 정상이라고 믿었습니다. 프로덕션에서 스팟을 사용할 수 있는 타사 솔루션이 있지만 우리의 경우에는 목발이 많아서 구현하지 않았습니다. 기사에 설명된 접근 방식은 추가 스크립트, 크라운 등 없이 표준 AWS 기능 내에서 완전히 작동합니다.

다음은 스팟 인스턴스의 가격 내역을 보여주는 몇 가지 스크린샷입니다.

eu-west-5(아일랜드) 리전의 m1.large. 가격은 3개월 동안 대부분 안정적이었으며 현재 2.9배를 절약하고 있습니다.

us-east-5 지역(버지니아 북부)의 m1.large. 가격은 3개월에 걸쳐 지속적으로 변경되며 현재 가용 영역에 따라 2.3배에서 2.8배까지 절약됩니다.

us-east-3 리전(버지니아 북부)의 t1.small. 가격은 3개월 동안 안정되어 현재 3.4배를 절감하고 있습니다.

서비스 아키텍처

이 기사에서 다룰 서비스의 기본 아키텍처는 아래 다이어그램에 나와 있습니다.

Application Load Balancer → EC2 대상 그룹 → Elastic Container Service

ALB(Application Load Balancer)는 EC2 대상 그룹(TG)에 요청을 보내는 밸런서로 사용됩니다. TG는 ALB용 인스턴스에서 포트를 열고 이를 Elastic Container Service(ECS) 컨테이너의 포트에 연결하는 일을 담당합니다. ECS는 Docker 컨테이너를 관리하는 AWS의 Kubernetes와 유사합니다.

하나의 인스턴스에는 동일한 포트를 사용하여 여러 개의 실행 중인 컨테이너가 있을 수 있으므로 이를 고정적으로 설정할 수는 없습니다. ECS는 TG에 새 작업(Kubernetes 용어로는 포드라고 함)을 시작한다고 알리고, 인스턴스에서 사용 가능한 포트를 확인하고 그 중 하나를 시작된 작업에 할당합니다. TG는 또한 정기적으로 헬스체크를 통해 인스턴스와 API가 작동하는지 확인하고, 문제가 발견되면 해당 인스턴스로 요청 전송을 중단합니다.

EC2 Auto Scaling 그룹 + ECS 용량 공급자

위 다이어그램에는 EC2 Auto Scaling 그룹(ASG) 서비스가 표시되지 않습니다. 이름에서 인스턴스 확장을 담당한다는 것을 알 수 있습니다. 그러나 최근까지 AWS에는 ECS에서 실행 중인 시스템 수를 관리하는 기능이 내장되어 있지 않았습니다. ECS를 사용하면 CPU 사용량, RAM 또는 요청 수 등을 기준으로 작업 수를 확장할 수 있습니다. 그러나 작업이 모든 무료 인스턴스를 차지한 경우 새 머신이 자동으로 생성되지 않습니다.

ECS CP(ECS 용량 공급자)의 등장으로 이러한 상황이 바뀌었습니다. 이제 ECS의 각 서비스를 ASG와 연결할 수 있으며, 작업이 실행 중인 인스턴스에 맞지 않으면 새 서비스가 발생합니다(그러나 설정된 ASG 제한 내에서). 이는 반대 방향으로도 작동합니다. ECS CP가 작업이 없는 유휴 인스턴스를 발견하면 ASG 명령을 사용하여 해당 인스턴스를 종료합니다. ECS CP에는 인스턴스 로드의 목표 비율을 지정하는 기능이 있으므로 작업을 빠르게 확장하기 위해 특정 수의 머신을 항상 무료로 사용할 수 있습니다. 이에 대해서는 잠시 후에 설명하겠습니다.

EC2 시작 템플릿

이 인프라 생성에 대해 자세히 설명하기 전에 마지막으로 설명할 서비스는 EC2 시작 템플릿입니다. 매번 처음부터 반복하지 않도록 모든 시스템이 시작되는 템플릿을 만들 수 있습니다. 여기서 시작할 머신 유형, 보안 그룹, 디스크 이미지 및 기타 여러 매개변수를 선택할 수 있습니다. 시작된 모든 인스턴스에 업로드될 사용자 데이터를 지정할 수도 있습니다. 사용자 데이터에서 스크립트를 실행할 수 있습니다. 예를 들어 파일 내용을 편집할 수 있습니다. ECS 에이전트 구성.

이 문서에서 가장 중요한 구성 매개변수 중 하나는 다음과 같습니다. ECS_ENABLE_SPOT_INSTANCE_DRAINING=사실이다. 이 매개변수가 활성화되면 ECS는 스팟 인스턴스가 제거된다는 신호를 수신하자마자 해당 인스턴스에서 작동하는 모든 작업을 드레이닝 상태로 전환합니다. 이 인스턴스에는 새 작업이 할당되지 않습니다. 지금 롤아웃하려는 작업이 있으면 취소됩니다. 밸런서의 요청도 더 이상 수신되지 않습니다. 인스턴스 삭제 알림은 실제 이벤트 발생 2분 전에 옵니다. 따라서 서비스가 2분 이상 작업을 수행하지 않고 디스크에 아무것도 저장하지 않는 경우 데이터 손실 없이 스팟 인스턴스를 사용할 수 있습니다.

디스크 관련 - 최근 AWS 만든 ECS와 함께 EFS(Elastic File System)를 사용할 수 있는데, 이 방식을 사용하면 디스크도 장애물이 아니지만 원칙적으로 상태를 저장하는 데 디스크가 필요하지 않기 때문에 시도하지 않았습니다. 기본적으로 SIGINT(작업이 Draining 상태로 전환될 때 전송됨)를 수신한 후 실행 중인 모든 작업은 아직 완료되지 않았더라도 30초 후에 중지됩니다. 매개변수를 사용하여 이 시간을 변경할 수 있습니다. ECS_CONTAINER_STOP_TIMEOUT. 가장 중요한 것은 스팟 머신의 경우 2분 이상 설정하지 않는 것입니다.

서비스 만들기

설명된 서비스 생성으로 넘어가겠습니다. 그 과정에서 위에서 언급하지 못한 몇 가지 유용한 사항을 추가로 설명하겠습니다. 일반적으로 이것은 단계별 지침이지만 매우 기본적이거나 반대로 매우 구체적인 경우는 고려하지 않을 것입니다. 모든 작업은 AWS 시각적 콘솔에서 수행되지만 CloudFormation 또는 Terraform을 사용하여 프로그래밍 방식으로 재현할 수 있습니다. Adapty에서는 Terraform을 사용합니다.

EC2 시작 템플릿

이 서비스는 사용될 시스템의 구성을 생성합니다. 템플릿은 EC2 -> 인스턴스 -> 템플릿 시작 섹션에서 관리됩니다.

Amazon 머신 이미지(AMI) — 모든 인스턴스가 시작될 디스크 이미지를 지정합니다. ECS의 경우 대부분의 경우 Amazon에서 최적화된 이미지를 사용하는 것이 좋습니다. 정기적으로 업데이트되며 ECS 작동에 필요한 모든 것이 포함되어 있습니다. 현재 이미지 ID를 확인하려면 해당 페이지로 이동하세요. Amazon ECS 최적화 AMI, 사용 중인 지역을 선택하고 해당 지역의 AMI ID를 복사하세요. 예를 들어 us-east-1 지역의 경우 작성 당시의 현재 ID는 다음과 같습니다. ami-00c7c1cf5bdc913ed. 이 ID는 사용자 정의 값 지정 항목에 삽입되어야 합니다.

인스턴스 유형 — 인스턴스 유형을 나타냅니다. 귀하의 작업에 가장 적합한 것을 선택하십시오.

키 페어(로그인) — 필요한 경우 SSH를 통해 인스턴스에 연결할 수 있는 인증서를 지정합니다.

네트워크 설정 — 네트워크 매개변수를 지정합니다. 네트워킹 플랫폼 대부분의 경우 Virtual Private Cloud(VPC)가 있어야 합니다. 보안 그룹 — 인스턴스에 대한 보안 그룹. 인스턴스 앞에 밸런서를 사용할 것이므로 여기서는 밸런서에서만 들어오는 연결을 허용하는 그룹을 지정하는 것이 좋습니다. 즉, 2개의 보안 그룹이 있습니다. 하나는 포트 80(http) 및 443(https)에서 어디에서나 인바운드 연결을 허용하는 밸런서용이고, 다른 하나는 밸런서 그룹의 모든 포트에서 들어오는 연결을 허용하는 머신용입니다. . 두 그룹 모두의 아웃바운드 연결은 모든 주소에 대한 모든 포트에 대한 TCP 프로토콜을 사용하여 열려야 합니다. 나가는 연결에 대한 포트와 주소를 제한할 수 있지만 닫힌 포트에서 무언가에 액세스하려고 시도하고 있지 않은지 지속적으로 모니터링해야 합니다.

스토리지(볼륨) — 머신의 디스크 매개변수를 지정합니다. 디스크 크기는 AMI에 지정된 크기보다 작을 수 없으며, ECS 최적화의 경우 30GiB입니다.

고급 세부정보 — 추가 매개변수를 지정합니다.

구매 옵션 — 스팟 인스턴스를 구매할 것인지 여부. 원하지만 여기서는 이 상자를 선택하지 않고 Auto Scaling 그룹에서 구성할 것이므로 더 많은 옵션이 있습니다.

IAM 인스턴스 프로필 — 인스턴스가 시작될 역할을 나타냅니다. ECS에서 인스턴스를 실행하려면 일반적으로 역할에 있는 권한이 필요합니다. ecsInstanceRole. 어떤 경우에는 생성될 수 있습니다. 그렇지 않은 경우 여기에서 생성할 수 있습니다. 교수 이를 수행하는 방법에 대해. 생성 후 템플릿에 표시합니다.
다음으로 많은 매개변수가 있습니다. 기본적으로 기본값은 어디든 그대로 둘 수 있지만 각 매개변수에는 명확한 설명이 있습니다. 나는 EBS 최적화 인스턴스와 T2/T3 무제한 옵션을 사용하는 경우 항상 활성화합니다. 파열 가능 인스턴스.

사용 시간 — 사용자 데이터를 나타냅니다. 파일을 편집하겠습니다. /etc/ecs/ecs.config, ECS 에이전트 구성이 포함되어 있습니다.
사용자 데이터의 예는 다음과 같습니다.

#!/bin/bash
echo ECS_CLUSTER=DemoApiClusterProd >> /etc/ecs/ecs.config
echo ECS_ENABLE_SPOT_INSTANCE_DRAINING=true >> /etc/ecs/ecs.config
echo ECS_CONTAINER_STOP_TIMEOUT=1m >> /etc/ecs/ecs.config
echo ECS_ENGINE_AUTH_TYPE=docker >> /etc/ecs/ecs.config
echo "ECS_ENGINE_AUTH_DATA={"registry.gitlab.com":{"username":"username","password":"password"}}" >> /etc/ecs/ecs.config

ECS_CLUSTER=DemoApiClusterProd — 매개변수는 인스턴스가 지정된 이름의 클러스터에 속해 있음을 나타냅니다. 즉, 이 클러스터는 이 서버에 작업을 배치할 수 있습니다. 아직 클러스터를 생성하지 않았지만 클러스터를 생성할 때 이 이름을 사용하겠습니다.

ECS_ENABLE_SPOT_INSTANCE_DRAINING=true — 이 매개변수는 스팟 인스턴스를 끄라는 신호가 수신되면 해당 인스턴스의 모든 작업이 Draining 상태로 전환되어야 함을 지정합니다.

ECS_CONTAINER_STOP_TIMEOUT=1m - 매개변수는 SIGINT 신호를 수신한 후 모든 작업이 종료되기까지 1분을 갖도록 지정합니다.

ECS_ENGINE_AUTH_TYPE=docker — 매개변수는 Docker 체계가 인증 메커니즘으로 사용됨을 나타냅니다.

ECS_ENGINE_AUTH_DATA=... — Docker 이미지가 저장되는 프라이빗 컨테이너 레지스트리에 대한 연결 매개변수입니다. 공개인 경우 아무것도 지정할 필요가 없습니다.

이 기사에서는 Docker Hub의 공개 이미지를 사용하므로 매개변수를 지정합니다. ECS_ENGINE_AUTH_TYPE и ECS_ENGINE_AUTH_DATA 필요 없어.

알고 유용: 새 버전에서는 Docker, Linux, ECS 에이전트 등의 버전이 업데이트되므로 AMI를 정기적으로 업데이트하는 것이 좋습니다. 이를 잊지 않으려면 다음을 수행하십시오. 알림 설정 새 버전 출시에 대해. 이메일로 알림을 받고 수동으로 업데이트할 수도 있고, 업데이트된 AMI를 사용하여 시작 템플릿의 새 버전을 자동으로 생성하는 Lambda 함수를 작성할 수도 있습니다.

EC2 Auto Scaling 그룹

Auto Scaling 그룹은 인스턴스 시작 및 확장을 담당합니다. 그룹은 EC2 -> Auto Scaling -> Auto Scaling 그룹 섹션에서 관리됩니다.

템플릿 시작 — 이전 단계에서 생성된 템플릿을 선택합니다. 기본 버전을 그대로 둡니다.

구매 옵션 및 인스턴스 유형 — 클러스터의 인스턴스 유형을 지정합니다. 시작 템플릿 준수는 시작 템플릿의 인스턴스 유형을 사용합니다. 구매 옵션과 인스턴스 유형을 결합하면 인스턴스 유형을 유연하게 구성할 수 있습니다. 우리는 그것을 사용할 것입니다.

온디맨드 베이스(옵션) — 항상 작동하는 일반 비스팟 인스턴스 수입니다.

기본 대비 온디맨드 비율 — 일반 인스턴스와 스팟 인스턴스의 백분율 비율, 50-50이 균등하게 분배되고, 각 일반 인스턴스에 대해 20-80이 4개의 스팟 인스턴스가 인상됩니다. 이 예에서는 50-50을 표시하지만 실제로는 20-80을 가장 자주 사용하며 어떤 경우에는 0-100을 표시합니다.

인스턴스 유형 — 여기에서 클러스터에 사용될 추가 인스턴스 유형을 지정할 수 있습니다. 우리는 그 이야기의 의미를 잘 이해하지 못하기 때문에 그것을 결코 사용하지 않았습니다. 아마도 이는 특정 유형의 인스턴스에 대한 제한 때문일 수 있지만 지원을 통해 쉽게 늘릴 수 있습니다. 애플리케이션을 아시는 분은 댓글로 읽어주시면 감사하겠습니다)

네트워크 — 네트워크 설정에서 시스템의 VPC 및 서브넷을 선택합니다. 대부분의 경우 사용 가능한 모든 서브넷을 선택해야 합니다.

로드 균형 조정 - 밸런서 설정. 하지만 이 작업은 별도로 수행할 것이므로 여기서는 아무것도 건드리지 않겠습니다. 상태 확인 나중에 구성됩니다.

그룹 규모 — 클러스터의 머신 수에 대한 제한과 시작 시 원하는 머신 수를 나타냅니다. 클러스터의 머신 수는 메트릭에 따라 크기 조정이 이루어져야 하는 경우에도 지정된 최소값보다 작거나 최대값보다 크지 않습니다.

확장 정책 — 스케일링 매개변수. 그러나 실행 중인 ECS 작업을 기반으로 스케일링할 것이므로 나중에 스케일링을 구성할 것입니다.

인스턴스 축소 보호 — 축소 시 인스턴스가 삭제되지 않도록 보호합니다. ASG가 실행 중인 작업이 있는 머신을 삭제하지 않도록 이를 활성화합니다. ECS 용량 공급자는 작업이 없는 인스턴스에 대한 보호를 비활성화합니다.

태그 추가 — 인스턴스에 대한 태그를 지정할 수 있습니다(이 경우 새 인스턴스 태그 지정 확인란을 선택해야 함). 이름 태그를 지정하는 것이 좋습니다. 그러면 그룹 내에서 시작되는 모든 인스턴스가 동일한 이름을 갖게 되며 콘솔에서 보는 것이 편리합니다.

그룹을 생성한 후 이를 열고 고급 구성 섹션으로 이동합니다. 생성 단계에서 콘솔에 모든 옵션이 표시되지 않는 이유는 무엇입니까?

종료 정책 — 인스턴스를 삭제할 때 고려되는 규칙입니다. 순서대로 적용됩니다. 우리는 보통 아래 사진의 것을 사용합니다. 먼저, 가장 오래된 시작 템플릿이 있는 인스턴스가 삭제됩니다. 예를 들어 AMI를 업데이트한 경우 새 버전을 생성했지만 모든 인스턴스가 해당 버전으로 전환되었습니다. 그런 다음 다음 청구 시간에 가장 가까운 인스턴스가 선택됩니다. 그런 다음 출시 날짜를 기준으로 가장 오래된 항목이 선택됩니다.

알고 유용: 클러스터의 모든 시스템을 업데이트하고 사용하기 편리합니다. 인스턴스 새로고침. 이를 이전 단계의 Lambda 함수와 결합하면 완전히 자동화된 인스턴스 업데이트 시스템을 갖게 됩니다. 모든 머신을 업데이트하기 전에 그룹의 모든 인스턴스에 대해 인스턴스 축소 보호를 비활성화해야 합니다. 그룹 내 구성이 아니라 머신 자체로부터의 보호는 인스턴스 관리 탭에서 수행됩니다.

Application Load Balancer 및 EC2 대상 그룹

밸런서는 EC2 → 로드 밸런싱 → 로드 밸런서 섹션에서 생성됩니다. 우리는 Application Load Balancer를 사용할 것입니다. 다양한 유형의 밸런서 비교는 다음에서 읽을 수 있습니다. 서비스 페이지.

청취자 - 포트 80과 443을 만들고 나중에 밸런서 규칙을 사용하여 80에서 443으로 리디렉션하는 것이 합리적입니다.

가용 영역 — 대부분의 경우 모든 사람을 위한 접근성 구역을 선택합니다.

보안 설정 구성 — 밸런서의 SSL 인증서가 여기에 표시됩니다. 가장 편리한 옵션은 다음과 같습니다. 인증서를 만들다 ACM에서. 차이점에 대해 보안 정책 에서 읽을 수 있다 선적 서류 비치, 기본적으로 선택된 상태로 둘 수 있습니다. ELBSecurityPolicy-2016-08. 밸런서를 생성한 후에는 이를 볼 수 있습니다. DNS 이름, 도메인에 대한 CNAME을 구성해야 합니다. 예를 들어 Cloudflare에서는 다음과 같이 표시됩니다.

보안 그룹 — 밸런서에 대한 보안 그룹을 생성하거나 선택합니다. 이에 대해서는 바로 위의 EC2 시작 템플릿 → 네트워크 설정 섹션에서 자세히 설명했습니다.

대상 그룹 — 문제가 발생할 경우 교체하기 위해 밸런서에서 시스템으로 요청을 라우팅하고 가용성을 확인하는 그룹을 만듭니다. 대상 유형 인스턴스여야 합니다. 프로토콜 и 포트 밸런서와 인스턴스 간 통신에 HTTPS를 사용하는 경우 인증서를 업로드해야 합니다. 이 예에서는 이 작업을 수행하지 않고 포트 80을 그대로 둡니다.

상태 확인 — 서비스 기능을 확인하기 위한 매개변수입니다. 실제 서비스에서는 비즈니스 로직의 중요한 부분을 구현하는 별도의 요청이어야 합니다. 이 예에서는 기본 설정을 그대로 유지하겠습니다. 다음으로 요청 간격, 시간 초과, 성공 코드 등을 선택할 수 있습니다. 이 예에서는 사용될 Docker 이미지가 200 코드를 반환하므로 성공 코드 399-304를 표시합니다.

대상 등록 — 여기에서는 그룹의 자동차가 선택되었지만 우리의 경우 ECS에서 수행되므로 이 단계를 건너뜁니다.

알고 유용: 밸런서 수준에서는 특정 시점에 S3에 저장될 로그를 활성화할 수 있습니다. 형식. 여기에서 분석을 위해 타사 서비스로 내보내거나 다음을 사용하여 S3의 데이터에 대해 직접 SQL 쿼리를 만들 수 있습니다. 아테나를 사용하여. 편리하고 추가 코드 없이 작동합니다. 또한 지정된 기간이 지나면 S3 버킷에서 로그를 제거하도록 설정하는 것이 좋습니다.

ECS 작업 정의

이전 단계에서는 서비스 인프라와 관련된 모든 것을 만들었으니 이제 출시할 컨테이너에 대해 설명하겠습니다. 이는 ECS → 작업 정의 섹션에서 수행됩니다.

출시 유형 호환성 - EC2를 선택합니다.

작업 실행 IAM 역할 - 선택하다 ecsTaskExecutionRole. 이를 사용하여 로그가 작성되고 비밀 변수에 대한 액세스 권한이 부여됩니다.

컨테이너 정의 섹션에서 컨테이너 추가를 클릭합니다.

영상 — 프로젝트 코드가 있는 이미지에 연결합니다. 이 예에서는 Docker Hub의 공개 이미지를 사용합니다. bitnami/노드-예제:0.0.1.

메모리 제한 — 컨테이너의 메모리 제한. 하드 한도 — 하드 제한, 컨테이너가 지정된 값을 초과하면 docker kill 명령이 실행되고 컨테이너는 즉시 종료됩니다. 소프트 한도 — 소프트 제한, 컨테이너는 지정된 값을 초과할 수 있지만 머신에 작업을 배치할 때 이 매개변수가 고려됩니다. 예를 들어 머신에 4GiB의 RAM이 있고 컨테이너의 소프트 제한이 2048MiB인 경우 이 머신은 이 컨테이너를 통해 최대 2개의 작업을 실행할 수 있습니다. 실제로 4GiB RAM은 4096MiB보다 약간 작습니다. 이는 클러스터의 ECS 인스턴스 탭에서 확인할 수 있습니다. 소프트 제한은 하드 제한보다 클 수 없습니다. 한 작업에 여러 개의 컨테이너가 있는 경우 해당 제한이 합산된다는 점을 이해하는 것이 중요합니다.

포트 매핑 -에 호스트 포트 0을 표시하면 포트가 동적으로 할당되고 대상 그룹에서 모니터링된다는 의미입니다. 컨테이너 포트 — 애플리케이션이 실행되는 포트는 종종 실행 명령에 지정되거나 애플리케이션 코드, Dockerfile 등에 할당됩니다. 이 예에서는 3000을 사용합니다. 도커 파일 사용중인 이미지입니다.

건강 체크 — 컨테이너 상태 확인 매개변수. 대상 그룹에 구성된 매개변수와 혼동하지 마십시오.

환경 - 환경 설정. CPU 유닛 - 프로세서에 대해서만 메모리 제한과 유사합니다. 각 프로세서 코어는 1024개 장치이므로 서버에 듀얼 코어 프로세서가 있고 컨테이너가 512로 설정된 경우 이 컨테이너를 사용하는 4개의 작업을 서버 하나에서 시작할 수 있습니다. CPU 장치는 항상 코어 수에 해당하며 메모리의 경우처럼 코어 수가 조금이라도 적을 수는 없습니다.

명령 — 컨테이너 내부에서 서비스를 시작하는 명령으로, 모든 매개변수는 쉼표로 구분되어 지정됩니다. 이는 gunicorn, npm 등일 수 있습니다. 지정하지 않으면 Dockerfile의 CMD 지시어 값이 사용됩니다. 우리는 나타냅니다 npm,start.

환경 변수 — 컨테이너 환경 변수. 이는 간단한 텍스트 데이터이거나 다음의 비밀 변수일 수 있습니다. 비밀 관리자 또는 파라미터 저장소.

저장 및 로깅 — 여기서는 CloudWatch Logs(AWS의 로그 서비스)에 로깅을 설정하겠습니다. 이렇게 하려면 CloudWatch Logs 자동 구성 확인란을 활성화하면 됩니다. 작업 정의를 생성하면 CloudWatch에 로그 그룹이 자동으로 생성됩니다. 기본적으로 로그는 무기한 저장되므로 보존 기간을 만료되지 않음에서 필수 기간으로 변경하는 것이 좋습니다. 이 작업은 CloudWatch Log 그룹에서 수행됩니다. 현재 기간을 클릭하고 새 기간을 선택해야 합니다.

ECS 클러스터 및 ECS 용량 공급자

ECS → 클러스터 섹션으로 이동하여 클러스터를 생성합니다. 템플릿으로 EC2 Linux + 네트워킹을 선택합니다.

클러스터 이름 - 매우 중요합니다. 여기서는 Launch Template 매개변수에 지정된 것과 동일한 이름을 만듭니다. ECS_CLUSTER, 우리의 경우 - DemoApiClusterProd. 빈 클러스터 생성 확인란을 선택합니다. 선택적으로 Container Insights를 활성화하여 CloudWatch의 서비스 지표를 볼 수 있습니다. 모든 작업을 올바르게 수행했다면 ECS 인스턴스 섹션에 Auto Scaling 그룹에서 생성된 머신이 표시됩니다.

탭으로 이동 용량 공급자 새 항목을 만듭니다. 실행 중인 ECS 작업 수에 따라 머신 생성 및 종료를 제어해야 한다는 점을 상기시켜 드립니다. 공급자는 하나의 그룹에만 할당될 수 있다는 점에 유의하는 것이 중요합니다.

Auto Scaling 그룹 — 이전에 생성된 그룹을 선택합니다.

관리형 확장 — 공급자가 서비스를 확장할 수 있도록 활성화합니다.

목표 용량 % — 작업이 로드된 기계의 몇 퍼센트가 필요한가요? 100%를 지정하면 모든 머신은 항상 실행 중인 작업으로 바빠집니다. 50%를 지정하면 자동차의 절반이 항상 무료가 됩니다. 이 경우, 부하가 급격히 증가하면 새 택시는 인스턴스가 배치될 때까지 기다릴 필요 없이 즉시 무료 차량을 이용할 수 있습니다.

관리형 종료 방지 — 활성화합니다. 이 매개변수를 사용하면 공급자가 삭제로부터 인스턴스 보호를 제거할 수 있습니다. 이는 머신에 활성 작업이 없고 목표 용량%를 허용할 때 발생합니다.

ECS 서비스 및 확장 설정

마지막 단계 :) 서비스를 생성하려면 서비스 탭에서 이전에 생성된 클러스터로 이동해야 합니다.

발사 유형 — 용량 공급자 전략으로 전환을 클릭하고 이전에 생성된 공급자를 선택해야 합니다.

작업 정의 — 이전에 생성된 작업 정의와 해당 개정을 선택합니다.

서비스 이름 — 혼란을 피하기 위해 항상 작업 정의와 동일하게 표시합니다.

서비스 종류 - 항상 복제본.

작업 수 — 서비스에서 원하는 활성 작업 수. 이 매개변수는 크기 조정으로 제어되지만 여전히 지정되어야 합니다.

최소 정상 비율 и 최대 비율 — 배포 중 작업 동작을 결정합니다. 기본값은 100과 200으로 배포 시 작업 수가 몇 배로 증가한 다음 원하는 값으로 돌아옴을 나타냅니다. 실행 중인 작업이 1개(최소=0, 최대=100)인 경우 배포 중에 해당 작업이 종료되고 그 후에 새 작업이 발생합니다. 즉 가동 중지 시간이 발생합니다. 1개의 작업이 실행 중인 경우(최소=50, 최대=150), 1개의 작업을 절반으로 나누거나 XNUMX배로 늘릴 수 없기 때문에 배포가 전혀 발생하지 않습니다.

배포 유형 — 롤링 업데이트를 종료합니다.

배치 템플릿 — 기계에 작업을 배치하는 규칙. 기본값은 AZ Balanced Spread입니다. 즉, 모든 가용 영역의 머신이 증가할 때까지 각각의 새 작업이 새 인스턴스에 배치됩니다. 우리는 일반적으로 BinPack - CPU 및 Spread - AZ를 수행하며, 이 정책을 사용하면 작업이 CPU당 하나의 시스템에 최대한 조밀하게 배치됩니다. 새 머신을 생성해야 하는 경우 새 가용성 영역에 생성됩니다.

로드 밸런서 유형 — Application Load Balancer를 선택합니다.

서비스 IAM 역할 - 선택하다 ecsServiceRole.

로드 밸런서 이름 — 이전에 생성된 밸런서를 선택합니다.

상태 점검 유예 기간 — 새 작업을 롤아웃한 후 상태 확인을 수행하기 전에 일시 중지하며 일반적으로 60초로 설정합니다.

로드 밸런싱을 위한 컨테이너 — 대상 그룹 이름 항목에서 이전에 생성된 그룹을 선택하면 자동으로 채워집니다.

서비스 Auto Scaling — 서비스 확장 매개변수. 서비스 자동 조정 구성을 선택하여 원하는 서비스 수를 조정합니다. 확장 시 최소 및 최대 작업 수를 설정합니다.

서비스 Auto Scaling을 위한 IAM 역할 - 선택하다 AWSServiceRoleForApplicationAutoScaling_ECSService.

자동 작업 확장 정책 — 스케일링 규칙. 2가지 유형이 있습니다:

1. 표적 추적 — 목표 지표(CPU/RAM 사용량 또는 각 작업에 대한 요청 수)를 추적합니다. 예를 들어 평균 프로세서 로드가 85%가 되기를 원하며, 이 로드가 높아지면 목표 값에 도달할 때까지 새 작업이 추가됩니다. 부하가 낮으면 축소 방지가 활성화되지 않는 한 작업이 제거됩니다(축소 비활성화).
2. 단계 스케일링 - 임의의 사건에 대한 반응. 여기에서는 이벤트(CloudWatch 경보)에 대한 반응을 구성할 수 있으며, 이벤트가 발생하면 지정된 작업 수를 추가 또는 제거하거나 정확한 작업 수를 지정할 수 있습니다.

서비스에는 여러 가지 확장 규칙이 있을 수 있으며 이는 유용할 수 있으며 가장 중요한 것은 서로 충돌하지 않도록 하는 것입니다.

결론

지침을 따르고 동일한 Docker 이미지를 사용한 경우 서비스는 다음과 같은 페이지를 반환해야 합니다.

1. 우리는 서비스의 모든 시스템이 시작되는 템플릿을 만들었습니다. 또한 템플릿이 변경될 때 컴퓨터를 업데이트하는 방법도 배웠습니다.
2. 스팟 인스턴스 중지 신호 처리를 구성했으므로 이를 수신한 후 XNUMX분 이내에 실행 중인 모든 작업이 머신에서 제거되므로 손실되거나 중단되는 일이 없습니다.
3. 우리는 부하를 기계 전체에 균등하게 분배하기 위해 밸런서를 올렸습니다.
4. 스팟 인스턴스에서 실행되는 서비스를 만들었는데, 이를 통해 기계 비용이 약 3배 절감됩니다.
5. 가동 중지 시간 비용을 발생시키지 않고 증가된 워크로드를 처리하기 위해 양방향 자동 크기 조정을 구성했습니다.
6. 우리는 애플리케이션이 인프라(머신)를 관리하고 그 반대로는 관리하지 않도록 용량 공급자를 사용합니다.
7. 우리는 훌륭합니다.

예를 들어 대규모 이메일 캠페인에서 광고하는 경우와 같이 로드가 급증할 것으로 예측할 수 있는 경우 다음을 기준으로 크기 조정을 설정할 수 있습니다. 시간표.

시스템의 여러 부분에 있는 데이터를 기반으로 확장할 수도 있습니다. 예를 들어 다음과 같은 기능이 있습니다. 개별 프로모션 제안 발송 모바일 애플리케이션 사용자. 캠페인이 1만 명 이상의 사람들에게 전송되는 경우도 있습니다. 이러한 배포 후에는 많은 사용자가 동시에 애플리케이션에 로그인하므로 API에 대한 요청이 항상 크게 증가합니다. 따라서 프로모션 푸시 알림을 보내기 위한 대기열에 훨씬 더 많은 표준 표시기가 있는 것을 확인하면 즉시 로드 준비를 위해 여러 추가 시스템과 작업을 시작할 수 있습니다.

스팟 인스턴스와 ECS를 사용하는 흥미로운 사례나 확장에 관한 내용을 댓글로 알려주시면 기쁠 것입니다.

곧 주로 서버리스 스택(돈 포함)에서 초당 수천 개의 분석 이벤트를 처리하는 방법과 GitLab CI 및 Terraform Cloud를 사용하여 서비스 배포가 작동하는 방법에 대한 기사가 나올 것입니다.

우리를 구독하면 흥미로울 것입니다!

등록된 사용자만 설문 조사에 참여할 수 있습니다. 로그인제발

프로덕션에서 스팟 인스턴스를 사용합니까?

• 22,2%예6

• 66,7%18

• 11,1%기사를 통해 이에 대해 배웠으며 이를 사용할 계획입니다3

27명의 사용자가 투표했습니다. 5명의 사용자가 기권했습니다.

출처 : habr.com