실습 3 - 마이크로 서비스의 가용성 및 확장
개요
부트캠프의 이 단원에서는 마이크로 서비스를 항상 사용할 수 있고 수요에
맞게 증가할 수 있도록 보장하는 방법을 다룹니다. 아키텍처의 구성 요소가
작동하지 않는 이유로 한밤중에 단잠에서 깨야 한다면 매우 곤욕스러울
것입니다. Amazon Web Services는 복구를 위해 사람이 개입하지 않아도 될
만큼 손쉽게 고가용성을 위한 설계를 가능하게 해 줍니다. ECS 클러스터를
작동하는 컨테이너 인스턴스와 마이크로 서비스에 자체 복구를 적용하는
방법을 알아보려 합니다.
AWS는 고가용성 외에 확장을 중시합니다. 회사나 개발자가 늘어나는 수요를
뒷받침하지 못하면 얼리 어댑터와 열성적인 고객들은 불만을 갖게 될
것입니다. 신규 업체의 경우 모든 것이 완벽하게 돌아가고 고객에게 만족을
선사해야 하는 순간에 이러한 요인이 매우 중요하게 작용합니다. 이 단계에서
실패하면 서비스에 대한 관심은 있지만 충족이 불가능하기 때문에 손해가 두
배로 늘어납니다. 이런 이유로 서비스와 근본적인 인프라(예: 컨테이너
인스턴스)를 확장할 수 있는 가능성에 초점을 두어야 합니다. 고객이
언제든지 급작스럽게 늘어날 수 있다는 사실을 이해하는 사람이라면 확장을
자동화하는 것이 당연합니다.
실습에는 다음과 같은 몇 가지 활동이 포함됩니다.
필수 조건
본 실습에는 다음 사전 조건이 필요합니다.
- “Amazon ECS에서 컨테이너가 활성화된 마이크로 서비스 실행하기”의 실습
1 및 2 완료
기간
본 실습은 완료하는 데 약 90분이 소요됩니다.
Task 1: EC2 컨테이너 서비스: 클러스터, 서비스
개요
생성된 두 개의 클러스터가 있습니다. 살펴보도록 하죠.
https://console.aws.amazon.com/ecs/를 클릭하여 ECS 콘솔로 이동합니다.
현재 올바른 리전에 있는지 확인합니다.
아래와 같이 최소 두 개의 클러스터가 표시됩니다. CloudFormation에서 접두사가 무작위로 생성되기 때문에 전체 이름은 각기 다릅니다.
JenkinsStack 클러스터를 클릭합니다.
하나의 서비스가 실행되고 있는 것을 확인할 수 있습니다. Tasks 탭을
클릭하면 Jenkins 서비스에 속하는 작업 하나가 표시됩니다.
ECS Instances를 클릭하면 이 ECS 클러스터의 멤버로 컨테이너 인스턴스
하나가 표시됩니다.
이번에는 페이지 상단에서 Clusters를 클릭하고 다음 페이지에서
EcsClusterStack을 클릭합니다.
그러면 MustacheMeInfo, MustacheMeProcessor,
MustacheMeWebServer라는 3개의 서비스가 표시됩니다.
MustacheMeWebServer 서비스를 클릭합니다.
이 페이지에는 이 서비스에 속하는 작업에 사용되는 작업 정의, 작업의
원하는 카운트, 보류 중 및 실행 중 작업의 개수 등 세부 정보가
나옵니다.
하단 창에 Metrics 탭이 있습니다. 서비스의 CPU 및 메모리 사용률을
알려 주는 두 개의 차트가 제공됩니다. 이 차트는 최소값, 평균값, 최대값
단위로 측정됩니다.
서비스 페이지 상단에는 이 서비스가 속한 대상 그룹의 이름이 나와
있습니다. Target Group Name을 클릭해 보십시오.
Task 2: 애플리케이션 로드 밸런서
개요
애플리케이션 로드 밸런서는 Elastic Load Balancing 서비스를 위한 로드
밸런싱 옵션입니다. 애플리케이션 계층에서 작동하고 하나 이상의 Amazon
Elastic Compute Cloud (Amazon EC2) 인스턴스에서 실행되는 여러 서비스
또는 컨테이너의 콘텐츠를 기반으로 라우팅 규칙을 정의할 수 있게
허용합니다.
지금 보고 있는 것은 MustacheMeWebServer 대상 그룹입니다. 이 실습에는
이러한 다른 그룹이 3개 있습니다. 하나는 각 마이크로 서비스, 하나는
Jenkins를 위한 것입니다. 창 상단에는 필터 텍스트 필드가 있습니다.
“X”를 클릭해 활성 필터를 제거하고 모든 대상 그룹 표시를 허용합니다.
하단 창에서 이 그룹에 액세스할 수 있는 포트, 상주하는 VPC, 부착된 로드
밸런서, 일부 추가 구성 및 속성을 볼 수 있습니다.
Targets 탭을 클릭하면 이 그룹에 속하는 대상의 목록을 볼 수 있습니다.
여기에는 하나만 나오며, 정상적인 상태로 표시됩니다.
상태가 언급되었으니 일단 Health checks 탭을 클릭해 보십시오. 이는
대상을 대상 그룹에 추가해야 할지, 대상 그룹에서 제거해야 할지 결정하는
데 사용되는 파라미터입니다.
Description 탭으로 돌아가 Load balancer를 클릭해 보겠습니다.
그러면 애플리케이션 로드 밸런서가 나타납니다. Description 탭에서는
이 로드 밸런서의 DNS 이름에 대한 정보, 로드 밸런서가 인터넷과 접하는지
아니면 프라이빗인지 여부, 적용되는 가용 영역, 액세스를 제어하는 보안
그룹 등을 알려 줍니다.
Listeners 탭을 클릭합니다. 어떤 대상 그룹에 어떤 트래픽이 이동할지
보여 주는 부분입니다. 개념에 익숙해지기 위해서는 이 선 중 일부를
확장해야 합니다.
Description 탭으로 돌아가 보겠습니다. Basic 섹션에서 DNS Name을
강조 표시하고 복사하되, “(A Record)” 부분은 무시합니다.
원하는 브라우저로 이동하고 DNS 이름을 붙여
넣되 끝에 “:8000”을 추가합니다. 그러면 MustacheMe 웹 사이트가
나타납니다.
Task 3: 간편 URL 추가
개요
포트 8000이 항상 웹 서버의 기본값은 아닙니다. 따라서 고객이 특정 포트를
지정하지 않고 웹 사이트를 방문할 경우에도 계속해서 애플리케이션을 편하게
이용할 수 있도록 해야 합니다.
EC2 콘솔 페이지에 있는지
확인합니다.
Load Balancing 아래에서 Load Balancers를 클릭합니다. 로드
밸런서를 선택합니다.
아래 Listeners 탭을 클릭합니다.
4가지 규칙이 있습니다. Load Balancer Port 80에 대한 수신기를
확장합니다.
2가지 규칙이 있습니다. 기본값의 Path Pattern 및 Priority가 비어
있는 규칙의 경우, Actions(맨 오른쪽) 아래의 Edit 버튼을
클릭합니다. Target group name 드롭다운 아래에서 target group을
MustacheMeWebServerTargets로 변경합니다. Actions 아래의
Save를 반드시 클릭해야 합니다. 이렇게 하면 MustacheMeWebServer 대상
그룹의 포트 80에 기본 경로가 생성됩니다.
브라우저로 Load Balancer DNS A 레코드로 이동합니다. 이번에는 :8000을
추가하지 않아도 됩니다. 업데이트가 적용되는 데 몇 초 정도 걸릴 수
있습니다.
Task 4: 로드 밸런서를 통해 API 액세스
개요
웹 서버만 애플리케이션 로드 밸런서를 통해 액세스할 수 있는 것이
아닙니다. 모든 서비스가 ALB를 통해 서로를 호출합니다. 그러므로 올바른
포트를 지정하면 정보 API 마이크로 서비스에 액세스할 수 있습니다.
브라우저를 사용하여 대상 그룹으로 다시 이동합니다. 이 그룹은 EC2 웹
콘솔의 일부이며, Load Balancing \ Target Groups를 통해 액세스할
수 있습니다.
MustacheMeInfoTargets 대상 그룹을 선택합니다. 특정한 포트가 사용되는
것을 확인할 수 있습니다. 이 포트를 메모해 두십시오.
ALB DNS 레코드를 통해 MustacheMe 웹 사이트에 브라우저 창이 아직 열려
있을 수 있습니다. 그렇지 않다면 이제 이 DNS 레코드를 알아서 잘 찾을 수
있을 것입니다. 주소 표시줄에서 ALB DNS 이름과 정보 수신 포트를 결합하고
이동합니다.
- 그러면 기본 nginx 페이지가 나타납니다. 이제 “/infos/instance”를
추가해 수정하고 이동합니다.
JSON 형식의 텍스트로 마이크로 서비스가 실행 중인 인스턴스에 대한 일부 정보가
표시되는 것을 확인할 수 있습니다. 기본적으로 정보 API에서 GET 호출을 한
셈입니다.
Task5: 서비스에 결함 일으키기
작업을 중지하고 그 영향을 확인해 보겠습니다.
ECS 콘솔 페이지로 이동합니다.
EcsClusterStack 클러스터를 클릭합니다.
MustacheMeWebServerStack 서비스를 클릭합니다.
실행 중인 단일 작업이 표시됩니다. 이 작업을 클릭합니다.
작업에 대한 세부 정보를 제공하는 새 페이지가 표시됩니다. 오른쪽 상단
구석에 Stop 버튼이 있습니다. 이 버튼을 클릭합니다.
확인을 요청하는 메시지가 나타납니다. 빨간색 Stop 버튼을 클릭해
확인합니다.
이제 ALB DNS 이름을 통해
MustacheMe 웹 사이트로 돌아가고 브라우저에서 새로 고침을 누릅니다.
브라우저에서 사용 가능한 캐시를 우회하는 전체 페이지 다시 로드 기능을
사용해야 할 수도 있습니다.
- Chrome의 경우 Ctrl + F5또는 Shift + F5를 사용합니다.
- Firefox에서는 Ctrl + F5를 사용합니다.
- Safari에서는 Option 키를 누른 상태에서 도구 모음에서 '다시 로드' 버튼을
누릅니다.
- Internet Explorer의 경우 Ctrl + F5를 사용합니다.
- 웹 서버가 작동
중지되었음을 확인할 수 있습니다. 503 오류 코드가 나타납니다.
이 작업은 서비스를 통해 시작되었기 때문에 ECS가 교체 작업을 표시하기
위해 최대한 빠르게 작동합니다. 그러나 이 서비스에서 실행 중인 작업이 단
하나뿐이기 때문에 서비스에서 작업에 오류가 발생하면 작업을 교체하는
동안에 고객이 MustacheMe의 기능을 충분히 이용할 수 없어 불만이 생길 수
있습니다. 고가용성을 제공하지 못하는 것입니다. 이 문제를 시정해 보도록
하죠.
Task 6: 콘솔을 통해 작업 하나 더 추가
2개 이상의 작업이 실행되도록 유지해 서비스에 고가용성을 제공하려 합니다.
EcsClusterStack의 클러스터 페이지로 돌아가 MustacheMeWebServerStack
서비스를 클릭합니다.
오른쪽 상단 구석에서 파란색 Update 버튼을 클릭합니다.
작업의 개수를 2개로 변경합니다.
Update Service를 누릅니다.
View Service를 누릅니다.
실행 카운트가 Deployments 탭의 원하는 카운트와 일치하는 2가 될
때까지 몇 초 정도 걸립니다. 하단의 표 오른쪽 상단 구석에 있는 새로 고침
버튼을 클릭하여 마지막 업데이트를 받을 수 있습니다.
실행 카운트가 2가 되고 나면 웹 서버의 가용성이 증가합니다. Task 2.1:
실습의 실험을 다시 실행하고 작업 하나가 종료되더라도 웹 서버가 계속해서
작동하는지 확인해야 합니다. 작업을 중지한 후에 MustacheMe 사이트에서
브라우저를 아무리 새로 고쳐도 앞 페이지가 계속해서 나타납니다. 이 방법은
모든 마이크로 서비스에 적용해도 좋을 만큼 유용합니다. 하지만 그러기 전에
해결해야 할 문제가 하나 더 있습니다.
Task 7: “컴퓨팅 손실”
마이크로 서비스에서 실행 중이던 컨테이너 인스턴스가 갑자기 오작동을
일으킨다면 어떤 일이 생길까요? 해결하기에 아직 늦지 않았으니 알아보도록
하죠.
ECS 콘솔 페이지로 이동합니다.
EcsClusterStack 클러스터를 클릭합니다.
ECS Instances 탭을 클릭합니다.
사용 가능한 하나의 컨테이너 인스턴스를 클릭합니다.
표시되는 페이지에 이 컴퓨팅 리소스의 상태에 대한 정보가 나타납니다.
퍼블릭 및 프라이빗 DNS 레코드는 물론 퍼블릭 및 프라이빗 IP 주소도 확인할
수 있습니다. 등록된 리소스와 사용 가능한 리소스도 알아낼 수 있습니다.
EC2 Instance ID 탭을 클릭합니다. 그러면 EC2 콘솔로 이동합니다.
Actions \ Instance State \ Terminate를 클릭합니다.
Yes, Terminate를 클릭해 확인합니다.
ALB DNS 이름을 통해 MustacheMe 웹 사이트로 이동하고 브라우저에서 새로
고침을 누릅니다. 이번에도 브라우저에서 사용 가능한 캐시를 우회하는 전체
페이지 다시 로드 기능을 사용해야 합니다.
- Chrome의 경우 Ctrl + F5 또는 Shift + F5를 사용합니다.
- Firefox에서는 Ctrl + F5를 사용합니다.
- Safari에서는 Option 키를 누른 상태에서 도구 모음에서 '다시 로드' 버튼을
누릅니다.
- Internet Explorer의 경우 Ctrl + F5를 사용합니다.
- 503 오류 코드가 표시됩니다.
웹 사이트가 작동 중지되었습니다. 고객의 사용 경험이 저하되고
MustacheMe에 대한 만족도가 줄어듭니다.
- EC2 콘솔에서 왼쪽 열에 있는 Auto Scaling Groups를 클릭합니다. 왼쪽
열을 아래로 스크롤해야 할 수도 있습니다.
Auto Scaling 그룹 대시보드가 표시될 경우 Create Auto Scaling group 버튼
위에 Auto Scaling Groups: <number> 링크가 있습니다. 이 링크를
클릭합니다.
-
Auto Scaling 그룹 중 하나의 이름이 EcsClusterStack입니다. 전체 이름을
보려면 첫 번째 열을 확장해야 할 수도 있습니다. EcsClusterStack Auto
Scaling 그룹을 선택해 하단에 있는 창을 표시합니다. Instances 탭을
클릭합니다. 순간적으로 비정상적인 인스턴스가 눈에 띌지도 모릅니다.
그렇지 않다면 이미 교체되어 사라진 것입니다.
ECS 클러스터는 Auto Scaling 그룹에 속하는 EC2 인스턴스로 채워집니다.
이는 AWS가 시작 구성에 따라 원하는 만큼 많은 인스턴스를 생성한다는
뜻입니다.
몇 분 정도 지나면 새 인스턴스가 이 Auto Scaling 그룹의 일부가 되었음을
확인할 수 있습니다. 이제 ECS 콘솔로 돌아가 보겠습니다.
올바른 클러스터를 보고 있고 Services 탭에 초점이 맞춰 있는지
확인하십시오. 실행 작업 수가 점점 원하는 작업에 맞춰지는 것을 볼 수
있습니다. 몇 분에 한 번씩 새로 고침 버튼을 눌러도 됩니다. MustacheMe 웹
앱이 되살아난 것입니다.
방금 전까지 정전을 시뮬레이션해 보았습니다. Auto Scaling 그룹과 ECS
서비스의 장기 실행 기능 덕분에 애플리케이션이 몇 분 만에 복구되기는
했지만, 고객에게는 단 몇 분의 작동 중지 시간이라도 허용돼서는 안 됩니다.
Task 8: 다중 AZ
Well Architected
Framework의
안정성 기준에 따라 가용 영역 전체에 EC2 인스턴스를 배치해야 합니다.
다행히 Auto Scaling 그룹은 이러한 목적에 맞게 설계되었습니다.
EC2 콘솔로 이동합니다.
왼쪽 열 하단에서 Auto Scaling Groups를 클릭합니다.
이름이 EcsClusterStack인 ASG 를 선택합니다.
Activity History 탭을 클릭합니다. 몇 초 전에 새 EC2 인스턴스가 시작된 것을 확인할 수 있습니다.
Details 탭을 클릭합니다. 이 ASG에는 인스턴스가 하나밖에 없습니다. 수정해 보도록 하죠.
맨 오른쪽에 있는 Edit을 클릭합니다.
Desired를 2로, Max를 2로 변경합니다. 그런 다음 맨 오른쪽에 있는
Save를 클릭합니다.
Activity History 탭을 클릭하고 ASG의 상태를 모니터링합니다. 새로
고침 버튼을 눌러 새 인스턴스 시작 상태가 성공에 이를 때까지 기다려
보십시오.
Auto Scaling 그룹에 인스턴스가 2개 있다는 것이 확인되면 ECS 콘솔로
돌아가 EcsClusterStack 클러스터로 이동합니다. 새 인스턴스가 부팅 이후에
곧바로 클러스터에 자체 등록되면 Registered container instances
카운트가 2로 바뀝니다. 새로 고침 버튼을 두 번 정도 눌러야 할 수도
있습니다.
Registered container instances 카운트가 2가 되면
MustacheMeWebServerStack 서비스를 클릭합니다. 두 작업 모두 같은
인스턴스에서 실행되는데, 이 또한 수정해야 합니다. 표에서 각 Task
ID를 클릭하고 Details에서 EC2 instance id를 참조하여 확인할 수
있습니다.
오른쪽 상단 구석에 있는 Stop 버튼을 눌러 세부 정보를 살펴보고
Stop을 다시 눌러 확인하는 동안 작업 중 하나를 중지합니다(어떤 작업을
선택하는지는 중요하지 않음).
이제 MustacheMeWebServerStack 서비스에서 ECS Instances 탭을
클릭합니다.
표시되는 두 인스턴스의 사용 가능한 CPU를 통해 서비스에 두 개의
인스턴스에서 실행되는 작업이 두 개 있음을 추측할 수 있습니다. 서비스
세부 정보에서 각 작업을 살펴보고 두 작업의 인스턴스 ID를 찾아 이를
확인할 수도 있습니다.
Task 9: 가용성이 높은 정보 서비스 배포
서비스 중 하나에 대한 파라미터를 수정해 보죠. 이를 위해서는 CLI
인스턴스에 연결해야 합니다.
CLI 인스턴스의 IP 또는 DNS 이름을 찾습니다. EC2 콘솔에서 찾을 수
있습니다.
-
SSH로 CLI 인스턴스에 접속합니다.
코드 복사 블록ssh –i <자신의 KEY.PEM> ec2-user@<자신의 EC2 인스턴스 퍼블릭 DNS 이름>
-
해당 로컬 리포지토리(git-repos/mustachemeinfo)로 이동합니다.
코드 복사 블록cd ~/git-repos/mustachemeinfo
-
즐겨 사용하는 편집기에서 microservice.template를 엽니다.
코드 복사 블록nano microservice.template
이 템플릿에는 MustacheMeInfo 서비스를 작업 1개에서 2개로 확장하기 위해
1에서 2로 변경할 수 있는 변수가 있습니다. 힌트: 변수 이름에
“Desired”라는 단어가 있습니다.
-
편집을 마쳤으면 파일을 저장하고 변경 사항에 대해 git add, commit, push를
실행합니다.
코드 복사 블록git add * && git commit -m "scaling microservice from 1 to 2 tasks" && git push
AWS CodePipeline을 방문해 코드에서 변경한 사항이 원하는 소스 모음,
Docker 이미지 구축, 최종적으로 배포를 트리거했는지 확인할 수 있습니다.
파이프라인을 통해 배포가 완료되면 EcsClusterStack 클러스터에서 실행되는
MustacheMeInfoStack 서비스를 방문해 2개의 작업이 이 서비스를 구동하고
있는지 확인할 수 있습니다(Desired count 및 Running count 모두
2임).
Task 10: 모두 고가용성으로 만들기
회복력이 높은 서비스 하나로도 좋겠지만, 모든 서비스가 그러하다면 훨씬 더
나을 겁니다. 서비스가 원하는 2개의 작업으로 시작되도록 템플릿을 변경하는
방법은 이미 잘 알고 있습니다. 이 방법을 모든 마이크로 서비스에 적용해야
합니다.
이전 단계를 반복해 모든 마이크로 서비스에 각각 2개의 작업을 가져옵니다.
실행 중인 작업이 원하는 개수보다 많다고 해서 놀라지 마십시오. 우리가
선택한 배포 메커니즘은 정상 상태에서 100% 최소 백분율과 200% 최대
백분율로 작동합니다. 즉, 실행 중인 작업의 총 수를 늘려도 배포 중에
원하는 실행 작업을 100% 유지할 수 있습니다.
Task 11: CloudWatch 경보를 기반으로 서비스를 자동으로 확장
확장할 수치는 TargetResponseTime입니다. 트리거를 기준으로 작업을 확인할 수 있도록
확장에 비정상적으로 낮은 임계값을 사용하도록 합니다. [[[]{#OLE_LINK30
.anchor}]{#OLE_LINK29 .anchor}]{#OLE_LINK28 .anchor}이제 이 Auto Scaling
메커니즘을 정의해 보겠습니다.
EC2 콘솔로 이동합니다.
왼쪽 열에서 Load Balancing 아래의 Target Groups를 클릭합니다.
MustacheMeProcessorTargets 대상 그룹을 선택합니다.
아래 정보 섹션에서 Monitoring 탭을 클릭합니다.
정보 섹션 오른쪽 상단에 있는 Create Alarm을 클릭합니다.
Send a notification to 확인란의 선택을 취소합니다.
Whenever 드롭다운을 Average Latency의 Average로 설정합니다.
Is >=을 0.05초로 설정합니다.
For at least 점검 기간을 1 consecutive period 1분으로 유지하고,
Name of the alarm을 기본값으로 둡니다(단, 아래 사용할 경보 이름을
적어 둘 것).
Create Alarm을 클릭한 후 대화 상자를 닫습니다.
이제 ECS 콘솔로 이동합니다.
EcsClusterStack 클러스터를 클릭합니다.
MustacheMeProcessorStack 서비스를 클릭합니다.
Update 버튼을 클릭합니다.
왼쪽 하단에서 Configure Service Auto Scaling을 클릭합니다.
Configure Service Auto Scaling to adjust your service’s desired
count를 선택합니다.
고가용성을 위해 Minimum number of tasks를 2로 설정합니다.
이전 단계에서 설정한 대로 Desired number of tasks가 2로 설정되어
있어야 합니다.
Maximum number of tasks를 10으로 설정합니다.
IAM role for Service Auto Scaling에 대해 드롭다운 형태로 제공되는
부트캠프에서 생성한 IAM 역할을 선택합니다.
Add scaling policy를 클릭합니다.
원하는 정책 이름을 부여합니다(공백은 허용되지 않음).
Execute policy when에 대해 Use an existing Alarm을 선택하고
위에서 생성한 경보 이름을 드롭다운에서 선택합니다.
Scaling action에서 작업을 1 개 더 추가하려 한다고
표시합니다(0.05이 이미 설정되어 있어야 함).
Cooldown period를 300 초에서 30 초로 줄입니다.
Save를 클릭합니다.
새 확장 정책이 Automatic task scaling policies 아래에 나열되어
있는지 확인하고 Save를 다시 한 번 클릭합니다.
새 서비스 설정과 구성을 검토하고 Update Service를 클릭합니다.
성공적으로 완료된 항목의 목록이 표시됩니다.
이제 CloudWatch 콘솔로
이동합니다. 왼쪽의 Alarms를 클릭합니다. CloudWatch 경보에 대한 퀵
레슨: 경보가 INSUFFICIENT_DATA 상태로 남아 있을 수 있습니다. 현재
사이트로 들어오는 트래픽이 없기 때문에 보고할 수치가 없으면 CloudWatch
경보가 기본적으로 INSUFFICIENT_DATA 상태로 설정되므로 이는 정상적인
현상입니다. 브라우저로 돌아가 MustacheMe 앱을 방문하고 어떻게 달라졌는지
살펴보십시오. CloudWatch 콘솔을 다시 확인해 보고 1분 정도 기다리면 경보
상태가 OK로 바뀝니다(경보 상태를 몇 차례 새로 고쳐야 할 수도 있음).
상태가 ALARM으로 바뀌면 경보가 트리거된 것이며, 마이크로 서비스의 로드를
시뮬레이션하는 다음 단계로 넘어갈 수 있습니다.
Task 12: 몇 번의 클릭으로 마이크로 서비스 오버로드
직접 부여한 경보 임계값의 경우(0.05초보다 크거나 같은 응답 시간), 서비스
확장을 위해 분산된 서비스 거부가 필요하지 않습니다. 서비스를 몇 차례
이용하기만 하면 됩니다. 실제로 위의 단계에서 이미 경보를 트리거했을지도
모릅니다. 그렇지 않다면 조금 더 기다려 보십시오.
MustacheMe에 대한 ALB A 레코드로 브라우저를 이동합니다.
페이지를 몇 번 다시 로드하고 애플리케이션에 여러 개의 그림을 공급합니다.
CloudWatch를 방문해 경보가 발동되었고 조치가 취해졌는지 확인합니다.
힌트: 경보의 History 탭 아래를 확인해 보십시오.
Task 13: 관련 경보를 생성해 시작
여기서는 경보의 기준을 클러스터 수준의 예약된 전체 CPU에 두도록
하겠습니다.
ECS 콘솔로 이동합니다.
EcsClusterStack을 클릭합니다.
아래 Metrics 탭을 클릭합니다.
CPUReservation 그래프 이름을 클릭합니다. 그러면 이 특정한 CloudWatch
수치로 연결되는 브라우저 링크가 열립니다. 직접 경보를 생성할 수 있는지
알아보십시오. 1회 연속되는 1분의 기간 동안 예약된 클러스터의 CPU 중
70%에서 경보를 트리거하려고 한다고 가정해 보십시오. 아직 Actions가
설정되지 않았으므로 지금은 연관된 작업을 삭제해야 합니다.
Task 14: 확장 정책 생성
새로 생성된 CPU 예약 경보에서 조치를 취할 차례입니다.
EC2 콘솔로 이동합니다.
왼쪽 하단의 Auto Scaling Groups를 클릭합니다.
EcsClusterStack 그룹을 선택합니다.
다른 동작을 하기 전에 Auto Scaling 그룹이 인스턴스 2개를 넘어 확장될 수
있는지 확인해야 합니다. Details 탭을 클릭합니다.
Edit을 클릭하고 Max를 4로 변경한 후 Save 버튼을 누릅니다.
Scaling Policies 탭을 클릭합니다.
Add policy를 클릭합니다.
정책에 이름을 부여합니다.
Execute policy when 드롭다운을 위에서 생성한 경보로 설정합니다.
Take the action은 Add 1 instance when 70 <=
CPUReservation으로 설정해야 합니다.
Instance need를 120 seconds to warm up으로 설정합니다.
Create를 클릭합니다.
리소스 소비량이 늘어나면 CloudWatch를 살펴보고, 클러스터(ECS 콘솔)에서
ECS 인스턴스의 개수와 EC2 콘솔의 Auto Scaling 그룹 부분에서 Activity
History 탭을 확인할 수도 있습니다.
실습 3을 마쳤습니다. 축하합니다!
