[AWS] Load balancing & Auto Scaling Group

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

1. Scalability

Vertical Scaling(수직 확장)

• 인스턴스의 크기를 키우는 것 : CPU나 RAM 등 리소스를 늘림
• ex) t2.micro -> t2.large
• 확장에 한계가 존재
• 다운타임 발생 : 인스턴스를 중지했다가 재시작 해야 함
• RDS, ElasticCache는 수직 확장이 가능한 서비스

Horizontal Scaling(수평 확장)

• 인스턴스 개수를 늘리는 것
• 분산 시스템에 적합 -> 현대 시스템의 대부분

 

2. High Availability

• 애플리케이션이 최소 2개 이상의 AZ에서 실행되는 것
• 데이터 손실에서 살아남기 위해 사용 : 센터 하나가 멈춰도 계속 동작이 가능하게끔

---

Load balancing

트래픽을 여러 서버에 골고루 분산시켜주는 서비스

 

사용 이유

• 부하를 다수의 다운스트림 인스턴스로 분산시키기 위해
• 애플리케이션에 단일 액세스 지점 노출
• 인스턴스에 정기적으로 헬스 체크 수행
• SSL/TLS 처리 : HTTPS 암호화/복호화를 로드밸런서가 대신 처리
• 쿠키로 정적 분배 적용
• 영역 간 고가용성
• 공용 트래픽과 개인 트래픽 분리

 

Health Checks

• 로드밸런서에서 상태 확인은 매우 중요
• 이를 통해 로드밸런서가 전달하는 트래픽을 처리할 수 있는 인스턴스의 가용성을 파악할 수 있음
• 응답이 200이 아니면 건강하지 않은 것
• 헬스체크는 타겟 그룹 단위로 설정

* 타겟 그룹

EC2 인스턴스들을 논리적으로 그룹화한 것으로 EC2, IP주소, Lambda함수(ALB만 가능), ECS 컨테이너 등이 될  수 있음

 

AWS 로드밸런서 유형

1) Application Load Balancer

• HTTP(Layer 7) 전용 로드밸런서
• URL 경로 기반 라우팅 : /users, /api 등
• 호스트 기반 라우팅 : one.example.com, two/example.com
• 쿼리스트링, Header 기반 라우팅
• 웹소켓, HTTP/2 지원
• 마이크로서비스, 컨테이너(ECS, EKS)에 최적

2) Network Load Balancer

• Layer 4 수준, TCP/UDP 트래픽 처리
• 가용 영역 당 하나의 고정 IP를 가짐
• 탄력적 IP를 각 가용 영역에 할당할 수 있음
• 가장 비싸고 극도로 빠름

3) Gateway Load Balancer

• 배포 및 확장, 3rd party 네트워크 가상 어플라이언스의 플릿 관리에 사용됨
• Layer 3 수준
• IP 패킷 수준에서 동작
• 투명한 네트워크 게이트웨이

 

Sticky Sessions

같은 클라이언트는 항상 같은 인스턴스로 연결 -> 부하 분산을 불균등하게 만들 수 있음

: Classic Load Balancer, Application Load Balancer에서 설정할 수 있음

: 고정 세션에 사용되는 "쿠키"는 클라이언트에서 로드밸런서로 요청의 일부로서 전송되는 것으로 만료 기간을 포함

 

Cross-Zone Load Balancing

여러 AZ에 있는 인스턴스들에게 트래픽을 어떻게 분산할지 결정하는 설정으로 활성화 시, 모든 인스턴스가 균등하게 트래픽을 받음

 

1) ALB

• 기본값 : 활성화
• 비용 : 무료

2) NLB

• 기본값 : 비활성화
• 비용 : 활성화 시 AZ간 데이터 전송 비용 발생

3) GWLB

• 기본값 : 활성화
• 비활성화 불가능

 

SSL & TLS

* SSL : 연결을 암호화하는 데 사용되는 보안 소켓 계층

* TLS : 새로운 버전의 SSL

 

ACM

 

• AWS에는 무료로 SSL 인증서를 관리할 수 있는 서비스인 ACM이 있음
• ACM(AWS Certificate Manager)에는 사용자 지정 인증서를 업로드할 수 있음
• 인증서를 자동 갱신 해줌

 

SNI

• SNI(Server Name Indication)는 여러 SSL 인증서를 하나의 웹 서버에 로드해 하나의 웹 서버가 여러 개의 웹 사이트를 지원할 수 있도록 함
• 확장된 프로토콜로, 클라이언트가 초기 SSL 핸드셰이크 단계에서 대상 서버의 호스트 이름을 지정하게 함

 

Elastic Load Balancers - SSL Certificates

1) CLB

• AWS가 더 이상 권장하지 않는 구세대 로드밸런서
• 하나의 SSL 인증서만 지원
• 여러 인증서로 여러 호스트 이름을 지원하기 위해서는 CLB 자체를 여러 개 사용해야 함

2) ALB

• 여러 SSL 인증서를 사용하는 여러 리스너 지원
• SNI를 사용해 작동

3) NLB

• 여러 SSL 인증서를 사용하는 여러 리스너 지원
• SNI를 사용해 작동

---

Connection Draining

인스턴스가 제거될 때 기존 연결을 안전하게 종료하는 기능

인스턴스가 등록 취소, 혹은 비정상적인 상태에 있을 때 인스턴스에 어느 정도 시간을 주어 활성 요청을 완료할 수 있도록 함

= 종료 요청이 와도 남아있는 요청이 있으면 다 처리하고 죽는다고 생각하면 됨

 

> CLB : Connection Draining

> ALB & NLB : Deregistration Delay(등록 해제 지연)

---

Auto Scaling Group

트래픽에 따라 EC2 인스턴스 개수를 자동으로 늘리거나 줄이는 서비스

 

• 부하 증가에 따라 EC2 인스턴스를 추가해 스케일 아웃
• 부하 감소에 따라 EC2 인스턴스를 제거해 스케일 인
• 최소 및 괴대 실행 중인 EC2 인스턴스 수 보장
• ASG는 무료

 

Auto Scaling Group in AWS

 

CloudWatch Alarms & Scaling

• ASG를 CloudWatch 경보에 기반해 스케일 인 및 스케일 아웃할 수 있음
• 경보는 지표를 모니터링 함

---

Auto Scaling Policies

언제 어떻게 인스턴스를 늘리고 줄일지 결정하는 규칙

 

1) Dynamic Scaling Polices : 동적 확장

Target Tracking Scaling

• 목표값을 정하면 알아서 조정해줌 -> AWS가 알아서 계산해서 조정
• 설정이 매우 간단

 

Step Scaling

• 세밀한 제어 가능 -> 각 step이 독립적으로 작동
• 급격한 변화에 빠르게 대응
• CloudWatch Alarm 여러 개 필요, 설정이 복잡

 

Simple Scaling

• 알람 하나당 액션 하나
• Cooldown 기간 동안 다른 스케일링 불가 -> 스케일링 액션 하나 후 무조건 전체 대기
• Step Scaling보다 느리고 요즘은 잘 안 씀

 

2) Scheduled Scaling : 예약 확장

• 미리 정해진 시간에 확장 및 축소
• 예측 가능한 트래픽 패턴
• 특정 이벤트 대비 시 사용

 

3) Predictive Scaling : 예측 확장

• 머신러닝으로 미래 예측해서 미리 준비
• 트래픽 도착 전에 미리 준비
• 지연 시간 없음
• 반복되는 패턴에 효과적

---

Cooldown Period(휴지 기간)

스케일링 활동이 발생한 후, 쿨다운 기간에 진입 -> 기본값 300초

쿨다운 기간 동안 ASG는 추가 인스턴스를 실행 또는 종료할 수 없음

---

Warm-up Time(준비 시간)

새 인스턴스가 트래픽 받을 준비되는 시간

Warm-up 시간 동안에는 지표 계산에서 제외되므로 정확한 스케일링 판단이 가능