[AWS] aws 강의 섹션 7 (로드 밸런서, ALB, NLB, GWLB, ASG, 오토 스케일링)

Scalability 와 High Availabilty

Sclability

• 확장성은 말 그대로 얼마나 많은 양을 처리할 수 있냐를 의미한다.
  • 수직 확장성
  • 수평 확장성 (탄력)

수직 확장성

• 인스턴스의 크기를 확장하는 것을 의미한다.
• 그냥 인스턴스 더 비싼 거 쓰는 것이다. 
  • 데이터베이스와 같이 분산이 힘든 시스템에서 흔히 사용된다.
• 하드웨어 성능에 한계가 있기 때문에 수직 확장에도 한계가 있다.

수평 확장성

• 인스턴스나 시스템의 수를 늘리는 방법이다.
• 분배 시스템이 꼭 있어야 한다. (들어온 임무를 어떤 직원에게 분배할 것인지)
• 대부분의 애플리케이션이 분배 시스템으로 돼있다.

High availabilty

• 고 가용성은 보통 수평 확장과 함께 사용되는 개념이지만 늘 그런 것은 아니다.
• 고 가용성이란 애플리케이션 또는 시스템을 적어도 둘 이상의 센터에서 가동 중인 것을 의미한다
• 고 가용성의 목표는 데이터 센터의 손실에서 살아남는 것이다. (센터 하나가 멈춰도 계속 동작하는 것)
• 고 가용성이 수동적인 경우 (RDS가 여러 AZ에 있는 경우)
  • 장애가 발생했을 때 다른 AZ의 RDS로 돌려 운영하는 것 (운영자의 개입이 들어감)
• 고 가용성이 능동적인 경우 (수평 확장성)
  • 장애가 발생했을 때 운영자가 개입하지 않아도 다른 인스턴스들이 돌아가고 있기 때문에 문제 없음

Load Balancing이란?

• 로드 밸런서는 서버 혹은 서버집합으로  트래픽을 백엔드나 EC2 인스턴스로 분배하는 역할을 한다.

 

• 사용자가 많이질 수록 로드 밸런서에 부하가 늘어난다.
• 사용자는 자신이 어느 EC2에 연결됐는지 알지 못 한다.

왜 로드밸런서가 필요할까?

• 부하를 다수의 다운스트림 인스턴스로 분산하기 위해서다.
• 하나의 액세스 포인트 (도메인)만을 노출하고
• 인스턴스의 장애를 원활히 처리할 수 있다. 
  • 상태확인 매커니즘으로 불가능한 인스턴스엔 요청을 보내지 않는다. 
• HTTPS 프로토콜을 사용할 수도 있다. 
• 쿠키로 고정도를 강화할 수 있고
• 고가용성을 지니며
• 클라우드 내에서 private 트래픽과 public 트래픽을 분리할 수 있다. 

Elastic Load Balancer란?

• 관리형 로드 밸런서로 AWS가 관리하며, 어떤 경우에도 작동할 것을 보장하는 로드밸런서다.
• AWS가 업그레이드, 유지 관리 및 고가용성을 책임지며
• 로드밸런서의 작동 방식을 수정할 수 있도록 도와준다.
• 자체 로드 밸런서를 마련하는 것보다 저렴하다. 
• 로드 밸런서는 다수의 AWS 서비스들과 통합이 가능하다.
  • EC2와도 물론 통합이 가능하며
  • ECS
  • ACM
  • CloudWatch
  • Route 53 등 여러가지와 통합이 가능하다.

Health Check

연결된 인스턴스가 정상적으로 동작하고 있는지 확인하는 방식이다.

헬스 체크에 실패하면 해당 인스턴스로 요청을 보내지 않는다.

 

• 헬스 체크는 포트와 라우터에서 이뤄진다. 
• 예를 들어 백엔드라고 치면 8080 포트에 /health url로 요청을 보낸다
• 200 OK response가 돌아오면 헬스 체크에 성공한 것이다.

AWS 로드 밸런서의 종류

1. classic Load Balancer - V1 2009년에 만들어진 것 CLB라 불림
   • HTTP, HTTPS, TCP, SSL, secure TCP를 지원한다. 
   • 지금은 사용을 권장하지 않는다.
2. Application Load Balancer - V2 2016년에 나온 것 ALB라고 불림 
   • HTTP, HTTPS, WebSocket을 지원한다. 
3. Network Load Balancer - V2 2017년에 나옴 NLB라고 불림
   • TCP, TLS, secure tcp, udp를 지원한다.
4. Gateway Load Balancer - 2020년에 나옴 GWLB라고 불림
   • 네트워크 계층에서 동작한다.
   • ip 프로토콜 

신형 로드 밸런서를 사용하는 것이 권장된다. 

일부 로드 밸런서들은 내부에 설정될 수 있어 네트워크에 private 접근이 가능하고,

외부에서 접근 가능한 public 로드밸런서도 존재한다. 

로드 밸런서는 외부 사용자들의 모든 요청을 받아야 하므로 보안 그룹은 위와 같이

80과 443 포트를 허용하고, ip는 모든 것을 허용하도록 해야한다.

 

EC2는 로드밸런서의 요청만을 받으니 포트는 80으로 source는 보안그룹으로 설정해야 한다. 

 

Application Load Balancer

• 7계층, 즉 Http 전용 로드밸런서다
• 머신 (타켓 그룹)에 속하는 여러 HTTP 애플리케이션으로 트래픽을 분산시킨다. 
• HTTP2와 웹 소켓을 지원한다.
• 리다이렉트도 지원하므로 http를 https로 리다이렉트 할 수 있다.
• 다른 타겟 그룹에 대한 라우팅 테이블도 지원한다.
  • 예) URL 기반 라우팅 (/users,  /posts)
  • 호스트 네임 기반 라우팅 (도메인 네임)
  • 쿼리문이나 헤더에 기반한 라우팅도 가능하다.

마이크로 서비스나 컨테이너 기반 애플리케이션에 가장 좋은 로드밸런서다.

도커나 ECS같은 경우 ALB가 가장 적합한 로드밸런서이다. 

• 포트 매핑 기능이 있어,  ECS 인스턴스의 동적 포트로의 리다이렉션이 가능해지기 때문이다.

다음과 같은 마이크로 서비스에 가장 적합하다.

 

첫 번째 타겟 그룹 유저 EC2와 두 번째 타겟 그룹 검색 EC2로 적절하게 분배한다. 

 

하지만 위의 예시는 이들은 URL기반 라우팅이어서 지능적 라우팅(부하 분산)이 되지 않는다. 

따라서 각 대상 그룹으로 지능적으로 라우팅 하는 방법을 아는 동일 애플리케이션 로드 밸런서의 뒤에 있는 것이다. 

 

설명이 진짜 개떡같은데 ALB는 URL 기반으로 라우팅을 하고

이후 타겟 그룹에서 오토 스케일링 같은 부하 분산 기법을 사용한다는 의미다. 

 

타겟 그룹이란?

• EC2 인스턴스들 (오토 스케일링 그룹에 의해 관리되는) - HTTP 프로토콜
• ECS 작업들 - HTTP
• lambda 함수
• ip Addresses - 반드시 private ip 주소여야만 한다. 
  • 타겟 그룹이 private 주소여야 로드 밸런서와 내부에서 연결시켜 보안성을 높일 수 있기 때문
• ALB 는 여러 타겟 그룹으로 라우팅이 가능하며,
• 헬스 체크는 대상 그룹단에서 이뤄진다. 
• 타겟 그룹이 되기 위해선 서버의 private ip가 대상 그룹에게 지정되어야 한다.

다음은 쿼리문과 파라미터 기반 라우팅의 예시다.

 

Mobile이라면 타겟 그룹1로 플랫폼이 데스크탑이면 타겟 그룹2로 가게

규칙을 정해서 라우팅 할 수 있다. 

 

ALB 팁

1. 호스트 네임은 고정이다.
2. 애플리케이션 서버는 클라이언트의 ip를 직접 보지 못 한다. 
3. 클라이언트의 실제 ip는 헤더의 x-forwarded-for에 삽입된다. 
4. 포트와 프로토콜도 마찬가지로  x-forwarded-port와  x-forwarded-proto를 통해 얻어야 한다. 

ALB, NLB, GWLB 로드 밸런서 사용 예시

• ALB
  • HTTP와 HTTPS 유형의 트래픽을 분산 시키고 싶을 때 사용한다.
• NLB
  • TCP, UDP, TLS 유형에서 사용한다.
  • 초고성능이 필요할 때 사용하는 옵션이다.
  • 초 저지연을 유지하면서 초당 수백만건의 요청을 처리해야할 때 사용
• GWLB
  • 보안, 침입 감지, 방화벽 등에 사용된다.
  • 네트워크 트래픽을 분석하는데 사용된다.

애플리케이션 로드 밸런서 실습

인스턴스 생성 -> 로드 밸런서 생성 -> 가용영역 설정 -> 보안 그룹 설정

 

이후 포트 별 또는 URL 별로 들어오는 요청을 라우팅 시켜야한다.

 

ALB 이므로 HTTP 즉 80포트에서 들어오는 요청을 라우팅할 타겟 그룹을 정해야 한다.

 

타겟 그룹을 만들자.

 

인스턴스를 묶어 만들 수도 있고, IP 주소를 묶어서

람다 함수를 묶어서 등등이 가능하다.

 

그 다음 프로토콜을 선택해준다. 우리는 http 요청을 라우팅 해줄 것이므로 80으로 해준다. 

 

이후 타겟 그룹에 들어갈 인스턴스를 골라준다. 

 

이제 만들어진 타겟 그룹을 ALB의 리스너의 라우팅 대상으로 설정해주면 된다. 

 

로드 밸런서 설정 팁

• 인스턴스에 접근할 때는 로드밸런서를 통해서만 접근하는 것이 좋다.
  • 이를 위해선 EC2 인스턴스의 보안그룹에서 로드밸런서만 허용하도록 바꾸면 된다. 

• 로드밸런서 컨디션에 조건을 추가하여 특정 그룹으로 보낼지, 또는 리다이렉트를 시킬지를 결정할 수 있다. 

Network Load Balancer

• 4계층 로드 밸런서로, TCP와 UDP 트래픽을 처리할 수 있다.
• 시험에 UDP나 TCP가 나온다면 NLB를 떠올리도록 하자
• 네트워크 로드 밸런서는 굉장히 고성능이다.
• 초당 수백만 건을 처리할 수 있으며, 지연시간도 애플리케이션 로드 밸런서 대비 짧다. 
  • ALB: 400ms, NLB: 100ms의 지연시간을 갖는다.
• NLB는 가용 영역 당 하나의 고정 IP가 존재한다. 
  • 각 가용영역에 Elastic IP도 배정할 수 있다.
  • 여러 고정 IP가 있는 애플리케이션을 노출해야 할 때 무척 유용하다.
  • 만약 시험에 여러 개의 ip로 접속할 수 있는 애플리케이션을 만든다고 한다면 NLB를 떠올려야 한다.

NLB 작동 원리

• 타겟 그룹을 생성하면 NLB가 타겟 그룹으로 리다이렉션 한다.

NLB 타겟 그룹 대상

• EC2 인스턴스
• IP 주소 - 하드코딩 돼있어야 하며, 반드시 private ip 여야 한다. 
  • EC2의 private ip를 등록할 수도 있지만, 서버의 private ip를 등록할 수도 있다. 
• 애플리케이션 로드 밸런서
  • NLB 를 ALB 앞에 둘 수도 있다. 
  • NLB로 여러 개의 고정 ip 주소를 얻고 ALB를 통해 HTTP 트래픽을 처리하는 방식으로 구성할 수 있다.
• NLB에서 헬스 체크는 TCP, HTTP, HTTPS만 지원한다. 

Gateway Load Balancer

• 배포 및 확장과 AWS의 타사 네트워크 가상 어플라이언스의 플릿 관리에 사용된다. 
• 네트워크의 모든 트래픽이 방화벽을 통과하게 하거나 침입 탐지 및 방지 시스템에 사용한다.
  • 그래서 IDPS나 심층 패킷 분석 시스템 등을 네트워크 레벨에서 처리할 수 있다.

다음과 같이 동작한다고 생각하면 된다.

1. 유저가 보낸 요청이 게이트웨이 로드 밸런서에 도착한다.
2. 게이트웨이 로드밸런서에서 타사 서비스에 트래픽을 보낸다.
3. 타사 서비스에서 방화벽이나 침입 탐지등을 검사하고 문제가 있다면 트래픽을 드랍,
   문제가 없다면 트래픽을 다시 게이트웨이 로드밸런서로 보낸다.
4. 이후 로드밸런서는 타겟 그룹에 트래픽을 전달한다. 

• 네트워크 레이어인 3계층에서 동작한다. - IP 패킷 사용
• Transparent Network Gateway - 모든 요청이 NGLB를 통과하기 때문
• 대상 그룹의 가상 어플라이언스에 트래픽을 분산시킨다.
• 6081번포트의 GENEVE 프로토콜을 사용해야 한다.  

NGLB의 타겟 그룹

• EC2 인스턴스 - 타사 어플라이언스도 가능
  • EC2 인스턴스일 수도 있고 인스턴스 ID로 등록할 수 있따.
• IP 주소 - 반드시 private ip여야 한다. 
• 자체 네트워크나 자체 데이터 센터에서 가상 어플라이언스를 실행하면 ip로 수동 등록할 수 있다.

Sticky(고정) Sessions (Session Affinity (세션 밀집성 ))

Sticky Sessions란 사용자가 특정 백엔드 서버에 연결된 이후부터,
그 세션 동안 같은 백엔드 서버로 요청을 계속 보내는 것을 의미한다.

 

소셜 로그인을 백엔드에서 구현했을 때를 예시로 들 수 있는데,

 

서버

• 요청받은 username, password로 우리 서버의 인증된 회원인지 확인
• 확인되면 세션ID를 생성하고 세션 저장소에 저장해둠
• 세션ID를 쿠키에 담아서 클라이언트에 전달(response)

며칠후

클라이언트: 쿠키를 가지고 있다가 다음 요청시 쿠키와 함께 다시 요청

서버: 쿠키에 담긴 세션ID와 세션저장소에 담긴 세션 ID를 비교해서 사용자 인가여부를 결정

 

여기서 서버에 담긴 세션 ID와 쿠키를 비교할 때 다중 서버인 경우 세션 ID의 정보가 존재하지 않아

로그인에 실패하는 에러가 발생한다.

 

이를 해결하기 위한 대표적인 방법이 Stick Sessions인 것이다.

 

다만 같은 서버만 계속 사용하기 때문에 운이 안 좋으면 한 서버에 부하가 몰릴 수도 있다.

 

• ALB에서 설정할 수 있다.
• 쿠키를 사용하는데 쿠키가 만료되면 클라이언트는 다른 EC2 인스턴스로 리다이렉트 된다.

Sticky Sessions의 쿠키 종류

두 가지 종류의 쿠키가 존재한다

 

애플리케이션 기반 쿠키

• 사용자 정의 쿠키
  • 사용자 정의 쿠키로 애플리케이션에서 생성된다.
  • 애플리케이션에서 만드는 것이므로, 애플리케이션에 필요한 모든 사용자 정의 속성을 포함할 수 있다.
  • 쿠키 이름은 타겟 그룹별로 다르게 지정해야 하는데, 다음과 같은 이름은 사용하면 안 된다.
    • AWSALB, AWSALBAPP, AWSALBTG (이들은 모두 예약어이다.)
• 애플리케이션 쿠키
  • 로드 밸런서에 의해 생성된다.
  • ALB의 쿠키 이름은 AWSALBAPP이다.
• 애플리케이션 쿠키는 애플리케이션 내부에서 쿠키 만료 기간을 설정할 수 있다.

기간 기반 쿠키

• 로드 밸런서에서 생성되는 쿠키다
• ALB에서는 이름이 AWSALB이다.
• 특정 기간을 기반으로 만료되며, 그 기간도 로드밸런서에서 정해진다.

스티키 세션 활성화 방법

타겟 그룹 이동 -> 작업 클릭 -> 속성 수정 클릭 -> Stickness 활성화

 

Cross-Zone Load Balacing

교차 영역 밸런싱이란 가용영역에 상관없이 EC2 인스턴스 단위로 부하를 분산 시키는 것을 의미한다.

 

로드 밸런서 단위로 부하를 분산한다면 왼쪽 절반 오른쪽 절반으로 

 

왼쪽 가용영역에 EC2 개수가 적으므로 왼쪽에 아주 큰 부하가 걸릴 것이다. 이러한 상황을 방지 해준다.

 

• 애플리케이션 로드 밸런서의 경우 기본적으로 교차 영역 로드 밸런싱이 활성화 돼 있다.
  • 비활성화는 타겟 그룹에서 설정 가능하다.
  • 데이터가 다른 AZ로 넘어가도 요금이 부과되지 않는다.
    • 보통 데이터가 다른 가용영역으로 넘어갈 때마다 요금을 지불해야하기 때문
• 네트워크 로드 밸런서와 게이트웨이 로드 밸런서는 기본적으로 
  교차 영역 로드밸런서가 비활성화 돼있다.
  • 이 경우에 활성화를 하면 요금이 부과된다.

SSL/TLS

• SSL 인증서는 클라이언트와 로드 밸런서 사이에서 트래픽이 전송되는 동안 암호화가 되도록 해준다.
• 데이터가 네트워크를 통과하는 도중 암호화가 되어있어 보안상 이점이 있다.
• SSL은 Secure Socket Layer 보안 소켓 계층이란 뜻이며 연결을 암호화 할 때 사용한다.

 

• TLS는 SSL의 새 버전이고, Transport Layer Security라는 뜻이다.
• 요즘엔 TLS가 주로 사용되지만, 여전히 많은 사람이 TLS를 SSL이라 부른다.

 

• 퍼블릭 SSL 인증서는 인증 기관에서 발행한다
• 기관은 뭐 Comodo, Symanetc 등등 여러 가지가 있다.

이 SSL 인증서를 활용하면 사용자와 로드 밸런서 사이 트래픽을 암호화 할 수 있다.

 

SSL 인증서는 만료 날짜가 정해져 있으며, 인증서의 진위를 확인하기 위해 주기적으로 갱신해야 한다.

 

로드 밸런서 흐름

• 사용자는 HTTPS 프로토콜로 요청을 보낸다. 
• 로드 밸런서는 트래픽을 받고 나서 내부적으로 SSL 연결을 종료시킨다.
  • 어차피 EC2는 보안그룹으로 로드밸런서랑만 트래픽을 주고 받을 수 있으니까 보안 연결이 필요없음
• 백엔드는 따라서 HTTP로 로드 밸런서와 통신한다. 

로드 밸런서는 X.509 인증서를 사용한다. 

 

AWS 에서는 ACM (AWS Certificate Manager)를 통해 SSL 인증서를 관리할 수 있다.

 

• 로드 밸런서에서 HTTPS 리스너를 설정할 때는 SSL 인증서를 지정해줘야 한다. 
  • 인증서 목록을 추가해 여러 도메인을 지원할 수 있다.
• 클라이언트는 SNI(Server Name Indication)을 활용해 전송하는 호스트 네임을 지정할 수도 있다.

SNI

• 하나의 웹 서버에 여러 SSL 인증서를 로드해 웹 서버가 여러 웹사이트를 지원하게 만드는 방법이다. 
• 클라이언트가 초기 SSL 핸드셰이크에서 클라이언트의 호스트 네임을 보내주는 식으로 동작하는 프로토콜이다.
• 클라이언트가 이 도메인에 연결하고 싶다고 하면 서버는 어떤 인증서를 로드해야 하는지 알 수 있다.

ALB와 NLB, CloubFront에서 사용할 수 있다.

 

로드 밸런서에서 여러 SSL인증서를 사용한다면 ALB나 NLB가 답이 된다.

 

클라이언트에서 요청이 들어올 때 SSL 핸드셰이크로 도메인 네임을 알아낸다.

알맞은 SSL 인증서를 로드하고 해당 방식으로 암호화 하라고 클라이언트에게 응답한다.

 

클라이언트는 돌아온 SSL 인증서를 확인하고 알맞은 SSL 세션을 설정한다.

로드 밸런서는 들어오는 요청을 알맞은 타겟 그룹에 전달한다. 

 

ALB - 여러 개의 SSL 인증서 지원

 

NLB - 여러 개의 SSL 인증서 지원

 

Connection Draining

• Deregistraion Delay (등록 취소 지연) - ALB와 NLB를 사용할 땐 이 이름으로 불린다.
• 로드 밸런서가 백엔드 서버를 비활성화 하거나 제거할 때, 현재 처리 중인 요청을 안전하게
  완료할 시간을 주는 기능이다. 
• 이 기능으로 갑작스러운 연결 종료로 인해 클라이언트의 요청이 손실되거나 오류가 발생하는 것을 방지할 수 있다.
• 인스턴스 연결이 Drain 되면 ELB는 등록 취소 중인 EC2 인스턴스로 더 이상 요청을 보내지 않는다.

드레인 상태에 들어간 인스턴스가 마지막으로 클라이언트에게 받은 작업이 끝나면
EC2 인스턴스는 모든 연결이 종료된다.

• 드레인 시간은 1~3600 초 사이의 시간으로 설정할 수 있는데 기본 값은 300초다.
• 값을 0으로 설정해 비활성화 시킬 수도 있다.
• 1초 미만의 요청에 대해서 드레이닝 파라미터를 30초 정도로 설정하면 된다. 

Auto Scaling Group이란

• 실제 애플리케이션은 시간이 지남에 따라 웹사이트에 트래픽이 엄청 많이 지기도 하고 엄청 적어지기도 한다.
• 클라우드 즉 AWS 에서는 EC2 인스턴스를 아주 빠르게 만들거나 삭제할 수 있다.
• 이렇게 현재 트래픽 양에 따라 EC2 인스턴스를 확장하고 줄이는 것을 
  자동화 해주는 작업이 바로 오토 스케일링 그룹 ASG 이다.

목표

• Scale Out: EC2 인스턴스를 추가해서 늘어난 로드에 맞추는 것
• Scale in: EC2 인스턴스를 제거하여 줄어든 로드에 맞추는 것
• 전체적으로 매개변수를 설정해서 ASG에서 실행되는 최소 , 최대 인스턴스 개수를 정할 수도 있다.

ASG를 로드밸런서와 연결 시키면 ASG에 포함된 모든 EC2 인스턴스가 로드 밸런서에 연결된다.

• 특정 인스턴스가 un healthy 상태라면 해당 인스턴스를 종료하고 새 인스턴스를 만든다.
  • 로드 밸런서에서 인스턴스 상태를 체크하고 체크 결과를 ASG로 전송한다.
• ASG는 무료이다.

ASG 속성 설정

• Launch Template 설정 
  • ASG에서 EC2 인스턴스를 시작하는 방법에 대한 정보가 들어있다.
  • AMI, 인스턴스 유형, EC2 user data, EBS 볼륨, 보안 그룹, 
    SSH 키, IAM role, 네트워크, 서브넷 정보, 로드 밸런서 정보 등등,,
• ASG의 최소 크기, 최대 크기, 초기 용량과 스케일링 정책 설정 

CloudWatch 알림과 스케일링 정책

클라우드 워치 알림을 기반으로 ASG에서 스케일 인, 아웃을 할 수 있다.

 

클라우드 워치에서 평균 CPU를 관찰하거나, 사용자가 지정해준 지표를 검사하는 방식으로

임계점을 넘기면 알림을 울려 스케일 인, 아웃을 진행할 수 있다.

 

오토 스케일링 그룹 만드는 법

EC2에서 오토 스케일링 그룹을 선택한다. -> 생성 클릭

-> 시작 템플릿 만들기 -> AMI설정, 인스턴스 타입 설정, 키페어 설정, 보안그룹 등등 선택,,

-> 로드 밸런서 선택 -> 연결될 타겟 그룹 선택 -> 헬스 체크 방식 선택 -> ASG 용량 선택 -> 스케일 정책 선택 -> 끝

 

새로 생성되는 인스턴스들이 자동으로 타겟그룹에 들어간다. 

 

ASG - 스케일링 정책

• 동적 스케일링 
  • 타겟을 추적한다.
  • 설정이 아주 간단하다
  • 예) ASG의 cpu 평균 사용량 40%
    • 위와 같이 설정해두면 CPU의 평균 사용량 40%를 맞추기 위해 자동으로 삭제 or 추가가 일어난다.
• simple / step 스케일링
  • 클라우드 워치 알림과 규칙을 설정한다.
  • 예) 클라우드 워치 알림 트리거 (CPU > 70%) then add 2 units
  • 예) 클라우드 워치 알림 트리거 (CPU < 30%) then remove 1
• schedule 스케일링
  • 알려진 사용 패턴을 기반으로 스케일링을 예상할 수 있다.
  • 예) 금요일 오후 5시에 매번 사용자가 급증하므로 용량을 늘려라
• predictive 스케일링
  • 지속적으로 부하를 예측한 다음 미리 스케일링을 예약해둔다.
  • 반복되는 패턴이 있을 때 좋다. (이전의 데이터가 있는 경우 사용하기 좋다.)

scale on의 좋은 규칙

• CPU 사용률: 평균 CPU 사용률을 통해 인스턴스를 활성화 한다.
• 인스턴스 별 요청 수: 보통 한 번에 1000개의 요청을 처리하는 것이 가장 효율적인 인스턴스의 사용이라고 한다.
  그것 보다 적으면 인스턴스의 자원 낭비이며, 이것보다 높으면 하드 디스크 버퍼에 요청이 쌓인다는 뭐 그런 ,,
  따라서 인스턴스 별 요청 count에 따라 스케일링을 진행하는 방식이다. 
• 네트워크 in/out 기준:
  예) 업로드와 다운로드가 너무 많아 EC2 인스턴스에 병목현상이 발생될 것이라 예상된다면,
  평균 네트워크 사용량을 기준으로 스케일링을 설정하는 것이 좋다. 
  
  

Scaling Cooldowns

• 스케일링 작업이 있은 후에 기본적으로 5분간 쿨다운 시간에 들어간다. 
• 그리고 그 쿨다운 시간동안 ASG는 인스턴스를 추가하거나 종료하지 않는다. 
• 쿨다운 시간이 없다면 새 인스턴스가 추가돼서 CPU 사용량이 줄어들 때까지 인스턴스를 무한 생성할 것이다.
• AMI 같이 EC2를 새로 생성하는데 시간을 줄일 수 있는 요소를 활용하여 쿨다운 시간을 감소 시키도록 하자.

Instance Refresh

• EC2 launch 템플릿을 업데이트 할 경우 모든 EC2를 다시 새로 만들어야 할 것이다.
• 이 상황 속에서 점진적으로 EC2를 교체하는 방법이 바로 인스턴스 리프레쉬다.
• minimum Healthy percentage를 설정하여 서비스 운영에 필요한 최소의 인스턴스를 유지하며
  오래된 인스턴스들을 새로운 템플릿의 인스턴스로 교체한다.
• 이후 새로운 템플릿의 인스턴스에게 웜업 시간을 부여하고 정상적으로 운영할 수 있다 판단되면
  새로운 템플릿의 인스턴스로 운영을 이어나가고 오래된 템플릿의 인스턴스를 전부 교체한다.