High Availability and Scalability - ELB & ASG

정연희·2024년 5월 7일
0

AWS

목록 보기
9/18

기본 용어

Scalability

= application / system can handle greater loads by adapting

종류

  • vertical scalability
    • increase instance size (=scale up/down)
    • common for non distributed systems (ex. database)
    • RDS, ElastiCache are services that can scale vertically
    • 한계: 하드웨어적으로 향상시키는 데에는 한계가 있다
  • horizontal scalability (=elasticity)
    • increase number of instances (=scale out/in)
    • implies distributed systems (ex. web applications, modern applications)
    • 향상시킬 수 있는 정도에 한계가 없음

Availability

High availability means running your application / system in at least 2 data centers (=AZ). The goal of high availability is to survive a data center loss.

Load Balancing

개념

Load Balances는 다른 여러 개의 서버(ex. EC2 instance)로 트래픽을 전달하는 서버들을 의미한다. 즉, 트래픽을 여러 개의 서버에 분산하는 역할을 하는 서버들이다.

Load balancer의 필요성

  • 트래픽을 분산시킬 수 있음
  • 하나의 엔드포인트 제공(DNS)
  • 트래픽을 하나의 경로로 받아 여러 인스턴스에 분산시키기 때문에, 사용자 입장에서는 서로 다른 인스턴스에 접속하게 되더라도 같은 엔드포인트(주소)로 접속하면 됨
  • downstream instance에서 에러가 발생하더라도 애플리케이션 기능 제공 가능
  • 인스턴스들의 health check을 자동적으로 해줌
  • 웹사이트를 위한 SSL termination(HTTPS) 제공
  • enforce stickiness with cookies
  • high availability across zones
  • separate public traffic from private traffic

Health Checks
이 기능은 load balancer들이 특정 인스턴스로 트래픽을 전달해도 되는지를 알려준다. Health check은 port와 /health이라는 라우트를 통해 시행된다. 만약 Response가 200이 아니면 unhealthy한 것이다.

Load balancing algorithm

  • round robin
    • 서버에 들어온 요청을 순서대로 돌아가며 배정하는 방식, 서버와의 연결이 오래 지속되지 않는 경우 적합하다.
  • weighted round robin
    • 각 서버에 가중치를 매기고 가중치가 높은 서버에 요청을 우선적으로 배정하는 방식, 서버의 트래픽 처리 능력이 다른 경우 사용한다.
  • least connection
    • 요청이 들어온 시점에 가장 적은 연결 상태를 보이는 서버에 트래픽을 배정하는 방식, 서버에 분배된 트래픽들이 일정하지 않은 경우에 적합하다.
  • IP hash
    • 클라이언트의 IP주소를 특정 서버로 매핑하여 요청을 처리하는 방식, 사용자가 항상 동일한 서버로 연결된다.

계층별 load balancer

  • L4(4계층) Load Balancer

    • 전송 계층(Transport Layer, Layer 4) 에서 작동하는 로드 밸런서로,
      주로 TCP 및 UDP 프로토콜을 기반으로 클라이언트와 서버 간의 트래픽을 분산
    • 클라이언트의 IP 주소와 포트, 서버의 IP 주소와 포트를 기반으로 로드 밸런싱을 수행

  • L7(7계층) Load Balancer

    • 애플리케이션 계층(Application Layer, Layer 7) 에서 작동하는 로드 밸런서로,
    • 주로 HTTP 및 HTTPS 프로토콜을 기반으로 클라이언트와 서버 간의 트래픽을 분산
    • L7 로드 밸런서는 HTTP 프로토콜 기반의 요청 내용(URL, 헤더, 쿠키 등)을 바탕으로 로드 밸런싱을 수행

Load balancer security group

  • 클라이언트가 서버에 요청을 하고 싶을 경우, Load balancer에 요청을 보낸다. 그래서 load balance의 security group은 모두에게 오픈한 것을 볼 수 있다
  • 그러나 애플리케이션은 load balancer한테만 요청을 받을 수 있도록 해야 한다.

ELB (Elastic Load Balancer)

ELB는 AWS가 제공하는 load balancer로, AWS난 Load balance들이 작동하는 것을 보장한다. 즉, AWS가 업그레이드, 관리, availability를 해줌. 어떤 Load balancer들은 internal(private) 또는 external(public) ELB로 설정할 수 있음

장점

  • AWS난 Load balance들이 작동하는 것을 보장한다
    • 즉, AWS가 업그레이드, 관리, availability를 해줌.
  • 몇 개의 작은 설정만으로 load balancer를 쉽게 만들 수 있다
  • 다른 AWS 기능/서비스들과 함께 사용 가능

ELB 종류

  • Application load balancer - 2016 - ALB

    • v2 - new generation
    • 7계층인 application layer에서 작동하는 로드밸런서
    • HTTP, HTTPS, WebSocket의 헤더를 보고 적절한 패킷으로 전송 (지능적인 라우팅)
    • ALB는 IP주소+ 포트번호 + 패킷내용을 보고 스위칭
    • LB는 IP주소가 변동되기 때문에 Client에서 Access할 ELB의 DNS Name을 이용
    • 7계층인 application layer에서 작동하는 로드밸런서
    • ALB는 L7을 지원하기 때문에 EC2 대신에 SSL적용이 가능

  • Network load balancer - 2017 - NLB

    • v2 - new generation
    • 4계층(transpot layer)에서 작동하는 로드밸런서
    • TCP/IP, TLS, UDP 헤더를 보고 적절한 패킷으로 전송
    • NLB는 IP+ 포트번호를 보고 스위칭
    • NLB는 할당한 Elastic IP를 Static IP로 사용이 가능하여 DNS Name과 IP주소 모두 사용이 가능
    • NLB는 SSL 적용이 인프라 단에서 불가능하여 애플리케이션에서 따로 적용해주어야함

  • Gateway load balancer - 2020 - GWLB

    • operates at layer 3 (network layer) - IP protocol
    • 트래픽이 EC2에 도달하기 전에 먼저 트래픽을 검사하거나 분석하거나 인증하거나 로깅하는 작업을 수행

Sticky Session (Session Affinity)

로드 밸런서는 원래 요청을 여러 ec2 instance에 분배하기 때문에 항상 특정 인스턴스에게 요청이 전달되지 않는다.
그러나 Sticky Session은 로드 밸런서가 특정 사용자의 요청을 특정 ec2 instance에게 전달하는 기능이다.

  • Application load balancer, network load balancer에서만 사용 가능한 기능
  • stickiness을 위해 사용되는 'cookie'는 사용자가 설정할 수 있는 만기기한을 가지고 있다
    • 예외) NLB는 cookie 사용 X
  • Use case: 사용자가 세션 데이터를 잃지 않기 위해 특정 인스턴스에 계속 연결되게 하고자 하는 경우
  • 단점: 백엔드 인스턴스 간에 트래픽이 적절히 분배되지 않을 수 있음
  • Application-based cookies
    • custom cookie
      • generated by target(application itself)
      • can in clude any custom attributes required by the application
      • cookie name must be specified individually for each target group
      • expiration specified by application
    • application cookie
      • generated by target
      • expiration specified by application
  • duration-based cookies
    • generated by load balancer
    • expiration specified by load balancer

Cross Zone Balancing

Cross zone balancing은 Elastic Load Balancing(ELB) 서비스의 기능 중 하나로, 트래픽을 여러 AZ에 걸쳐 더 고르게 분산할 수 있게 한다. 즉, 여러 AZ에 있는 모든 인스턴스들은 똑같은 양의 트래픽을 담당하게 된다. 예시와 함께 설명하자면

  • cross zone balancing 사용하지 않는 경우
    • 각 로드밸런서는 트래픽의 똑같은 양을 분배받고, 로드 밸런서와 연결된 AZ에 있는 인스턴스들은 해당 로드밸런서에 분배된 트래픽을 나눠가진다.
    • 아래 사진을 예시로 들자면 각 로드밸런서는 트래픽 50%를 담당하고, AZ1에는 2개의 인스턴스만 있기에 AZ1 인스턴스들은 각각 25%의 트래픽을 분배받는다. 한편 AZ2 인스턴스들은 각각 6.25%의 트래픽을 분배받는다
  • cross zone balancing 사용하는 경우
    • 모든 AZ에 있는 인스턴스들은 똑같은 양의 트래픽을 분배받는다.
    • 아래 사진에서는 각 인스턴스는 트래픽 10%를 담당한다.

load balancer 종류에 따른 설정

  • application load balancer
    • enabled by default
    • no charges for inter AZ data
  • network load balancer & gateway load balancer
    • disabled by default
    • need to pay charges for inter AZ data if enabled

SSL Certificates

SSL certificate은 클라이언트와 로드 밸런서 사이에서 이루어지는 트래픽을 암호화하는 기능이다. 다른 이름으로는 in-flight encryption이다. 오직 수신자와 송신자 측에서만 데이터를 해독할 수 있다.

SSL (Secure Sockets Layer)
인터넷에서 데이터를 안전하게 전송하기 위해 개발된 보안 프로토콜이다. 이 프로토콜의 기능은

  • 암호화: 이 프로토콜은 전송되는 데이터를 암호화하며, 오직 송신자와 수신자만이 데이터를 읽을 수 있도록 보장한다.
  • 인증: 서버 인증서를 통새 서버의 신원을 확인하는 것이다. 클라이언트는 서버가 실제로 신뢰할 수 있는 서버인지 확인할 수 있으며, 때로는 클라이언트 인증서를 사용하여 서버가 클라이언트의 신원을 확인할 수도 있다. 서버는 SSL/TLS 인증서를 신뢰할 수 있는 인증기관(CA, Certificate Authority)에 의해 서명된다

TLS (Transport Layer Security)
TLS는 SSL의 새로운 버전으로 SSL과 TLS는 종종 함께 언급된다. 현재는 TLS가 더 널리 사용되고 있다.

SSL Certificates 작동 방식

사용자는 로드 밸런서에게 HTTPS로 요청을 보내면, 로드 밸런서는 해독된 요청을 HTTP로 인스턴스에게 전달한다. 이때, 로드 밸런서와 인스턴스 사이의 데이터가 암호화되지 않은 이유는 어차피 해당 데이터는 같은 private VPC 내에서 전송되는 것이기 때문이다

Load balancer와 SSL Certificate

  • 로드 밸런서는 X.509 certificate (SSL/TLS server certificate)을 사용한다
  • 인증서는 ACM(AWS Certificate Manager)로 관리할 수 있다
  • 사용자가 직접 개인 인증서를 대신 업로드 가능하다
  • HTTPS listener
    • you must specify a default certificate
    • can add an optional list of certs to support multiple domains
    • clients can use SNI (Server Name Indication) to specify the hostname they reach
    • ability to specify a security policy to support older versions of SSL/TLS (legacy clients)

SNI (Server Name Indication)

SNI는 TLS 프로토콜의 확장 기능 중 하나로, 하나의 IP 주소에서 여러 SSL/TLS 인증서를 사용할 수 있게 해준다. 이는 특히 가상 호스팅 환경에서 유용하다. 가상 호스팅은 하나의 서버에서 여러 도메인 이름을 호스팅하는 것을 말한다다.

  • 작동 원리
    • 클라이언트가 서버에 SSL/TLS 연결을 시도할 때, 클라이언트는 자신이 접속하려는 도메인 이름을 서버에 전달해야 한다. 서버는 이 도메인 이름을 사용하여 적절한 SSL/TLS 인증서를 선택하고, 이를 클라이언트와의 연결에 사용한다.
    • SNI 없이 서버는 클라이언트가 어떤 도메인에 접속하려는지 알 수 없으므로, 기본적으로 하나의 인증서만 사용할 수 있습니다. 이는 여러 도메인을 호스팅하는 서버에서는 문제가 됩니다.
  • 필요성
    • 가상 호스팅: 하나의 서버에서 여러 도메인을 호스팅하는 경우, 각 도메인마다 별도의 SSL/TLS 인증서를 사용해야 할 때가 많다. SNI를 사용하면 하나의 IP 주소에서 여러 인증서를 사용할 수 있어 효율적이다.
  • 유의할 점
    • ALB, NLB (newer generation), CloudFront에만 사용 가능

Deregistration Delay

이는 ELB에서 인스턴스를 로드 밸런서에서 제거할 때 적용되는 지연 시간을 의미한다. 이 기능은 로드 밸런서에서 인스턴스를 비활성화할 때 즉시 연결을 끊지 않고, 일정 기간 동안 기존 연결을 유지함으로써 클라이언트와의 세션을 안전하게 종료할 수 있도록 한다.

  • 작동 원리
    1. 인스턴스 비활성화 요청: 인스턴스를 로드 밸런서에서 제거하거나 비활성화할 때 이 요청이 발생한다.
    2. 기존 연결 유지: 로드 밸런서는 기존 연결을 유지하면서 더 이상 새로운 요청을 해당 인스턴스로 전달하지 않는다.
    3. 지연 시간: 설정된 지연 시간 동안(기본값은 300초, 최대 3600초) 기존 연결이 종료될 때까지 기다린다. 요청시간이 대부분 짧으면 지연 시간을 짧게 설정하는 것이 좋다.
    4. 인스턴스 제거: 지연 시간이 끝나면 인스턴스가 로드 밸런서에서 완전히 제거된다. 지연시간이 0으로 설정될 경우, 바로 인스턴스가 제거된다
  • 필요성
    • 세션 유지: 클라이언트가 현재 인스턴스와 연결되어 있는 경우, 지연 시간을 통해 세션을 유지하고 정상적으로 완료할 수 있도록 한다. 이는 사용자 경험을 개선하는 데 도움이 된다.
    • 안정성 향상: 긴 시간 동안 실행되는 작업이나 데이터 전송이 완료될 수 있도록 보장하여 서비스의 안정성을 높인다
    • 부하 분산: 새로운 인스턴스가 추가되거나 기존 인스턴스가 제거될 때, 로드 밸런서는 안정적으로 부하를 분산할 수 있다

Auto Scaling Group (ASG)

이는 어플리케이션 트래픽 상황에 따라 서버 개수를 조절하는 기능이다. 만약 트래픽이 많아지면 scale out(서버 추가 생성), 줄어들면 scale in(서버 제거)한다. ASG 특징으로는

  • 작동하는 서버 최소 개수과 최대 개수를 설정 가능
  • 새로 생성되는 서버들은 로드 밸런서에 자동적으로 연결됨
  • unhealthy해서 삭제된 인스턴스들을 위해 재생성도 한다.
  • CloudWatch alarm을 이용해 특정 수치가 넘으면 scaling을 트리거하도록 하는 scaling policy를 설정하여 자동적으로 scale out/scale in 할 수 있다

Scaling Policies

  • Dynamic scaling

    • target tracking scaling
      • ex) I want the average ASG CPU to stay at around 40%
    • simple/step scaline
      • when a CloudWatch alarm is triggered (ex. CPU > 70%), then add 2 units
      • when a CloudWatch alarm is triggered (ex. CPU < 30%), then remove 1 unit

  • Scheduled Scaling

    • anticipate a scaling based on known usage patterns
    • ex) increase min capacity to 10 at 5PM on Fridays

  • Predictive Scaline

    • continuously forecast load and schedule scaling ahead

Good metrics to scale on

  • CPU Utilization: average CPU utilization across your instances
  • RequestCountPerTarget: to make sure the number of requests per EC2 isntances is stable
  • Average Network In/Out
  • any custom metric

Scaling Cooldowns

  • scaling 활동 이후, cooldown 기간이 시작된다 (default 300 sec)
  • 이 기간에는 ASG는 새로운 인스턴스를 생성하거나 인스턴스를 제거하지 않는다.
  • 권장: 바로 사용할 수 있는 AMI를 이용해 요청을 더 빨리 처리할 수 있도록 설정 시간을 줄이고 cooldown 기간을 줄이는 것
profile
정연희
이전 포스트

EC2 Instance Storage

다음 포스트

AWS Lightsail

0개의 댓글