AWS SAA chapter 6. 고가용성 및 스케일링성 - ELB & ASG

고가용성 및 스케일링성

• 확장성(Scalability) : 애플리케이션 시스템이 조정을 통해 더 많은 양을 처리할 수 있다는 의미이다.
  • 수직 확장성 : 인스턴스의 크기를 확장하는 것을 의미함
    • 사용 사례 : 데이터베이스와 같이 분산되지 않은 시스템에서 흔히 사용된다.(RDS, ElastiCache)
    • 하지만 일반적으로 확장할 수 있는 정도에 한계가 있다.
  • 수평 확장성(탄력성) : 애플리케이션에서 인스턴스나 시스템의 수를 늘리는 방법이다.
    • 수평 확장을 했다는 건 분배 시스템이 있다는 것을 의미한다.
    • 현대적 애플리케이션은 대부분 분배 시스템으로 이루어져 있다.
• 고가용성(Availability) : 애플리케이션 또는 시스템을 적어도 둘 이상의 AWS의 AZ나 데이터 센터에서 가동 중이라는 것을 의미한다.
  • 고가용성의 목표는 데이터 센터에서의 손실에서 살아남는 것으로, 센터 하나가 멈춰도 계쏙 작동이 가능하게끔 하는 것을 의미한다.
  • 고가용성은 수동적일 수도 있고(ex : for RDS Multi AZ), 능동적일 수도 있다.(for horizontal scaling)

High Availability & Scalability for EC2

• Vertical Scaling : Increase instance size(= scale up / down)
  • From : t2.nano
  • to : u-12t1.metal
• Horizontal Scaling : Increase number of instances(=scale out/in)
  • Auto Scaling Group
  • Load Balancer
• High Availability : 동일한 애플리케이션의 동일 인스턴스를 다수의 AZ에 걸쳐 실행하는 경우
  • Auto Scaling Group multi AZ
  • Load Balancer multi AZ

Load Balancing

• 서버 혹은 서버셋으로 트래픽을 백엔드나 다운 스트림 EC2 인스턴스 또는 서버들로 전달하는 역할을 한다.
• 부하를 다수의 다운 스트림 인스턴스로 분산할 수 있다.
• 사용하는 이유
  • 많은 유저가 연결될 수록 EC2 인스턴스로 가는 부하가 분산된다.
  • 애플리케이션에 단일 액세스 지점(DNS)을 노출하게 된다.
  • 다운스트림 인스턴스의 장애를 원활히 처리할 수 있다.(로드 밸런서가 헬스체크 메커니즘으로 어떤 인스턴스로 트래픽을 보낼 수 있기 때문)
  • 인스턴스의 상태를 확인할 수 있다.
  • SSL 종료도 할 수 있으니 웹 사이트에 암호화된 HTTPS 트래픽을 가질 수 있다.
  • 쿠키로 stickiness를 강화할 수 있다.
  • 영역에 걸친 고가용성을 가진다.
  • 클라우드 내에서 개인 트래픽과 공공 트래픽을 분리할 수 있다.
• ELB(Elastic Load Balancer)는 관리형 로드 밸런서이기도 하다.
  • AWS가 관리하며, 어떤 경우에도 작동할 것을 보장한다.
  • AWS가 업그레이드와 유지 관리 및 고가용성을 책임진다.
  • 로드 밸런서의 작동 방식을 수정할 수 있다.
• 자체 로드 밸런서를 마련하는 것보다 저렴하고, 자체 로드 밸런서를 직접 관리하면 확장성 측면에서 굉장히 번거롭다.
• 로드 밸런서는 다수의 AWS 서비스와 통합되어 있다.
  • EC2, EC2 Auto Scaling Groups, Amazon ECS
  • AWS Certificate Manager(ACM) , CloudWatch
  • Route 53, AWS WAF, AWS Global Accelerator

Health Checks(상태 확인)

• 상태 확인은 일래스틱 로드 밸런서가 EC2 인스턴스의 작동이 올바르게 되고 있는지의 여부를 확인하기 위해 사용된다.
• 만약 제대로 작동하는 중이 아니라면 해당 인스턴스로는 트래픽을 보낼 수 없기 때문에 로드 밸런서에겐 인스턴스의 상태가 아주 중요하다.
• 상대 확인은 포트와 라우트에서 이뤄진다.
  • HTTP 프로토콜의 경우 response가 200(OK)로 응답되지 않을 경우, unhealthy로 기록된다.
  • 그렇게 될 경우 ELB는 해당 인스턴스로 트래픽을 보내지 않게 된다.

Types of load balancer on AWS

• Class Load Balancer(v1 - old generation) - 2009 - CLB
  • HTTP, HTTPS, TCP, SSL, secure TCP를 지원한다.
  • AWS는 이제 이 로드 밸런서의 사용을 권장하지 않고 있다.(이젠 더이상 지원하지 않는다)
• 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
  • layer 3와 IP 프로토콜에서 동작한다.(네트워크층)
  • 네트워크 트래픽을 분석할 수 있고, 보안, 침입 탐지, 방화벽 등에 특화되어 있다.
• 일부 로드 밸런서들은 내부에 설정될 수 있어서 네트워크에 개인적인 접근이 가능하고, 웹사이트와 공공 애플리케이션 모두에 사용이 가능한 외부 공공 로드 밸런서도 있다.

Load Balancer Security Groups

• 위의 사진은 로드 밸런서를 적용한 EC2의 보안 그룹 규칙이다.
• 유저는 HTTP나 HTTPS를 사용해 어디서든 로드 밸런서에 접근이 가능해야 하기 때문에 80, 443 포트를 anywhere로 열어뒀다.
• EC2 인스턴스는 로드 밸런서를 통해 곧장 들어오는 트래픽만을 허용해야 하기 때문에 EC2 인스턴스의 보안 그룹 규칙은 포트 80에서 HTTP 트래픽을 허용하며 소스는 IP 범위가 아니라 보안 그룹이 된다.
• EC2 인스턴스의 보안 그룹을 로드 밸런서의 보안 그룹으로 연결한다.
• 이를 통해 강화된 보안 메커니즘이 된다.

Application Load Balancer(ALB)

• Layer 7, 즉 HTTP 전용 로드 밸런서로 머신 간 다수 HTTP 애플리케이션의 라우팅에 사용된다.
• 이러한 머신들은 대상 그룹이라는 것으로 묶이게 된다.
• 동일 EC2 인스턴스 상의 여러 애플리케이션에 부하를 분산한다.(ex:container)
• HTTP/2와 WebSocket을 지원한다.
• Redirect도 지원하므로 HTTP에서 HTTPS로 트래픽을 자동 리다이렉트하려는 겨우 로드 밸런서 레벨에서 가능하다.
• 경로 라우팅도 지원한다
  • URL 대상 경로에 기반한 라우팅이 가능하다.
    • ex : example.com/users & example.com/posts는 URL 상에서 서로 다른 경로이고, 이들을 다른 대상 그룹에 리다이렉트 할 수 이다.
  • URL의 hostname에 기반한 라우팅도 가능하다.
    • ex : one.example.com & other.example.com에 접근이 가능하다고 하면 두 개의 다른 대상 그룹에 라우팅이 될 수 있다.
  • 쿼리 문자열과 헤더에 기반한 라우팅도 가능하다.
    • ex : example.com/user?id=123&order=false가 있다면 id=123&order=false가 다른 대상 그룹에 라우팅 될 수 있다.
• 마이크로 서비스나 컨테이너 기반 애플리케이션에 가장 좋은 로드 밸런서이다. 이후 배우게 될 도커와 Amazon ECS의 경우에는 ALB가 가장 적합한 로드 밸런서가 된다.
  • 왜냐하면 port mapping 기능이 있어 ECS 인스턴스의 동적 포트로의 리다이렉션을 가능하게 해주기 때문이다.

Target Group 이란?

• EC2 인스턴스가 대상 그룹이 될 수 있다. 이들은 오토 스케일링 그룹에 의해 관리될 수 있다.
• ECS 작업도 될 수 있다.(이는 ECS 관련 게시물에서 자세히 다룬다.)
• Lambda functions 앞에서도 로드 밸런서가 있을 수 있다.(AWS에서 serverless 로 불린다)
• IP 주소들의 앞에도 위치할 수 있다.(반드시 사설 IP주소여야 한다)
• ALB는 여러 대상 그룹으로 라우팅할 수 있으며, health check는 대상 그룹 레벨에서 이뤄진다.

Platform 별 라우팅 예시

ALB 관련 알면 좋은 점

• 고정 호스트 이름이 부여된다(ex : XXX.region.elb.amazonaws.com)
• 애플리케이션 서버는 클라이언트의 IP를 직접 보지 못한다.
  • 클라이언트의 실제 IP는 X-Forwarded-For라고 불리는 헤더에 삽입된다.
  • 또한 X-Forwarded-Proto에 의해 사용되는 프로토콜도 얻을 수 있다.

Network Load Balancer(NLB)

• Layer 4 로드 밸런서이므로 TCP와 UDP 트래픽을 다룰 수 있다.
• 성능이 뛰어나다.
• 애플리케이션 로드 밸런서에 비해 지연 시간 또한 짧다.
• 가용 영역별로 하나의 고정 IP를 갖는다. 또한 elastic IP를 각 AZ에 할당할 수 있다.
• AWS 프리 티어에 포함되지 않는 옵션이다.

• Target Groups
  • EC2 instances
  • IP Address - must be private IPs
  • ALB(ALB 앞에 NLB를 사용할 수도 있다)
  • Health Checks는 TCP, HTTP, HTTPS를 지원한다

Gateway Load Balancer(GWLB)

• 배포 및 확장과 manage a fleet of 3rd party network virtual appliances in AWS
• 네트워크의 모든 트래픽이 방화벽을 통과하게 하거나 침입 탐지 및 방지 시스템에 사용한다
• IDPS나 심층 패킷 분석 시스템 또는 일부 페이로드를 수정할 수 있다.(네트워크 수준에서)
• GWLB의 기능은 네트워크 트래픽을 분석하는 것등에 있다.
• IP 패킷의 네트워크 계층인 Layer 3에서 동작한다.
• Transparent Network Gateway 기능 : VCP의 모든 트래픽이 GWLB가 되는 단일 엔트리와 출구를 통과하기 때문이다.
• 대상 그룹의 가상 appliances 집합에 전반적으로 그 트래픽을 분산해 로드 밸런서가 된다.
• SAA 시험에서는 6081 포트의 GENEVE 프로토콜을 사용해라.

Gateway Load Balancer - Target Groups

• EC2 instances
• IP address - must be private IPs

Sticky Sessions(Session Affinity)

• 로드 밸런서에서 2가지 요청을 수행하는 클라이언트가 요청에 응답하기 위해 백엔드에 동일한 인스턴스를 갖는 것(이 말은 즉, 클라이언트1의 요청이 EC2 instance1에 올라온 서버를 사용하면, 다음에 두번째 요청에서도 EC2 instance1을 사용함을 뜻함)
• 해당 원리에 관해서는 Cookie와 연관된다.
  • 클라이언트에서 로드 밸런서로 요청의 일부로써 전송됨
  • stickiness 과 expiration date를 위함
• 즉, 쿠키가 만료되면 클라언트가 다른 EC2 인스턴스로 리다이렉션 된다는 것이다.
• 사용 시에는 사용자의 로그인과 같은 중요한 정보를 취하는 세션 데이터를 잃지 않기 위해 사용자가 동일한 백엔드 인스턴스에 연결된다.
• 단, stickiness를 사용할 경우 백엔드 EC2 인스턴스 부하에 불균형을 초래할 수 있다.
  • 일부 인스턴스에 고정 사용자를 갖게되기 때문이다.

Sticky Session - Cookie Names

• Application-based Cookies
  • Custom Cookie
    • 대상으로 생성된 사용자 정의 쿠키로 애플리케이션에서 생성된다. 그리고 애플리케이션에 필요한 모든 사용자 정의 속성을 포함할 수 있다.
    • 쿠키 이름은 각 대상 그룹별로 개별적으로 지정해야 된다.
      • 단, AWSALB, AWSALBAPP, AWSALBTG 등으로 사용해선 안된다(ELB에 예약된 지정어이다.)
  • Application Cookie
    • 로드 밸런서 자체에서 생성된다.
    • ALB의 쿠기 이름은 AWSALBAPP 이다.
• Duration-based Cookies
  • 로드 밸런서에서 생성되는 쿠키로 ALB에서는 이름이 AWSALB이다.
  • 특정 기간을 기반으로 만료되며 그 기간이 로드 밸런서 자체에서 생성되는 것이다.(애플리케이션 기반 쿠키는 애플리케이션에서 기간을 지정할 수 있다)

Cross-Zone Load Balancing

• 교차 영역 로드 밸런싱을 쓰면, 각각의 로드 밸런서 인스턴스가 모든 가용 영역에 등록된 모든 인스턴스에 부하를 고르게 분배한다.
• ALB
  • 교차 영역 로드 밸런싱이 기본으로 활성화되어 있다.(대상 그룹 설정에서 비활성화할 수 있다)
  • 데이터를 다른 가용 영역으로 옮기는 데 비용이 들지 않는다.
• NLB & GWLB
  • 교차 영역 로드 밸런싱이 기본으로 비활성화되어 있다. 활성화하려면 비용을 지불해야 한다.
    • 가용 영역 사이에 data를 이동시키면 비용이 들기 때문이다.

SSL/TLS 개념

• SSL(Secured Socket Layer) 인증서는 클라이언트와 로드 밸런서 사이에서 트래픽이 이동하는 동안 암호화 해준다.
  • 이를 in-flight(전송 중) 암호화 라고 한다.
• 데이터는 네트워크를 이동하는 중에는 암호화되고, 송신자와 수신자 측에서만 이를 복호화할 수 있다.
• SSL은 연결을 암호화하는 데 사용한다.
• TLS(Transport Layer Security)는 새로운 버전의 SSL이다.
  • TLS가 많이 쓰이지만 SSL과 TLS 구분없이 SSL이라고 부른다.
• Public SSL certificate(퍼블릭 인증서)는 인증 기관(CA)에서 발급한다.
  • CA : Symantec, GoDaddy, GlobalSign 등등이 있다.
• 퍼블릭 SSL 인증서를 로드 밸런서에 추가하면, 클라이언트와 로드 밸런서 사이의 연결을 암호화할 수 있다.
  • SSL certificate는 만료 기간이 있기 때문에 주기적으로 갱신해줘야 한다.

Load Balancer - SSL Certificates

• 사용자가 HTTPS를 통해 인터넷에서 로드 밸런서에 접속하면, 로드 밸런서는 내부적으로 SSL Termination을 수행한다.
• 백엔드에서는 암호화되지 않은 HTTP로 EC2 인스턴스와 통신한다.(VPC로 이동하는 트래픽은 프라이빗 네트워크를 쓰기 때문에 안전하게 보호된다.)
• 로드 밸런서는 X.509 인증서를 사용하는데, 이걸 SSL 또는 TLS 서버 인증서라고 부른다.
• AWS에는 이 인증서들을 관리할 수 있는 ACM(AWS Certificate Manager)이라는 것이 있다.
  • 이 곳에 인증서를 업로드 할 수 있다
• HTTP 리스너를 구성할 때 반드시 HTTPS 리스너로 해야 한다.
  • 기본 인증서를 지정해줘야 한다.
  • 다중 도메인을 지원하기 위해 다른 인증서를 추가할 수도 있다.
  • 클라이언트는 SNI(Server Name Indication)라는 것을 써서 접속할 호스트의 이름을 알릴 수 있다.
  • 우리가 원하는 대로 보안 정책을 지정할 수 있다.

SSL - Server Name Indication

• SNI는 아주 중대한 문제의 해결책이다. 여러 개의 SSL 인증서를 하나의 웹 서버에 로드해 하나의 웹 서버가 여러 개의 웹 사이트를 지원할 수 있게 해준다.
• 이것은 확장된 프로토콜로, 클라이언트가 대상 서버의 호스트 이름을 지정하도록 한다.(최초 SSL handshake 단계에서)
• 그러면, 클라이언트가 접속할 웹사이트를 말했을 때, 서버는 어떤 인증서를 로드해야 하는지 알 수 있게 된다.
• 확장된 프로토콜로 새로 추가된 것이기 때문에 모든 클라이언트가 지원하지는 않는다. 이 프로토콜은 애플리케이션 로드 밸런서와 네트워크 로드 밸런서 그리고 CloudFront에서만 동작한다.
• 즉 어떤 로드 밸런서에 SSL 인증서가 여러 개 있다면 ALB나 NLB 둘 중에 하나를 고르면 된다.

Connection Draining(Deregistration Delay, 연결 취소 지연)

• 인스턴스가 등록 취소, 혹은 비정상인 상태가 있을 때 인스턴스에 어느 정도의 시간을 줘 in-flight request(활성 요청)을 완료할 수 있도록 하는 기능이다.
• 인스턴스가 Draining 되면 ELB는 등록 취소 중인 EC2 인스턴스로 새로운 요청을 보내지 않는 것이다.
• 연결 드레이닝 파라미터는 매개변수로 표시할 수 있다.
  • 1~3600초 사이의 값으로 설정할 수 있다.(default : 3000s)
  • 이 값을 0으로 설정하면 비활성화이다.
  • 짧은 요청의 경우에는 낮은 값으로 설정하면 좋다

Auto Scaling Group(ASG)

• 웹 사이트 방문자가 많이지면 load 시간이 바뀔 수 있다.
• EC2 인스턴스 생성 API 호출을 통해 서버를 빠르게 생성하고 종료할 수 있다.
• 이를 자동화 하고 싶다면 ASG를 생성할 수 있다

ASG의 목표

• 증가한 로드에 맞춰 EC2 인스턴스를 추가(Scale-out)
• 감소한 로드에 맞춰 EC2 인스턴스를 제거(Scale-in)
• ASG에서 실행되는 EC2 인스턴스의 최소 및 최대 개수를 보장하기 위해 매개변수를 사용할 수 있다.
• 로드 밸런서와 페어링 하는 경우 ASG에 속한 모든 EC2 인스턴스가 로드 밸런서에 연결된다.
• 한 인스터스가 비정상이면 종료하고, 이를 대체할 새 인스턴스를 생성한다.
• ASG는 무료이다.

ASG Attributes

• Launch Template을 생성해야 한다.
  • EC2 인스턴스를 시작하는 방법에 대한 정보가 포함되어 있다.
  • AMI + InstanceType
  • EC2 User Data
  • EBSVolumes
  • 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

Auto Scaling - CloudWatch Alarms & Scaling

• CloudWatch Alarm을 기반으로 ASG를 스케일 인 및 스케일 아웃 할 수 있다.
• Alarm의 기준은 지표(metric)이다. 즉, 모니터링 할 수 있는 평균 CPU나 원하는 사용자 지정 지표 어떤 것도 지정할 수 있다.
  • 예를 들어 ASG 전체의 평균 CPU가 너무 높으면 EC2 인스턴스의 추가가 필요하고, 지표에 따라 Alarm을 발생시켜 ASG의 스케일링 활동을 유발한다.

Auto Scaling Groups - Dynamic Scaling Policies

• Target Tracking Scaling
  • 가장 쉽고 간편하다
  • 오토 스케일링 그룹의 평균 CPU 사용률을 추적하여 기본 기준선 주변에 머무를 수 있도록 할 때 사용
• Simple / Step Scaling
  • Cloud Watch alarm을 설정하고 Scale out/in 할 인스턴스 수를 정할 수 있다
    • 예시 : 전체 ASG에 대해 CPU 사용률이 70%를 초과하는 경우 용량을 두 유닛 추가하도록 설정할 수 있다.
  • 단순 조정 정책은 말 그대로 단순한 갯수로 조정하게 하는것
  • 단계 조정 정책은 임곗값 초과치의 크기에 따라 증가 갯수를 변경할 수 있다.
• Scheduled Actions
  • 나와 있는 사용 패턴을 바탕으로 스케일링을 예상하는 것. 스케일링이 필요함을 미리 알 때에 예정된 작업을 설정하면 된다.
  • 예시 : 매주 금요일 오후 5시에 큰 이벤트가 예정되어 있으니 자동으로 10시까지 늘리도록 하는 것
• Predictive scaling
  • AWS 내 오토 스케일링 서비스를 활용하여 지속적으로 예측 생성할 수 있다. 로드를 보고서 다음 스케일링을 예측하는 것
  • Good metrics to scale on
    1. CPU utilization
    2. RequestCountPerTarget
    3. Average Network In/Out
    4. Any custom metric

Auto Scaling Groups - Scaling Cooldowns

• 스케일링 작업이 끝날 때마다 (인스턴스의 추가 또는 삭제를 막론하고) 기본적으로 300초의 휴지 기간을 갖는 것이다.
• 휴지 기간에는 ASG가 추가 인스턴스를 실행 또는 종료할 수 없다.
• 이를 통해 새로운 인스턴스가 안정화될 수 있도록 하며, 새로운 지표의 양상을 살펴보기 위함이다.
• 즉시 사용 가능한 AMI을 이용하여 EC2 인스턴스 구성 시간을 단축하고, 이를 통해 요청을 좀 더 신속히 처리하는 것이 좋다.