about me
20'S LIFE IN SYDNEY and BUSAN
Auto Scaling
미리 정해 놓은 규칙에 따라 워크로드(작업량)를 자동으로 확대 또는 축소할 수 있는 기술로 클라우드가 제공하는 탄력성에 의해 만들어지고, 사용자의 요구 수준을 반영할 수 있는 기술입니다.
Auto Scaling을 이용하면 처리 요구량이 급등하는 시기, 즉 피크 워크로드에 맞춰 새 리소스를 자동으로 추가하고 환경설정하고, 처리 요구량이 줄어들면 해당 리소스를 감소시키기 때문에, 과잉 프로비전을 할 필요성이 사라집니다.
*프로비전(provision) 필요한 컴퓨팅 리소스들을 필요한 곳에 배치, 유휴 자원들을 다시 회수하는 일련의 작업들을 의미
Auto Scaling의 장점
동적 스케일링 : Auto Scaling의 가장 큰 장점은 사용자의 요구 수준에 따라 리소스를 동적으로 스케일링 할 수 있다는 점입니다. 스케일 업 할 수 있는 서버의 수에는 제한이 없고, 필요한 경우 서버 두 대에서 수백 ~ 수만 대의 서버로 즉시 스케일 업할 수 있습니다.
로드 밸런싱 : Auto Scaling은 리소스를 동적으로 스케일업 혹은 스케일다운 합니다. 로드밸런서와 함께 사용하면, 다수의 EC2 인스턴스에게 워크로드를 효과적으로 분배할 수 있고, 다수의 AZ에 분포된 EC2 인스턴스에 대한 워크로드도 자동으로 분배하도록 설정할 수 있습니다. 따라서 사용자가 정의한 규칙에 따라 워크로드를 효과적으로 관리 할 수 있습니다.
타겟 트래킹 : 사용자는 특정 타겟에 대해서만 Auto Scaling을 할 수 있으며, 사용자가 설정한 타겟에 맞춰 EC2 인스턴스의 수를 조정합니다.
헬스 체크와 서버 플릿 관리 : Auto Scaling을 이용하면 EC2 인스턴스의 헬스 체크 상태를 모니터링 할 수 있습니다. 헬스 체크를 하는 과정에서 특정 인스턴스의 문제가 감지되면, 자동으로 다른 인스턴스로 교체 합니다.
다수의 EC2 서버에서 애플리케이션을 호스팅 하는 경우, 이들 일련의 EC2 서버 집합을 AWS는 서버 플릿(Fleet)이라 부릅니다.
Auto Scaling은 적정 수준의 서버 플릿 용량을 유지하는 데도 도움을 줍니다. 예를 들어, 어떤 기업의 애플리케이션이 6대의 EC2 서버에서 실행 중일 때 6대 서버에 대한 헬스 체크 상태를 모니터링 하다가 특정 서버에 문제가 생기면 즉시 대응 조치를 할 수 있습니다. 한 대 또는 그 이상의 서버가 다운 되면 Auto Scaling은 6대의 서버 인스턴스 처리 용량을 유지하기 위해 부족분만큼의 서버를 추가로 실행시키는 방식으로 서버 플릿을 유지합니다.
EC2 Auto Scaling 활용
Auto Scaling은 EC2 인스턴스 뿐만 아니라 다른 인스턴스와도 결합 가능하지만, EC2 사용자에게 가장 인기가 많은 서비스 입니다. EC2 Auto Scaling은 오직 EC2 서버라는 리소스만 대상으로 합니다.
시작 템플릿(Launch Configuration)
Auto Scaling으로 인스턴스를 확장 또는 축소하려면 어떤 서버를 사용할지 결정해야 합니다. 이는 시작 템플릿을 통해서 가능하며, AMI 상세 정보, 인스턴스 타입, 키 페어, 시큐리티 그룹 등 인스턴스에 대한 모든 정보를 담고 있습니다. 만약 시작 템플릿을 사용하고 있지 않고 시작 템플릿을 생성하지 않으려는 경우에는 대신 시작 구성을 생성할 수 있습니다. 시작 구성은 EC2 Auto Scaling이 사용자를 위해 생성하는 EC2 인스턴스 유형을 지정한다는 점에서 시작 템플릿과 비슷합니다. 사용할 AMI의 ID, 인스턴스 유형, 키 페어, 보안 그룹 등의 정보를 포함시켜서 시작 구성을 생성합니다.
Auto Scaling 그룹 생성
Auto Scaling 그룹은 스케일업 및 스케인 다운 규칙의 모음으로 EC2 인스턴스 시작부터 삭제까지의 모든 동작에 대한 규칙과 정책을 담고 있습니다. 따라서 Auto Scaling 그룹을 생성하기 위해서는 스케일링 정책 및 유형에 대해서 잘 숙지하고 있어야 합니다.
Scaling 유형
인스턴스 레벨 유지 기본 스케일링 계획으로도 부르며, 항상 실행 상태를 유지하고자 하는 인스턴스의 수를 지정할 수 있습니다. 일정한 수의 인스턴스가 필요한 경우 최소, 최대 및 원하는 용량에 동일한 값을 설정하면 됩니다.
수동 스케일링
기존 Auto Scaling 그룹의 크기를 수동으로 변경할 수 있습니다. 수동 스케일링을 선택하면 사용자가 직접 콘솔이나, API, CLI 등을 이용해 수동으로 인스턴스를 추가 또는 삭제 해야 합니다. 해당 방식은 추천하지 않는 방식입니다.
예측 스케일링
트래픽의 변화를 예측할 수 있고, 특정 시간대에 어느 정도의 트래픽이 증가하는지 패턴을 파악하고 있다면 일정별 스케일링을 사용하는 것이 좋습니다. 예를 들어 낮 시간대에는 트래픽이 최고치에 이르고 밤 시간대에는 트래픽이 거의 없다면 낮 시간대에 서버를 증설하고 밤 시간대에 스케일 다운 하는 규칙을 추가하면 됩니다.
동적 스케일링
수요 변화에 대응하여 Auto Scaling 그룹의 용량을 조정하는 방법을 정의합니다. 이 방식은 CloudWatch가 모니터링 하는 지표를 추적하여 경보 상태일 때 수행할 스케일링 규칙을 정합니다. 예를 들어 CPU 처리 용량의 80% 수준까지 급등한 상태가 5분 이상 지속될 경우 Auto Scaling이 작동돼 새 서버를 추가하는 방식입니다. 이와 같은 스케일링 정책을 정의 할 때는 항상 스케일 업과 스케일 다운 두 가지의 정책을 작성해야 합니다.
EC2 Auto Scaling은 다음과 같은 유형의 동적 스케일링 정책을 지원합니다.
타겟 트랙킹 스케일링 : 미리 정의된 성능 지표를 이용하거나, 커스텀 성능지표(custom metric)을 사용하여 타겟 값으로 설정할 수 있습니다.
단순 스케일링 : 단 하나의 스케일링 설정에 따라 그룹의 현재 용량을 늘리거나 줄입니다. 예를 들어 CPU 활용지표가 80% 에 도달할 때 하나의 인스턴스를 추가하고, 40% 미만으로 떨어질 때 인스턴스 하나를 감소시키는 방식이 있습니다. 이때 새 인스턴스를 시작 혹은 정지 시키기 위한 대기 시간도 정의할 수 있으며 이를 쿨다운 기간이라고 부릅니다.
단계 스케일링 : 단순 스케일링은 특정 이벤트에 대해 매번 같은 액션을 한다면, 단계 스케일링은 좀 더 세분화 해서 단계를 나누어 규칙을 추가할 수 있습니다.
인스턴스 삭제 정책
Auto Scaling은 스케일업 정책은 물론 스케일다운 정책도 반영합니다. 스케일다운 정책이 적용되면, EC2 인스턴스가 삭제되며, 서버를 셧다운 하는 것은 리소스 관리 측면에서도 꼭 필요한 일입니다.
스케일다운 정책에서는 명확하게 몇 개의 인스턴스를 삭제할 것인지 정의할 수 있으며, 어떤 인스턴스를 먼저 셧다운 할 것인지 환경 설정을 통해 결정할 수 있습니다.
인스턴스 삭제 정책은 매우 다양하지만 아래 두 가지가 대표적입니다.
사용자의 서버 플릿에서 가장 오랫동안 실행된 서버를 삭제합니다.
가장 오랫동안 실행된 서버일수록 패치 수준이 낮고 메모리 누수 등의 문제가 누적해 있을 가능성이 크르모 이를 삭제함으로써 최신의 성능 기준을 유지할 수 있다는 장점이 있습니다.
시간 단위 과금이 임박한 서버를 삭제합니다.
이 서버를 삭제하면 Auto Scaling의 특유 장점을 최대한 살려, 과금 부담을 줄일 수 있습니다.
댓글