방탄 ECS 클러스터 - AWS에서 안전하고 안정적이며 경제적인 클러스터를 만들기 위한 모범 사례

AWS에서 ECS 클러스터를 실행하는 것은 번거로울 수 있습니다.일련의 정지와 전쟁 이야기를 겪은 후에 저는 예산 범위 내에서 집단의 안전과 취약성에 대한 어려움을 극복하는 과정에서 얻은 경험과 교훈을 소개합니다.

개인 호스트, ALB/ELB를 통해 공개

부하 평형기는 집단으로 통하는 스위치일 것입니다.웹 서비스를 실행할 때, 군집이 개인 서브넷에서 실행되고 인터넷에서 용기에 직접 접근할 수 있는지 확인하십시오.이상적인 경우, 내부 용기는 무작위적이고 임시적인 포트를 공개해야 합니다. 이 포트는 목표 그룹에 연결됩니다.부하 평형기에서만 허용되는 안전 그룹의 통신도 확보해야 한다.

Spot 인스턴스 사용

Spot 실례는 계산량이 많거나 작업 집단이나 개발/무대 환경 비용을 절약하는 좋은 방법이다.spot 인스턴스가 무엇인지 모르는 경우 AWS 문서를 참조하십시오.

Spot Instance is an unused EC2 instance that is available for less than the On-Demand price.

실제로 이를 사용하면 최대 80%의 비용을 절감할 수 있습니다!하지만 함정이 하나 있다.Spot 실례는 가격 책정 모델을 바탕으로 AWS가 자동으로 죽일 수 있기 때문에 언제든지 삭제될 수 있습니다. 1분만 경고하면 됩니다.

환경 변수에 매개 변수 저장 사용하기

용기의 작업 정의에서 환경 변수를 직접 지정할 수 있지만, 이것은 설정 변수를 용기에 전달하는 가장 좋은 방법이 아닙니다.이것은 안전하지 않습니다. 인프라 시설과 env 변수를 결합시켜 작업 정의를 바꾸고 새로운 배치를 수행해야 합니다.대신 AWS SSM(Simple System Manager) 매개변수 스토리지를 시작하는 동안 환경 변수를 주입해야 합니다.
이것은 안전하고 암호화되며 감사할 수 있고 확장할 수 있으며 관리할 수 있는 중앙 진상 원천으로 ECS뿐만 아니라 Lambda, EC2, CloudFormation 등에도 사용할 수 있다.또한 다른 AWS 서비스와 잘 통합되기 때문에 변수가 바뀌면 이벤트에 반응할 수 있습니다.추가 정보on official AWS blog.

EC2 인스턴스 시작 시 ECS 에이전트 업데이트

> service MY-SERVICE was unable to place a task because no container instance met all of its requirements.

이것이 바로 우리가 어느 날 정지 상태를 조사할 때 본 잘못이다.'왜?'-우리는 줄곧 자신에게 그 문제를 묻고 있다.한동안의 발굴을 거쳐 우리는 근본적인 원인을 찾았다.
AWS는 현장 인스턴스에서 클러스터를 실행하므로 클러스터를 종료하기로 결정했습니다.다행히도, 우리의 자동 축소 그룹은 필요한 수량의 운행 실례를 유지하기 위해 그것들을 다시 만들었지만, 문제가 하나 있다.AMI는 오래된 ECS 에이전트를 설치하여 스토리지에서 SSM 매개변수를 추출할 수 없으므로 작업이 재부팅을 거부합니다.
솔루션EC2 자동 배율 그룹 사용자 데이터에 다음과 같은 간단한 코드 두 줄이 포함되어 ECS 에이전트가 시작된 인스턴스에서 최신 버전인지 확인합니다.

sudo yum update -y ecs-init

# Depending on AMI
### On ECS-optimized Amazon Linux 2 AMI
sudo systemctl restart docker

### On ECS-optimized Amazon Linux AMI
sudo service docker restart && sudo start ecs

사용이 아닌 보존에 따라 인스턴스 확장

service MY-SERVICE was unable to place a task... 잘못 기억하십니까?또 다른 상황은 집단이 그것을 놓을 충분한 자원이 없다는 것일 수도 있다.이것은 CPU 보존율이 80%에 달하지만 사용률이 매우 낮은 수준을 유지해서 확대 작업을 할 수 없는 매우 흔한 상황이다.

일반적인 배율 조정 작업 문제.사용률은 낮지만 보존율은 높다.
이것이 바로 사용량이 아닌 메모리나 CPU 보존량에 따라 그룹을 실행하는 EC2 시스템을 확장하고자 하는 이유입니다.사용자의 서비스는 사용 상황에 따라 확장되어야 합니다. 사용량이 증가함에 따라 자원을 보존하는 수량도 증가합니다. 이것은 베이스 EC2의 자동 축소 그룹 작업을 효과적으로 촉발할 것입니다.

healthcheck 유예 및 냉각 시간 조정

용기가 작동하는 데 얼마나 걸릴지 아는 것이 헬스체크의 기한을 정확하게 조정하는 관건적인 정보이다.만약 너무 급진적으로 설정되어 있다면, 실행 중인 실례는 너무 일찍 건강하지 않다고 표시되고, 실행하기 전에 스케줄러에 의해 죽을 수도 있습니다.이것은 설정과 종료 실례의 끊임없는 순환을 촉발할 것이다.대부분의 경우, 이 기간을 늘리면 너의 문제를 해결할 수 있을 것이다.
다른 한편, 기한을 연장하면 배치가 느려지고 집단이 잘 확장되지 못할 수도 있다.나의 건의는 60초부터 이 양이 충분한지 검사하는 것이다.

보행자 배율 대신 대상 궤적 배율 조정 사용

단계 배율과 달리 단계 배율에서는 확대 또는 축소 작업에 대해 두 개의 임계값을 설정하여 대상 궤적 배율 서비스에서 서비스/인스턴스의 수를 자동으로 계산하여 지정된 값에 도량을 유지하거나 근접하도록 합니다.이것은 더욱 쉽게 설정할 수 있을 뿐만 아니라, 더욱 적은 설정이 필요할 뿐만 아니라, 나의 경험에 따라 더욱 효과적이기 때문이다.

또는 Lambda의 이벤트 사용자 정의 축소 정책을 사용할 수도 있습니다.

AWS가 제공하는 자동 축소 옵션이 사용자의 요구를 충족시키지 못한다면, ECS 이벤트, 지표, 경보에 반응하는 사용자 정의 축소 논리를 항상 Lambda 함수에 포함할 수 있습니다.더 많은 정보를 찾을 수 있습니다here.

다중 AZ로 이동

AZ는 사용 가능한 영역을 나타내며 AZ를 별도의 데이터 센터로 간주할 수 있습니다.역사적으로 우리는 몇 가지 사례whole AWS AZs went down가 있기 때문에 이것은 미래에 발생할 가능성이 높다.그러나 중단 없이 클러스터를 보호하는 것은 매우 간단합니다. 여러 AZ에 시스템을 배치하기만 하면 됩니다.
여러 AZ 관리 클러스터에 대한 Auto Scaling Group 의 가용성은 유연성과 신뢰성을 제공하지만, ECS 스케줄러는 여러 영역에서 이러한 기본 시스템 관리 작업을 할당하여 단일 AZ 장애와 독립적으로 클러스터를 고도로 사용할 수 있도록 합니다.

청록색 배포 구성

공정에서 완전한 민첩성을 실현하는 도전은 엔지니어가 쉽게 배치할 수 있도록 하는 것이지 정지 시간과 팀 전체의 긴밀한 관심을 필요로 하는 임무가 아니다.이것이 바로 푸른색과 녹색 배치가 역할을 발휘하는 곳이다.

배치를 실행할 때 현재 환경/서비스와 완전히 같은 복사본을 생성하고 데이터는 점차적으로 새로운 목표로 이동하며 분당 몇% 증가하여 최종적으로 새로운 단원에서 100%에 도달한다.모든 데이터가 새로운 목표에 도달하고 안정되면 녹색 단원은 은퇴하고 새로운 버전인'파란색'이 새로운 표준, 즉'녹색'이 된다.새 버전이 고장났을 때, 예를 들어 응답량이 너무 많은 400 프로그램은 멈추고, 유량은 녹색으로 완전히 굴러갈 것이다.
이런 방법은 당신의 개발진이 매일 몇 차례의 새로운 버전의 코드를 전송할 수 있도록 합니다. 다운을 걱정하지 않고 오류 코드를 생산 환경으로 전송할 필요가 없습니다.더 많은 정보on official AWS blog를 읽을 수 있습니다.

IaaC 사용

Terraform, Cloudformation 또는 Cloud Development Kit(CDK) 등의 도구는 복제 가능한 방식으로 집단을 제공하는 완벽한 방식이다.클라이언트가 다른 환경이나 동적 실행이 필요한 각 지점의 임시 저장 환경을 요청할 때 특히 유용합니다.이 밖에도 플러그 앤 플레이 방식의 모범 사례에 따라 정교하게 제작된 많은 모듈을 찾을 수 있습니다. 이 모듈들은 클릭만 하면 이런 집단을 만들 수 있습니다.

CloudWatch 로그 사용

어플리케이션의 문제 해결을 쉽게 하려면 항상 컨테이너 STDOUT 로그를 CloudWatch로 전송합니다.containerDefinitions에 다음 행을 추가하기만 하면 됩니다.

"logConfiguration": {
  "logDriver": "awslogs",
  "options": {
    "awslogs-group": "awslogs",
    "awslogs-region": "us-west-2",
    "awslogs-stream-prefix": "awslogs-example"
  }
}

필요한 IAM 권한 추가를 잊지 마십시오.logs:CreateLogGroup, logs:CreateLogStream, logs:PutLogEvents, logs:DescribeLogStreamsCloudWatch에서만 해당 정보를 쉽게 찾을 수 있습니다 Insights.
또한 응용 프로그램 코드에서 로그 줄의 끝을 \n 에서 \r 으로 변경하여 여러 줄 문자열을 하나의 항목으로 저장하는 것을 기억하십시오.이것은 당신의 돈을 절약할 수 있을 뿐만 아니라, 그것들을 더욱 훌륭하게 만들 수도 있다.
만약 당신이 이 글을 좋아한다면, 나의 클라우드 시작을 보십시오 - Dynobase - Professional GUI Client for DynamoDB