AWS Scale Up, EIP

scalability : scale + ability. 스케일에 따라 탄력적으로 대응함. “확장성”으로 번역됨.

 

EC2의 중요한 특징으로 가상화, 종량제이다.

이 두 개념은 클라우드 컴퓨팅의 핵심적인 기술이다.

 

먼저, 가상화. 가상머신이란 것은 네가 생각하는 그런 게 맞다. 일반 컴퓨터 위에 가상의 운영 체제를 하나 더 돌리는 거다. 윈도우 위에 다른 윈도우, 맥, 리눅스 이런 거 돌리기 가능.

개인용 가상머신은 VirtualBox, VMWare, Parallels 이런 거 쓸거다.

 

다음은 종량제. 쓴 양만큼 비용 책정한다는 거다. 이 개념을 이해하기 위해서는 병렬 컴퓨터를 이해해야 한다. 병렬 컴퓨터는 또 뭐냐? 여러 대의 컴퓨터를 합쳐서 하나의 컴퓨터처럼 쓰는 거다. 그 결과 여러 개의 cpu와 메모리를 가진 것처럼 보인다. 반대로 한 컴퓨터를 쪼개서 구린 컴퓨터 여러 대처럼 쓰는 것도 가능하다. 그래서 트래픽 수에 따라 필요한 리소스를 병렬 컴퓨터의 특성을 이용해서 쓴 만큼 비용을 책정하는 종량제가 가능해진다.

 

scalability, 확장을 위한 전략은 두 가지로 나뉜다.

 

Scale Up : 수요가 늘어나면 좋은 컴퓨터로 업그레이드 한다.

Scale Out : 여러대의 컴퓨터가 같이 처리한다.

 

일단 트래픽이 많아지면 scale up으로 하되 최고 사양임에도 부족하면 scale out을 함.

 

---

scale up의 필요성을 체험해보기 위해 스트레스 테스트를 해보자.

수비는 윈도우, 공격은 리눅스로 가자.

우선 리눅스 인스턴스에 접속한 후 부하발생기(아파치에서 만든 ab. apachebench의 준말.)를 켜보자.

sudo apt-get update

sudo apt-get install apache2-utils

ab

 

ab치면 이런저런 설명이 나올텐데 여기서 중요한 건

request : 접속 횟수

concurrency : 접속하는 사람의 수(동시접속)

request가 100이고 concurrency가 10이면 10명이 100번 접속.

 

ab –n 400 –c 1 http://13.125.181.191/

주의할 점은 주소의 맨 마지막에 /를 넣어줘야 작동한다는 것.

 

작동한 걸 하나씩 봐보자.

 

time taken for tests : 총 소요시간. 400번 접속하는데 0.449초 걸림.

Filed requests : 접속 실패인데 없다.

Requests per second : 초당 처리 속도 = 1초에 890.5번 접속을 감당할 수 있다.

Time per request : 개별 처리 속도 = 접속할 때 평균(mean) 걸리는 시간. 니가 접속하면 1.123ms 걸린다.

 

강도를 높여서

ab –n 400 –c 2 http://13.125.181.191/

ab –n 400 –c 5 http://13.125.181.191/

뭐 이런 거 해봐라.

개별 처리 속도가 점점 늦어질 것.

이를 감당하기 위해서 우리가 Scale Up이 필요하다는 거다.

 

한편, 인스턴스 하단을 보면 CPU 사용률이 늘어난 것을 확인할 수 있을 것이다.

이 그래프를 보고 Scale Up을 할 것인지 하지 않을 것인지를 판단해야 한다.

 

 

 

어떻게? 일단 더 좋은 인스턴스로 바꿀 수 있다.

우선 scale up 하고 싶은 인스턴스를 AMI로 얼린다.

그런데 scale up하기 전 주의할 점은 인스턴스를 정지했다가 다시 키면 IP가 바뀐다.

AMI로 얼린 걸 다시 살려도 본래 IP와 다른 IP를 준다.

 

이 문제 때문에 필요한 것이 Elastic IPs이다. 번역되어 있기로는 탄력적 IP란다.

Allocate elastic ip 누르면 고정된 ip를 준다. 물론 금액을 지불하는 한도 한에는.

이 elasitc ip를 원하는 인스턴스에 붙이면 고정된 ip가 유지 되겠지?

 

성능을 올리기 위해서 AMI로 얼릴 때 IP를 고정하기 위해서는 반드시 elastic ip를 받아야 한다는 것을 잊지 마라.

 

받은 후에는 release하면 이 ip를 광활한 인터넷 세계로 풀어주겠다는 것임. 한 마디로 삭제.

인스턴스에 연결하고 싶다면 연결하면 됨 ㅇㅇ

 

 

 

연결하면 아래와 같이 인스턴스에는 탄력적 IP를 할당받게 됨.

 

 

 

---

Elastic IP를 알아봤으니까 이제 정말로 Scale Up을 해보자.

주의할 점은, Scale Up은 위험한 작업이다. 비용 발생도 문제고 인스턴스가 잘 못 될수도 있다.

그러니까 정신차리고 신중하게 해라.

 

ⓐ 우선 scale up할 인스턴스의 AMI를 하나 만든다.

AMI를 만들 때 서버가 잠시 꺼지는 것을 잊지 마라. 이용자 적을 때 할 것.

 

ⓑ 그 후 AMI에서 instance를 업그레이드 하면 된다.

CPU 많은 걸로 바꾸던가. 필요한대로.

launch 하면 새로운 인스턴스가 생겼을 것이다.

 

그런데 전에 있던 인스턴스(scale up 하기 전의 인스턴스)는 어떻게 해야 하나?

ⓒ scale up 전의 인스턴스에서 붙어있었던 Elastic IP를 새 인스턴스에 붙여주면 된다.

Elastic IP 페이지에 가서 새 인스턴스에 붙이면 된다.

안전하게 하려면 우선 기존에 연결되어 있던 걸 해제 한 다음 새 인스턴스에 연결.

 

정리하자면,

ⓐ 우선 scale up할 인스턴스의 AMI를 하나 만든다.

ⓑ 그 후 AMI에서 instance를 업그레이드 하면 된다.

ⓒ scale up 전의 인스턴스에서 붙어있었던 Elastic IP를 새 인스턴스에 붙여주면 된다.

그러면 Scale Up 끝!

 

그런데 최고 사향 컴퓨터가 감당하지 못할 정도로 이용자가 몰리면 어떻게 할까?

Scale Out을 하면 된다.

처음부터 scale out을 하지 말아라. 우선은 scale up. egoing의 말로는 그렇다.

왜냐하면 여러개의 컴퓨터가 만들어지면 관리의 복잡함이 증가함에 따라 관리가 힘들어지기 때문.