[SAA] ELB(Elastic Load Balancer), ASG(Auto Scaling Group)

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

• Scalability(확장성)
  • 애플리케이션 / 시스템이 조정을 통해 더 많은 양을 처리할 수 있는 능력
  • Vertical Scalability(수직 확장성)
    • 인스턴스의 크기를 늘리는 것 (사양 업그레이드)
    • 분산되지 않은 데이터베이스 같은 시스템에 적합 (RDS, elasticCache)
    • 하드웨어적 한계가 있음
    • scale up / scale down
  • Horizontal Scalability(수평 확장성) = elasticity(탄력성)
    • 인스턴스 혹은 시스템의 개수를 늘리는 것
    • 수평확장을 하는 것은 분산 시스템이 있다는 것을 의미 (웹이나 현대 애플리케이션은 대부분 분산시스템으로 이루어짐)
    • Amazon EC2와 같은 클라우드 제공 업체로 쉽게 수평 확장 가능
• High Availability(고가용성)
  • 수평 확장과 함꼐 사용되는 개념
  • 애플리케이션 또는 시스템을 적어도 둘 이상의 AWS AZ나 데이터 센터에서 가동중인 것을 의미
  • 데이터 센터에서의 손실에서 살아남는 것이 목표, 하나가 멈춰도 나머지가 가동하여 대비하는 것
  • Auto Scaling Group multi AZ or Load Balancer multi AZ를 이용
  • 고가용성은 수동적일 수 있음 ex) RDS Multi AZ
  • 고가용성은 능종적일 수 있음 ex) 수평 확장

2. Load Balancing

• 서버 혹은 서버 집합으로 트래픽을 백이나 다운스트림 EC2로 전달하는 역할
• 사용 목적
  • 트래픽 분산
  • 앱에 단일 접근 포인트 DNS를 통해 노출 가능
  • 정기적인 health check를 통하여 하위 인스턴스틔 실패에 대처 가능
  • 웹사이트에 SSL termination(HTTPS)를 제공 - 암호화된 https 트래픽을 가질 수 있음
  • 쿠키를 통해 정적 분배 적용
  • 가용영역 내 고가용성을 가짐
  • 클라우드 내에서 private traffic과 public traffic을 분리할 수 있음
• ELB(Elastic Load Balancer) 사용 목적
  • ELB(Elastic Load Balancer): 관리형 로드 밸런서
    • 애플리케이션에 사용 가능한 정적 DNS 이름을 제공
    • AWS가 관리, 어떠한 경우에도 로드 밸런서가 작동할 것을 보장
    • AWS는 업그레이드, 유지 관리 및 고가용성을 책임짐
    • AWS는 몇가지 구성 놉(configuration knbs)을 제공
    • 다수의 AWS 서비스와 통합 (EC2, EC2 auto scailing, ECS, ACM, CloudWatch, Route53, WAF, WAS Global Accelerator)
• Health Check
  • ELB가 EC2의 올바른 작동을 확인하고 비정상적이면 트래픽을 중단
  • 포트와 라우트로 점검
    • Protocal: Http
    • Port: 4567
    • EndPoint: /health
    • 응답이 200이 아닐 경우 비정상으로 판단
• AWS Load Balancer의 종류
  • CLB: Classic Load Balancer (v1 - old generation) - 2009 더이상 사용되지 않음
  • ALB: Application Load Balancer (v2 - new generation) - 2016
    • Layer 7, http 전용 로드 밸런서
    • 여러 머신간 다수 http 애플리케이션 라우팅에 사용
    • 동일 EC2 인스턴스 상의 여러 애플리케이션에 대한 로드 밸런싱 ex) containers
    • http/2와 WebSocket 지원
    • redirection 지원 (http => https)
    • 대상 그룹(target groups)
      • EC2 instances(Auto Scailing Group에 의해 관리) - HTTP
      • ECS Tasks(ECS 자체에 의한 관리) - HTTP
      • Lambda functions - HTTP 용청이 JSON 이벤트로 번역
      • IP address - Private IP이여야 함
    • 대상 그룹(target groups)에 따른 라우팅
      • URL 경로 기반 (test.com/test1 , test.com/test2)
      • URL 호스트 기반 (test1.test.com , test2.test.com)
      • 쿼리스트링, 헤더 기반 (test.com?name=test&age=20)
    • 마이크로 서비스나 컨테이너 기반 애플리케이션에 가장 적합 ex) Docker, Amazon ECS
    • ECS의 동적 포트로 리디렉션하는 포트 매핑 기능이 있음
    • ALB는 여러 대상 그룹으로 라우팅할 수 있으며, 헬스 체크는 대상 그룹 수준에서 이루어짐
    • Query String / Parameter Routing
      • 고정된 호스트 이름 사용 (XXX.region.elb.amazonaws.com)
      • 애플리케이션 서버는 클라이언트의 IP를 직접적으로 보지 못함
        • 실제 IP는 Header X-Forwarded-For에 삽입
        • 포트(X-Forwarded-Port)와 프로토콜(X-Forwarded-Proto)도 확인 가능
  • NLB: Network Load Balancer (v2 - new generation) - 2017
    • Layer 4, TCP, UDP를 다룰 수 있는 로드 밸런서, HTTP를 다루는 L7의 하위 계층
    • 고성능 (초당 수백만건의 요청 처리 가능), ALB에 비해 지연 시간이 짧음(약 100 ms / ALB는 400 ms)
    • 가용 영역당 하나의 고정 IP를 가짐
    • 탄력적 IP를 각 가용 영역에 할당 가능 (helpful for whitelisting specific IP)
    • AWS 프리 티어에 포함 X
    • 대상 그룹(target groups)
      • EC2 instances (TCP 또는 UDP 트래픽을 EC2 인스턴스로 리다이렉트 가능)
      • IP 주소 (하드코딩된 private IP)
      • Application Load Balancer (고유 IP를 얻을 수 있고 ALB 덕분에 HTTP 유형의 트래픽 또한 처리할 수 있기에 유효한 설정)
    • Health check: TCP / HTTP / HTTPS 중 하나의 프로토콜로 헬스 체크 제공
    • 보안 그룹 정의 X, NLB로 들어온 트래픽이 EC2 인스턴스로 들어가기 때문에 EC2의 보안그룹이 결정
  • GWLB: Gateway Load Balancer - 2020
    • 배포 및 확장과 AWS의 3rd party 네트워크 가상 어플라이언스의 플릿 관리를 위해 사용
    • 방화벽, 침입 탐지 및 방지 시스템, 딥 패킷 검사 시스템, 페이로드의 조작 등
    • user -> gwlb -> 타사 대상 그룹의 가상 어플라이언스 -> gwlb -> app
    • app 에 도달하기 전 트래픽을 검사하고 drop or 전달
    • L7보다 낮은 단계인 네트워크 계층(L3) 단계에서 실행 - IP 패킷의 네트워크 계층
    • Transparent Network Gateway: 모든 트래픽에 대해 단일 입/출구를 가지고 검사
    • Load Balancer: 가상 어플라이언스에 대해 트래픽 분산
    • 6081 포트에서 GENEVE 프로토콜 사용
    • 대상 그룹(target groups)
      • EC2 Instances
      • IP 주소(개인 IP를 수동 등록, private IP)
• Load Balancer의 보안 그룹
  • HTTP 80 기본 포트와 HTTPS 443 기본 포트를 열어놓고 EC2의 보안 그룹은 이를 상속해야 Load Balancer에서 온 입력만을 들여보내는 강화된 보안 매커니즘이 작용됨

• Sticky Sessions(Session affinity) in ELB - 고정 세션 혹은 세션 밀접성

  • 로드 밸런서에 두가지 요청을 수행하는 클라이언트가 요청에 응답하기 위해 백엔드에 동일한 인스턴스를 갖는 것
    • 로드 밸런서 뒤에 있는 동일한 인스턴스로 항상 리디렉션 되도록 고정 세션을 구현할 수 있음
    • 유저 1이 ALB를 거칠 때 몇번이고 같은 인스턴스로 통신하게 되는 것
    • CLB, ALB에서 사용 가능
    • 쿠키를 통하여 고정성(Stickiness)이 가능하고 만료 기간이 있음
    • 유저가 세션 데이터를 잃으면 안될 때 사용
    • Sticiness 활성화 시 백앤드 EC2 인스턴스에서 트래픽 불균형이 생길 수 있음
  • Cookie
    • Application-Based Cookies
      • Custom Cookie
        • 사용자 정의 쿠키(앱에서 생성), 만료 기간 설정 가능
        • 앱에 필요한 모든 사용자 정의 속성 포함 가능
        • 쿠키 이름은 각 대상 그룹별로 개별적으로 지정 가능
        • AWSALB, AWSALBAPP, AWSALBTG같은 이름을 쓰면 안됨(ELB에서 예약됐으므로)
      • Application Cookie
        • 로드밸런서로부터 생성
        • ALB의 쿠키 이름은 AWSALBAPP
    • Duration-Based Cookies
      • 로드밸런서로부터 생성, 특정 기간을 기반으로 만료, 그 기간은 로드밸런서에 의해 생성
      • 쿠키 이름은 ALB에서는 AWSALB, CLB에서는 AWSELB 사용

• Cross-Zone Load Balancing

  • with Cross-Zone Load Balancing
    • 각 AZ에 ALB의 내부 인스턴스 개수가 불균형한 경우 모든 인스턴스에 고르게 부하를 분배
    • abl1(인스턴스 2), alb2(인스턴스 8)에 부하가 10일 경우 각 인스턴스가 10%씩 부하를 분배
  • without Cross-Zone Load Balancing
    • AZ 영역을 교차하지 않고 요청을 분산
    • • abl1(인스턴스 2), alb2(인스턴스 8)에 부하가 10일 경우 alb1과 alb2에 50%씩 부하를 분배하고 alb1의 인스턴스는 25%씩, alb2의 인스턴스는 6.25%식 부하 분배
  • Application Load Balancer
    • 대상 그룹 레벨에서 비활성화 가능, default는 활성화 상태
    • 가용 영역 간 데이터에 대한 요금 X
  • Network Load Balancer & Gateway Load Balancer
    • default 비활성화
    • 활성화 시 가용 영역간 데이터에 대한 요금 청구
  • Classic Load Balancer
    • default 비활성화
    • 활성화 시 가용 영역간 데이터에 대한 요금 X

• SSL/TLS 인증서

  • SSL 인증서: 클라이언트와 로드밸런서 사이에서 트래픽이 이동하는 동안 암호화 (in-flight 암호화 / 전송중 암호화)
  • SSL(Secure Socket Layer) 보안 소켓 계층을 의미, 연결 암호화 시 사용
  • TLS(Transport Layer Security)는 SSL의 신버전
  • Public SSL은 Certificate authorities(CA)에서 발급
    • 인증기관: Comodo, Symantec, GoDaddy 등,,,
    • 로드밸런서에 추가 시 클라이언트와 LB 사이의 연결 암호화
    • 만료기간이 있어 주기적으로 갱신하여 인증 상태를 유지해야 함
  • 동작 방식
    • user가 https 통신을 통하여 로드 밸런서 접근
    • ssl termination (ssl 종료)
    • LB가 HTTP 통신을 통해 백엔드와 통신 수행(내부 VPC망은 private하기 때문에 HTTP도 안전)
  • 특징
    • LB는 X.509 인증서를 이용, 이를 SSL 혹은 TLS 서버 인증서라 부름
    • 인증서를 ACM(AWS Certificate Manager)에 업로드 할 수 있음
    • HTTPS 리스너를 이용해야하고 default 인증서를 지정해야함
    • 다중 도메인을 위해 다른 인증서를 추가할 수도 있음

• SNI(Server Name Indication)

  • 중대한 문제의 해결책, 여러개의 SSL 인증서를 하나의 웹서버에 로드해 하나의 웹서버가 여러개의 웹서버를 지원할 수 있게 함
  • 확장된 프로토콜로 클라이언트가 대상 서버의 호스트 이름을 지정하는데, 이는 최초 SSL 핸드쉐이크 시 일어남
    • 클라이언트가 접속할 웹사이트를 말햇을 때 서버는 어떤 인증서를 로드해야하는지 알 수 있는 것
    • ALB, NLB, CloudFront에서만 동작
  • 지원 항목
    • CLB: 1개의 SSL 인증서만 지원
    • ALB & NLB: SNI를 사용하여 여러개의 인증서로 여러개의 리스너를 둘 수 있음

• ELB Connection Draining

  • CLB: Connection Draining
  • ALB & NLB: Deregistration Delay
  • 인스턴스가 등록 해제 되거나 unhealth 할 때 in-flight 활성 요청 을 처리할 시간을 주는 것
  • 드레이닝 중인 EC2에는 트래픽을 보내지 않는다. 이미 연결된 유저는 기존 연결 및 요청이 마무리 될때까지 충분한 드레이닝 시간을 가지고 완료된 뒹 드레이닝 된다.
  • 드레이닝 시간을 설정할 수 있으며, default 300, 0으로 설정 시 draining 사용 X

• ASG(Auto Scaling Group)

  • 웹사이트나 애플리케이션의 부하가 변경되었을 때 사용자는 AWS에서 서버를 빠르게 생성하고 종료가능, 이를 자동화하기 위하여 ASG 사용
  • 무료이지만 EC2 인스턴스와 같은 하위 리소스에 대한 비용만 지불
  • 목표
    • 부하 증가에 따른 EC2 scale out
    • 부하 감소에 따른 EC2 scale in
    • 최소 및 최대 실행중인 EC2 인스턴스 보장
    • 새로운 인스턴스를 로드밸런서에 자동 등록
    • 인스턴스가 unhealth한 경우 대체할 새 EC2 인스턴스 등록
  • ASG 속성
    • Launch Template
      • AMI + InstanceType
      • 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 site / initial capacity
    • scaling policies
  • CloutWatch Alarms & Scaling
    • ASG를 CloudWatch 경보에 기반하여 스케일 인 아웃 가능
    • 경보는 지표(평균 CPU, 사용자 지정 지표 - custom metric)를 모니터링
    • 평균 CPU와 같은 지표는 전체 ASG 인스턴스에 대해 계산
  • Auto Scaling Polices
    • Dynamic Scaling Policies(동적 조정)
      • Target Tracking Scaling(대상 추적 크기 조정)
        • 가장 간단하고 쉽게 설정할 수 있는 방법 ex) 평균 ASG CPU가 약 40% 대에 유지되도록 함
      • Simple / Step Scaling(단계 크기 조정)
        • CloudWatch 경보가 트리거될 때 ex) cpu > 70%일 경우 2 유닛 추가, cpu < 30%일 경우 1유닛 제거
      • Scheduled Actions(예약된 크기 조정)
        • 알려진 사용 패턴에 기반하여 스케일링 에상 ex) 매주 금요일 오후 5시에 최소 용량을 10으로 증가
      • Predictive Scaling(예측 조정)
        • 과거 히스토리에서 로드를 분석하고 예측한 뒤 해당 예측에 따라 scaling
    • 스케일링에 사용하기 좋은 평가 지표
      • CPU Utilization : 인스턴스 전반에 걸친 평균 CPU 사용률
      • Request Count Per Target: EC2 인스턴스당 요청 수가 안정적인지 확인하기 위해 사용
      • AVG Network In/Out: 평균 네트워크 입출력량
      • Any Custom Metric: CloudWatch를 통한 지표로 확인
  • Scaling Cooldown
    • 스케일링이 발생한 후 쿨 다운기간에 진입(default 300 sec)
    • 쿨다운 기간에는 ASG 추가 인스턴스를 실행 또는 종료할 수 없음
    • 즉시 사용이 가능한 AMI를 사용하여 EC2 인스턴스 구성 시간을 단축하고 이를 통해 요청을 신속하게 처리하는 것이 좋음