Auto Scaling
안녕하세요. 저는 AWS 교육 및 자격증 팀의 Andy Cummings입니다. Auto Scaling에 대한 소개를 시작하겠습니다. 저는 AWS에서 근무한 지는 거의 1년 반 정도 되었고 현재는 북미 지역 교육 담당자로 AWS 고객에게 실시간으로 교육 이벤트를 제공하는 일을 담당하고 있습니다.
이 동영상에서는 Auto Scaling에 대해 소개합니다. 그 서비스의 잠재적으로 이용 가능한 사례들을 살펴본 다음, 데모를 통해서 실제로 그 서비스가 작동하는 것을 확인하도록 하겠습니다.
Auto Scaling이란
자, AWS Auto Scaling이란 무엇일까요? Auto Scaling은 해당 애플리케이션 로드를 처리하는데 사용할 수 있는 정확한 EC2 인스턴스 수치를 확실하게 가늠하도록 도와줍니다.
Auto Scaling을 사용하는 경우, 한 지점에서 워크로드 요구사항을 충족하는데 필요한 EC2 인스턴스의 수를 예측해야 할 필요가 없습니다. EC2 인스턴스에서 애플리케이션을. 실행할 때는 Cloud Watch를 사용하여 워크로드 실적을 모니터링하는 것이 중요합니다. 그러나 Cloud Watch 자체만으로는 EC2 인스턴스를 추가 또는 제거하지 않습니다. 이것이 Auto Scaling이 필요한 부분입니다.
워크로드의 예를 살펴보겠습니다. Cloud Watch를 사용하여 표준 주간 EC2 리소스 요구 사항을 측정했습니다. 자원 요구 사항은 수요일에 가장 많은 용량을 필요로 하고 토요일에 가장 적은 용량을 필요로 하는 식으로 변동합니다. 이 경우에는 수요일의 최대 수요 시간을 항상 맞출 수 있도록 여유 있는 EC2 용량을 할당하는 루트를 찾아갈 수 있습니다. 그러나 이는 대부분의 요일에는 이용되지 않는 리소스를 운용하고 있음을 의미합니다. 이는 옵션이기는 하지만 비용은 최적화되지 않습니다. 규모의 다른 측면에서 보면 EC2 인스턴스를 더 적게 할당할수록 비용이 절감할 수 있습니다. 이것은 특정 일에 용량이 부족하다는 것을 의미하며, 이러한 용량 문제를 해결하지 못하면 애플리케이션이 사용자의 업무를 제대로 수행하지 못하거나 사용자 시간이 종료될 수도 있습니다. 분명한 것은 이것이 좋지 않다는 것입니다.
Auto Scaling에서는 지정한 조건에 따라 EC2 인스턴스를 추가하거나 제거할 수 있습니다. Auto Scaling은 성능 요구 사항이 변동하는 환경에서 특히 강력합니다. 이를 통해 성능을 유지하고 비용을 최소화할 수 있습니다. 따라서 Auto Scaling은 두 가지 중요한 질문에 대한 실질적인 해답입니다.
- 첫째, 어떻게 하면 사용자 워크로드가 변동하는 성능 요구 사항을 충족시키는데 충분한 EC2 리소스를 확보할 수 있을까요?
- 둘째, 어떻게 해야 EC2 리소스 프로비저닝을 필요한 만큼만 수행하도록 자동화할 수 있을까요?
Auto Scaling은 두 가지 중요한 AWS 모범 사례를 활용합니다. 환경을 확장 가능하게 만들고 최대한 자동화할 수 있습니다. 서비스를 좀 더 자세히 살펴보겠습니다.
Scaling이란
그러면 scaling이란 정확히 어떤 의미인가요? 여러분이 수행해야 할 첫 번째 일은 스케일 아웃과 스케일 인의 개념을 확립하는 것입니다. Auto Scaling 기능은 사용자가 정의한 조건(예: 80% 이상의 CP 활용률)이나 스케줄을 기준으로 워크로드에서 실행되는 EC2 인스턴스의 수를 자동으로 조정할 수 있습니다.
Auto Scaling이 더 많은 인스턴스를 추가하면 이것을 Scaling Out이라고 합니다. Auto Scaling이 인스턴스를 종료하면 이것이 Scaling In이 되는 것입니다.
이러한 이벤트를 발생시키는 요인에 대해 제어할 수 있다는 것을 기억하세요.
작동 원리
그러면 Auto Scaling이 어떻게 작동할까요? Auto Scaling에는 세 가지 구성 요소가 필요합니다.
- 먼저, 시작 구성을 생성합니다.
- 다음으로, Auto Scaling 그룹을 만듭니다.
- 그리고 마지막으로 하나 이상의 Auto Scaling 정책을 정의합니다.
지금부터 이러한 구성요소 각각에 대하여 자세히 살펴보겠습니다.
시작 구성
시작 구성이란 무엇일까요? 이것은 Auto Scaling에 의해 무엇이 시작될 것인가를 정의하는 것에 관한 것입니다. EC2 인스턴스를 콘솔에서 실행할 때 지정해야 하는 모든 사항 즉, 사용할 Amazon 머신 이미지, 인스턴스 유형, 보안 그룹 또는 인스턴스에 적용할 역할을 생각해보세요.
Auto Scaling 그룹
Auto Scaling 그룹이란 무엇일까요? 이는 배치가 이루어지는 위치와 그 배치의 경계를 정의하는 것에 관한 것입니다. 여기서 인스턴스를 배포할 VPC와 상호 작용할 로드 밸런서를 정의합니다. 또한 그룹에 대한 경계를 지정합니다. 최소 2개를 설정하면 서버 수가 2개 미만이 되면 다른 인스턴스가 실행되어 그것을 대체합니다. 최대값을 8로 설정하면 그 그룹내의 인스턴스가 8개를 초과할 수 없습니다. 시작하려는 숫자가 타겟 용량입니다.
Auto Scaling 정책
Auto Scaling 정책이란 무엇일까요? 이것은 EC2 인스턴스를 시작하거나 종료할 시기를 지정하는 방법입니다. 예를 들자면, 매주 목요일 오후 3시에 Auto Scaling을 예약하거나 인스턴스 추가 또는 제거를 트리거하는 임계 값을 정의하는 조건을 만들 수 있습니다. 조건 기반 정책은 Auto Scaling을 동적으로 만들어 변동하는 요구 사항을 충족시킬 수 있습니다. 언제 스케일 아웃하고 언제 스케일 인할 것인지를 결정하는 최소한 한 개 이상의 Auto Scaling 정책을 만들어 놓는 것이 좋습니다.
동적 Auto Scaling은 어떻게 작동할까요? 한 가지 일반적인 구성은 EC2 인스턴스 또는 로드 밸런서의 성능 정보를 기반으로 CloudWatch 경보를 작성하는 것입니다. 성능 임계 값을 초과하면 CloudWatch 경보가 환경의 EC2 인스턴스에서 확장하거나 축소되는 Auto Scaling 이벤트를 트리거합니다.
샘플
샘플 CloudWatch 경보를 살펴보겠습니다.
경보의 첫 번째 부분은 특정 임계값이 있는 조건입니다. 이 경우에는 80% 이상의 CPU 사용률이 되겠습니다. 제어할 수 있는 기간도 지정되어 있다는 점에 주목하세요. 이것은 CPU 사용률이 5분 이상 연속으로 80% 이상일 경우 경보가 발동될 것임을 명시하는 것을 의미합니다. 프로세서가 30초 동안 스파이크가 발생하여 Auto Scaling을 활용하여 새 인스턴스를 트리거하지 않도록 하려면 기간에 집중해야 합니다.
경보의 두 번째 부분은 알람이 트리거된 후 수행할 작업입니다. Auto Scaling을 통해 인스턴스를 추가하거나 제거할 수 있습니다. 여기서는, 기본적으로 5분인 하나의 연속된 기간 동안 CPU가 80% 이상을 기록하면 Auto Scaling을 통해 두 개의 새 인스턴스가 Auto Scaling 그룹에 추가됩니다. 더 많은 인스턴스를 추가하면 CPU 사용률이 하락합니다.
또 다른 CloudWatch 경보를 설정하여 Auto Scaling 그룹에서 언제 인스턴스를 종료해야 하는지에 대한 임계 값을 정의해야 합니다. 예를 들어, CPU 사용률이 연속 5분 이상 20% 미만으로 떨어지면 하나의 인스턴스를 종료하세요.
이 모든 기능의 특장점은 Auto Scaling이 워크로드를 역동적으로 관리하므로 사용자는 다른 문제에 집중할 수 있다는 것입니다.
데모
좋습니다. 그러면 Auto Scaling에 대한 간략한 데모를 통해 직접 확인해 보겠습니다. 기본 실행 구성, Auto Scaling 그룹 및 Auto Scaling 정책을 만들어보려고 합니다. 그런 다음 Auto Scaling을 트리거하여 작업을 마무리하겠습니다. 첫 번째로 할 일은 EC2 서비스를 시작하는 것입니다. 시작 구성, Auto Scaling 그룹 및 하나 이상의 Auto Scaling 정책이라는, 사용자가 구축해 놓을 필요가 있는 세 가지 구성 요소를 기억하세요. 왼쪽 창에서 Auto Scaling 섹션으로 스크롤 하여 Auto Scaling 그룹을 선택합니다. Auto Scaling 그룹 생성하기를 클릭합니다. 그런 다음 시작 구성을 생성하도록 선택을 해야 합니다. 이전에 EC2 인스턴스를 시작해본 적이 있다면 다음 선택이 무엇인지를 알고 있을 것입니다. Amazon AMI를 선택하려고 합니다. 그런 다음 m4.large 인스턴스 유형을 선택하겠습니다. 이제 시작 구성에 이름을 지정합니다. Linux M4라고 하죠. 또한 스토리지 및 보안 그룹에 대한 기본 설정은 그대로 둡니다. 그리고 설정을 검토할 것 입니다. 시작하기를 클릭하여 구성 시작을 생성합니다. 이제 이미 존재하는 기존의 키 페어를 선택하려고 합니다. 그리고 시작 구성을 생성합니다. 자, 그러면 사용자는 Auto Scaling 그룹의 속성으로 직접 이동합니다. 그것을 Sales App으로 명명하기로 하죠. 방금 구축한 시작 구성을 사용하고 있음을 알 수 있습니다. 우리는 두 개의 인스턴스로 시작하도록 지정하겠습니다. 그런 다음 실제로 VPC와 서브넷을 지정하여 인스턴스를 배포합니다. 그런 다음 스케일링 정책 만들기를 구성합니다. 좋습니다. 스케일링 정책을 사용하여 이 그룹의 용량을 조정하도록 선택하겠습니다. 그리고 2개와 8개의 인스턴스 사이의 스케일링을 설정할 것입니다. 이것이 여기에서의 최소값 및 최대값이 됩니다. 또한 우리는 메트릭의 목표 값을 설정할 수 있는 간단한 목표 추적 정책을 사용합니다. 여기에서 평균 CPU 사용률을 60 퍼센트로 지정합니다. 목표 추적 정책은 자동으로 인스턴스를 시작하거나 종료하여 목표 값을 충족시킵니다. Scaling In 및 Out을 위한 개별 정책을 여전히 만들 수는 있지만 대상 추적은 Auto Scaling 정책을 시작하기 위한 가장 간단한 방법입니다. 알림 및 태그를 추가할 수 있는 위치를 확인합니다. 그런 다음 검토하세요. 그리고 Auto Scaling 그룹 생성을 선택합니다. 이제 Auto Scaling 그룹을 살펴보겠습니다. 진행 과정에서 모든 것을 볼 수 있도록 이것을 조금만 더 타이트하게 움직이겠습니다. 최소 인스턴스가 2개, 최대 인스턴스가 8개로 설정되어 있는 것을 볼 수 있으며, 인스턴스 탭으로 이동하면 현재 보류 중인 인스턴스가 두 개 있음을 알 수 있습니다. 이는 완전히 새로운 인스턴스인데요. 지금은 존재하지만 이전에는 없었던 이유가 무엇이든, Auto Scaling이 이 안에서 두 개의 인스턴스를 자동 실행하도록 최소값을 설정하는 것을 잊지 마시기 바랍니다. 이제 Auto Scaling을 즉시 트리거하려면 최소 그룹 크기를 수동으로 늘려야 합니다. 세부 정보 탭을 클릭하고 세부 정보 편집을 선택하면 최소 인스턴스 수와 원하는 구성이 변경되므로 최대 4개까지 변경해보려고 합니다. 자, 이제 최소 인스턴스 수는 2개가 아닌 4개가 되어야 합니다. 따라서 이미 2개가 있는 것을 보았기 때문에, 추가로 2개의 인스턴스가 시작되는 것을 확인해야 합니다. 인스턴스 탭으로 다시 돌아가서 속을 들여다보면 시작 구성에 따라 자동으로 실행된 인스턴스가 2개 더 있는 것을 알 수 있을 것입니다. 이제 학습한 내용을 요약해 보겠습니다. Auto Scaling에서는 지정한 조건에 따라 EC2 인스턴스를 추가하거나 제거할 수 있습니다. Auto Scaling은 성능 요구 사항이 변동하는 환경에서 특히 강력합니다. 이를 통해 성능을 유지하고 비용을 최소화할 수 있습니다. 이 과정의 특징은 사용자가 자고 있는 한밤중에 EC2 인스턴스를 Scaling In하거나 Scaling Out할 수 가 있다는 것입니다. 세 가지 핵심 구성 요소는 무엇을 배포할 것인 지에 대한 시작 구성, 배포 위치에 대한 Auto Scaling 그룹, 배포 시기에 대한 Auto Scaling 정책입니다. 여러분이 배운 모든 AWS 서비스는 솔루션을 구축하기 위한 하나의 도구임을 기억하세요. 활용할 수 있는 도구가 많을수록 여러분은 더 강력해집니다. 시청해 주셔서 감사합니다.