AWS Cloud Practitioner - Load Balancer, Auto Scaling

1. 시스템 아키텍처

• 확장성(Scalability)
  • 수직적 확장
    • 자원을 추가하는 방식
    • 시스템이 종료된 상태이어야만 가능
    • EC2 인스턴스를 t2.mirco에서 더 큰 사양의 t2.large로 변경하는 것
  • 수평적 확장
    • 노드를 추가하는 방식
    • EC2 인스턴스 개수를 늘리는 것
    • 탄력성이라고도 함
    • 주로 애플리케이션의 확장 방법으로 사용되며, 시스템을 종료하지 않아도 확장 가능

• 고가용성(High Availability)
  • 지속적으로 사용 가능한 상태를 구축하는 것
  • AWS에서는 여러 가용영역(데이터센터)에 시스템을 분산 배치하는 방법을 고가용성 설계라고 함

• 느슨한 결합(Loosely Coupled)
  • 한 시스템의 상태가 다른 쪽에 영향을 덜 미치는 결합
  • 반대 개념으로는 Tightly Coupled가 있음

2. Elastic Load Balancing (ELB)

2-1. Load Balancer의 개념

• 로드밸런서는 네트워크 트래픽을 분산하는 aws의 서비스
• 네트워크 트래픽이 로드밸런서를 거치면서 EC2 인스턴스, 컨테이너, IP 주소 등 여러 대상으로 자동으로 분산된다.
• 로드밸런서가 비정상적인 대상을 감지하면, 해당 트래픽으로 라우팅을 중단하고, 정상적인 대상으로만 트래픽을 라우팅한다.

2-2. Elastic Load Balancer 종류

• Application Load Balancer
  • Layer 7(애플리케이션 계층)
  • 주로 HTTP, HTTPS 관한 작업 처리
  • HTTP Header Contents를 사용해 라우팅 처리
  • 웹 애플리케이션이나 서비스에 적합
• Network Load Balancer
  • Layer 4(전송 계층)
  • TCP, UDP, TLS 관한 작업 처리
  • Protocol, Port Number를 사용해 라우팅 요청 처리
  • 대용량 트래픽 처리에 적합
• Gateway Load Balancer
  • Layer 3(네트워크 계층), 로드밸런서의 엔드포인트로활용
  • Layer 4(전송 계층)
  • GENEVE protocol을 사용하며, encapulation하여 트래픽 전송
  • Transparency한 네트워크 게이트웨이를 제공하므로 원본 패킷의 데이터가 중요한 가상어플라이언스에 적합
• Classic Load Balancer(이전 세대)
  • Layer 4,Layer 7
  • HTTP, HTTPS, TCP, TLS
  • Protocol, Port Number를 사용해 라우팅요청 처리
  • 이전 세대 EC2-Classic 네트워크에서 사용

2-3. Elastic Load Balancer 구성(GWLB 제외)

• Listener
  • 구성한 프로토콜 및 포트를 사용하여 트래픽이 올바르게 전달되었는지 확인하는 기능
  • 리스너에 정한 규칙에 따라 로드밸런서가 대상 그룹에서 대상으로 라우팅 하는 방법이 결정됨
  • 클라이언트와 대상간의 연결을 위한 프로토콜 및 포트번호 설정으로 구성됨
• Target Group
  • 로드밸런서에서 전송된 트래픽의 목적지
  • Target Group이 될 수 있는 Target은
    • EC2 인스턴스
    • EC2 Auto Scaling Group
    • IP address
    • Lambda
    • Application Load Balancer

2-4. Application Load Balancer 실습

• 로드밸런서 대상그룹 생성
  
• 로드밸런서 리스너 설정후 대상그룹 연결
  
• 로드밸런서 연결 확인
  
  -> 새로고침 시 ip가 변경되는 모습

3. Auto Scaling

3-1. Auto Scaling의 개념

• 애플리케이션 수요에 따라 EC2 인스턴스를 자동으로 축소하거나 확장하는 기능
• 사용자가 정의한 조정 정책에 따라 인스턴스가 확장되거나 축소됨
• 디폴트 값으로 EC2 인스턴스 수를 지정해두고, 조정 정책이나 예약된 작업이 없는 경우 이 인스턴스 수를 유지

3-2. Auto Scaling 장점

• 수요에 따라 EC2 인스턴스를 자동으로 확장 or 축소하므로 비용 절감
• 수동으로 EC2 용량을 프로비저닝 할 필요가 없음
• 손상된 EC2 인스턴스를 탐지하여 자동으로 교체 해줌
• 여러 가용 영역을 사용하도록 구성하여 하나의 가용영역이 사용 불가 상태가 되면 다른 가용 영역에서 새 인스턴스를 시작
  
  
  프로비저닝의 의미?
  -> 프로비저닝(provisioning)이라는 용어는 필요한 IT리소스를 준비하고 설정하는 과정
  쉽게 말하면, 클라우드 서비스에서 리소스를 필요한 만큼 제공 하거나 사용 가능 하도록 준비하는 것을 일컫는다.

3-3. Auto Scaling 구성요소

• 오토 스케일링 그룹
  -> EC2의 인스턴스 그룹
• 시작 템플릿(런치 템플릿)
  ->EC2 서버를 시작하기 위한 AMI, 인스턴스 유형 정보를 가진 템플릿
• 조정 옵션(조정 정책)
  -> Auto Scaling을 실행하기 위한 조건

3-4. Auto Scaling 조정정책

• 항상 현재 인스턴스 수준 유지
  • 지정된 수의 실행 인스턴스를 항상 유지하도록 Auto Scaling그룹을 구성
  • 인스턴스가 비정상 상태임을 확인하면 해당 인스턴스를 종료한 뒤 새 인스턴스 시작
• 수동 조정
  • 자동화 정책 없이 최대, 최소 또는 원하는 용량의 변경 사항만 지정하는 경우 사용
• 일정을 기반으로 조정
  • 확장 작업이 시간 및 날짜 함수에 따라 자동으로 수행
• 온디맨드 기반 조정
  • 수요 변화에 맞춰 Auto Scaling 그룹의 크기를 동적으로 조정
    • 대상 추적 조정(Target Tracking Scaling)
      -> 지정한 목표가 목표값을 초과할 때 한해서 Auto Scaling 그룹을 확장하는 방식, CPU 평균 사용률, 네트워크 인터페이스에서 송/수신한 평균 바이트 수, 로드밸런서 요청 수 등의 지표를 사용 가능
    • 단계 조정(Step Scaling)
      -> CloudWatch alarm의 지표를 기반으로 Auto Scaling 그룹을 확장하는 방식, 크기 조정 활동이 시작된 후 정책은 크기 조정 활동 또는 상태 확인 교체가 완료되고 휴지 기간(Cooldown Period)이 끝날 때 까지 기다린 후 추가 경보에 응답
    • 단순 조정(Simple Scaling)
      -> 단계 조정과 방식은 동일, 차이점은 크기 조정 활동 또는 상태 확인 교체가 진행 중인 동안에도 정책이 추가 경보에 계속 응답
• 예측 조정 사용 (Predictive Scaling)
  • 머신 러닝을 사용하여 CloudWatch의 기록 데이터를 기반으로 용량 필요량을 예측

휴지 기간(Cooldown Period)이란?
-> 오토스케일링 정책에 따라 인스턴스가 확장되거나 축소된 후 오토스케일링 그룹을 안정상태로 돌아가기 위해 설정한 기간
상태 확인 교체란?
-> 상태 확인(Healt Check)결과 비정상적인 인스턴스를 제거하거 새 인스턴스를 추가하는 작업