AWS 고가용성 및 확장성

1. Scalability & High Availability (확장성과 고가용성)

• Scalability means that an application / system can handle greater loads by adapting.

  ⇒ 확장성이란 기기나 부품의 증설을 통해 시스템이나 앱의 부하량 한도를 늘려주는 것을 말한다

• There are two kinds of scalability:
  • Vertical Scalability (수직적 확장성)
  • Horizontal Scalability (= elasticity) (수평적 확장성)

• Scalability is linked but different to High Availability

  ⇒ 확장성은 고가용성과 연관되어 있긴하지만 엄연히 다르다

2. Vertical Scalability (수직적 확장)

• Vertically scalability means increasing the size of the instance

  ⇒ 수직적 확장이란 메모리나 디스크와 같은 스펙 사이즈를 증가시키는것을 의미한다

• For example, your application runs on a t2.micro

  ⇒ 예를 들어, t2.micro 어플리케이션을 동작시킨다고 가정해보자

• Scaling that application vertically means running it on a t2.large

  ⇒ 어플리케이션을 수직적으로 확장시킨다는 것은 곧, t2.large로 돌리겠단 뜻이다

• Vertical scalability is very common for non distributed systems, such as a database.

  ⇒ 수직적 확장은 데이터베이스와 같이, 분산 시스템이 아닌 곳에서 흔히 쓰인다

• RDS, ElastiCache are services that can scale vertically.

  ⇒ RDS, ElastiCache가 수직적 확장이 가능한 서비스이다

• There’s usually a limit to how much you can vertically scale (hardware limit) junior

  ⇒ 보통 얼마나 사용자가 수직적 확장을 할 수 있을지가 한계이다

3. Horizontal Scalability (수평적 확장)

• Horizontal Scalability means increasing the number of instances / systems for your application

  ⇒ 수평적 확장이란 인스턴스나 시스템의 갯수를 증설시키는 것을 의미한다

• Horizontal scaling implies distributed systems.

  ⇒ 수평적 확장은 분산 시스템에서 구현된다

• This is very common for web applications / modern applications

  ⇒ 웹 / 모던 어플리케이션에서 흔히 쓰인다

• It’s easy to horizontally scale thanks the cloud offerings such as Amazon EC2

  ⇒ Amazon EC2와 같은 클라우드 제공 서비스 덕에 쉬운 수평적 확장이 가능하다

4. High Availability (고가용성)

• High Availability usually goes hand in hand with horizontal scaling

  ⇒ 고가용성은 수평적확장과 함께 연관이 되어있다

• High availability means running your application / system in at least 2 data centers (== Availability Zones)

  ⇒ 고가용성은 어플리케이션이나 시스템을 적어도 2곳 이상의 데이터센터에서 가동시키는것을 의미

• The goal of high availability is to survive a data center loss

  ⇒ 고가용성의 주 목표는 데이터센터 손실로부터 벗어나는 것이다

• The high availability can be passive (for RDS Multi AZ for example)

  ⇒ 고가용성은 수동적일수 있다 (다수의 AZ에서 가동되는 RDS)

• The high availability can be active (for horizontal scaling)

  ⇒ 고가용성은 능동적일수 있다 (수평적 확장에 대해서)

5. High Availability & Scalability For EC2

• Vertical Scaling: Increase instance size (= scale up / down) (수직적 확장, 인스턴스 자원 스펙 증설)
  • From: t2.nano - 0.5G of RAM, 1 vCPU
  • To: u-12tb1.metal – 12.3 TB of RAM, 448 vCPUs
• Horizontal Scaling: Increase number of instances (= scale out / in) (수평적 확장, 인스턴스 수 증설)
  • Auto Scaling Group (자동 스케일링 그룹)
  • Load Balancer (로드 밸런서)
• High Availability: Run instances for the same application across multi AZ (고가용성, AZ를 초월하여 같은 어플리케이션을 위한 인스턴스들을 돌리는데 필요)
  • Auto Scaling Group multi AZ (다수 AZ 자동 스케일링 그룹)
  • Load Balancer multi AZ (다수 AZ 로드 밸런서)

6. What is load balancing?

• Load Balances are servers that forward traffic to multiple servers (e.g., EC2 instances) downstream

  ⇒ 로드 밸런싱은 한 서버에서 다른 다수의 서버로 트래픽을 전달시키는 것을 말한다

  

7. Why use a load balancer?

• Spread load across multiple downstream instances

  ⇒ 다수의 다운스트림 인스턴스로의 부하를 분산시킴

• Expose a single point of access (DNS) to your application

  ⇒ 한 어플리케이션으로의 단일 접근 지점을 노출 (DNS)

• Seamlessly handle failures of downstream instances

  ⇒ 다운스트림 인스턴스의 실패를 원활하게 다루기 위함

• Do regular health checks to your instances

  ⇒ 규칙적인 인스턴스 health check를 위함

• Provide SSL termination (HTTPS) for your websites

  ⇒ 웹사이트에 대한 SSL termination 제공

• Enforce stickiness with cookies

  ⇒ 첫 서버에 접근했을 경우, 다음 전송시 처음에 접근한 서버에만 붙도록 함

  https://ssunw.tistory.com/entry/ELB-및-ASG-Elastic-Load-Balancer-Sticky-Sessions

• High availability across zones

  ⇒ zone별 고가용성을 위함

• Separate public traffic from private traffic

  ⇒ private 트래픽에서 발생하는 public traffic 분산을 위함

8. Why use an Elastic Load Balancer?

• An Elastic Load Balancer is a managed load balancer
  • AWS guarantees that it will be working (AWS는 작동을 보장한다)
  • AWS takes care of upgrades, maintenance, high availability (AWS는 업그레이드, 지속성, 고가용성을 지원)
  • AWS provides only a few configuration knobs (AWS는 오직 하나의 구성 knobs를 제공한다)

• It costs less to setup your own load balancer but it will be a lot more effort on your end

  ⇒ 로드밸런서를 구성할수록 비용은 적게들겠으나, 그만큼 많은 노력일 들것이다

• It is integrated with many AWS offerings / services
  • EC2, EC2 Auto Scaling Groups, Amazon ECS
  • AWS Certificate Manager (ACM), CloudWatch
  • Route 53, AWS WAF, AWS Global Accelerator

9. Health Checks (헬스 체크)

• Health Checks are crucial for Load Balancers

  ⇒ 헬스 체크는 로드 밸런서에 있어 가장 중대한 사항이다

• They enable the load balancer to know if instances it forwards traffic to are available to reply to requests

• The health check is done on a port and a route (/health is common)

  ⇒ 헬스 체크는 port와 route path를 정하고 진행된다

• If the response is not 200 (OK), then the instance is unhealthy

  ⇒ 아래 예시에서, 만약 200 OK가 뜨지 않는다면 이는 서버상태가 비정상이란 뜻이다

10. Types of load balancer on AWS (AWS에서의 로드밸런서 종류)

• AWS has 4 kinds of managed Load Balancers
• Classic Load Balancer (v1 - old generation) – 2009 – CLB
  • HTTP, HTTPS, TCP, SSL (secure TCP)

  ⇒ 이부분은 2022년 8월 이후로 deprecated 되었다

• Application Load Balancer (v2 - new generation) – 2016 – ALB
  • HTTP, HTTPS, WebSocket
• Network Load Balancer (v2 - new generation) – 2017 – NLB
  • TCP, TLS (secure TCP), UDP
• Gateway Load Balancer – 2020 – GWLB
  • Operates at layer 3 (Network layer) – IP Protocol

• Overall, it is recommended to use the newer generation load balancers as they provide more features

  ⇒ 전반적으로, 가장 최신 세대의 로드밸런서가 많은 feature들을 가지므로, 최신세대 것을 쓰는것을 추천한다

• Some load balancers can be setup as internal (private) or external (public) ELBs

  ⇒ 몇몇 로드 밸런서는 internal 또는 external ELB로서 셋업 가능하다

11. Load Balancer Security Groups

12. Application Load Balancer (v2)

• Application load balancers is Layer 7 (HTTP)

  ⇒ ALB는 OSI 7번째 계층에 속한다

• Load balancing to multiple HTTP applications across machines (target groups)

  ⇒ 다수 HTTP 어플리케이션을 향한 로드밸런싱은 기기들을 건너건너 향한다 (타겟그룹)

• Load balancing to multiple applications on the same machine (ex: containers)

  ⇒ 다수 어플리케이션을 향한 로드밸런싱은 같은 기기내에 있다

• Support for HTTP/2 and WebSocket

  ⇒ HTTP/2와 웹소켓을 지원

• Support redirects (from HTTP to HTTPS for example)

  ⇒ 리다이렉션 지원

• Routing tables to different target groups (다양한 타겟 그룹을 향한 테이블 라우팅)

  1) Routing based on path in URL (http://example.com/users & http://example.com/posts)

  ⇒ URL Path 지정을 통한 라우팅

  2) Routing based on hostname in URL (http://one.example.com/ & http://other.example.com/)

  ⇒ hostname 지정을 통한 라우팅

  3) Routing based on Query String, Headers (http://example.com/users?id=123&order=false)

  ⇒ 쿼리 스트링 지정을 통한 라우팅

• ALB are a great fit for micro services & container-based application (example: Docker & Amazon ECS)

  ⇒ ALB는 마이크로 서비스와 컨테이너 기반 어플리케이션에 적절하다

• Has a port mapping feature to redirect to a dynamic port in ECS

  ⇒ 포트 매핑 기능은 ECS에서의 동적인 포트에 대한 리다이렉트가 가능하다

• In comparison, we’d need multiple Classic Load Balancer per application

  ⇒ 반면, 클래식 로드 밸런서는 어플리케이션 하나당 다수의 로드밸런서 필요

13. Application Load Balancer (v2) HTTP Based Traffic

• EC2 instances (can be managed by an Auto Scaling Group) – HTTP

  ⇒ EC2 인스턴스 (자동 스케일링 그룹에 의해 관리되어지는 인스턴스)

• ECS tasks (managed by ECS itself) – HTTP

  ⇒ ECS 태스크 (ECS 자체에서 관리되는 태스크들)

• Lambda functions – HTTP request is translated into a JSON event

  ⇒ 람다 functions : HTTP 요청이 JSON 이벤트로 변환

• IP Addresses – must be private IPs

  ⇒ IP 주소 : 반드새 Private IP여야 함

• ALB can route to multiple target groups

  ⇒ ALB는 다수 타겟그룹을 향해 라우팅 된다

• Health checks are at the target group level

  ⇒ helath check는 타겟 그룹 레벨에서 진행된다

14. Application Load Balancer (v2) Query Strings/Parameters Routing

15. Application Load Balancer (v2) Good to Know

• Fixed hostname (http://xxx.region.elb.amazonaws.com/) ⇒ hostname을 지정할 것

• The application servers don’t see the IP of the client directly

  ⇒ 어플리케이션 서버는 Client의 IP를 직접적으로 확인하지 않음

  • The true IP of the client is inserted in the header X-Forwarded-For
  • We can also get Port (X-Forwarded-Port) and proto (X-Forwarded-Proto)

16. Network Load Balancer (v2)

• Network load balancers (Layer 4) allow to (OSI 레벨4에 해당)
  • Forward TCP & UDP traffic to your instances ⇒ 사용자 인스턴스를 향한 TCP & UDP 트래픽 포워딩

  • Handle millions of request per seconds

    ⇒ 초당 100만건의 요청을 관리

  • Less latency ~100 ms (vs 400 ms for ALB) ⇒ NLB는 100ms (vs ALB는 400 ms)

• NLB has one static IP per AZ, and supports assigning Elastic IP (helpful for whitelisting specific IP)

  ⇒ NLB는 AZ당 하나의 고정IP를 가지고, 탄력적 IP지정을 지원

  (화이트리스트에 등록된 특정 IP에 도움이된다)

• NLB are used for extreme performance, TCP or UDP traffic

  ⇒ NLB는 TCP 또는 UDP 트래픽과 같은 고성능을 내는데에 사용

• Not included in the AWS free tier (AWS 프리티어에 미포함)

17. Network Load Balancer (v2) TCP (Layer 4) Based Traffic

18. Network Load Balancer – Target Groups

• EC2 instances
• IP Addresses : 반드시 private IP여야 한다
• Application Load Balancer (ALB)
• TCP, HTTP, HTTPS에 대한 Health Check를 지원

19. Gateway Load Balancer

• Deploy, scale, and manage a fleet of 3rd party network virtual appliances in AWS

  ⇒ 3rd 파티의 가상 네트워크 fleet에 대한 배포, 확장, 관리를 가능케 하는 AWS내의 기능

• Example: Firewalls, Intrusion Detection and Prevention Systems, Deep Packet Inspection Systems, payload manipulation, …

  ⇒ 예시 : 방화벽, 외부 침입 감지 시스템, Deep 패킷 인스펙션 시스템

• Operates at Layer 3 (Network Layer) – IP Packets

  ⇒ OSI 계층 중 3계층 (Network Layer)에서 작동

• Combines the following functions:

  • Transparent Network Gateway – single entry/exit for all traffic

    ⇒ 투명적 네트워크 게이트웨이 : 모든 트래픽에 대한 단일 접근,접속종료

  • Load Balancer – distributes traffic to your virtual appliances

    ⇒ 로드밸런서 : 가상 applicances에 대한 트래픽 분산

• Uses the GENEVE protocol on port 6081

  ⇒ 6081포트로 작동하는 GENEVE 프로토콜 사용

20. Gateway Load Balancer - Target Groups

• EC2 Instances
• IP Addresses : 반드시 private IP여야 한다

21. Sticky Sessions (Session Affinity)

• It is possible to implement stickiness so that the same client is always redirected to the same instance behind a load balancer

  ⇒ stickiness를 적용함으로써, 같은 클라이언트가 항상 같은 인스턴스에 리다이렉트 되도록 한다

• This works for Classic Load Balancer, Application Load Balancer, and Network Load Balancer

  ⇒ CLB, ALB, NLB에서 작동한다

• For both CLB & ALB, the “cookie” used for stickiness has an expiration date you control

  ⇒ CLB와 ALB모두, 사용자가 지정한 만료기한까지 stickiness 기능을 유지한다

  Note : NLB works without cookies (NLB는 쿠키없이 동작한다)

• Use case: make sure the user doesn’t lose his session data

  ⇒ 사용 예 : 사용자가 세션 데이터 손실을 하지 않도록 확실히 해두고 싶을때

• Enabling stickiness may bring imbalance to the load over the backend EC2 instances

  ⇒ stickiness는 부하량에 대한 불균형을 불러올 수도 있다

22. Sticky Sessions – Cookie Names

• Application-based Cookies (어플리케이션 기반 쿠키)
  • Custom cookie

    • Generated by the target

      ⇒ target에 의한 생성

    • Can include any custom attributes required by the application

      ⇒ application에서 요구되는 다양한 custom attiribute를 포함

    • Cookie name must be specified individually for each target group

      ⇒ 쿠키이름은 각각의 타겟 그룹에 대해 개인적으로 지정된다

    • Don’t use AWSALB, AWSALBAPP, or AWSALBTG (reserved for use by the ELB)

      ⇒ AWSALB, AWSALBAPP, AWSALBTG와 같은 명칭은 사용 금지 (예약어임)

  • Application cookie

    • Generated by the load balancer

      ⇒ load balancer에 의해 생성됨

    • Cookie name is AWSALBAPP

      ⇒ 쿠키 이름은 AWSALBAPP

• Duration-based Cookies (기한 기반 쿠키)

  • Cookie generated by the load balancer

    ⇒ loadbalancer에 의해 생성된 쿠키

  • Cookie name is AWSALB for ALB, AWSELB for CLB

    ⇒ AWSALB는 ALB에 대한 쿠키이름, AWSELB는 CLB에 대한 쿠키이름

23. Cross-Zone Load Balancing

• Cross Zone 로드 밸런싱을 on할 경우 : 인스턴스 별로 부햐량이 10씩 고루 분배
• Cross Zone 로드 밸런싱을 off할 경우 : AZ1 에서는 25씩, AZ2에서는 6.25씩 되어서 부하량 불균형 발생

• Application Load Balancer

  • Enabled by default (can be disabled at the Target Group level)

    ⇒ 활성화 상태가 기본값으로 되어 있음 (Target Group 레벨에서는 비활성화)

  • No charges for inter AZ data

    ⇒ AZ에 대해 과금 없음

• Network Load Balancer & Gateway Load Balancer

  • Disabled by default

    ⇒ 비활성화가 기본값으로 되어 있음

  • You pay charges ($) for inter AZ data if enabled

    ⇒ 활성화 시 과금이 발생

• Classic Load Balancer

  • Disabled by default

    ⇒ 비활성화 상태가 기본값

  • No charges for inter AZ data if enabled

    ⇒ AZ에 대해 과금 없음

24. SSL/TLS - Basics

• An SSL Certificate allows traffic between your clients and your load balancer to be encrypted in transit (in-flight encryption)

  ⇒ SSL 인증서는 클라이언트와 로드밸런서 사이의 전송중인 트래픽을 암호화시키도록 한다

• SSL refers to Secure Sockets Layer, used to encrypt connections

  ⇒ SSL은 Secure Socket Layer의 약자로, 연결을 암호화한다

• TLS refers to Transport Layer Security, which is a newer version

  ⇒ TLS는 Transport Layer Security의 약자로, SSL의 새로운 버전이다

• Nowadays, TLS certificates are mainly used, but people still refer as SSL

  ⇒ 오늘날에는 TLS 인증서라는 명칭이 주로 사용되지만, 사실 SSL을 가리키는 것이다

• Public SSL certificates are issued by Certificate Authorities (CA)

  ⇒ 공용 SSL 인증서는 CA에서 관리되어 진다

  ex) Comodo, Symantec, GoDaddy, GlobalSign, Digicert, Letsencrypt, etc…

• SSL certificates have an expiration date (you set) and must be renewed

  ⇒ SSL 인증서는 유효기간이 존재하기 때문에, 주기마다 갱신해줘야 한다

25. Load Balancer - SSL Certificates

• The load balancer uses an X.509 certificate (SSL/TLS server certificate)

  ⇒ 로드 밸런서는 X.509 인증서를 사용한다 (SSL/TLS 서버 인증)

• You can manage certificates using ACM (AWS Certificate Manager)

  ⇒ 사용자는 ACM을 이용해 인증서 관리가 가능하다

• You can create upload your own certificates alternatively

  ⇒ 본인만의 인증서 업로드가 가능하다

• HTTPS listener:

  • You must specify a default certificate

    ⇒ 반드시 기본값이 설정된 인증서가 있어야 한다

  • You can add an optional list of certs to support multiple domains

    ⇒ 다수 도메인 support를 위해서 인증서 리스트들을 추가시켜야한다

  • Clients can use SNI (Server Name Indication) to specify the hostname they reach

    ⇒ 클라이언트는 도달하기 위한 hostname을 특정을 위해 SNI를 사용한다

  • Ability to specify a security policy to support older versions of SSL / TLS (legacy clients)

    ⇒ 옛날 버전의 SSL/TLS support를 위한 security 정책을 세울 수 있다

26. SSL – Server Name Indication (SNI)

• SNI solves the problem of loading multiple SSL certificates onto one web server (to serve multiple websites)

  ⇒ SNI는 다수의 SSL 인증서 부하의 문제를 해결하기 위한 것이다

• It’s a “newer” protocol, and requires the client to indicate the hostname of the target server in the initial SSL handshake

  ⇒ 새로운 프로토콜이고, 첫 SSL 핸드쉐이크에서 클라이언트가 타겟 서버의 호스트네임을 가리키도록 한다

• The server will then find the correct certificate, or return the default one

  ⇒ 서버는 올바른 인증서를 찾아내거나, 또는 기본 인증서를 return 시킬것이다

• Note:

  • Only works for ALB & NLB (newer generation), CloudFront

    ⇒ ALB와 NLB에서만 작동하거나, CloudFront에서 작동한다

  • Does not work for CLB (older gen)

    ⇒ CLB에서는 작동 불가

27. Elastic Load Balancers – SSL Certificates

• Classic Load Balancer (v1)

  • Support only one SSL certificate

    ⇒ 딱 1개의 인증서만 지원가능

  • Must use multiple CLB for multiple hostname with multiple SSL certificates

    ⇒ 다수의 SSL 인증서와 함께, 다수의 hostname을 위한 다수 CLB를 사용해야함

• Application Load Balancer (v2)

  • Supports multiple listeners with multiple SSL certificates

    ⇒ 다수 SSL 인증서가 포함된 다수의 listener를 지원

  • Uses Server Name Indication (SNI) to make it work

    ⇒ 잘 작동되도록 SNI를 사용

• Network Load Balancer (v2)

  • Supports multiple listeners with multiple SSL certificates

    ⇒ 다수 SSL 인증서가 포함된 다수의 listener를 지원

  • Uses Server Name Indication (SNI) to make it work

    ⇒ 잘 작동되도록 SNI를 사용

28. Connection Draining (커넥션 드레이닝)

• Feature naming
  • Connection Draining – for CLB (CLB에서는 커넥션 드레이닝)
  • Deregistration Delay – for ALB & NLB (ALB와 NLB에서는 등록취소 딜레이)

• Time to complete “in-flight requests” while the instance is de-registering or unhealthy

  ⇒ 인스턴스가 등록취소중이거나 unhelthy할 시, 전송중인 리퀘스트에대한 완료시간

• Stops sending new requests to the EC2 instance which is de-registering

  ⇒ de-register중인 EC2인스턴스에 새로운 리퀘스트 전송을 중단시키는 것이다

• Between 1 to 3600 seconds (default: 300 seconds)

  ⇒ 1초부터 3600초까지 설정 가능 (기본값 : 300초)

• Can be disabled (set value to 0)

  ⇒ 0으로 설정하면 비활성화이다

• Set to a low value if your requests are short

  ⇒ 짧은 경과시간의 리퀘스트들이라면, 낮은 값을 주는것이 좋다

29. What’s an Auto Scaling Group?

• In real-life, the load on your websites and application can change

  ⇒ 현실에서, 웹사이트나 어플리케이션에서의 부하량이 변할 수 있다

• In the cloud, you can create and get rid of servers very quickly

  ⇒ 클라우드에서는 서버의 생성과 삭제를 빠르게 진행할 수 있다

• The goal of an Auto Scaling Group (ASG) is to ⇒ ASG의 목적

  • Scale out (add EC2 instances) to match an increased load

    ⇒ 부하량 증가에 맞는 확장성 증가 (EC2 인스턴스 확보)

  • Scale in (remove EC2 instances) to match a decreased load

    ⇒ 부하량 감소에 맞는 확장성 감소 (EC2 인스턴스 감소)

  • Ensure we have a minimum and a maximum number of EC2 instances running

    ⇒ 동작중인 EC2의 최대와 최소 갯수를 보장

  • Automatically register new instances to a load balancer

    ⇒ 로드 밸런서에 자동적으로 새로운 인스턴스들을 등록한다

  • Re-create an EC2 instance in case a previous one is terminated (ex: if unhealthy)

    ⇒ 이전 인스턴스가 terminate 될 경우, 해당 EC2 인스턴스를 재생성한다

• ASG are free (you only pay for the underlying EC2 instances)

  ⇒ ASG는 무료이다 (EC2 인스턴스에 대한 값 지불을 했을경우)

30. Auto Scaling Group Attributes (ASG 속성)

• A Launch Template (older “Launch Configurations” are deprecated)
  • AMI + Instance Type
  • EC2 User Data
  • EBS Volumes
  • Security Groups
  • SSH Key Pair
  • IAM Roles for your EC2 Instances
  • Network + Subnets Information
  • Load Balancer Information
• Min Size / Max Size / Initial Capacity
• Scaling Policies

31. Auto Scaling - CloudWatch Alarms & Scaling (CloudWatch 알람 & Scaling)

• It is possible to scale an ASG based on CloudWatch alarms

  ⇒ 클라우드 워치 알람상에서 ASG의 증설이 가능하다

• An alarm monitors a metric (such as Average CPU, or a custom metric)

  ⇒ 알람은 metric 모니터링이 가능하다 (CPU 사용량 등)

• Metrics such as Average CPU are computed for the overall ASG instances

  ⇒ 평균 CPU와 같은 metrics는 전체적인 ASG 인스턴스에 의해 계산된다

• Based on the alarm

  • We can create scale-out policies (increase the number of instances)

    ⇒ scale out 정책 수립 가능 (인스턴스 갯수 증가)

  • We can create scale-in policies (decrease the number of instances)

    ⇒ scale in 정책 수립 가능 (인스턴스 갯수 감소)

  

32. Auto Scaling Groups – Dynamic Scaling Policies (동적 스케일링 정책)

• Target Tracking Scaling

  • Most simple and easy to set-up

    ⇒ 전반적으로 단순하고 셋업이 쉽다

  • Example: I want the average ASG CPU to stay at around 40%

    ⇒ 예제 : 사용자가 약 40% 가량의 평균 ASG CPU를 원한다

• Simple / Step Scaling

  • When a CloudWatch alarm is triggered (example CPU > 70%), then add 2 units

    ⇒ CloudWatch 알람이 트리거 되었을 때, 2개의 인스턴스가 추가된다

  • When a CloudWatch alarm is triggered (example CPU < 30%), then remove 1

    ⇒ CloudWatch 알람이 트리거 되었을 때, 1개의 인스턴스가 감소된다

• Scheduled Actions

  • Anticipate a scaling based on known usage patterns

    ⇒ 알려진 사용례 패턴 상에서, 확장을 예상해 볼 수 있다

  • Example: increase the min capacity to 10 at 5 pm on Fridays

    ⇒예제 : 금요일 오후 5시에 최소 용량을 10으로 증가시킨다

33. Auto Scaling Groups – Predictive Scaling (예측 스케일링)

• Predictive scaling: continuously forecast load and schedule scaling ahead

  ⇒ 지속적으로 부하량을 예측하고 앞으로의 스케일링을 스케쥴 한다

34. Good metrics to scale on (Scale on에 있어 좋은 metrics)

• CPU Utilization: Average CPU utilization across your instances

  ⇒ CPU 사용 : 인스턴스 전반에 걸친 평균 CPU 사용

• RequestCountPerTarget: to make sure the number of requests per EC2 instances is stable

  ⇒ Target당 요청 수 : EC2 인스턴스당 요청의 숫자를 확실하게 안정적으로 하도록 함

• Average Network In / Out (if you’re application is network bound)

  ⇒ 평균 네트워크 In / Out

• Any custom metric (that you push using CloudWatch)

  ⇒ 다양한 custom metric

35. Auto Scaling Groups - Scaling Cooldowns (ASG - 스케일링 쿨다운)

• After a scaling activity happens, you are in the cooldown period (default 300 seconds)

  ⇒ 스케일링 활동 발생 후, cooldown 기간에 들어간다 (기본 300초)

• During the cooldown period, the ASG will not launch or terminate additional instances (to allow for metrics to stabilize)

  ⇒ 쿨다운 기간동안, ASG는 추가적인 terminate나 launch를 하지 못한다

• Advice: Use a ready-to-use AMI to reduce configuration time in order to be serving request fasters and reduce the cooldown period

  ⇒ 충고 : 리퀘스트 요청을 더 빠르게 하고 cooldown 기간을 감소시키기 위해, reduce 설정을 사용한 AMI를 사용

  ---