Jins' Dev Inside

클라우드 환경에서 AWS 의 솔루션들을 사용하는 데 있어서 AWS Auto Scale 은 그 꽃이라고 할 수 있다.

AWS 의 Auto Scale 솔루션은 서비스의 스케일링(Scaling) 을 자동화할 수 있게 해주는 클라우드 인프라 솔루션이다.

AWS 의 Auto Scaling Group / Launch Configuration / Scaling Plan 와 같은 핵심 구성 요소들을 포함한다.

오토 스케일링 정책을 통한 설정을 바탕으로 몇 개의 인스턴스를 운용할지, 어떤 시점에 Scale 을 늘리고 어떤 시점에 낮출지 결정할 수 있다.

(Scaling 에 대해 잘 모른다면 다음 포스트를 참조하자. 

https://jins-dev.tistory.com/entry/Scaling-%EC%9D%98-%EC%A2%85%EB%A5%98%EC%97%90-%EB%8C%80%ED%95%9C-%EC%A0%95%EB%A6%AC)

이에 따라 Auto Scale 솔루션은 다음과 같은 장점들을 갖고 있다.

1. Cost Optimization

Scale 이 커져서 AWS 의 인프라들을 많이 사용하게 되면 비용이 증가하고 Scale 을 낮출 경우 비용을 절감시킬 수 있기 때문에 비용적인 측면을 같이 고려해서 사용해야 하며,

이러한 측면이 고려된 설계를 한다면 Auto Scale 을 통해 필요한만큼만 리소스를 사용함으로써 비용을 최적화할 수 있다.

(단, Auto Scale 솔루션 자체는 추가 비용이 들지 않는다.)


2. High Availability

Auto Scale 솔루션을 이용하면 Auto Scaling Group 에 대해 여러 Availability Zone 들에 고르게 인스턴스들을 할당하고 해제할 수 있다.

가령 Scale Out 을 통해 인스턴스들의 숫자가 많아질 때 하나의 영역에만 할당하는 것이 아니라 여러 영역에 고르게 분포시킬 수 있고, 해제할 때에도 균등하게 할당을 해제할 수 있다.

3. Well-Architectured Service

Auto Scale 을 통해 실제 요구량보다 많은 리소스를 사용하는 Over-Provisioning(오버 프로비저닝) 이나 실제보다 적은 리소스를 할당하는 Under-Provisioning(언더 프로비저닝) 을 방지할 수 있다.

이는 아키텍처를 설계함에 있어 유연성을 가져다줄 수 있다.


Auto Scale 솔루션은 다음과 같은 수명주기를 갖고 있다.

수명 주기에 따라 Scale Out 된 인스턴스들은 Pending 상태 이후 In-Service 상태로 전환되며 Scale In 될 때에는 Terminating 프로세스를 수행하게 된다.

진행 중인 인스턴스를 Attach 하거나 Detach 하는 과정 역시 라이프사이클에 포함된다.

위와 같은 수명 주기 내에서 Auto Scale 은 주로 CloudWatch 지표를 바탕으로 이벤트가 트리거되며 이벤트를 통해 Lambda 함수를 호출한다던지, SNS 알림을 생성한다든지 하는 다른 작업을 같이 진행할 수 있다

Amazon EC2 Auto Scaling API 에 대한 호출은 AWS CloudTrail 을 통해 추적해볼 수 있다.

서버의 Scalability 를 관리하기 위한 방법은 굉장히 중요하다.

실 서비스의 아키텍처를 구조화할 때도 반드시 고려해야할 부분이고, 이 결정은 실제로 서비스에 큰 영향을 주게 된다.

가령 사용자가 갑자기 증가할 경우, 엄청난 수의 요청에 대한 처리를 어떻게 할 것인가는 Backend 에서 가장 중요하게 고려해야할 부분 중 하나이다.

Scaling 의 방법에는 크게 Scale Up 과 Scale Out 이 존재한다.

Scale Up : 서버 자체의 Spec 을 향상시킴으로써 성능을 향상시킨다. Vertical Scaling 이라 불리기도 한다. 서버 자체의 갱신이 빈번하여 정합성 유지가 어려운 경우(주로 OLTP 를 처리하는 RDB 서버의 경우) Scale Up 이 효과적이다.

성능 향상에 한계가 있으며 성능 증가에 따른 비용부담이 크다. 대신 관리 비용이나 운영 이슈가 Scale Out 에 비해 적어 난이도는 쉬운 편이다. 대신 서버 한대가 부담하는 양이 많이 때문에 다양한 이유(자연 재해를 포함한다...)로 서버에 문제가 생길 경우 큰 타격이 불가피하다.

Scale Out : 서버의 대수를 늘려 동시 처리 능력을 향상시킨다. Horizon Scaling 으로 불린다. 단순한 처리의 동시 수행에 있어 Load 처리가 버거운 경우 적합하다. API 서버나, 읽기 전용 Database, 정합성 관리가 어렵지않은 Database Engine 등에 적합하다.

특히 Sharding DB 를 Scale Out 하게 된다면 주의해야하는데, 기존의 샤딩 알고리즘과 충돌이 생길 수도 있고(샤드가 갯수에 영향을 받을 경우...) 원하는 대로 부하의 분산이 안생길 수 있으니 각별히 주의할 필요가 있다.

스케일 아웃은 일반적으로 저렴한 서버 여러 대를 사용하므로 가격에 비해 뛰어난 확장성 덕분에 효율이 좋지만 대수가 늘어날 수록 관리가 힘들어지는 부분이 있고, 아키텍처의 설계 단계에서부터 고려되어야 할 필요가 있다.

요즘은 클라우드를 사용하기 때문에 Scaling 에 있어서 큰 이점이 있으며, 서비스의 목표치에 알맞게 Scalability 를 설계하고 두 스케일링 방법을 모두 적용시키는 것이 일반적이다.