Share
Sign In
ELB & ASG
기본 개념
확장성
수직 확장성: 단일 컴퓨터의 성능을 늘리고 줄이는 것 (scale up / down)
수평 확장성: 컴퓨터의 수를 늘리고 줄이는 것 (scale out / in)
가용성
데이터 센터가 여러 군데 있어 한 쪽이 무너져도 서비스는 무사히 운영될 수 있는 것
Elastic Load Balance (ELB)
로드 밸런스(부하 분산)는 서버에 오는 트래픽을 적절히 분산시켜 부하를 줄이는 것을 말한다. 인스턴스의 입장에서는 외부에 자신을 노출할 필요 없이 로드 밸런서에서 오는 트래픽만 처리하면 되기 때문에 보안에 매우 유리하다. ELB는 AWS에서 제공하는 로드 밸런서라 생각하면 된다.
Health Check: 로드밸런서는 자신에게 연결된 인스턴스가 살아 있는지 확인해야 한다. 주기적으로 물어보고 살아 있는 인스턴스에게만 트래픽을 준다.
Class Load Balancer - 옛날에 쓰던 거
Application Load Balancer - L7 HTTP, HTTPS, WebSocket
Network Load Balancer - L4 TCP, TLS, UDP
Gateway Load Balancer- L3 IP Protocol
Classic Load Balancer (CLB)
TCP (L4)와 HTTP & HTTPS (L7)를 지원하고 TCP나 HTTP로 health check한다. 고정된 호스트 네임을 가진다.
Application Load Balancer (ALB)
L7 (HTTP) 로드 밸런서이다. Docker 컨테이너처럼 같은 머신의 여러 어플리케이션에 로드 밸런싱할 수 있고, 또 Web Socket도 지원한다. ALB는 URL을 분석해서 라우팅하기 때문에 마이크로 서비스나 컨테이너 어플레이션에 사용하는 것이 유리하다.
ALB는 대상 그룹(Target group)으로 서비스를 묶어 로드 밸런싱한다. 이 그룹에는 EC2 인스턴스, ECS tasks, 람다 함수, (사설) IP 주소가 속한다. health check는 타겟 그룹별로 이루어진다. 인스턴스는 로드 밸런서에서 오는 트래픽만 받기 때문에 실제 어디서 보냈는지는 알지 못한다. 그래서 X-Forwarded-For란 헤더를 만들어 클라이언트의 IP를 넣어준다. (-Port, -Proto)도 있다.
Network Load Balancer (NLB)
L4 (TCP & UDP) 로드 밸런서이다. 낮은 단에서 수행하므로 성능이 매우 좋다. NLB는 AZ 당 하나의 고정 IP가 있으며 Elastic IP를 지원한다. 트래픽을 EC2 인스턴스, 람다 함수, IP 주소, 혹은 ALB로 보낼 수 있다. IP 주소는 AWS 밖의 개인 서버를 로드 밸런싱 할 수 있음을 의미한다.
NLB는 ALB와는 다르게 클라이언트의 IP가 그대로 보내진다.
Gateway Load Balancer (GWLB)
모든 트래픽을 중간에서 검사하고 싶으면 어떻게 해야 할까? 트래픽을 중간에서 낚아채 검사를 하고 정상적인 트래픽만 목적지로 보내는 역할을 하는 것이 GWLB이다. GWLB와 외부 검사 어플리케이션과는 6081 GENEVE 포트로 통신한다. 또한 L3에서 동작하며 아래 기능이 결합했다.
Transparent Network Gateway - 모든 트래픽의 진입점을 하나로 만듬
Load balancer - 트래픽을 적절히 분산함
대상 그룹에는 EC2 instances, IP 주소가 포함될 수 있다.
Sticky Session
API를 요청할 때마다 다른 서버로 로드 밸런싱 된다면 로그인이 유지되지 않을 것이고 연속적인 작업이 불가능할 것이다. 이를 해결하기 위해 첫 연결 때 세션을 구축하여 같은 서버에서 일을 처리하도록 한다. 이때 '쿠키'를 쓴다.
어플리케이션 기반 쿠키
커스텀 쿠키 - 타겟(서버)이 직접 만들고 각 타겟 그룹별로 지정되어 있다. 단, AWSALB, AAWSLABAPP, AWSALBTG은 예약되어 있기 때문에 쓰면 안된다.
어플리케이션 쿠키 - 로드 밸런서가 만들고 AWSALBAPP을 이름으로 한다.
기간 기반 쿠키 - 로드 밸런서가 만들고 일정시간만 유지한다. AWSALB(ALB 용), AWSELB(CLB 용)를 이름으로 한다.
Cross-Zone Load Balancing
이 사진의 경우에는 어떻게 트래픽을 분산해야 할까? 최상위의 ELB는 아래 몇 개의 인스턴스가 있는지 알지 못 하기 때문에 그냥 AZ별로 50대 50으로 보내줄 것이다. 반면, Cross-Zone Load Balancing은 아래 인스턴스의 수에 대항에서 트래픽을 보내준다.
SSL/TLS
SSL(Secure Sockets Layer) 인증은 중간에서 트래픽을 읽을 수 없게 암호화하는 기술이다. TLS(Transport Layer Security)는 SSL을 발전시킨 기술이며 현재 가장 많이 쓰지만, 그냥 퉁쳐서 SSL로 표현한다. 공인 SSL은 인증 기관에서 발급한다.
로드 밸런서는 클라인언트와 서버의 중간에서 SSL 인증을 관리하고 암호화되었음을 보장한다. 로드 밸런서는 X.509 인증을 사용하며 ACM(AWS Certificate Manager)를 통해 인증들을 관리할 수 있다. 또한 SNI(Server Name Indicator)을 통해 어떤 도메인에 어떤 SSL 인증을 해주어야 하는지 관리할 수도 있다. 다만 CLB에서는 SSL 인증서 하나밖에 사용하지 못 한다.
Connection Draining
최근에는 Deregistration Delay라고 부른다. 어떤 인스턴스가 Unhealthy해지면 그쪽으로는 트래픽을 보내면 안된다. 하지만 아직 Connection이 남은 트래픽의 경우에는 몇 초 정도 요청을 마무리할 시간을 준다. 이것이 Connection Draining이다. 이때는 새로운 트래픽은 들어가지 않고 설정에 따라 0(disabled)~3600초까지 시간을 줄 수 있다.
Auto Scaling Group(ASG)
들어오는 트래픽의 양에 따라 수평 확장(scale in/out)해주는 기술이다. 최대 최소 인스턴스 수 사이에서 유동적으로 인스턴스의 수를 변화시킨다. 이 그룹을 로드 밸런서에 넣어 확장성을 보장한다. ASG에 IAM Role을 할당해면 ASG에 포함되는 모든 인스턴스에 자동으로 할당할 수 있다. 또한 한 인스턴스가 죽어도 ASG가 알아서 새로운 인스턴스를 만든다.
스케일 정책
수동 조정 - 직접 조정한다.
동적 조정 - 대상 추적 조정 (Target Tracking Scaling) - 간단하게 ASG 자체에서 지원하는 정책, "평균 CPU 사용률 40% 유지"
동적 조정 - 단순 조정(Simple Scaling)- CloudWatch를 사용, 조건 하나만 가능, "CPU > 40%면 2개 추가" 등
동적 조정 - 단계 조정(Step Scaling) - CloudWatch를 사용, 조건들의 범위를 나눠 설정 가능, "CPU > 40%면 2개 추가", "CPU < 30%면 하나 제거"
예약 조정(Scheduled Actions) - 특정 시간대에 특정 명령을 걸어둠
예측 조정(Predictive Scaling) - ML을 이용해 과거 데이터를 비교해 알아서 조정해준다.
Auto Scaling Alarms: AWS CloudWatch를 통해 인스턴스들의 상태를 분석해서 확장할지 축소할지 판단하고 명령한다. 이때 판단 근거로는 CPU 사용량, 요청 수, 네트워크 트래픽 양 등이 있다.
지표(Metric) 유형
CPUUtilization: 평균 CPU
RequestCountPerTarget: EC2 당 요청수
Avergage Network In / Out: 들어오고 나가는 트래픽의 양
Any Custom metric: CloudWatch를 통해 다양하게 만들 수 있다.
조정 휴지 (Scaling Cooldowns)
Scaling 활동(명령)이 있고 300초 동안 cooldown period를 둔다. 이 기간 동안에는 어떤 인스턴스도 시작/종료되지 않고, 활동의 근거와 지금의 지표가 일치하는지 확인한다. 일치한다면 scaling을 진행하고 아니라면 무시한다. 이 과정을 두는 이유는 CPU < 30%로 관측되어서 인스턴스 축소를 명령했지만, 그냥 순간적으로 변했을 수도 있기 때문이다.
ASG 기본 종료 정책
1.
인스턴스의 수가 가장 많은 AZ를 선택한다.
2.
가장 오래된 템플릿을 가진 인스턴스를 삭제한다.
3.
청구 시간이 가장 가까운 인스턴스를 삭제한다.
수명 주기 후크 (Lifecycle Hooks)
인스턴스가 실행되거나 종료되기 전에 특정한 행동을 수행하게 할 수 있다.
시작 템플릿(Launch Template) vs 시작 구성(Launch Configuration)
시작 구성은 레거시다. 시작 템플릿만 알아보자
여러 버전을 가질 수 있다.
재사용, 상속 가능하도록 부분별로만 변경할 수도 있다 (parameters subsets)
On-demand와 스팟 인스턴스 둘 다를 가지고 프로비저닝할 수 있다.
T2 무제한 기능을 사용할 수 있다.
(SAP) 스케일 프로세스
Launch
Terminate
HealthCheck
ReplaceUnhealthy
AZRebalance - AZ별 EC2 수 조정
AlarmNotification
ScheduledActions
AddToLoadBalancer
InstanceRefresh - 오래된 거 지우고 새 거 추가
실습
참고. Amazon Linux 2 Stress Test
# stress install
sudo amazon-linux-extras install epel -y
sudo yum install stress -y
# stress --cpu (cpu 갯수) --timeout (초)
stress --cpu 2 --timeout 60