Scale Up(Vertical Scaling)과 Scale Out(Horizontal Scaling)

 

Sacle Up과 Scale Out은 비단 AWS에서 뿐만이 아니더라도 서버나 DB/스토리지 확장 방법에 있어 많이 쓰이는 용어이다.

 

Scale Up이란 단순히 말하자면 기존의 하드웨어를 보다 높은 사양으로 업그레이드를 하는 것을 말한다. 예를 들어 성능이나 용량 증강을 목적으로 하나의 서버에 디스크를 추가하거나 CPU/메모리를 업그레이드 하는 것을 말한다. 이처럼 하나의 서버의 능력을 증강하기 때문에 수직 스케일링(Verical scaling)이라고도 한다.

 

반면 Scale Out은 장비를 추가해서 확장하는 방식을 말한다. 기존 서버만으로 용량이나 성능의 한계가 있으면, 비슷한 사양의 서버를 연결해 추가된 분만큼 용량이 증가할 뿐만 아니라 워크로드를 분담해 성능을 높일 수 있다. 사용자는 분산 파일 시스템이나 글로벌 네임스페이스(global namespace)를 통해 스토리지 서버 클러스터를 하나의 시스템으로 인식하며, 서버를 추가로 확장하기때문에 수평 스케일링(Horizontal scaling)이라고도 불린다.

 

Scale Up vs. Scale Out

 

EC2 Scale Up 실습

 

AWS에서 Scale Up을 실습을 위해 아래와 같은 시나리오로 실습을 해 볼 계획이다.

 

1. wordpress(이하 wp) ec2 생성
2. 해당 wp ec2를 통해 스트레스 테스트를 할 ec2(이하 stresser) 생성
3. wp ec2에 부하 테스트
4. wp ec2 scale up
5. scale up한 wp ec2에 부하 테스트

간단히 다이어그램을 그려보면 아래와 같다.

 

 

실습 자체는 심플하다. 먼저 EC2 2개를 먼저 준비해주자. 모두 t2.micro 의 인스턴스 유형으로 생성했고 wordpress의 경우 앞선 실습에서 이용하였던 bitnami wordpress ami를 이용하여 생성해주었다. 부하 테스트만 해 줄것이기 때문에 별도의 wordpress 설정은 하지 않았다. stresser의 AMI는 ubuntu 이미지를 이용하였다.

 

 

wp 인스턴스를 실행 후 퍼블릭 IPv4 주소(혹은 DNS)로 접속해보자.

 

 

정상적으로 접속됨을 확인하였다. 이번에는 stresser에 ssh로 접속하여 보자.

 

 

성공적으로 두개의 EC2를 생성하였다. 이제 stresser에 스트레스 테스트에 필요한 패키지를 설치하여야 한다. 

ab라는 stresser를 이용할 것이다.

 

아래의 명령어를 이용하여 필요한 패키지 리스트를 update하고 apache2-utils를 설치해주자.

 

sudo apt-get update;
sudo apt-get install apache2-utils;

정상적으로 설치되고 ab의 help 페이지를 보자.

 

크게 -n(requests)와 -c(concurrency)를 값을 조절하며 스트레스 테스트를 해볼 예정이다.

 

wordpress ec2에 가해지는 부하를 확인하기 위해 wp ec2에도 ssh 접속하여 top 명령어를 실행해놓고 스트레스 테스트 시의 CPU 부하를 확인해보자.

 

 

평상시의 CPU 점유율은 평온하다. stresser ec2에서 아래의 명령어를 통해 스트레스를 줘보자.

먼저 동시접속(-c) 1개로 400개의 요청(-n)을 보낼 것이다.

 

ab -n 400 -c 1 http://<wp ec2의 ip>/

 

 

다시 wp ec2에서 top을 확인할시에 cpu의 점유율이 치솟는 것을 볼 수 있다.

다시 stresser로 돌아오면 ab 실행결과가 아래와 같은 리포트 형태로 나오게된다.

 

 

총 400개의 요청 중 실패한 요청은 없고, 전체 처리시간에 15.29초가 걸렸다. 초당 26.16개의 요청을 처리하였으며 요청 당 처리속도는 38.228ms 즉 0.038초 정도 소요된 것을 알 수 있다.

 

여기서 요청수를 고정한 채 동시접속을 점점 늘려가면서 아래와 같이 실험을 해 보았다.

 

 

동시 접속수가 늘어날 때마다 개별처리속도가 현저히 늘어나는 것을 볼 수 있다. 동시접속수가 50이 넘어가는 순간 1.8초가 소요되게 되는데 실제로 웹 페이지를 불러올 시 이 정도가 소요되면 매우 느리다는 기분을 느낄 것이다.

 

이때 Scale Up을 통해 이러한 이슈를 해결해 보자.

 

AWS EC2를 Scale Up을 하기 위해서는 인스턴스 재기동이 불가피하다.

다시말해 서비스 중단 후 Scale Up을 한 인스턴스를 재기동해야 한다는 것이다. 

 

실제 서비스에서는 같은 서비스를 하는 여러 대의 인스턴스가 클러스터링 되어있겠지만 어찌되었든 서비스이 영향이 가기에 매우 조심하여야 한다.

 

Elastic IP(탄력적 IP a.k.a 고정 IP)

 

Scale Up을 하기 전에 다음과 같은 고민이 들 수 있다.

 

 

인스턴스를 재기동할 시에 Public IP가 재할당되게 되는데 그럼 이전의 Public IP로는 접속할 수 없는 것 아닌가? (운이 좋으면 같은 Public IP로 할당 받겠지만...)

 

이러한 고민이 들었다면 당신은 네트워크 엔지니어로서 탁월한 자질을 가진 것이라 할 수 있다.

각설하고 EC2에서 계속 같은 IP를 사용싶다면(고정 IP) 탄력적 IP를 사용하면 된다.

 

물론 공짜는 아니지만 Free Tier 시간 내에서 EC2 하나에 대해서 하나의 탄력적 IP를 사용하는 것은 과금이 되지 않는다.

 

 

다만 주의할 점은 반드시 EC2 인스턴스를 종료시키고 탄력적 IP를 릴리즈 하지 않으면 존재하는 탄력적 IP에 대해 과금이 된다는 것이다! (필자는 몇 일에 걸쳐 실습을 진행하였는데 실수로 인스턴스는 중지 시켰지만 Elastic IP를 릴리즈 하지 않아 과금이 되고야 말았다. 피 같은 0.79$...)

 

여튼 반드시 실습 후에는 탄력적 IP까지 릴리즈 하도록 하자.

 

탄력적 IP는 콘솔에서 네트워크 및 보안 > 탄력적 IP 메뉴를 들어가면 볼 수 있다.

 

 

그럼 탄력적 IP 주소 할당을 클릭하여 생성 메뉴로 진입한다.

 

 

서울 리전인 ap-northeast-2를 선택해주고 퍼블릭 IPv4 주소 풀은 Amazon의 IPv4 주소풀을 선택하면 된다.

이후 할당을 누르면 아래와 같이 탄력적 IP가 할당된 것을 볼 수 있다.

 

 

 

이후 해당 탄력적 IP 주소를 체크하고 작업을 눌러 wp ec2 인스턴스와 연결해주자.

인스턴스 메뉴에서 wp 인스턴스를 클릭 시에 아래와 같이 탄력적 IP 주소가 보인다면 성공이다.

이제 이 인스턴스를 중지하였다가 다시 실행해도 아래의 탄력적 IP로 접속이 가능할 것이다.

 

 

이제 wp 인스턴스를 Scale Up 해보자.

(해당 실습은 과금이 되는 관계로 실제로 진행해보진 않을 것이다.)

 

다만 생활코딩의 Scale Up 강좌를 통해 확인하였을 시에 인스턴스 Scale Up(t2.micro → t2.large) 같은 조건의 t2.micro보다 Request 개별 처리속도가 현저히 좋아졌음을 확인할 수 있었다.

 

 

Scale Out에 대한 실습은 다음 포스팅에 이어서 진행하겠다.

 

References

• 스토리지 기초 지식 3편: 스케일 업과 스케일 아웃