[발 번역] 아마존 클라우드에서의 Auto Scaling

해당 블로그는 KT UCloud 의 지원을 받고 있습니다.

해당 포스트는 http://techblog.netflix.com/2012/01/auto-scaling-in-amazon-cloud.html 의 글을 발 번역한 것입니다. 최근에 계속 Netflix 관련 글을 번역하게 되는데, Netflix는 2010년 경, 데이터 센터대신에 아마존 클라우드로 모든 인프라 스트럭처를 이전하였습니다. 그래서 이에 대한 기술력이 가장 높은 회사중에 하나가 아닐까 합니다. 글을 읽고 공개한 자료들을 보면, 정말 AWS에 대해서 엄청난 수준의 이해와 경험을 가지고 있는 것 같습니다. 오역에 주의하세요.

Auto Scaling in the Amazon Cloud

 2010년에 모든 인프라스트럭처를 클라우드를 옮겨가기 시작한 이후로, 운영하는 모든 서버풀을 관리하기 위해서 아마존 Auto Scaling Group을 사용해오고 있습니다. Auto Scaling Group 이 서비스의 가용성을 향상시키고, 클라우드 비용을 최적화 시켜주는 최고의 툴을 제공한다고 믿습니다. auto scaling 서비스를 이용한 2년 이상의 경험으로, 이미 경험에서 배운 몇가지 교훈들뿐만 아니라, 왜 이것을 사용해야 하고, 어떻게 사용하는지에 대해서 나누는 좋은 시간을 가질 수 있었습니다. Auto Scaling과 친숙하지 않은 분들을 위해서, Auto Scaling Group은 아마존에서 자신의 클라우드 기능의 일부로 제공하는 자동화서비스입니다. Auto Scaling은 비정상 서버를 교체하고, 서버 풀의 사이즈를 자동적으로 늘리거나, 줄이는 기능을 포함해서, 동작중인 서버 풀을 관리하는 기능을 제공합니다. 좀 더 많은 정보를 원하시면 Amazon Documentation 을 보시기 바랍니다.

Benefits

1. Availability

모든 서비스 환경에서 동작중인 서버는 하나의 Auto Scaling Group에 속해있어야 합니다. simian army   툴 중에 하나를 이용해서 해당 환경에서 비정상 서버의 위치를 찾아내고 종료시키는 것을 검증했습니다. 목표는 비정상 노드를 최대한 빨리 발견하고 종료시키는 것입니다.  아마존에 의해서 자동적으로 교체될 것이라고 기대할 수 있습니다. 이것은 또한 어떤 서버든지 아마존에 의해서나 하드웨어 장애로 인해서 종료될 때도 적용할 수 있습니다. stateful 과 stateless, 두 가지 서비스 모두를 위해서도 동작합니다. stateful 서비스 또한 AMI가 실행될 때, 어떻게 필요한 모든 것들을 셋업할 것인지 알고 있습니다.  게다가  대부분의 서비스는 stateless 이고 해당 작업은 최적화 된 auto scaling을 사용하기 위한 정보를 제공하고 다룸으로써  매우 쉽습니다.

2. Optimization

Availability에서 가장 중요한 것은 auto scaling의 사용입니다. 비용과 리소스의 최적화는 확실히 더 매력적입니다. 필요에 의해서 리소스의 할당이 가능하게 되고 거기에 따라 비용을 지불하게 되는 것은 클라우드의 큰 이점 중의 하나입니다.매우 적은 어플리케이션만 일정한 워크로드를 가지고, Netflix 역시 예외는 아닙니다. 사실, 사용자 패턴에 따라서 피크타임에 매우 큰 사용량의 변화가 있습니다. Auto Scaling은 리소스 풀 사이즈를 사용량에 따라서 다양하게 설정하게 해주어서 비용을 아끼고,  처리 용량을 수동으로 설정할 필요도 없고, 처리 용량을 넘어가는 문제가 없어서, 예측하지 못한 문제에 쉽게 대체할 수 있습니다.

3. Making it Work

Auto Scaling을 설정하는 것은 복잡한 일입니다. 간단하게 말하면, Auto Scaling은 크게 세 가지 단계로 구성되어 있습니다. 첫번째로, 제약이 있는 자원들( 예, 메모리, CPU ) 등을 분류하는 것입니다.  두번째로  아마존의 리소스 모니터링 서비스인, CloudWatch 를 이용해서 제약이 있는 자원들을 모니터하도록 합니다. 마지막으로 자원에 변경이 있을 때에 연관된 프로파일과 어떤 행동을 할지에 대한 동작과 알람을 설정합니다. AWS에서 제공하는 사용할 수 있는 메트릭은 특별히 모든 어플리케이션 종류에 대해서 중요한 지표로 여길수는 없는 CPU 사용율뿐입니다. 해당 프로세스를 쉽게 할 수 있도록 몇가지 스크립트와 두 단계의 툴을 개발했습니다.

첫 번째 단계의 툴은 인프라스트럭처를 모니터링하고 모니터링을 위한 정보 메트릭스를 CloudWatch로 보내기 위한 익스포팅을 해주는 모니터링 라이브러리입니다. 개발자들이 익스포트하기 쉽도록 어노테이션을 제공합니다. “@Monitor” 태그와 연관된었다고 어노테이션 된 필드가 있으면, 해당 필드는 자동적으로 JMX에 등록이 되고, 설정 가능한 필터를 통해서 CloudWatch에 전달됩니다. 몇가지 기능들이 있지만, 중요한 스텝은, Auto scaling 설정을 위한 필드를 익스포트 하기 위한 태그를 하는 것입니다.  Netflix Open Source 에서 해당 라이브러리에 대한 차후의 블로그를 찾아보시기 바랍니다.(역자 주: 다음 블로그를 보시면 해당 정보를 볼 수 있습니다. http://techblog.netflix.com/2012/07/open-source-at-netflix-by-ruslan.html )

두 번째 단계의 툴은 Netflix Application console(slides).에 통합될 기능들입니다. 전체 클라우드 인프라스트럭처를 관리할 수 있는 툴이지만, 여기서는 Auto Scailing을 쉽게 하기 위해 추가한 기능들에 대해서만 초점을 맞추도록 하겠습니다. push 프로세서의 부분으로써, 새로운 버전의 코드를 위한 auto scaling group을 새로 만들었습니다. 이것은 전체 설정을 이전 그룹에서 새 그룹으로 복사되었는지 확인할 필요가 있다는 것을 의미합니다. 해당 툴은 허가 받은 사용자가 간단한 HTML UI를 통해서 규칙을 변경하거나 볼 수 있도록 해줍니다. 게다가, 몇가지 Auto Scaling Rule 들 설정을 도와주는 간단한 샘플 스크립트를 가지고 있습니다. SNS Notification을 설정하고, roll-back 옵션을 만들고, 해당 스크립트는 다음 사이트에서 테스트가 가능합니다(github site).

마지막으로, 동적으로 Auto Scaling을 잘 하기 위한 가장 중요한 조각은 로드 속에서 프로그램의 동작을 테스트하고 이해하는 것입니다. 실제 트래픽에서 작은 규모의 서버군을 실제로 다운시켜보거나, 하나의 서버에 인공적으로 로드를 만들어서 해당 작업을 했습니다. 실제 부하 상황에서, 어플리케이션이 어떻게 동작하는지 이해하지 않거나, 실제 어플리케이션의 제약 조건이 뭔지 모르면,  비효율적이거나, 심지어 장애를 일으키는 Auto Scaling 설정을 할수도 있습니다.

The End Result

아래의 그래프들은 2틀 동안의 요청 트래픽을 보여줍니다. 서버 풀에서 CPU 사용량과 트래픽에 맞추어서 적절한 수의 서버가 동작하고 있습니다. 서버 대수가 요청 비율과 CPU 사용 부하에 있어서 거의 평행한 것을 볼 수 있습니다.(역자 주: 첫번째 그림은 Request Rate, 두 번째는 서버 대수, 세 번째는 CPU 로드입니다.)

Lessons learned

Scale up early, scale down slowly

Netflix에서는 Scale Up은 빨리하고 Scale Down은 천천히 하는 것을 권장합니다. 우리는 팀에서 Auto Scaling 정책과 CloudWatch 알람을 이용해 symmetric percentages 과  symmetric  periods 적극 이용하는 것을 적극 옹호합니다. 더 자세한 것은 여기에 있습니다. (역자 주: 원래 Scale up은 장비를 좀 더 좋은 장비로 바꾸는 것인데, 여기서의 Scale up은 말 그대로 장비를 추가하는 것을 의미합니다. 일반적으로 Scale Out이 이 의미에 맞습니다. github에 연결된 wiki 자료를 꼭 보시기 바랍니다. “여기” 로 표시한 부분에 있습니다.)

Scale up을 빨리하기 위해서 임계점의 75% 정도에서 짧은 시간동안 CloudWatch 알람을 설정하기를 권장합니다. 5~10분 정도 지속되면 해당 이벤트를 시작하기를 권장합니다. 새로운 노드가 시작하는데 EC2 인스턴스의 시작시간이나, 어플리케이션이 시작하는 시간이 필요하다는 것을 기억하기 바랍니다. 해당 25%의 틈이, 짧고 불규칙한 한계를 벋어나는 요청의 증가나 새로운 노드가 시작하는 도중에 실패하는 것을 인한 처리 용량의 손실로 부터 보호해줍니다. 예를 들어, 최대 CPU 사용량이 80%라면, 해당 알람은 CPU 사용량이 60%를 넘은 5분 후에 발생하도록 설정하는 것입니다.

Scale down을 천천히 하는 것은 너무 빨리 처리 용량이 줄어드는 위험을 완화시키거나, 잘못된 처리 용량의 감소의 위험을 줄여주므로 중요합니다. 이런 경우를 방지하기 위해서,  스케일을 천천히 하기 위한 방법으로 시간을 사용합니다. 예를 들어, CPU 사용량이 60%를 5분 동안 넘으면 바로 10% 확장하지만,  CPU 사용량이 30% 정도로 20분 이상 지속되어야만 10%를 줄입니다. 시간을 이용하는 장점은, 비 대칭적인 확장 정책을 적용하게 됨으로써, 서버의 용량이 부족한 상황이나, 너무 많은 처리 용량을 제거하고 바로 다시 서버가 추가되어야 하는 상황을 막아줍니다.(역자 주: 예를 들어 조건에 맞아서 계속 서버를 추가하고 제거하는 상황이 벌어질 수 있습니다.) 이런 현상은 Scale Down에 대한 정책을 너무 공격적으로 잡았을 때 발생할 수 있습니다. 시간 기반 확장 정책은 계획되지 않았던, 서비스 장애시에, 잘못 스케일을 축소하는 것을 막아줍니다. 예를 들어, 서비스가 잠시 다운되었다고 가정하면, 해당 시점에 해당 서버와 연관된 요청이 장애로 인해서 줄어들 수 있습니다. 이 때, 미들 티어에서 잘못 scale down 할 수 있습니다. 장애난 서버가 설정된 시간보다 적게 장애가 난다면, scale down 이벤트는 발생하지 않을 것입니다.

 

Provision for availability zone capacity

Auto Scaling 정책은 해당 Availability zone에서 필요한 용량에 기초해서 결정되어야 합니다. 퍼센트 기반 스케일링 정책을 활용해서 여러 availability zone 으로 Auto Scaling Group을 구성하는 것은 매우 중요합니다. 예를 들어서, 서비스를 세개의 존에서 각각 최소 10개 최대 30개의 리퀘스트를 처리할 수 있도록 설정을 했다면,  해당 서비스는 최대 초당 110 요청의 부하(RPS: Requests Per Second)로 한대의 ELB, 그리고 각 존마다 균등하게 라운드 로빈으로 요청을 보내서 테스트되어야 합니다.  효과적으로, 각 zone은 전체의 1/3 정도의 트래픽을 충분히 처리할 능력을 공급해야 합니다. 퍼센트 기반 스케일링 정책 아래서 하나 이상의 zone 이 추가로 제공될 수 있습니다. 전체가 1850 RPS 라고 가정하면, zone 마다 617 RPS 가 전달됩니다. 2개의 Zone이 6대의 장비가 있고, 마지막 Zone이 5대의 장비를 가진다면, 총 17대의 장비가 있습니다. 그리고 6대를 가진 Zone은 평균적으로 서버마다 103 RPS를 처리한다고 하면, 로드 테스트에서 바라는 것보다 13% 정도 더 처리가 가능합니다. 문제의 원인은 균형이 맞지 않은 Availability Zone에 있습니다. Scale Up/Down 을 함으로써, Zone안의 서버가  균형이 맞지 않을 수 있습니다.  이것이 퍼센트 기반 확장 정책을 이용할 때 발생하는 경향이 있습니다. CloudWatch 에 의해서 계산되고 집계되는 것은 간단합니다.  균등한 가중치, 평균, 제공된 Zone 에 대한 셋팅 정도입니다.

 

Conclusion

Auto Scaling 은 매우 강력한 툴이지만, “양날의 검” 도 될 수있습니다. 적절한 설정과 테스트 가 없으면, 유용하기 보다는 훨씬 위험합니다. 최적화를 시도하거나, 설정을 복잡하게 만들 때, 몇몇 안 좋은 케이스가 발생할 수 있습니다. 위에서 설명했듯이, 올바르고 조심스럽게 설정하면, Auto Scaling은 가용성은 늘려주고 전체적인 비용을 줄여줍니다. 좀 더 사용한 툴이나, 우리의 경험에 대해서 알고 싶으면 위키에 많은 문서 뿐만 아니라 사용하는 툴의 소스까지 포함한 auto scaling github project 를 방문하시기 바랍니다.

Greg Orzell

Justin Becker