7. 오토스케일링

petclinic 서비스가 잘 되면서 가끔 감당하기 어려운 트래픽이 오는 경우가 생겼습니다. 그래서 트래픽이 늘어나는 경우를 대비하여 오토스케일링이 되도록 설정하려고 합니다.

오토스케일링은 굉장히 까다로운 작업입니다. 해당 서비스의 특성, 트래픽의 특성 등을 고려하여 정책을 결정해야 합니다. 특히 EC2 기반의 ECS 인프라에서는 서비스의 오토스케일링뿐 아니라 ECS 컨테이너 인스턴스(EC2)에 대한 오토스케일링까지 고려해야 하기 때문에 굉장히 까다롭습니다. 그리고 늘어나고 줄어드는 것을 확인하는데 오랜 시간이 필요합니다. 최대한 쉬운 방식으로 진행할 것이며 여유를 가지고 따라해보시기 바랍니다.


7.1 서비스 오토스케일링

시작하기에 앞서 두가지 조정Scaling 정책에 대해서 알아보겠습니다.

첫 번째는 대상 추적 정책입니다.

 "특정 측정치에 대한 대상 값을 기준으로 서비스가 실행하는 작업의 수를 늘리거나 줄입니다. 이 과정은 온도 조절기를 사용하여 집안 온도를 유지하는 방법과 비슷합니다. 사용자가 온도를 선택하면 나머지는 모두 온도 조절기에서 자동으로 수행됩니다."

예를 들어 CPU 사용량 지표값이 50%가 되도록 대상추적 정책을 정했다면 작업을 늘이거나 줄이면서 50%를 유지하도록 합니다.

첫 번째는 단계 조정 정책입니다.

 "일련의 조정 조절(경보 위반의 크기에 따라 달라지는 단계 조절)을 기준으로 서비스가 실행하는 작업의 수를 늘리거나 줄입니다."

예를 들어, CPU 사용량이 50~60%가 되면 인스턴스를 20% 증가시키고 60~80%가 되면 인스턴스를 40%를 증가시키는 식의 구체적인 기준을 가지고 작업이 늘어나고 줄어듭니다.

대상 추적 정책이 단계 조정 정책에 비해서 비교적 쉽습니다. 왜냐하면 단계 조정 정책은 사용자가 구체적인 기준을 모두 정해야하기 때문입니다. 그 기준을 정하는 것 자체가 많은 시행착오가 필요합니다. 그래서 우리는 대상 추적 정책으로 서비스 오토스케일링을 진행할 것입니다.

그전에 작업 정의를 업데이트하겠습니다. 현재 작업에 전체에 대해서 1024MiB로 제한을 걸었는데 이것을 컨테이너의 소프트 제한(625MiB)만 걸고 작업 정의 전체의 제한은 풀도록 하겠습니다. 그 이유는 인스턴스 메모리가 4GiB(4096MiB)라고 되어 있지만 작업 입장에서 인스턴스의 가용 메모리가 4GiB보다 조금 작기 때문입니다. 그렇기 때문에 엄격하게 작업마다 1024MiB를 예약하게 되면 인스턴스 안에서 4개의 작업을 실행할 수 없습니다. (모니터링에서 인스턴스의 메모리 예약 크기가 25.9%로 나온것입니다.) 최신 작업 정의를 선택하여 [새 개정 생성]을 클릭합니다. 작업 메모리 입력 영역을 비우고 생성합니다.


그림 7-1



이제 계산을 해보겠습니다. 우리의 컴퓨팅 자원을 생각해보면 t2.medium 인스턴스가 2대가 있습니다. 총 4vCPU와 8GiB의 자원이 있습니다. 그리고 평상시에 예약하고 있는 자원을 생각해보면 작업 2개가 총 1vCPU와 1250MiB(컨테이너 소프트제한)를 예약하여 사용하고 있습니다. 한 인스턴스 내에서 4개의 작업이 실행 가능합니다. 이제 오토스케일링 설정을 진행하겠습니다.

ECS 웹 콘솔 클러스터 메뉴에서 ‘petclinic-rest-cluster’를 선택하고 서비스 탭에서 ‘petclinic-rest-service’를 선택합니다. 그리고 우측 상단에 업데이트를 클릭합니다.


그림 7-2



서비스 구성과 네트워크 구성은 그대로 두고 오토스케일링 구성으로 넘어갑니다. 오토스케일링을 구성하는 라디오 박스를 선택합니다. 최소 작업 개수는 2개로 설정하고 원하는 작업 개수도 2개로 설정합니다. 그리고 최대 작업 개수를 8개로 설정합니다.


그림 7-3



그다음 조정 정책을 추가합니다.


그림 7-4


앞서 설명한 대상 추적을 선택합니다. 정책 이름에는 ‘cpu-target-tracking-55percent-policy’라고 입력합니다. 서비스 측정치는 ECS 서비스의 평균 CPU 사용량입니다. 대상값을 55로 입력합니다. 55%에 대해서 항상성을 유지하도록 노력할 것입니다. 확장 휴지 기간과 축소 휴지 기간은 150초로 설정합니다. 기본값은 300초인데 5분을 좀 더 동작하도록 반으로 줄였습니다. 그리고 저장합니다.


그림 7-5


저장 후에 다음 단계로 넘어갑니다. 검토를 하고 업데이트를 마무리합니다. 완료가 되면 ECS 서비스 화면의 오토스케일링 탭에서 정보를 확인할 수 있습니다. 오토스케일링의 동작에 중요한 역할을 하는 경보Alarm가 만들어졌습니다. CloudWatch 웹 콘솔에서 경보 메뉴를 클릭해봅니다.


그림 7-6



경보를 이해하기 위해서는 기간, 평가 기간Evaluation Period, 경보에 대한 데이터 포인트Datapoints to Alarm에 대해서 알 필요가 있습니다.

기간은 해당 지표를 평가하는 시간입니다. 현재 오토스케일링 경보의 경우에는 기간이 1분으로 설정되어 있습니다. 1분에 한번씩 지표값을 확인합니다.

평가 기간은 경보 상태를 결정할 때 평가할 가장 최근 데이터 포인트의 수입니다. ‘petclinic-rest-service-AlarmHigh’의 경우에는 3분으로 설정되어 있습니다. 최근 3분 동안을 평가한다는 의미입니다.

경보에 대한 데이터 포인트는 평가 기간 동안 임계값을 몇 번 넘었는지 나타내는 수입니다. ‘petclinic-rest-service-AlarmHigh’의 경우에는 평가 기간은 3분이고 경보에 대한 데이터 포인트는 3개 입니다. 즉 최근 3분 내내 임계값을 넘게 되면 경보를 울리게 됩니다. 만약 평가 기간이 5분이고 경보에 대한 데이터 포인트가 3개라면 5분 동안 3번만 임계값을 넘으면 되고 연속적일 필요는 없습니다.

앞서 기술하였듯이 ‘petclinic-rest-service-AlarmHigh’는 3분(평가기간) 동안 1분(기간)에 한번씩 3번(경보에 대한 데이터 포인트) CPU 사용율이 55%를 넘게 되면 작업을 추가적으로 실행합니다.

‘petclinic-rest-service-AlarmLow’는 15분 동안 1분에 한번씩 15번 CPU 사용율이 49.5% 이하가 되면 작업들을 줄이기 시작합니다. 이 값들은 대상값을 55%로 입력하게 되면 자동으로 설정됩니다.

이제 테스트를 위해서 서버에 부하를 주도록 하겠습니다. Cloud9 터미널에 접속합니다. ab라는 명령어를 통해서 부하를 줄 것입니다.

ab -n {총횟수} -c {동시에 요청하는 개수} {로드밸런서 DNS 이름}/test/stress


총 회수는 1만 회입니다. 동시에 5개씩 요청을 보냅니다. 주소는 로드밸런서의 DNS 이름 뒤에 ‘/test/stress’라고 붙이면 됩니다. 어떻게 부하를 주는지는 Cloud9에서 petclinic-rest → src → main → java → vw → demo → petclinic → interfaces → tests → StressTestController.java 파일을 확인해보시면 알 수 있습니다. 한번 호출하면 보통 2~4초 걸리는 요청이기 때문에 이 명령어를 완료하려면 1시간 이상이 걸립니다.


그림 7-7



여유를 가지고 기다려 보면 CPU의 사용량이 증가하는 것을 확인할 수 있습니다. ECS 서비스 화면에서 이벤트 탭을 모니터링합니다. 곧 경보가 발생하고 경보에 의해서 작업 개수desired count가 변경되는 것을 확인할 수 있습니다.


그림 7-8



약 한시간 뒤에 CloudWatch의 경보 화면을 확인해 보았습니다. 트래픽은 계속 들어오고 있으며 CPU 사용률이 줄어들긴 했지만 우리가 원하는 만큼(55%) 줄어들지는 않았습니다. 작업은 더 이상 실행할 수 없습니다. 이제는 컨테이너 인스턴스를 더 추가해야 할 때입니다.


그림 7-9


인스턴스를 추가해보겠습니다. ECS 웹 콘솔 클러스터 메뉴에서 ‘petclinic-rest-cluster’를 선택하고 ECS 인스턴스 탭을 클릭합니다. ECS 인스턴스 조정 버튼을 클릭합니다.


그림 7-10


그리고 원하는 인스턴스 개수를 3개로 늘립니다.


그림 7-11


조금 시간이 지나면 인스턴스가 생성됩니다.


그림 7-12



서비스 업데이트를 통해서 최대 작업 개수를 12개로 업데이트합니다.


그림 7-13



바로 작업 개수를 10개로 늘리는 것을 확인할 수 있습니다.


그림 7-14


이제 10000개의 리퀘스트가 종료되었습니다. 만약 아직도 실행 중이라면 꺼보겠습니다. 그리고 실제로 줄어드는지 확인해 보겠습니다. 트래픽이 멈춘지 30분 쯤 지난 시점으로 5개로 줄어들었습니다. 하나씩 하나씩 줄이고 있습니다.


그림 7-15


7.2 ECS 인스턴스 오토스케일링

트래픽이 계속 늘어나고 서비스가 더 이상 추가적으로 작업을 실행할 수 없을 때 ECS 인스턴스를 추가해야 합니다. 이전 단계에서는 ECS 클러스터의 ECS 인스턴스 탭에서 수동으로 개수를 추가했습니다. 이번에는 서비스 오토스케일링처럼 ECS 인스턴스에 대해서 오토스케일링을 해보겠습니다.

이 장의 도입부에서 미리 설명했듯이 서비스의 오토스케일링과 ECS 오토스케일링을 동시에 하려면 굉장히 복잡하고 테스트하기도 쉽지 않습니다. 최대한 쉬운 방식으로 트래픽을 견디도록 ECS 인스턴스 오토스케일링을 설정해보겠습니다.

EC2 웹 콘솔에서 오른 쪽 하단의 메뉴 중에서 [Auto Scaling 그룹]이라는 메뉴를 클릭합니다. ECS를 생성할 대 CloudFormation을 통해서 자동으로 오토스케일링 그룹이 생성되었습니다.

‘EC2ContainerService-petclinic-rest-cluster-EcsInstance…’라는 이름을 확인할 수 있습니다. 선택하면 세부 정보 탭에서 정보들을 확인할 수 있습니다.


그림 7-16


활동 기록 탭은 ECS 서비스 화면의 이벤트 탭과 비슷합니다. 인스턴스가 실행되고 종료되는 등의 상태를 확인할 수 있습니다. 조정 정책 탭은 오토스케일링 조정 정책을 생성하는 곳입니다. 조정 정책은 서비스 오토스케일링과 마찬가지로 단계 조정 정책, 대상 조정 정책이 있고 추가적으로 단순 조정 정책이 있습니다. 인스턴스 탭에서는 현재 인스턴스들을 확인할 수 있습니다.

우선 세부 정보를 수정하겠습니다. 탭 우측 상단에 편집 버튼을 클릭합니다. 목표 용량을 2, 최소 2, 최대 4를 입력합니다. 최소가 0 이면 인스턴스가 모두 종료되어 서비스도 종료될 수 있습니다. 기본 휴지는 150초로 설정하여 좀 더 빨리 진행할 수 있도록 수정했습니다. 마치고 저장합니다.


그림 7-17


그다음 조정 정책 탭을 선택하고 새로운 조정 정책을 만들어 보겠습니다. 탭 바로 아래에 있는 정책 추가 버튼을 클릭합니다. 기본값이 대상 조정 정책입니다. 이름은 ‘cpu-55percent-policy’라고 입력합니다. 대상 값은 55, 인스턴스 필요 시간은 0으로 합니다. 인스턴스 필요 시간은 인스턴스가 실행된 후 워밍업하는 시간인데 우리는 워밍업할 필요가 없기 때문에 0이라고 입력합니다.


그림 7-18


조정 정책을 생성하고 나면 경보가 생성됩니다. AlarmHigh는 ‘3분 이내에 3개의 데이터 포인트에 대한 CPUUtilization > 55’이며 AlarmLow는 ‘15분 이내에 15개의 데이터 포인트에 대한 CPUUtilization < 41.25’입니다. 서비스 오토스케일링과 비교하여 High는 같은 조건인데 Low는 더 작습니다. (서비스 AlarmLow: 49.5)


그림 7-19


그리고 ECS 서비스의 최대 작업 개수도 16개로 수정해줍니다. 왜냐하면 이제 ECS 인스턴스 오토스케일링을 통해서 최대 4개의 인스턴스가 실행될 수 있기 때문입니다.


그림 7-20


이제 서비스에 부하를 주도록 하겠습니다. 아까랑 같은 명령어에서 이번에는 더 긴 시간 동안 더 더 많은 트래픽을 주려고 합니다. 그래서 전체 10만 개를 동시에 6번씩 요청하도록 하겠습니다.


그림 7-21


이제 또 여유를 가지고 기다려봅니다. 틈틈히 ECS 서비스의 이벤트 탭과 EC2 오토스케일링 그룹 메뉴의 활동 기록 탭, 그리고 CloudWatch에서 클러스터 cpu 사용량과 서비스 cpu 사용량 지표를 동시에 확인해봅니다.

30분 뒤에 확인을 해봤습니다. 서비스 이벤트를 확인해보면 계속해서 작업 개수가 증가했습니다. 차례로 2개의 ECS 인스턴스가 실행이 되었고 총 13개의 작업이 동시에 실행되고 있습니다. 그리고 그 이후에는 안정적인 그래프를 그리고 있습니다.


그림 7-22


이제 트래픽을 끄고 다시 확인해보겠습니다. 서비스나 인스턴스가 빠질 경우 Alarm의 평가 기간이 15분 이므로 여유를 가지고 기다려봅니다. 50분 뒤에 확인해보았습니다.


그림 7-23


약 36분 부터 트래픽이 없는 상태가 되었고 15분 뒤에 인스턴스가 하나 종료되었습니다. 그 뒤에 휴지 기간 이후에 다른 인스턴스도 종료되었습니다.


그림 7-24


인스턴스 종료 이후에 작업 개수가 줄어들기 시작했습니다. 결국 2개로 돌아왔습니다.


그림 7-25


이렇게 인스턴스 오토스케일링과 서비스 오토스케일링을 동시에 설정하고 테스트해보았습니다. 지금은 단순한 트래픽 패턴에 단순한 정책으로 테스트를 해보았지만 사실 많은 경우의 수가 있고 그에 대해서 대비할 수 있어야합니다. 앞서 설명했듯이 트래픽의 패턴과 서비스의 특성에 맞게 정책을 잘 수립하고 노하우를 쌓아야 합니다.

사실 많은 사람들이 EC2 기반의 오토스케일링이 어렵기 때문에 Fargate를 추천합니다. 여기까지 잘 따라 오셨다면 Fargate는 쉽게 하실 수 있을 겁니다.