AWS - 이론) Elasticity, Management 서비스

탄력성 관리및 도구 서비스

ELB

- 로드밸런싱 제공 서비스

- 로드밸런싱을 제공하는 어플리케이션들에게 지속적으로 Ping 보내어 상태확인을 하여 문제가 생긴다면 더이상 그쪽으로는

  로드밸런싱을 하지 않는다

- Cloud Watch와 상호작용 가능

- 각 로드밸런서에 Public DNS이름이 제공되므로 웹어플리케이션을 프라이빗 서브넷에 배치 가능하다

- 가용영역 단위로 트래픽을 나누어준다. => 교차영역로드밸런싱으로 해결가능

1. 부하분산

라운드로빈

- LoadBalancer의 부하분산은 라운드로빈 방식으로 진행한다 즉, 우선순위가 없이 차례대로 부하분산을 한다

 또한 가용영역들에 대하여 1:1로 부하 분산을 진행하므로 부하 집중 현상을 주의해야 한다.

부하집중 현상

- Load Balancer의 부하분산 방법은 라운드로빈 방식이므로 서로 다른 가용영역에 존재하는 인스턴스 수가 

   다를때에는 특정 인스턴스에 부하가 몰리게 되므로 서로 다른 가용영역에 존재하는 인스턴스수를 동일하게 해주어야 한다

예를들어 A 가용영역에는 1개의 인스턴스가 있고 B 가용영역에는 2개의 인스턴스가 있을때에 B가용 영역에서는 

2개의 인스턴스가 다시 부하를 나누어 처리하지만 A가용영역에서는 1개의 인스턴스에서 모든 부하를 처리해야한다.

CrossZone Load Balancing(교차영역 로드밸런싱)

- 가용영역 단위로 로드밸런싱을 하는 것이아니라 전영역을 묶어 트래픽을 분산한다.

   가용영역 들에 존재하는 모든 인스턴스로 부하를 분산한다.

2. ELB 종류

1) External ELB

- 인터넷에서 요청을 받아 부하를 분산한다

 따라서 Public IP가 부여되며 Public Subnet에 위치시켜 인터넷과 연결되도록 해야한다.

2) Internal ELB

- Internal ELB는 VPC 서브넷 내부의 요청만을 받아 부하를 분산한다

  따라서 Public IP가 부여되지 않는다 때문에 Public Subnet에 연결하더라도 인터넷 연결이 되지 않는다

3. ELB 세션 유지방법

1) Sticky Session

- 한 사용자의 요청을 하나의 인스턴스와 연결하여 처리하게 만드는 기능

- ELB에서 독자적으로 발행한 쿠리를 사용하는 것과 애플리케이션에서 발행한 쿠키를 사용하는것중에 선택가능

2) ElastiCache

- 모든 인스턴스에서 세션정보를 공유하도록 할 수 있다.

- 내결함성, 가용성, 확장성을 고려하여 요즘에는 거의 이 기술을 이용 

프록시 프로토콜?

- 사용자의 트래픽을 그냥 전달하는 것이 아니라 ELB의 주소를 담아서 보냄

ELB 고정 세션

- 로드밸런서가 사용자의 세션의 수명동안 특정 인스턴스에 바인딩 할 수 있다.

- 로드밸런서 생성 쿠키를 이용하여 어플리케이션 인스턴스를 추적

연결 드레이닝

- 로드밸런서가 트래픽을 분산한 인스턴스가 특별한 이유로 종료시켜야 할 때 

  받은 트래픽을 모두 처리할 때 까지 인스턴스의 종료를 지연시킨다

=> 최종 요청을 보낸 사용자까지 처리를 한 후에 인스턴스의 연결을 종료한다.

다중로드 밸런서

- 접속하는 디바이스의 종류에 따라 다른 로드밸런서를 이용하게 한다.

Cloud Watch

- AWS 클라우드의 리소스와 어플리케이션에대한 모니터링 서비스(CPU, 메모리, 등의 사용량들을 확인한다)

- 자신의 업무 특성에 맞는 지표를 만들 수 있다 

- 경보(알림 기능이 있다) 필요에 따라 SNS, 이메일, 문자 등으로 알림을 받을 수 있다

- AutoScaling 과 연계하여 자동으로 스케일 인,아웃을 할 수 있다

Cloud Watch 사용 예시

1) EC2 

- CPU 사용률이 5분동안 60%를 초과하는 경우 특정 작업을 한다

2) RDS

- 동시 연결 수가 1분동안 10개를 초과하는 경우 특정 작업을 한다

3) ELB

- 정상 호스트 수가 10분 동안 5개 미만인 경우 특정 작업을 한다

AutoScaling

- 자동 스케일 인 아웃

스케일 조정작업

1) API

2) 스크립트

3) AWS Auto Scaling 서비스 

동작 

1. 시작구성 

- 무엇을 AutoScaling 할지를 정함

- 다음의 내용이 구성됨

1) 시작 구성 이름

2) AMI

3) 인스턴스 유형

4) 사용자 데이터

5) 보안 그룹

6) IAM 역할

2. Auto Scaling 그룹 

- 어디에서 AutoScaling 될지를 정함

- AutoScaling Group을 만들어 해당 그룹 내에서 Auto Scaling 되도록 지정

- 다음의 내용이 구성됨

1) AutoScaling Group 이름

2) 시작 구성 이름

3) 최소 및 최대 limit

4) AZ 또는 서브넷

5) 로드 밸런서

6) 원하는 용량

3. AutoScaling 정책

- 언제 Auto Scaling을 실시할지를 정함

1) Auto Scaling 정책

- 지표를 기준으로 조정활동을 개시하도록 Cloud Watch 를 사용해 동적 조정

2) 예약된 

시나리오

1) 최초 2개의 인스턴스가 동작

2) CPU 사용률이 60%

3) 인스턴스가 4개로 늘어남

4) CPU 사용률이 60%

5) 인스턴스가 8개로 늘어남

6) CPU 사용률이 60%

7) 인스턴스가 16개로 늘어나야 하지만 최대 limit이 12이므로 12개로 늘어남

웜업 시나리오

정책1 : CPU 사용량 60% 시 인스턴스 1개 추가

정책2 : CPU 사용량 80% 시 인스턴스 2개 추가   

(*웜업 - 인스턴스가 추가되면 바로 시행이 가능한 것이 아니라 약간의 시간을 기다려야 하는데 이시간을 웜업이라 한다)

1) Cpu사용량이 60%가 넘어가 정책1이 적용되어 인스턴스가 1개 추가 되었다

2) 인스턴스가 웜업기간이 있는 상황에서 계속해서 CPu사용량이 증가되고 있는 상황이다.

3) 아직 추가된 인스턴스에 대한 웜업기간에 CPU 사용량이 80% 넘어가 정책2가 적용된다

4) 웜업 기간에 경보가 발생했기 때문에 첫번째 경보에서 추가된 인스턴스 1개(정책1) 을 빼고 최종적으로 인스턴스 2개가 추가된다.

자체 힐링기능

- 최소 , 최대를 1로 설정 => 인스턴스가 죽게되면 계속해서 다시 살아남 

AutoScaling 스레싱

- CPU 사용량이 올라가서 CPU를 추가하였는데 Cpu를 추가 함으로써 CPU사용량이 다시 줄어들어 

  CPU를 제거하고 다시 제거하므로써 CPU사용량이 올라가며 이가 반복되는 상황

- 최소 및 최대용량을 신중하게 정해야 한다.