[AWS] EC2 Scalability (Scale UP/Scale Out)

EC2 특징과 Scalability (Scale UP/Scale Out/ELB)

▣ 가상화

• 가상머신이란?

물리적인 형태를 가지고 있는 컴퓨터 소프트웨어로 만든 가짜 머신(컴퓨터)

일개의 프로그램, CPU, 메모리 등을 가지고 정말 머신(컴퓨터)인척 함.

>> 이런 복잡한 일을 왜 하는지? 하나의 물리적 기계 위에서 여러개의 운영체제를 설치해서 사용하기 위해서

• 가상머신의 종류

개인용 : VMWare, VirutualBox, Parallels ...

기업용 : 클라우딩 컴퓨터(AWS 등)

개인용과 기업용의 공통점 : 물리적인 컴퓨터가 최소 한대는 있어야함. 그래야지 가상머신(인스턴스)들을 만들 수 있다. 하지만 AWS와 같은 서비스는 어마어마한 물리적인 컴퓨터를 가지고 있어야하고, 가지고 있다 실제로.

• 클라우딩 컴퓨터의 장점

1. 저렴한 인스턴스(컴퓨터)로도 충분히 많은 사용자를 수용할 수 있다.

2. 강력한 인스턴스(여러개의 물리적인 컴퓨터를 가지고 있는 효과의 컴퓨터)를 짧은 시간에 만들 수 있다.

3. ★사용자 접속수가 올라감에 따라 필요한 컴퓨터를 바로바로 증가시킨다.

Scalability 변화하는 수요에 얼마나 탄력적으로 대응할 수 있는가.

전략 : 하나의 인스턴스(컴퓨터)를 더 좋은 컴퓨터로 교체하는 것.

스트레스 테스트(stress test) 환경 구축하기 ]

공격당할 인스턴스의 CPU 점유율 확인 명령어 : 해당 인스턴스 접근 ssh -i ~ > top

공격할 인스턴스 공격!

( 에러가 생긴다면 sudo apt-get install > ) sudo apt-get install apache2-utils(ab bench를 설치하기 위함) > y > ab(apache bench) [enter-requests요청, concurrency 동시접속 “집중”] > ab -n 400 -c 1 도메인주소(또는 IP)

결과 분석 ]


Time taken for tests(s)
: 총 소요시간

failed request : 실패 (제대로 된 정보를 못 보내주는 경우)


requests per second(s) : 초당처리속도, 1초에 인스턴스에 접근할 수 있는 횟수


time per request (ms) : 개별처리속도. 400명 한명한명이 접속할 때마다 얼마나 시간이 걸리는가?(평균값) (ex) 35ms (0.035s)


▣ Scalability 방법

1. Scale Up : 수요에 따라 더 좋은 컴퓨터(인스턴스)로 업그레이드 하는 것.

• 기존 인스턴스를 이미지화 시킨 후, 이미지화 된 인스턴스를 AMIs에서 더 좋은 인스턴스 타입을 선택하여 Lanch!
• 이미지화 : 해당 인스턴스 우측 클릭 > Image > Create Image (설정 기간동안 인스턴스 중단!)

※ 주의사항

함수로 인스턴스를 중단(stop) 시키지 않는다 : 다시 시작하면 도메인과 IP가 바뀌어져 있음. ( 원인 : IP 고갈현상 )

이미지화 하게 되면 인스턴스가 일정 기간동안 중단(stop)되는데, 고정 IP 받는 방법!

1. Dashboard > network&security > elastic IPs > Allocate New Address > 아마존으로부터 고정 IP를 받는다 (유료!) > 이 작업은 일단 기존 인스턴스에 붙여준다.

( 나중에 스케일업해준 인스턴스랑 연결해줄것임 , Release Address : 고정 IP 삭제 )


2. 1번에서 받은 고정 IP를 인스턴스와 연결. 우측클릭 > Associate Address(scale up한 인스턴스와 연결) > security group 기존 인스턴스와 동일한 것으로 설정해주기.

2. 방법2 추후 업데이트

2. Scale Out (ELB)

• 여러대의 컴퓨터(인스턴스)가 협력해서 동일한 목표를 달성하는 것.
• 시스템이 컴퓨팅 파워를 더 많이 요구할 수록, Scale Up 하다보면 단일 컴퓨팅으로서의 한계에 도달하게 된다.

Scale Out의 흐름(인스턴스 하나에는 일반적으로 세가지로 이루어져있다.)

WEB SERVER(아파치 등)     -(요청)->     MIDDEL WARE(jsp, php, spring, jango ... )     -(요청)->     DATABASE(mysql, 오라클 등)

컴퓨터 하나가 감당하고 있었던 세 가지 중 하나를 새로운 컴퓨터(인스턴스)로 이전하는 것. (기존 인스턴스와의 연결 : 새로운 컴퓨터의 IP로 접근.)

단점 : 더 복잡해졌다는 것. (사용자의 입장에서는 달라지지 않았지만 내부적인 구조가 바뀜. )

일반적으로, 웹서버는 여러개로 나누지 않는다. 사용자가 IP를 통해서 접근을 하는데 여러개가 있으면, 혼란이 오기 때문에. 하지만 방법은 있다!

방법1. DNS

사용자가 홈페이지에 접근을 할 때 도메인을 썼던 IP를 썼던, 결과적으로는 IP를 찾아서 홈페이지에 접근하게 되는데, 이 때 사용자 몰래 DNS(전화번호부라고 생각하면 편함)에 접속해서 IP를 알아낸다. DNS의 설정을 바꾸어서 어떤 사용자가 도메인으로 접속했을 때, 서로 다른 IP를 가지고 있는 웹서버에 분산해서 접근하게 된다.

방법2. ELB

Load Balancer(AWS의 ELB) 부하의 균형을 잡아주는 장치.

Load Balancer(IP 가지고 있음)로 사용자들이 접속(Load Balancer Port-기본적으로 80)해서 이 장치가 Instance Port를 통해 분산시켜주는 것.

방법3. Auto Scaling

• ELB 과정을 사람이 아닌 기계가 하도록 하는 일종의 인공지능 서비스.
• 아마존 웹서비스의 꽃 중에 하나!
  
  

1. 과부화 된 인스턴스를 이미지한다.

2. auto scaling > lanch configurations

인스턴스를 만드는 과정과 똑같이 진행하면 된다. (auto scaling에 사용할 이미지를 선택하는 것.)

자동으로 생성할 인스턴스를 어떤것을 사용할지 설정.

3. auto scaling > auto scaling groups

어떠한 조건에서 인스턴스를 만들지 정의함.

launch configurations를 통해 만든 인스턴스를 컴퓨터를 실제로 만들어 주는 것.

- submit : 가용구역을 설정할 수 있는데, 하나보다는 여러개를 설정하는 것이 좋다. 하나의 가용구역에서 문제가 생겼을 때를 대비.

 

▣ ELB 생성

Elastic Load Balancer : AWS에서 지원해주는 부하 균형 장치

[Load Balancer > Load Balance]

STEP1 : define load balance

로드밸런스 이름을 정하고, (Inside) 기본으로 두기

로드밸런스 포트와 인스턴스 포트 설정 , HTTP80 / HTTP80 (기본적) ,HTTPS 443 /HTTP80 ... 등 (인증서 관련 문제)

STEP2: assign security groups

보안 설정.

STEP3 : configure security settings

STEP4 : configure health check

Load Balancer가 사용자의 분산을 해주는데 어떤 컴퓨터가 죽었을 때 그쪽으로는 연결해주면 안되기 때문에,

각각의 컴퓨터가 죽어있는지 살아있는지 체크하는 것.

- ping path : ELB과 웹서버에 접속했을 때 ping path에 적힌파일에 접속할 수 있다면, 살아있다고 생각하고

안되면 죽었다고 생각하고 사용자들을 그쪽으로 보내지 않는 것.

- Response timeout 정한 시간 보다 더 걸리면 건강하지 않다고 생각함.

- Health Check Interval 정한 시간 마다 ELB가 health 체크

- Unhealthy Threshold : Response timeout, health check interval을 통해 체크했을 때, 기입한 숫자만큼 되지 않으면 죽었다고 생각

- Health Threshold : 죽어있는 상태에서도 접속은 하는데 기입한 숫자만큼 시도했을 때 되면 살았다고 생각하고 다시 서비스를 보냄/

STEP5 : ADD EC2 Instances

STEP6 : add tags

STEP7 : review & elb 생성 확인. (eLB도 도메인을 가지고 있다, 도메인 통해 접속 가능!)

▣ ELB 사용

1. 과부화 된 인스턴스를 이미지화 시킨다.

2. 새로운 인스턴스를 만든다.

3. 만들어놓은 ELB에 1번과 2번 인스턴스를 등록한다.

(status에 InService가 보이면 서비스가 되고 있다는 뜻, 이때 1번에서 펜딩시켜놓은 인스턴스가 자동으로 살아나있다.)

* stress test를 통해 ELB 도메인으로 접속했을 때, 각각의 인스턴스로 랜덤하게 접근하는 것을 볼 수 있다.

( 추적 명령어 : sudo tail -f /var/log/apache2/access.log )

▣ ELB 주의사항

사용자가 글을 쓰거나, 이미지를 업로드하는 것과 같은 작업이 포함된 서비스에서는 ELB 사용에 주의!

그런 작업은 데이터베이스에 저장되게 되는데, 각각의 인스턴스에 데이터베이스가 하나씩 있다면, 사용자가 ELB로 글을 작성했을 때와 다른 인스턴스로 접근한다면 자신이 쓴 글을 볼 수 없는 문제가 생길 수 있다.

그러므로 이런 경우의 DB는 동일한 인스턴스에 두는 것이 일단은 바람직하다.