안녕하세요 클래스메소드의 수재입니다.
EC2를 이용한 웹 서비스를 운용하는 경우 갑작스런 부하 증가에 대응하기 위해 AutoScaling을 이용하는 경우가 많습니다.
EC2 AutoScaling이란 무엇인지 그리고 모범 사례나 주의 사항 등에 대해 알아보도록 하겠습니다.
글을 읽기 전에
이번 글에서는 EC2 AutoScaling이 무엇인지 그리고 모범 사례나 주의사항에 대해 알아봅니다.
따라서 실제로 작성하는 방법 등은 기재하고 있지 않습니다.
작성 방법은 공식 문서를 참고해주세요.
EC2 AutoScaling 이란?
Amazon EC2 Auto Scaling을 사용하면 애플리케이션의 로드를 처리할 수 있는 정확한 수의 Amazon EC2 인스턴스를 유지할 수 있습니다 - 공식 문서
EC2를 이용할 때 일정한 수의 인스턴스를 유지할 수 있도록 수를 조절하는 작업을 스케일링(Scaling)이라고 하며 작성된 정책을 통하여 Scaling을 자동으로 유지하는 것을 AutoScaling이라고 합니다.
AutoScaling을 적용하기 위한 인스턴스의 모음을 AutoScaling Group(이하 ASG)이라고 합니다.
Group에는 최소 인스턴스 수(Minimum size), 최대 인스턴스 수(Maximum size), 원하는 인스턴스 수(Desired Size)를 정할 수 있습니다.
예를 들어 최대가 4, 최소가 1, 원하는 수가 2 이라면 처음에 2대의 인스턴스로 시작하며 Scaling 정책이나 예약된 작업이 없다면 이 수를 유지합니다.
ASG에서 확장(Scale Out)이 발생하면 최대 4대까지 인스턴스가 증가하고 축소(Scale In)이 발생하면 최소 1대의 인스턴스는 유지하도록 설정됩니다.
Scale Up?Out?In?
서버 및 인스턴스를 운용할 때 부하가 증가하면 서버의 사양을 늘리거나 숫자를 늘리는 경우가 많습니다.
AWS에서는 사양을 올리는 것을 Scale Up 이라고 하며 숫자를 늘리는 것을 Scale Out, 숫자를 줄이는 것을 Scale In 이라고 합니다.
장점
AutoScaling을 이용하면 탄력적으로 리소스를 늘리고 줄일 수 있는 클라우드 환경의 장점을 가장 잘 누릴 수 있습니다.
공식 문서에서는 AutoScaling의 장점으로 다음을 소개하고 있습니다.
- 내결함성
- 가용성
- 비용 최적화
자동으로 비정상인 인스턴스를 감지하면 새 인스턴스로 교체할 수 있습니다. 또한 여러 가용 영역을 사용하도록 구성할 수 있기 때문에 한 가용 영역에서 문제가 발생하면 정상 가용 영역에 인스턴스를 시작하여 서비스를 유지할 수 있습니다.
애플리케이션이 항상 현재 트래픽 수요를 처리할 수 있는 적절한 용량을 갖도록 조절할 수 있습니다. 이는 사용자가 작성하는 정책에 따라 유동적으로 변경할 수 있습니다.
이를 통해 리소스를 필요한 만큼만 유지하기에도 용이합니다.
구성 요소
AutoScaling Group(이하 ASG)
자동 조정 및 관리를 위해 논리적 그룹으로 처리되는 EC2 인스턴스 모음을 뜻합니다.
ASG는 어떠한 인스턴스가 비정상이 되면 새로운 인스턴스를 시작한뒤 교체하여 고정된 수의 인스턴스를 유지합니다.
Launch Template(시작 템플릿)
AMI ID, 인스턴스 유형, 키 페어, 보안 그룹 및 기타 매개변수 등 인스턴스 구성 정보를 지정하는 템플릿입니다.
생성 후 구성 요소를 변경할 수 있으며 버전 관리도 지원하기 떄문에 재사용도 용이합니다.
Scaling Plan(스케일링 정책)
EC2 Auto Scaling은 그룹을 확장하는 스케일링 정책(=확장 정책)을 제공합니다.
- 수동 조정 : ASG에 인스턴스를 수동으로 연결하거나 분리합니다. ASG는 초기 크기로 유지되며 동적으로 변화하지 않습니다.
- 단계 크기 조정 : 특정 지표의 여러 임계값을 지정하고 각 임계값에 도달하면 조정 작업을 수행합니다.
- 단순 크기 조정 : 특정 인스턴스 수 또는 비율만큼 그룹 용량을 줄이거나 늘립니다.
- 대상 추적 크기 조정 : 지정된 로드 지표 대상 값에 따라 동적 크기 조정을 활성화합니다. CPU 사용률, 메모리, 네트워크 입/출력 등과 같은 특정 매개변수를 기반으로 리소스를 축소하거나 확장할 수 있습니다.
- 일정에 따라 조정 : 특정 날짜 및 시간 동안 조정 이벤트를 수행합니다. 예를 들어 애플리케이션 트래픽이 높아지는 시기를 정확히 아는 경우 해당 시간에 인스턴스를 확장하도록 지정합니다.
수명 주기
ASG의 EC2 인스턴스는 다른 EC2 인스턴스와 수명 주기가 다릅니다.
ASG에서 인스턴스를 시작하거나 인스턴스가 그룹에 수동으로 추가되면 수명 주기가 적용됩니다.
인스턴스가 종료되거나 그룹이 인스턴스를 제거하고 종료하면 수명 주기가 종료됩니다.
모범 사례 및 주의 사항
절대적인 모범 사례는 없지만 제가 생각하기에 모범 사례라 생각되는 내용들을 소개하겠습니다.
필요에 맞는 헬스 체크 유형 선택
Auto Scaling은 그룹 내의 인스턴스 및 ELB에 대해 정기적인 상태 확인을 수행합니다.
인스턴스가 정상이 아니면 해당 인스턴스를 Terminate(삭제)하고 새 인스턴스를 시작합니다.
헬스 체크에는 EC2 타입과 ELB 타입이 있습니다.
EC2 타입은 EC2의 상태가 running이 아니거나 시스템 상태가 impaired인 경우 정상적이지 않은 것으로 간주됩니다.
만약 ASG내의 인스턴스를 수동으로 중지하는 경우 EC2의 상태가 running 이외에 해당하기 때문에 인스턴스가 종료됩니다.
따라서 ASG에 인스턴스를 포함시켜서 환경을 구축하고 있다면 AutoScaling은 잠시 정지해두는 것이 좋습니다.
ELB 유형은 EC2 인스턴스 및 ELB 에 대해 상태 점검을 실시합니다.
ELB 타입을 선택하는 경우, ELB의 헬스 체크에 합격하는 EC2가 ASG에 포함되도록 설정해야 합니다.
만약 헬스 체크를 통과하지 못하는 인스턴스를 배치한다면 인스턴스의 종료 및 부팅이 반복됩니다.
ELB 타입과 Deep Health Check 패턴 의 병용은 피하는 것이 좋습니다.
Deep Health Check에 사용할 리소스(예: DB)에 문제가 있는 경우 상태 확인에 실패하기 때문에 EC2에 문제가 없는데도 ELB의 헬스 체크에 실패하여 인스턴스의 부팅과 종료가 반복됩니다.
EC2는 언제든 종료될 수 있는 상태여야 한다
ASG의 인스턴스는 필요에 따라 언제든 종료가 됩니다.
만약 인스턴스 내부에 데이터를 보관하는 경우 데이터가 소실되어 버립니다.
예로 들면 인스턴스 내부에 업로드를 위한 데이터, 로그 데이터, DB에 반영하기 전의 데이터 등을 보관한 상태로 인스턴스가 종료되어 버린다면 문제가 될 수 있습니다.
따라서 휘발성이어도 문제가 없는 데이터 이외에는 외부 저장소(S3, EFS)에 저장하는 것이 좋습니다.
로그 데이터 등은 파일이 아닌 스트림으로 CloudWatch 등에 저장하는 것을 추천합니다.
EC2는 시작하자마자 사용할 수 있는 상태로
AutoScaling으로 추가되는 인스턴스에 수동으로 어떠한 조작을 더해야만 올바른 가동이 가능한 상태가 되는 것은 비효율적이며 관리 실패점이 될 가능성이 있습니다.
따라서 인스턴스가 시작되면 바로 서비스에 이용할 수 있는 상태로 AMI와 시작 템플릿을 구성하는 것이 좋습니다.
스케일링 정책은 상황에 맞게 사용하기
EC2의 지표에 따라 동적으로 스케일링 되도록 설정하는 대상 추적 크기 조정으로 대부분의 상황에선 충분히 대응할 수 있습니다.
하지만 대상 추적 크기 조정은 이미 사용량이나 기타 지표가 상승한 후의 대응(사후 대응)이 되므로 사전에 대응 가능한 경우에 예로들면 EC2를 확장할 필요가 있다는 것을 미리 알 수 있는 경우 수동으로 미리 최소, 최대, 원하는 인스턴스 수를 수정하도록 하는 것이 좋습니다.
또한 특정 시간대에 스케일링이 필요하다면 일정에 따라 스케일링 하도록 지정할 수 있습니다.
혹은 예측 스케일링(Predictive scaling)을 이용하면 최근의 경향에 따라 자동으로 사전에 확장 규모를 지정할 수도 있습니다. 따라서 애플리케이션의 응답성을 사전에 확보할 수 있습니다.
예측 스케일링을 위해서는 최소 24시간의 데이터가 필요하며 최대 14일 간의 경향을 바탕으로 적절한 수의 확장 규모를 지정해줍니다.
그리고 예측 스케일링을 이용중에 예측보다 실제 트래픽이 적은 경우에는 스케일 인은 되지 않습니다. 마찬가지로 예측보다 부하가 높은 경우에도 스케일 아웃되지 않는다는 점은 주의가 필요합니다.
따라서 예측 스케일링으로 예상할 수 없었던 수요의 급증 등에 대응하기 위해 동적 스케일링 정책을 조합하면 보다 최적의 스케일링 정책이 됩니다.
관련 내용에 대해 reinvent의 세션 및 적절한 스케일링 구성을 위한 워크샵을 AWS에서 제공하고 있어서 공유합니다.
스케일링 정책 뿐만 아니라 웜풀의 이용, 확장에 따라 RDS의 스케일업 등도 소개하고 있어 많은 참고가 됩니다.
- [Proactive auto scaling for optimal cost and availability(AWS:reinvent2023, pdf)[https://d1.awsstatic.com/events/Summits/reinvent2023/CMP335-R_Proactive-auto-scaling-for-optimal-cost-and-availability-REPEAT.pdf]
- RUNNING EFFICIENT AND RESILIENT WORKLOADS WITH AMAZON EC2 AUTO SCALING(AWS WORKSHOT)
EC2의 모니터링 빈도
시작 템플릿을 생성할 때 세부 모니터링을 활성화하여 EC2 인스턴스에 대한 CloudWatch 지표 데이터를 1분 간격으로 가져오면 변경에 더 빠르게 응답할 수 있습니다.
5분 간격으로 지표를 확장하면 응답 시간이 느려지고 오래된 지표 데이터가 확장될 수 있습니다.
기본적으로 EC2는 5분마다 지표를 추적하는 기본 모니터링을 제공합니다.
세부 모니터링 활성화에는 추가 비용이 발생합니다.
검증하기
당연한 내용이지만 스케일링 정책을 변경하여 스케일링 되었을 때 인스턴스가 정상적으로 작동하는지, 부하 테스트를 하였을 때 서비스 운영에 문제가 없는지 등을 검증하는 것이 좋습니다.
마무리
EC2 AutoScaling에 대해 다시 상기할 겸 구성 요소 등에 대해 간략히 적어보았습니다.
EC2 AutoScaling을 도입하시려는 분에게 도움이 되길 바랍니다.
위에 소개한 내용 외에 AWS의 다른 서비스와 연계하여 사용하는 방법도 AWS에서 소개하고 있으므로 참고하시길 바랍니다.
긴 글 읽어 주셔서 감사합니다.
오탈자 및 내용 피드백은 must01940 지메일로 보내주시면 감사합니다.
0
