ELB, ASG

확장성 - 어플리케이션 시스템이 조정을 통해 더 많은 양을 처리할 수 있음, 수직 확장성, 수평 확장성(탄력성)

 

수직 확장성 - 인스턴스의 크기를 확장, t2.micro -> t2.large, 데이터베이스 같은 분산되지 않은 시스템에 사용, 하드웨어 성능에 따른 제한, scale up, down

 

수평 확장성 - 어플리케이션에서 인스턴스나 시스템의 수를 늘림, 분배 시스템, scale out, in

 

고가용성 - 어플리케이션 또는 시스템을 적어도 둘 이상의 AWS의 AZ나 데이터센터에서 가동 중을 의미, 데이터 센터에서의 손실에서 살아남는 것으로, 다른 센터가 멈춰도 계속 작동하는 것

 

로드 밸런싱 - 서버 또는 서버셋으로 트래픽을 백엔드나 다운스트림 EC2 인스턴스나 서버로 전달하는 역할

   - 부하를 여러 다운스트림 인스턴스로 분산하기 위해

   - 어플리케이션에 단일 엑세스 지점(DNS)를 노출

   - 다운스트림 인스턴스의 장애를 원활하게 처리 가능

   - 인스턴스 상태 확인

   - SSL 종료 제공으로 암호화된 HTTPS 트래픽 가능

   - 쿠키로 고정도 강화, 영역에 걸친 고가용성 제공

   - 클라우드 내 개인 트래픽, 공공 트래픽 분리 가능

 

Elastic Load Balancer - 관리형 로드 밸런서로 AWS가 관리하고 어떤 경우에도 작동하는 것을 보장, 업그레이드, 유지 관리, 고가용성 책임, 작동 방식 변경할 수 있도록 일부 구성 제공, 비용과 확장성 측면에서 사용하는 것이 좋음, EC2, Scaling Group, ECS, ACM, CloudWatch, S3 등과 통합되어 있음, 인스턴스 헬스 체크 가능(포트, 라우트, 200OK가 아니면 비정상으로 판단, 트래픽 전달 X)

   - CLB : Classic Load Balancer, 2009, 현재 지원 X

   - ALB : Application Load Balancer, 2016

   - NLB : Network Load Balancer, 2017

   - GWLB : Gateway Load Balancer, 2020

 

ALB - 7계층, HTTP 전용 로드 밸런서, 머신 간 다수 HTTP 어플리케이션 라우팅에 사용, HTTP/2, Websocket 지원, 경로 라우팅 지원(URL 대상 경로, URL 호스트 이름, 쿼리 문자열, 헤더), 마이크로 서비스, 컨테이너 기반에 적절함, 포트 매핑 기능이 있어 인스턴스의 동적 포트로 리다이렉션 가능, 하나로 다수의 어플리케이션 처리 가능

   - 타켓 그룹 : EC2 인스턴스(오토 스케일링으로 관리되는), ECS 작업, 람다 함수, 사설 IP 주소

   - 고정 호스트 이름 부여, 클라이언트의 IP를 직접 알지 못함(X-Forwarded-For 헤더에 있음, X-Forwared-Port, X-Forwarded-Proto)

 

NLB - 4계층, TCP, UDP, 높은 성능(초당 수백만 건 처리 가능, ALB에 비해 지연 시간 짧음), AZ별로 하나의 고정 IP를 가짐, Elastic IP 주소를 각 AZ에 할당 가능, 헬스 체크(TCP, HTTP, HTTPS)

 

GWLB - 3계층, 배포 및 확장, 가상 어플라이언스 플릿 관리에 사용, IDS, FW, 네트워크 트래픽 분석 가능, 투명 네트워크 게이트웨이, 가상 어플라이언스의 집합의 로드 밸런서, GENEVE 프로토콜, 6081 포트

 

ELB

  - Sticky Session : 고정성, 고정 세션을 실행하는 것, 로드 밸런서에 2가지 요청을 수행하는 클라이언트가 요청에 응답하기 위해 백엔드에 동일한 인스턴스를 갖는 것, 쿠키(클라이언트에서 로드 밸런서로 요청의 일부로 보내짐)가 만료되면 다른 EC2 인스턴스로 연결, 이 기능을 사용하면 EC2 인스턴스 부하에 불균형 가능성 있음

        - Application based Cookie

               - Custom Cookie : 어플리케이션에서 생성, 어플리케이션에 필요한 사용자 정의 속성 포함 가능, 그룹별로 개별 이름 지정(AWSALB, AWSALBAPP, AWSALBTG 이런거 X, ELB에서 사용 중)

               - Application Cookie : 로드 밸런서에서 생성, AWSALBAPP

        - Duration based Cookie : 로드 밸런서에서 생성, ALB - AWSALB, CLB - AWSELB, 특정 기간을 기반으로 만료

 

  - Cross-Zone Load Balancing : 모든 영역에 있는 EC2 인스턴스에 트래픽이 고르게 분배됨, 한쪽 영역에 인스턴스가 몰려있어도, Cross Zone 사용 안하면 각 영역의 인스턴스 수만큼 분배됨

        - ALB : 기본으로 활성화 상태, 비활성화 가능, 다른 AZ로 데이터 옮길 때 비용 X

        - NLB, GWLB : 기본으로 비활성화 상태, 활성화 하거나 다른 AZ로 데이터 옮길 때 비용 지불

        - CLB : 기본으로 비활성화, 다른 AZ로 데이터 옮길 때 비용 X

 

  - SSL/TLS : 클라이언트와 로드 밸런서 사이에서 트래픽이 이동하는 동안 암호화, SSL(연결을 암호화하는데 사용), TLS(새로운 버전의 SSL), 공인 인증서는 CA에서 발급, SSL 인증서는 만료 기간이 있어 갱신 필요, X.509 인증서 사용(SSL, TLS 서버 인증서), ACM(AWS Certificate Manager), 기존 인증서를 ACM에 업로드 가능, HTTPS listener(기본 인증서로 지정, 다중 도메인 지원을 위해 다른 인증서 추가 가능, SNI을 이용해 접속할 호스트 이름 알리기 가능)

        - SNI : Server Name Indication, 여러 SSL 인증서를 하나의 웹서버에 로드해 한 웹서버에서 여러 웹 사이트 지원이 가능한 기능, 확장된 프로토콜, 클라이언트가 대상 서버의 호스트 이름 지정 가능, ALB, NLB, CloudFront 에서만 가능, CLB 불가

 

  - Connection Draining : CLB(Connection Draining), ALB&NLB(Deregistration Delay), 인스턴스가 등록 취소나 비정상적인 상태일 때 어느 정도의 시간을 주고 활성 요청을 완료할 수 있도록 하는 기능, 인스턴스가 draining 되면 ELB는 등록 취소 중인 EC2로 판단해 새로운 요청을 보내지 않음, 1 ~ 3600초, 기본은 300초로 5분, 0으로 하면 draining 발생하지 않음

 

ASG - Auto Scaling Group, 증가한 로드에 맞춰 EC2 인스턴스를 추가하거나(Scale Out) 감소한 로드에 맞춰 EC2 인스턴스를 제거하는 것(Scale In), 최대 및 최소 인스턴스 개수 지정 가능, 로드 밸런서와 페어링하면 ASG에 속한 모든 EC2 인스턴스가 로드 밸런서에 연결됨, 한 인스턴스가 비정상이면 종료하고 새 인스턴스를 생성, ASG는 무료지만 하위 인스턴스에 대한 비용은 지불, CloudWatch 지표 기반(CPU, 사용자 지정..)으로 ASG Scale을 out, in 할 수 있음

  - Dynamic Scaling Policy

        - Target Tracking Scaling : 가장 단순, ASG 평균 CPU 사용률과 같은 기준선을 만들고 상시 사용 가능하도록 함

        - Simple / Step Scaling : CloudWatch 경보 설정 평균 CPU 사용률이 일정 이상이거나 이하일 때 유닛을 추가나 제거하는 형식

        - Scheduled Actions : 나와 있는 사용 패턴을 바탕으로 Scaling을 예상, 미리 out, in이 예상될 때 사용

  - Predictive Scaling : Scheduled Actions를 통해 ASG를 지속적으로 예측 생성 가능, 로드를 확인하고 다음 Scaling을 예상

  - 지표 : CPU 사용률, 대상별 요청 수, 네트워크 입/출력량

  - Scaling Cooldowns : Scaling 작업이 끝날 때마다 기본적으로 5분정도의 휴식 시간 가짐, 이 시간에는 ASG가 추가 인스턴스를 실행하거나 종료할 수 없음, 해당 시간동안 인스턴스의 안정화와 지표를 확인하기 위함, 즉시 사용 가능한 AMI를 이용해 EC2 인스턴스 구성 시간을 단축해 요청을 좀 더 빨리 처리하는 것이 좋음, 활성화 시간이 짧아지면 휴식 시간도 짤아지기 때문에 더 많은 Dynamic Scaling이 가능