[AWS/Cloud] 강의 노트 : 고가용성 및 스케일링성: ELB 및 ASG

---

고가용성 및 스케일링성

확장성

• 확장성 : 애플리케이션이 조정을 통해 더 많은 양을 처리할 수 있다는 의미
• 확장성의 종류
  • 수직 확장성 : 인스턴스의 크기를 확장하는 것
    • 1개의 인스턴스가 더 많은 일을 처리할 수 있도록 크기를 키움
    • DB와 같이 분산되지 않은 시스템에서 흔히 사용
  • 수평 확장성 (=탄력성)
    • 애플리케이션에서 인스턴스나 시스템의 수를 늘리는 방법
    • 분배 시스템이 있을 때 사용

 

고가용성

• 애플리케이션 또는 시스템을 적어도 둘 이상의 AZ나 데이터 센터에서 가동 중이라는 것을 의미
• 데이터 센터에서의 손실에서 살아남는 것이 목표 : 센터 하나가 멈춰도 계속 작동이 가능

 

EC2의 고가용성 및 확장성

• 확장성
  • 수직 확장 : 인스턴스의 크기를 늘리는 것 (scale up / down)
  • 수평 확장 : 인스턴스의 수를 늘리는 것 (scale out / in)
• 고가용성
  • 동일 애플리케이션의 동일 인스턴스를 다수의 AZ에 걸쳐 실행하는 경우

---

ELB (Elastic Load Balancing)

• 로드 밸런서 : 서버 혹은 서버셋, 트래픽을 백엔드나 다운스트림 EC2 인스턴스 또는 서버들로 전달하는 역할
• 더 많은 인스턴스가 연결 → EC2 인스턴스로 가는 부하가 더욱 분산되도록 함
• 유저들은 백엔드 인스턴스 중 어떤 것에 연결되어 있는지 알 수 없다
• 유저들은 자신들이 ELB로 연결되면 한 엔드 포인트에 연결이 된다는 것만 알고 있다

 

로드밸런서의 필요성

• 부하를 다수의 다운스트림 인스턴스로 분산하기 위함
• 애플리케이션에 단일 액세스 지점(DNS)을 노출하게 되고 다운스트림 인스턴스의 장애를 원활히 처리할 수 있다
  • 로드 밸런서가 상태 확인 매커니즘으로 어떤 인스턴스로 트래픽을 보낼 수 없는지 확인 → 인스턴스 상태 확인 가능
• SSL 종료를 할 수 있으므로 웹 사이트에 암호화된 HTTPS 트래픽을 가질 수 있다
• 쿠키로 고정도를 강화할 수 있고, 영역에 걸친 고가용성을 가지며, 클라우드 내에 개인 트래픽과 공공 트래픽을 분리할 수 있다

 

로드밸런서 사용 이유

• 관리형 로드 밸런서 : AWS가 업그레이드와 유지 관리 및 고가용성을 책임, 로드 밸런서의 작동 방식을 수정할 수 있게끔 일부 구성 놉도 제공
• 무조건 쓰는 편이 좋다
  • 자체 로드 밸런서를 마련하는 것보다 저렴함
  • 자체적으로 관리할 때 확장성 측면에서 굉장히 번거롭다
• 로드 밸런서는 다수의 AWS 서비스들과 통합되어 있다
  • EC2, EC2 스케일링 그룹, ACM, Route 53 …

 

상태 확인

• ELB가 EC2 인스턴스 작동이 올바르게 되고 있는 지 여부를 확인하기 위해 사용
  • 작동되지 않으면 EC2 인스턴스로 트래픽을 보낼 수 없음
• 상태 확인은 포트와 라우터를 통해 이뤄짐
  • EC2 인스턴스가 HTTP 상태코드로 200을 보내지 않는다면 인스턴스 상태가 좋지 않다고 기록
  • → ELB는 해당 EC2로 트래픽을 보내지 않게 함

 

AWS의 네 종류의 관리형 로드 밸런서

1. 클래식 ELB (= CLB)
   • 기존 세대 또는 V1
   • HTTP, HTTPS, TCP, SSL, secure TCP 지원
   • AWS에서 사용을 권장하지 않음
2. 신형 ELB (= ALB)
   • HTTP, HTTPS, WebSoket 프로토콜 지원
3. 네트워크 로드 밸런서
   • TCP, TLS, secure TCP, UDP 프로토콜 지원
4. 게이트웨이 로드 밸런서 (=GWLB)
   • 네트워크 층에서 작동 → 3계층과 IP 프로토콜에서 작동

cf. 결론적으로 ALB를 사용하는 것을 권장

 

로드밸런서 보안

• 유저는 HTTP나 HTTPS를 사용해 로드밸런서 접근 가능
• EC2 인스턴스는 로드 밸런서를 통해 들어오는 트래픽만을 관리⇒ 로드 밸런서에서 온 트래픽 만을 허용하는 강력한 보안 매커니즘 가능
• → 접근 소스를 IP 범위가 아니라 보안 그룹으로 설정

---

ALB(Application Load Balancer, v2)

• 7계층, 즉 HTTP 전용 로드 밸런서로 머신 간 다수 HTTP 애플리케이션의 라우팅에 사용
  • 머신들은 대상 그룹이라는 그룹으로 묶임
• 동일 EC2 인스턴스 상의 여러 애플리케이션에 부하를 분산, 컨테이너와 ECS를 사용하게 됨
• HTTP/2와 WebSocket을 지원
• 리다이렉트 지원 : HTTP에서 HTTPS로 트래픽을 자동 리다이렉트하려는 경우 → 로드 밸런서 레벨에서 가능
• 경로 라우팅 지원
  • 대상 그룹에 따른 라우팅 가능 : ex) URL 대상 경로에 기반한 라우팅
  • 호스트 이름에 기반한 라우팅 가능
  • 쿼리 스트링, 헤더에 기반한 라우팅 가능
• 마이크로 서비스나 컨테이너 기반 애플리케이션에 가장 좋은 로드 밸런서
• 도커나 ECS의 경우 ALB가 가장 적합한 로드 밸런서가 될 것 → 포트 맵핑 기능으로 ECS 인스턴스의 동적 포트로의 리다이렉션을 가능하게 해준다
• ALB는 하나 만으로도 다수의 애플리케이션을 처리할 수 있다

 

대상 그룹

• EC2 인스턴스 - 오토 스케일링 그룹에 의해 관리 가능
• ECS 작업
• 람다 함수
• IP 주소 (사설 IP 주소)

• 쿼리 문자열이나 매개변수 라우팅 사용 → 대상 그룹을 다르게 라우팅 규칙을 설정 가능

 

알고 있으면 좋을 것들

• 로드 밸런서를 사용하는 경우에도 고정 호스트 이름이 부여
• 애플리케이션 서버는 클라이언트의 IP를 직접 보지 못함
  • 클라이언트의 실제 IP는 X-Forwarded-For라는 헤더에 삽입
  • X-Forwarded-Port, X-Forwarded-Proto에 의해 사용되는 프로토콜을 얻게 됨
• 클라이언트 IP는 로드 밸런서와 직접 통신 → 연결 종료 기능을 수행
• 로드밸런서가 EC2 인스턴스와 통신 → 사설 IP인 로드 밸런서 IP를 사용해 EC2 인스턴스로 접속
• EC2 인스턴스가 클라이언트 IP를 알기 위해서는, HTTP 요청에 있는 추가 헤더 X-Forwarded-Port, X-Forwarded-Proto를 확인해야 함

---

NLB (Network Load Balancer)

• 네트워크 로드 밸런서는 L4 로드 밸런서로 TCP와 UDP 트래픽을 다룰 수 있다
• cf. HTTP를 다루는 L7보다 하위 계층
• 시험 : ````UDP/TCP(L4) ⇒ NLB`
• ALB에 비해 지연 시간이 짧음
• AZ 마다 하나의 고정 IP를 갖는다
• 탄력적 IP 주소를 각 AZ에 할당할 수 있다
  • 여러 개의 고정 IP를 가진 애플리케이션을 노출할 때 유용
• 시험 : **1~3개의 IP로만 액세스할 수 있는 애플리케이션**을 만들어야 하는 조건 → **네트워크 로드 밸런서**를 옵션으로 고려
• 고성능, TCP, UDP, 정적 IP => NLB

---

NLB (Network Load Balancer)

• 대상 그룹을 생성 → NLB가 대상 그룹을 리다이렉트

 

Target Group

• EC2 인스턴스는 대상 그룹이 될 수 있다
• ⇒ NLB가 TCP or UDP 트래픽 → EC2 인스턴스로 리다이렉트 가능
• IP 주소를 등록 가능
  • 조건 : IP 주소는 반드시 하드코딩, 프라이빗 IP이어야 함
    • 자체 EC2 인스턴스의 프라이빗 IP를 보낼 수도 있지만, 자체 데이터 센터 서버의 프라이빗 IP를 사용할 수도 있다
• ALB 앞에 NLB를 사용할 수 있다
  • NLB 덕분에 고정 IP 주소를 얻을 수 있다
  • ALB 덕분에 HTTP 유형의 트래픽을 처리하는 규칙을 얻을 수 있다
• NLB 대상 그룹이 수행하는 ‘상태 확인’에 대해 알아야 함 - 세 가지 프로토콜 지원
  • TCP, HTTP, HTTPS 프로토콜 지원

---

GWLB (GateWay Load Balancer)

• 배포 및 확장, AWS의 타사 네트워크 가상 어플라이언스의 플릿 관리에 사용
• 네트워크의 모든 트래픽이 방화벽을 통과하게 하거나 침입 탐지 및 방지 시스템에 사용
• → IDPS나 심층 패킷 분석 시스템 또는 일부 페이로드를 수정, 네트워크 수준에서 가능
• 네트워크 계층인 L3 수준에서 실행

• 트래픽이 애플리케이션으로 이동하기 전에 모든 트래픽을 검사하려면?
  1. GWLB를 생성
  2. VPC에서 라우팅 테이블이 업데이트
  3. cf. 라우팅 테이블 : VPC 존재하는 서브넷들이 특정 범위의 IP 목적지를 향할 때, Target을 정해주는 역할
  4. 모든 트래픽은 GWLB를 통과
  5. GWLB는 Target Group으로 트래픽을 확산
  6. 모든 트래픽은 어플라이언스에 도달, 어플라이언스는 트래픽을 분석/처리
     • 방화벽이나 침입탐지 등
  7. 이상이 없으면 GWLB로 다시 전송, 이상이 있다면 트래픽을 드롭
  8. GWLB로 전송된 트래픽은 다시 애플리케이션으로 전송됨
  ⇒ GWLB의 기능은 네트워크 트래픽을 분석하는 것
• ⇒ GWLB를 사용하면 간단히 처리가 가능
• GWLB는 모든 로드 밸런서보다 낮은 수준에서 실행 : L3 (네트워크 계층)
• GWLB 2가지 기능
  1. 투명 네트워크 게이트웨이
     • VCP의 모든 트래픽이 GWLB가 되는 단일 엔트리와 출구를 통과
  2. 대상 그룹의 가상 어플라이언스 집합에 전반적으로 트래픽을 분산해 로드 밸런서가 됨
• 시험 : **6081**번 포트의 **GENEVE** 프로토콜을 사용 ⇒ **GWLB**

cf. 그림 이해를 목표로 할 것

 

Target Group

• EC2 인스턴스
• IP 주소 : Private IP이어야 함

---

ELB 고정 세션 및 세션 밀접성 (Sticky Seesion, Session Affinity)

• 고정성 혹은 고정 세션을 실행하는 것
• 로드 밸런서에 2가지 요청을 수행하는 클라이언트가 요청에 응답하기 위해 백엔드에 동일한 인스턴스를 갖는 것
• 2개의 EC2 인스턴스와 3개의 클라이언트가 있는 ALB와 같은 것
  • 1번 클라이언트가 요청을 생성해 첫 번째 EC2 인스턴스를 통과하면
  • 로드 밸런서에서 두 번째 요청을 실행할 때, 동일한 인스턴스로 이동하게끔 한다
  cf. 로드 밸런서가 모든 요청을 확산하는 것과는 다른 동작
• 쿠키를 통해 고정성과 만료 기간을 갖는다
• 고정성을 활성화하면 백엔드 EC2 인스턴스 부하에 불균형을 초래할 수 있다
  • 일부 인스턴스는 고정 사용자를 갖게 됨

 

쿠키

• 고정 세션에 2가지 유형의 쿠키가 있음
  1. 애플리케이션 기반 쿠키
     • 커스텀 쿠키 : 애플리케이션에서 생성
       • 대상으로 생성된 사용자 정의 쿠키
       • 애플리케이션에 필요한 모든 사용자 정의 속성을 포함할 수 있다
       • 쿠키 이름은 각 대상 그룹 별로 개별적으로 지정해야 함 (ELB에서 사용하는 이름을 사용하지 않아야 한다)
       • ex) AWSALB, AWSALBAPP, AWSALBTG)
     • 애플리케이션 쿠키 : 로드 밸런서에서 생성
       • ALB 쿠키 이름은 AWSALBAPP
     • 애플리케이션에서 기간을 지정할 수 있다
  2. 기간 기반 쿠키
     • 로드 밸런서에서 생성되는 쿠키
     • ALB에서 이름이 AWSALB
     • 특정 기간을 기반으로 만료, 그 기간이 로드 밸런서 자체에서 생성되는 것

---

Cross-Zone Load Balancing (교차 영역 밸런싱)

• 아주 불균형한 AZ 영역이 존재할 때 교차 영역 로드 밸런싱을 쓰면
  • 클라이언트가 트래픽의 절반을 첫 번째 ALB 인스턴스로 보내고 나머지 절반을 다른 쪽에 보냈다 하더라도, ALB는 받은 트래픽을 10개의 EC2 인스턴스 모두에 전달
• → 각각의 로드 밸런서 인스턴스가 모든 가용 영역에 등록된 모든 인스턴스에 부하를 고르게 분배함

⇒ 모든 영역에 있는 EC2 인스턴스에 트래픽이 고르게 분배

• ALB : 교차 영역 밸런싱이 기본 설정
  • 대상 그룹 설정에서 비활성화 가능
  • 교차영역 밸런싱 기본 설정 → AZ 간 데이터 전송 비용이 들지 않음
• NLB, GWAB : 교차 영역 밸런싱 비활성화가 기본 설정
  • 활성화하려면 비용을 지불해야 함
  • AZ 간 데이터 전송을 원한다면 비용이 발생

---

SSL/TLS 인증

SSL/TSL 기초

• SSL 인증서 : 클라이언트와 로드 밸런서 사이에서 트래픽이 이동하는 동안 암호화 (in-flight 암호화, 전송 중 암호화)
  • 데이터는 전송 중에 암호화 ****되어있고, 송신자와 수신자 측에서만 복호화 가능
• SSL : Security Socket Layer (보안 소켓 계층), 연결을 암호화하는 데 사용
• TLS : 새로운 버전의 SSL, Transport Layer Security (전송 계층 보안)
  • 최근에는 TLS 인증서가 주로 사용됨
  cf. 보통은 SSL/TLS를 묶어 SSL로 부른다
• 퍼블릭 SSL은 인증기관(CA)에서 발급
  • Comodo, Symantec, GoDaddy, Let’s Encypt 등이 있음
• 퍼블릭 SSL 인증서를 로드 밸런서에 추가
• → 클라이언트와 로드 밸런서 사이의 연결을 암호화 할 수 있다
• SSL 인증서에는 만료 날짜가 있어서 주기적으로 갱신해줘야 한다

 

SSL 동작 방식

1. 사용자가 HTTPS를 통해 접속
2. 인터넷(HTTPS)을 통해 로드 밸런서에 접속 → 로드 밸런서에서는 내부적으로 SSL 종료를 수행
3. 백엔드에서는 HTTP로 EC2 인스턴스와 통신 (암호화 되지 않은 상태)
   • VPC로 이동하는 트래픽은 프라이빗 네트워크를 사용하기 때문에 안전하게 보호
   • 로드 밸런서는 X.509 인증서를 사용 → SSL 또는 TLS 서버 인증서라고 부름
   • AWS에는 서버 인증서들을 관리할 수 있는 ACM(AWS 인증서 관리자)가 있다
   • 원한다면 직접 인증서를 업로드 가능
   • HTTP 리스너를 구성할 때 반드시 HTTPS 리스너로 해야 함
     • 기본 인증서 지정
     • 다중 도메인 지원을 위한 다른 인증서 추가 가능
     • 클라이언트는 SNI (서버 이름 지정)을 사용해서 접속할 호스트의 이름을 알릴 수 있다
     • 원하는대로 보안 정책을 지정할 수 있음

 

SNI (Server Name Indication)

• 여러 개의 SSL 인증서를 하나의 웹 서버에 로드
• → 하나의 웹 서버가 여러 개의 웹 사이트를 지원할 수 있게 해준다
• 확장된 프로토콜로, 클라이언트가 대상 서버의 호스트 이름을 지정하도록 한다
• 클라이언트가 접속할 웹사이트를 말했을 때, 서버는 어떤 인증서를 로드해야 하는지 알 수 있다

cf. 모든 클라이언트가 지원하는 것은 아님 : ALB와 NLB, CloudFront에서만 동작

• 시험 : 어떤 로드 밸런서에 SSL 인증서가 여러 개 있다 → ALB나 NLB 중 하나
• 보충
  • SNI는 TLS 프로토콜의 확장, TLS의 제약을 해결하기 위해 설계
  • SNI가 도입되기 전에는 하나의 IP 주소가 하나의 SSL 인증서만 연관
  • → 동일한 서버에서 서로 다른 도메인 이름을 가진 여러 안전한 웹사이트를 호스팅하는 데 제약이 발생
• ALB가 있고, target group이 2개 존재
• 2개의 SSL 인증서 : 각 대상 그룹에 해당하는 인증서
  1. 클라이언트는 ALB에 접속하고 싶은 대상을 전달
  2. ALB는 대상을 파악하고 해당하는 SSL 인증서를 로드
  3. 연결을 제공
  SSL 인증서 지원 항목 정리
  • CLB (V1) : SSL 인증서를 하나만 둘 수 있다
    • 여러 개의 인증서로 여러 호스트 이름을 지원하려면 CLB 자체를 여러 개 둬야 함
  • ALB (V2) : 여러 개의 SSL 인증서, 다중 리스너를 지원 가능
    • SNL 사용
  • NLB (V2) : 여러 개의 SSL 인증서로 다중 리스너 지원 가능
    • SNI 사용
  ※ SSL Termination
  • SSL로 암호화된 데이터 트래픽이 해독되는 프로세스
  • 암호 해독 프로세스의 속도를 높이고, 백엔드 서버의 처리 부담을 줄일 수 있다
  • ALB와 조합해서 사용

   

---

Connection Draining (연결 드레이닝)

cf. draining : 배수

• CLB를 사용할 때는 연결 드레이닝이라 부르고, ALB나 NLB를 사용하는 경우 등록 취소 지연이라고 부름
• 인스턴스가 비정상인 상태로 지연이 있을 때, 인스턴스에 어느 정도의 시간을 제공
• → 인-플라이트 요청(활성 요청)을 완료할 수 있도록 하는 기능
• 연결(인스턴스)이 드레이닝 되면, ELB는 등록 취소 중인 EC2 인스턴스로 새로운 요청을 보내지 않음

• 도식 설명
  • EC2 인스턴스가 3개 존재, 그 중 하나는 드레이닝 모드로 설정
  • EC2 인스턴스에 이미 연결된 유저는 충분한 드레이닝 시간을 얻게 되고, 기존 연결 및 기존 요청을 완료할 수 있게 됨
  • 작업이 끝나면 모든 연결이 정지됨
  • 만약 새로운 유저가 ELB에 연결을 시도→ 새로운 연결은 다른 EC2 인스턴스와 수립될 것 (2번째나 3번째)
  • → ELB는 EC2 인스턴스가 드레이닝 상태에 있으므로
  • 연결 파라미터 값은 1-3,600초 사이의 값으로 설정 가능 (기본적으로 300초, 5분)
  • 0으로 설정하면 드레이닝을 비활성화
  • 짧은 요청의 경우, 낮은 값으로 설정하면 좋다 (1초 미만의 요청일 때 드레이닝 파라미터를 30초 정도로 설정)
  • 요청시간 긴 업로드의 경우 높은 값으로 설정

---

ASG (Auto Scaling Group)

• 웹이나 앱을 배포할 때 웹 사이트 방문자가 갈수록 많아지면서 로드가 바뀔 수 있다
• 클라우드에서 EC2 인스턴스 생성 API 호출을 통해 서버를 빠르게 생성하고 종료할 수 있다
• 이 과정을 자동화하기 위해 ASG를 생성할 수 있다
  • ASG의 목표는 스케일 아웃 / 스케일 인
    • 스케일 아웃 : 증가한 로드에 맞춰 EC2 인스턴스를 추가
    • 스케일 인 : 감소한 로드에 맞춰 EC2 인스턴스를 제거하는 것
    ⇒ ASG는 시간에 따라 크기가 변함
  • ASG에서 실행되는 ASG 인스턴스의 최대 & 최소의 개수를 유지하기 위해 매개변수를 정의할 수 있음
• 로드 밸런서와 페어링 → ASG에 속한 모든 EC2 인스턴스가 로드 밸런서에 연결→ 트래픽을 자동으로 인스턴스 그룹에 할당, ASG는 필요한 경우 인스턴스를 자동으로 늘리거나 줄인다
• cf. 로드 밸런서와 ASG를 연결 → 로드 밸런서는 ASG 인스턴스 그룹에 들어오는 트래픽을 분산
• 한 인스턴스가 비정상이면 종료하고, 이를 대체할 새 EC2 인스턴스를 생성
• ASG는 무료, EC2 인스턴스와 같이 생성된 하위 리소스에 대한 비용만 내면 된다

 

작동 과정

• ASG 내 인스턴스의 최소 개수를 설정
• 희망 용량 개수를 설정
• 최대 용량 개수를 설정 : 최대 용량 개수를 희망 용량 개수보다 더 높게 설정하면 스케일 아웃
• ⇒ EC2 인스턴스를 추가, ASG가 더 커진다

 

로드 밸런서와 작동하는 ASG

• ASG에 4개의 인스턴스가 등록되어 있다면
• ELB가 모든 인스턴스에 트래픽을 즉시 분산
• → 사용자가 로드 밸런싱된 웹사이트에 액세스 가능토록 한다
• ELB는 상태 확인을 통해 EC2 인스턴스의 상태를 확인하고, ASG로 전달할 수 있다
• ⇒ 로드 밸런서가 비정상이라 판단하는 EC2 인스턴스를 ASG가 종료할 수 있어 매우 편리하다
• 스케일 아웃이 되면 ELB가 트래픽을 보내고 로드를 분산시킴

⇒ 로드 밸런서와 ASG는 좋은 조합

 

Auto Scaling Group Attribute

• 인스턴스 속성을 기반으로 ASG를 생성 → 시작 템플릿을 생성해야 함
  • 시작 템플릿에서는 ASG 내에서 EC2 인스턴스를 시작하는 방법에 대한 정보가 포함
• 최소 용량 / 최대 용량 / 초기 용량을 정의해야 함

CloudWatch 경보가 오토 스케일링과 통합되는 방식

• CloudWatch : 경보를 기반으로 ASG를 스케일 인/아웃 할 수 있다
• 지표를 기준으로 함
  • 모니터링 할 수 있는 평균 CPU, 원하는 사용자 지정 지표 등을 지정 가능

---

ASG의 스케일링 정책 - 동적 스케일링 정책

• 3가지(+1) 유형으로 나뉨
  1. Target Tracking 스케일링
     • 가장 단순하고 설정하기 쉬움
     • ex) 모든 EC2 인스턴스에서 ASG의 평균 CPU 사용률을 추적, 수치가 40%대에 머물 수 있도록 할 때에 사용
     • 기본 기준선을 세우고 상시 가용이 가능하도록 함
  2. Simple / Step 스케일링
     • CloudWatch 경보를 설정하고 단계적 설정에 따라 변경됨
       • CPU 사용률이 30% 이하로 떨어지면 유닛 하나를 제거 등
     • ex) 전체 ASG에 대한 CPU 사용률이 70%를 초과할 때 용량을 두 유닛 추가하도록 설정
  3. Scheduled Action
  • 유저의 사용 패턴을 바탕으로 스케일링을 예상
  • ex) 금요일 오후 5시에 이벤트가 예정, 이에 대비해 최소 ASG 용량을 일정 기간 동안 자동으로 늘리도록 함
  1. Predictive 스케일링
     • 과거 로드를 분석해서 흐름을 예측
     • 머신러닝 기술을 이용해 향후 자주 사용될 것으로 예상됨

 

대표적인 지표

1. CPU 사용률
2. 테스트를 기반으로 하는 대상 별 요청의 수
   • EC2는 한 번에 1개 씩, 1,000개의 요청까지만 최적으로 작동
3. 평균 네트워크 I/O 사용량
4. 커스텀 지표

 

Scaling Cooldowns

• 스케일링 작업이 끝날 때마다 인스턴스의 추가 또는 삭제를 막론하고 기본적인 휴식 기간을 갖는 것
• 휴지 기간에는 ASG가 추가 인스턴스를 실행 또는 종료할 수 없음
• 새로운 인스턴스가 안정화 → 새로운 지표의 양상을 살펴보기 위함
• 즉시 사용 가능한 AMI를 이용해서, EC2 인스턴스 구성 시간을 단축
• → 요청을 신속히 처리 : ASG 상에서 더 많은 동적 스케일링이 가능해진다