High Availability & Scalability

Scalability

• scale을 조절함으로써 더 많은 양을 처리 할 수 있게 해줌
  • 수직적 스케일 (Vertical Scalability)
  • 수평적 스케일 (Horizontal Scalability = elasticity)

Vertical Scalability

• 인스턴스의 크기를 확장하는 것을 의미
• 데이터베이스와 같이 분산되지 않은 시스템에서 사용
  • RDS, ElastiCache

Horizontal Scalability

• 인스턴스나 시스템의 수를 늘려줌

High Availability

• 애플리케이션 또는 시스템을 적어도 둘 이상의 AWS의 AZ나 데이터 센터에서 가동 중인 것을 말한다 (Scalability와 다른 개념)
• 고가용성의 목표는 하나의 센터가 멈춰도 시스템이 아무 문제 없이 작동되게 하는 것

HA & Scalability For EC2

• Vertical Scaling : scale up / down
• Horizontal Scaling : scale out (인스턴스 수 증가) / in (인스턴스 수 감소)
  • Auto Scaling Group
  • Load Balancer
• HA : 같은 애플리케이션을 다중 AZ에 구성
  • Auto Scaling Group multi AZ
  • Load Balancer multi AZ

What in load balancing?

• 트래픽은 다중화된 서버들로 보내줌
• 부하 분산의 기능 (부하를 다수의 다운스트림 인스턴스로 분산을 위함)
• 유저들은 어떤 인스턴스에 연결 되었는지는 모른다 (애플리케이션에 단일 액세스 지점 (DNS)를 노출)
• 로드밸런서의 health check 기능으로 어떤 인스턴스의 오류인지 검출 가능
• SSL 가능
• 쿠키와 HA
• 클라우드 내의 개인 트래픽과 공공 트래픽의 분리 가능

Elastic Load Balancer

• 관리형 로드 밸런서
• AWS가 HA를 유지하도록 관리
• 가능한 사용하는 것이 좋다
• 다수의 서비스들과 통합되어 있다

Health Checks

• 작동이 올바르게 되고 있는지 확인
• 상태확인은 포트와 라우트에서 이루어진다 (/heath 경로가 일반적)
• 200 (OK)응답이 안온다면 health check는 실패
• 실패하게 되면 실패한 인스턴스로는 트래픽을 보내지 않음

Types of load balancer on AWS

• Classic Load Balancer (2009)
  • HTTP, HTTPS, TCP, SSL
• Application Load Balancer (2016)
  • HTTP, HTTPS, WebSocket
• Network Load Balancer (2017)
  • TCP, TLS, UDP
  • 초고성능을 위할 때, 지연 시간을 최소로 유지하면서 초당 수백만 건의 요청을 처리
• Gateway Load Balancer (2020)
  • 3계층인 네트워크 레이어 (IP protocol)
  • 보안, 침입 탐지, 방화벽 등에 특화

Load Balancer Security Groups

• EC2 인스턴스의 보안 규칙은 로드 밸런서의 보안 규칙과 연결할 수도 있다
  • 인스턴스의 IP로는 직접적인 연결은 불가능하지만 로드 밸런서를 통해서는 접근이 가능하다
• 네트워크 트래픽을 분석하기 위한 로드 밸런서
• 강화된 보안 메커니즘

Application Load Balancer

• 애플리케이션 계층인 7 계층, HTTP 전용 로드 밸런서
• URL 경로, 호스트 이름, HTTP 헤드 및 쿼리 문자열을 기반으로 트래픽을 다른 대상 그룹으로 라우팅 할 수 있다
• 머신 간 다수 HTTP 애플리케이션의 라우팅에 사용
• 머신들은 대상 그룹으로 묶인다
• 부하를 분산
• 컨테이너와 ECS를 사용
• 라다이렉트도 설정 가능
• URL기반의 라우팅 가능
• 마이크로 서비스나 컨테이너 기반 애플리케이션에 가장 좋은 로드 밸런서 (Docker, ECS)
• 포트 매핑 기능이 존재 (독립된 타겟 그룹을 처리 할 수 있음)
• 뒷단의 EC2가 요청한 사용자의 IP를 알기 위해서는 HTTP 요청에 있는 추가 헤더인 X-Forwarded-For을 확인 해야 한다
  • X-Forwarded-Port(포트를 확인)와 X-Forwarded-Proto

ALB Target Groups

• EC2 인스턴스 : HTTP
• ECS : HTTP
• Lambda functions
• IP Addresses

Network Load Balancer

• HTTP를 다루는 Layer 7보다 낮은 Layer 4 계층 (전송 계층)으로, TCP, UDP 트래픽을 다룬다
• 초당 수백만 건의 요청을 처리 할 수 있고 지연시간도 짧다
• AZ별로 하나의 고정 IP를 가진다
• 탄력적 IP주소를 각 AZ 에 할당 가능하다 (정적 IP를 가진다)
• 여러 개의 고정IP를 가진 애플리케이션을 노출 할 때 편리하다
• NLB는 로드 밸런서의 보안 그룹을 정의하지 않고 곧장 타겟 그룹으로 트래픽을 보내며, 타켓 그룹의 보안 그룹이 트래픽을 허용할지 말지를 결정한다

NLB Target Groups

• EC2 인스턴스
  • TCP, UDP 트래픽을 EC2 인스턴스로 리다이렉트할 수 있따
• IP Addresses
  • 반드시 사설 주소여야 한다
• ALB
  • ALB 앞단에 NLB를 둘 수 있다
  • NLB로 고정 IP를 얻을 수 있고, ALB를 통해 HTTP 유형의 트래픽을 처리할 수 있따
• Health check로는 3가지 프로토콜을 지원한다
  • TCP, HTTP, HTTPS

Gateway Load Balancer - GWLB

• NLB보다 낮은 Layer 3인 네트워크 계층에서 실행된다 (IP 패킷)
• 6081번 포트의 GENEVE 프로토콜을 사용한다
• 배포 및 확장과 AWS의 타사 네트워크 가상 어플라이언스의 플릿 관리에 사용
• 네트워크의 모든 트래픽이 방화벽을 통과하게 하거나 침입 탐지 및 방지 기능 등 네트워크 수준에서 사용
• 네트워크 트래픽을 분석해서 올바르지 않다면 트래픽을 드롭한다

GWLB의 2가지 기능

• Transparent Network Gateway
  • 트래픽의 단일 엔트리와 출구를 통과
• Load Balancer
  • 대상 그룹의 가상 어플라이언스 집합에 전반적으로 그 트래픽을 분산해 로드 밸런서가 된다

GWLB Target Groups

• EC2 instances
• IP Addresses

Elastic Load Balancer - Sticky Seesions (Session Affinity)

• 2가지 요청을 수행하는 클라이언트가 요청에 응답하기 위해 백엔드에 동일한 인스턴스를 갖는 것
• CLB와 ALB에서 설정이 가능하다
• 쿠키로 인해 이런 기능을 이용할 수 있는데 쿠키가 만료되면 클라이언트가 다른 EC2 인스턴스로 리다이렉션 된다
• 세션 만료시에는 사용자의 로그인과 같은 중요한 정보를 취하는 세션 데이터를 잃지 않기 위해 사용자가 동일한 인스턴스에 연결된다
• 고정성을 활성화 하면 백엔드 EC2 인스턴스 부하에 불균형을 초래할 수 있다
• 설정 방법은 Target groups > Actions > Edit attributes > Stickiness를 통해 설정 가능하다

Sticky Seesions - Cookie

• Application-based Cookies

  • 대상으로 생성된 사용자의 정의 쿠키로 애플리케이션에서 생성
  • 애플리케이션에 필요한 모든 사용자 정의 속성을 포함할 수 있다
  • 쿠키 이름은 각 대상 그룹별로 개별적으로 지정해야 한다

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

  • 로드 밸런서에서 생성되는 쿠키
  • 특정 기간을 기반으로 만료

Elastic Load Balancer - Cross Zone Load Balancing

• 두개의 AZ에 인스턴스가 불균형하게 존재 해도 트래픽을 모두 균일하게 할당하는 것
• 트래픽을 고르개 분배할 수 있다
• Attributes에서 설정할 수 있다

Cross-zone Load Balancing

• Application Load Balancer
  • ALB는 default로 교차 영역 로드 밸런싱이 활성화 되어 있다
  • 다른 AZ 로 데이터를 옮길 때 비용이 들지 않는다
• Network Load Balancer
  • ALB와 달리 교차 영역 로드 밸런싱이 활성화 되어 있지 않다
  • 활성화 하려면 비용이 든다
• Classic Load Balancer
  • NLB와 마찬가지로 비활성화가 기본이다

SSL/TLS - Basics

• X.509 인증서로도 불림
• AWS에서는 이런 인증서들을 관리 할 수 있는 ACM이라는 서비스가 존재
• SSL 인증서는 클라이언트와 로드 밸런서 사이에서 트래픽이 이동하는 동안 암호화 (in-flight 암호화)
• SSL은 Secure Sockets Layer이며, 연결을 암호화하는데 사용한다
• TLS는 Transport Layer Security이다
• 퍼블릭 인증서는 인증기관(CA)에서 발급
• 퍼블릭 SSL 인증서를 로드 밸런서에 추가하면, 클라이언트와 로드 밸런서 사이의 연결을 암호화 할 수 있다
• SSL인증서는 만료 기간이 존재한다

Load Balancer - SSL Certificates

• 사용자가 HTTPS를 이용해 접속
• Load Balancer가 SSL Termination을 수행
• 백엔드에서는 HTTP로 통신
• VPC로 이동하는 트래픽은 프라이빗 네트워크를 사용하기 때문에 안전하게 보호
• 클라이언트는 SNI (Server Name Indication)을 통해 접속할 호스트의 이름을 알릴 수 있다

SNI - Server Name Indication

• 여러개의 SSL 인증서를 하나의 웹 서버에 로드해 하나의 웹 서버가 여러 개의 웹 사이트 지원을 할 수 있게 해준다
• 클라이언트가 대상 서버의 호스트 이름을 지정하도록 한다 (최초 SSL handshake 단계)
  • 로드 밸런서에게 요청하는 과정도 서버 이름 지정 과정이다
• 클라이언트가 접속할 웹사이트를 말했을 때, 서버는 어떤 인증서를 로드해야 하는지 알 수 있다
• ALB, NLB, CloudFront에서만 동작한다
  • 어떤 로드 밸런서에 SSL 인증서가 여러 개 있다면 ALB나 NLB 둘 중 하나 (Listener에서 추가 가능)

Connection Draining

• Connection Draing - for CLB
• Deregistration Delay - for ALB & NLB
• 인스턴스가 등록 취소, 혹은 비정상인 상태에 있을 때 인스턴스에 어느 정도의 시간을 주어 인-플라이트 요청, 즉 활성 요청을 완료할 수 있도록 하는 기능
• 연결 드레인이 되면 로드 밸런서는 등록 취소 중인 EC2 인스턴스로 새로운 요청을 보내지 않는다
• 값이 0이면 드레인은 일어나지 않는다
• 짧은 요청의 경우 낮은 값으로 설정하는 것이 좋다

Auto Scaling Group

• 웹 사이트나 애플리케이션의 트래픽이 증가하면서 API를 통해 스케일을 자동화 할 수 있다
• scale out / in
• 로드 밸런서와 페어링 하는 경우 ASG에 속한 모든 EC2 인스턴스가 로드 밸런서와 연결된다
• 로드 밸런서는 EC2 인스턴스의 health check결과를 ASG로 전달 할 수 있다
• Activity history에서 변경 사항 등 기록을 확인 할 수 있다

Auto Scaling Group in AWs

• Minimum Capacity - 최소 용량
• Desired Capacity - 희망 용량
• Maximum Capacity - 최대 용량
• 최대 용량 내에서 희망 용량을 더 높은 숫자로 설정하면 scale out

Auto Scaling - CloudWatch Alarms & Scaling

• CloudWatch 경보를 기반(메트릭 정보)으로 ASG를 scale out / in 할 수 있다

Auto Scaling Groups - Dynamic Scaling Policies

• Target Tracking Scaling
  • 모든 EC2 인스턴스에서 ASG의 평균 CPU 사용률을 추적해서 수치가 40% 에 머무르도록 설정
• Simple / Stop Scaling
  • CloudWatch 알람을 기반으로 설정
  • 한번에 추가할 유닛과 삭제할 유닛을 단계별로 설정해야함
• Scheduled Actions
  • 나와 있는 사용 패턴을 바탕으로 스케일링을 예상

Auto Scaling Groups - Predictive Scaling (예측 스케일링)

• 지속적으로 예측을 사용
• 시간에 걸쳐 과거 로드를 분석하고 예측을 생성한다
• 해당 예측을 기반으로 사전에 스케일링 작업이 예약된다

Good metrics to scale on

• CPU Utilization
• RequestCountPerTarget (대상 별 요청 개수 지표)
• Average Network In / Out (평균 네트워크 입출력량)

Auto Scaling Groups - Scaling Cooldowns

• 스케일링 작업이 끝날 때마다 인스턴스의 추가 삭제를 막론하고 5분 혹은 300초의 휴지 기간을 가진다
• 휴지 기간에는 인스턴스의 추가 또는 삭제를 할 수 없다
• 새로운 인스턴스가 안정화 기간을 가질 수 있다
• 인스턴스 구성 시간을 줄여 즉시 적용이 가능하게 하는 것도 좋은 방법이다 (활성화 시간을 단축하는 결과)