AWS auto scaling 을 사용하기 위해 알아두면 좋을 내용들

간혹 auto scaling 을 사용하면 서비스 중단없이 인프라 자원이 확장되었다 축소되었다 하는걸로 환상을 가지고 있는 사람들이 종종 있다. 

AWS 에서 제공하는 auto scaling 을 인프라 자원에 대한 확장이고 서비스는 그들의 관심사가 아니다 

서비스를 무중단으로 auto scaling 하는 것은 운영자의 몫.. 

관련하여 auto scaling 에 대한 명확한 개념 정리와 최대한 서비스를 중단시키지 않는 방법은 무엇이 있는지 차근차근 확인해보려고 한다. 

일단 이번에는 auto scaling 의 개념과 사용방법에 대해서 먼저 알아보았다. 

1. Auto Scaling Lifecycle

auto scaling group 의  EC2 인스턴스는 다른 EC2 인스턴스의와 다른 경로 또는 수명주기를 가지고 있음 

auto scaling group 설정에 따라 인스턴스를 시작하고 서비스에 추가되었을 때 수명주기가 시작됨. 

인스턴스를 종료 할 때 라이프 사이클이 종료되거나 auto scaling group  설정에 따라 서비스에서 인스턴스를 종료할 수 있음 

 1) Auto Scaling : Auto Scaling은 사용자가 정의한 정책, 일정 및 상태 확인에 따라 자동으로 Amazon EC2 인스턴스를 시작하거나 종료하도록 설계된 웹 서비스입니다. 

auto scaling 룰 자체를 주는 것에 대해서는 무료이지만 인스턴스 사용 요금은 내야함 

 2) Auto Scaling types

 - Vertical Scaling : 인스턴스 사이즈 변경, EBS capacity 증가

 - horizontal Scaling : 인스턴스를 추가하거나 삭제, ELB 활용 

 3) auto scaling 시나리오 

 - auto scaling group 에 최소/최대 운영할 인스턴스 개수 정의

 - 언제 scaling 할지에 대한 정책 설정 (scaling plan)

 - cloudwatch 를 통해 사용량 데이터 수집 및 scaling 시도

 - 지정한 spot 에 scaling group 에 지정된 형태로 인스턴스 확장

 4) 자원 사용량 측정 

 - CloudWatch : 다양한 항목에 대해 사용량을 모니터링 하고 관리할 수 있는 서비스, 

알람을 설정하고 측정되는 데이터를 기반으로 어떠한 액션을 취할 수 있도록 알람을 설정할 수 있다. 

 - CloudWatch Alarm : CloudWatch에서 알람은 특정 기간 동안 하나의 메트릭을 모니터링하는 것이며 메트릭은 모니터링할 대상을 뜻함 (ex. CPU Usage , Network In traffic 등)

 - 모니터링 항목에 대해 지정한 범위 안의 값이 변경되었을 때 알람이 상태를 변경함. 

5) Auto scaling group 계획 관리

 - 인스턴스를 생성하고 구성하는데 얼마나 시간이 소요되는지?

 - 어떠한 모니터링 항목이 어플리케이션의 성능을 측정하는데 적정한지?

 - 기존의 어떠한 자원 (EC2 인스턴스나 AMIS) 는 오토스케일링 그룹의 일부로 사용할 수 있음 

 - 몇개의 AZ 에 auto scaling group 이 확장시킬 것인지?

 - 인스턴스를 auto scaling 한 후 application 기동을 수행할 역할 지정 

6) auto scaling group 에서의 부하 분산 

 - 들어오는 웹 트래픽에 대해서 자동으로 분산해야 함 

 - 어플리케이션에 접근하기 위한 싱글 포인트 

 - 로드밸러서와 EC2 인스턴스의 사용량 데이터는 CloudWatch 로 보내짐 

 - 어플리케이션을 확장하는데 ELB 모니터링 항목을 사용할 수 있음 

2. Auto Scaling Lifecycle Hooks

 - Auto Scaling lifecycle hooks 는 사용자가 지정한 액션을 오토스케일링이 수행되거나 중단될 때 수행할 수 있게 한다. 

관련하여 필요한 요소들은 아래와 같다. 

1) bootstrapping 이란?

 - bootstrapping 을 통해 수행할 수 있는 일들

  . 최근의 software 를 설치

  . S3 로부터 data copy

  . DNS 에 등록

  . 서비스 기동 

  . 패키지 업데이트 

  . 리부팅 수행 

  . 포트 80 오픈 (ELB 에 등록, 디바이스 마운트)

 - bootstrapping 도구 

 . 인스턴스에 포함된 스크립트 (Bash, Powershell)

 . 설정 관리 도구 (chef, Puppet)

 . Amazon Opsworks

2) EC2 Metadata 와 UserData

 - 모든 EC2 인스턴스는 로컬 인스턴스의 metadata 와 userdata 서비스에 접근할 수 있다. 

 - metadata : 인스턴스에 대해 변경할 수 없는 정보 

  . 인스턴스에서 http://169.254.169.254/latest/meta-data/ 로 확인할 수 있다. 

 - Metadata 를 통해 Hostname, AMI ID, Instance ID, Public/Private DNS, Availability Zone 등을 검색할 수 있음 

 - 인스턴스 생성 시 text 16KB 까지 사용 가능 

 - text 는 인스턴스에서 설정작업을 위해 스크립트로 parsing 할 수 있어야 한다. 

 - Cloudinit 은 인스턴스 최초 부팅 시 UserData 를 수행할 수 있다. 

 - Cloudinit 은 Amazon Linux, Ubuntu, RHEL AMI 에 설치되어 있다. (각 플랫폼 별 repo 를 통해 설치할 수 있음)

 - EC2Config 는 Windows Server AMIs 에 설치되어 있다. 

 - Userdata 를 통해 Apache 나 MySQL 등의 패키지를 설치하고 EIP 를 연결할 수 있다. 

3. 마무리 

1) 하나의 Autoscaling 그룹으로 모든걸 만족시킬 수 없다. 

 - 적절한 모니터링 항목을 선택할 것 

  . CPU Usage, Queue Depth, 현재 유저의 수 등.. 

 - 너무 공격적으로 확장하지 말 것 

  . Over provisioning 을 비용을 증가시킴

  . 탄력적인 확장 : scaling up 한 이후에 너무 빠른 시간안에 scale back 하게 되면 오히려 비용이 증가됨 

 - 너무 소극적으로 확장하지 말것 

  . 서비스 성능이 저하될 수 있음 

  . 용량 부족으로 서비스 중단될 수 있음 

 - 너무 성급하게 확장하고 천천히 축소하는 것을 지양해야 함 

2) 추가된 기능 (2015년 ;;)

 - auto scaling group 안에 인스턴스를 추가/제외 할 수 있음 

 - 트러블 슈팅을 위해 인스턴스를 스탠바이 상태로 유지할 수 있음 

 - 소프트웨어를 설치하고 로그를 검색하기 위핸 인스턴스를 펜딩 상태로 유지할 수 있음 

 - 기동중인 인스턴스의 launch configuration 을 기반으로 auto scaling group 을 생성할 수 있음 

위 내용은 아래 링크의 문서를 기반으로 스터디 한 내용입니다. 

http://www.slideshare.net/awskorea/kr-webinar-2015-autoscaling-masterclass