AWS SAA : ELB, ASG

Load Balancer

트래픽을 백엔드나 서버셋으로 전달하는 서버

애플리케이션에 DNS를 노출하고, 다운스트림 인스턴스의 장애 해결

사용자는 어떤 인스턴스로 트래픽을 보내는지 확인이 불가

HTTPS 트래픽으로 운영됨

가용성 availability 를 높임

개인 트래픽과 공공 트래픽 분리

 

ELB

관리형 로드 밸런서

EC2 인스턴스로 Health Check 보내고, 응답코드 받아옴

응답코드 200 : 정상

ELB 종류

• Classic Load Balancer (CLB) → HTTP, HTTPS, TCP, SSL, secure TCP
• Application Load Balancer (ALB) → HTTP, HTTPS, WebSocket
• Network Load Balancer (NLB) → TCP, TLS (secure TCP), UDP : 초고성능, 지연 시간 최소
• Gateway Load Balancer (GWLB) → 3 Network Layer, IP Protocol : 보안, 침입 탐지, 방화벽에 특화됨, 네트워크 트래픽 분석을 위한 로드 밸런서

ELB를 둘러싼 보안

• 유저는 HTTP (80), HTTPS (443)를 사용해 어디서든 로드 밸런서 접근 가능

EC2를 둘러싼 보안

• 보안그룹 소스를 ELB로 설정하여 ELB로부터만 접근 가능

Listener rules

기본 규칙 : 모든 요청을 ALB의 타겟 그룹에 보냄

규칙 추가 가능 : 호스트 헤더 / Path / HTTP request method (GET, POST) / Source IP / HTTP header / Query string 의 조건

 

ALB (Application Load Balancer)

HTTP 전용 로드 밸런서 → 마이크로 서비스, 컨테이너 기반 애플리케이션에 적합

머신 간 다수 HTTP 애플리케이션의 라우팅에 사용

로드를 분산 ← 컨테이너, ECS 사용

HTTP/2, Websocket 지원

Redirect 지원

route routing 지원

URL 대상 경로에 기반

URL 호스트 이름에 기반

Query String, Headers 에 기반

대상 그룹 (Target Group)

• EC2 인스턴스 ← 오토 스케일링 그룹으로 매니지됨
• ECS 태스크 ← ECS 그 자체로 매니지됨
• Lambda function ← HTTP Request 가 json event로 변환
• Private IP 주소

application server는 client의 IP를 직접 확인 X

→ 클라이언트 header (X-Forwarded-For)에서 Port, proto, IP 확인 가능

 

NLB (Network Load Balancer)

L4 로드 밸런서. TCP, UDP 트래픽을 다룸.

초당 수백만건의 요청 처리

지연 시간이 짧음

가용 영역별로 하나의 고정 IP를 가짐

Elastic IP 주소를 각 AZ에 할당 가능

여러 개의 고정 IP (정적 IP) 를 가진 애플리케이션을 노출할 때 가능

타겟 그룹

• EC2 인스턴스
• IP 주소 ← 반드시 Private IP 여야하고, 하드코딩되어야 함.
• Application Load Balancer ← ALB의 HTTP 특성과 NLB 의 고정 IP 특성

상태 확인

• TCP 프로토콜
• HTTP 프로토콜
• HTTPS 프로토콜

 

Gateway Load Balancer

배포 및 확장, AWS 의 가상 네트워크 appliance에 사용

모든 트래픽이 방화벽을 통과하게 하거나, 침입 탐지 및 방지에 사용

네트워크 수준에서 해결

1. Users : VPC에서 라우팅 테이블이 업데이트
2. 모든 사용자 트래픽은 GWLB를 통과
3. GLWB는 가상 어플리언스의 대상 그룹 전반으로 트래픽 확산, 도달 후 트래픽 분석 후 처리 (방화벽, 침입 탐지)
4. 만약 트래픽에 이상이 없으면, GWLB로 다시 보냄
5. GWLB에서는 트래픽을 애플리케이션으로 보냄

네트워크 트래픽을 분석

L3 (IP 패킷의 네트워크 레이어)

1. Transparent Network Gateway : 단일 엔트리, 출구
2. Laod Balancer : Virtual Appliance에 traffic을 분산

Use the GENEVE protocol on port 6081

타겟 그룹

• EC2 instances
• IP Addresses (must be private IPs)

 

Sticky Sessions (Session Affinity)

클라이언트가 로드 밸런서에 2가지 이상의 요청을 할 경우, 동일한 인스턴스로 전달

→ 사용자의 로그인과 같은 중요한 세션 데이터를 잃지 않기 위해 사용

CLB, ALB에서 설정

쿠키 ← Sticky Session의 원리. 클라이언트에서 로드 밸런서로 요청할 때 같이 보냄. 쿠키 만료되면, 클라이언트가 다른 인스턴스로 전달됨

1. Application-based 쿠키
   • 애플리케이션 자체에서 기간을 설정 가능
   • 커스텀 쿠키
     • 타겟에 의해 생성됨
     • 애플리케이션에 필요한 모든 사용자 정의 속성 포함
     • 쿠키 이름은 각 대상 그룹별로 개별적으로 지정
       • AWSALB, AWSALBAPP, AWSALBTG ← 사용 불가
   • 애플리케이션 쿠키
     • 로드 밸런서 자체에 의해 생성됨
     • 쿠키 이름 : AWSALBAPP
2. Duration-based 쿠키
   • 로드 밸런서에 의해 생성됨
   • 특정 기간을 기반으로 만료되며, 그 기간은 로드 밸런서 자체에 의해 생성됨
   • 쿠키 이름 : AWSALB (ALB), AWSELB (CLB)

→ 쿠키 이름 몰라도 됨

이로 인해 불균형한 EC2 인스턴스 사용량이 초래될 수도 있음

 

Cross-Zone Load Balancing

두 가용 영역에서 불균형일 경우

Cross zone load balancing을 사용하면, 각각의 로드 밸런서 인스턴스가 모든 가용 영역에 등록된 모든 인스턴스에 부하를 고르게 분배

→ ALB에서 기본으로 설정되어 있음. AZ간 데이터 이동이 무료.

Cross zone load balancing을 사용하지 않으면, 가용 영역 내에서 부하를 알아서 분배함.

→ NLB, GWLB 에서 기본으로 설정되어 있음. 활성화하려면 비용 지불 필요.

 

SSL/TLS 인증서

클라이언트와 로드 밸런서 사이에서 트래픽이 이동하는동안 암호화

in-flight 암호화

송신자와 수신자 측에서만 이를 복화할 수 있음

SSL : 보안 소켓 계층 (Secure Sockets Layer) → 연결 암호화에 사용

TLS : 새로운 버전의 SSL → 전송 계층 보안

요즘에는 TLS가 사용됨.

Public SSL ← CA에 의해 만들어짐

로드 밸런서에 public SSL을 추가하면, 클라이언트와 로드 밸런서 사이의 연결을 암호화할 수 있음

User - (HTTPS : encrypted)→ LB - (HTTP over private VPC) → EC2

SSL 인증서에는 만료 날짜가 있어 이를 주기적으로 관리해야 함

ACM : AWS Certificate Manager ← 인증서 관리

HTTPS Listener

• 기본 인증서 업로드
• 다중 도메인 지원을 위한 인증서 추가클라이언트는 SNI를 사용해 접속할 호스트의 이름을 specify

SNI : Server Name Indication : 서버 이름 지정

• 여러 개의 인증서를 하나의 웹 서버에 로드해, 하나의 웹서버가 여러 개의 웹사이트를 지원할 수 있게 함
• 클라이언트가 대상 서버의 호스트 이름을 지정하도록 함 → 클라이언트가 접속할 웹사이트를 말했을 때, 서버가 어떤 인증서를 로드해야하는지 알 수 있도록.
• ALB, NLB, CloudFront 에서 작동함

 

Connection Draining

CLB → Connection Draining

ALB, NLB → Deregistration Delay

인스턴스가 드레이닝 상태일 때 (등록 취소, 비정상인 상태일 때),

활성 요청이 있을 경우, 인스턴스에 어느 정도의 시간을 주어 완료할 때까지 대기

없을 경우, ELB는 요청을 보내지 않고 다른 인스턴스에 요청을 보냄

 

Auto Scaling Group

스케일 아웃 : 증가한 로드에 맞춰 EC2 인스턴스 추가

스케일 인 : 감소한 로드에 맞춰 EC2 인스턴스 제거

• 최소 및 최대 개수를 설정할 수 있음

로드 밸런서와 페어링하는 경우, ASG에 속한 모든 인스턴스가 로드밸런서에 연결됨

한 인스턴스가 비정상이면 종료하고 이를 대체할 새 EC2 인스턴스를 새로 생성함

ASG 자체는 무료이고, 생성된 하위 리소스(EC2) 에 대한 비용만 지불하면 됨

Launch Template 를 구성하면 됨. (EC2 인스턴스를 시작하는 방법과 유사)

• AMI + Instance Type
• EC2 User Data
• EBS Volumes
• Security Groups
• SSH Key Pair
• IAM Roles for your EC2 instances
• Network, subnet
• Load Balancer Information

Min Size, Max Size, Initial Capacity, Scaling Policies 구성

CloudWatch Alarm & Scaling

: scale out, scale in 정책에 따른 경보에 의해 내부에서 자동으로 스케일링

 

Scaling Policy

• Dynamic Scaling
  • Target Tracking Scaling
    • CPU 사용률과 같은 ASG에 대한 목표 값을 설정
  • Simple / Step Scaling
    • CloudWatch Alarm이 발생할 경우, 추가 혹은 제거
• Scheduled Scaling
  • 알려진 사용 패턴을 기반으로 스케일링을 예측
  • ex. 금요일 오후 사용자가 늘어나므로 매주 금요일 오후 스케일 아웃
• Predictive Scaling
  • 지속적으로 부하를 예측한 다음 미리 예약
  • 반복되는 패턴, 주기적인 데이터가 있을 때 좋음
  • 과거 부하를 분석한 다음 예측치를 생성해 예측치를 기반으로 스케일링 예약

Scaling에 사용하기 좋은 기준 Metric

• CPUUtilization
• RequestCountPerTarget
• Average Network In / Out
• Any Custom metric that you push using CloudWatch

Scaling Cooldown

: 스케일링 액티비티 이후, 쿨다운 시간에 들어감

: 쿨다운동안 ASG는 추가 인스턴스를 개시하거나 삭제하지 않음 ← 매트릭이 안정화되고, 새로운 인스턴스가 적용되어 새로운 매트릭이 어떻게 변화할지 지켜봐야 함