고가용성 및 스케일링성
확장성: 애플리케이션 시스템이 조정을 통해 더 많은 양을 처리할 수 있다는 의미
- 수직 확장성: 인스턴스의 크기를 확장하는 것
- 하위 인스턴스의 유형을 업그레이드해 수직적으로 확장
- 일반적으로 확장할 수 있는 정도에는 (하드웨어 제한) 한계가 있음
- 스케일 업 / 스케일 다운
- 수평 확장성(탄력성): 인스턴스나 시스템의 수를 늘리는 것
- 수평 확장을 했다 = 분배 시스템이 있다
- 스케일 인 / 스케일 아웃
고가용성: 애플리케이션 또는 시스템을 적어도 둘 이상의 AZ나 데이터 센터에서 가동 중
- 데이터 센터에서의 손실에서 생존이 목표
- 다중 AZ가 활성화된 자동 스케일러 그룹이나 로드 밸런서
Elastic Load Balancing (ELB) 개요
로드 밸런서: 트래픽을 백엔드나 다운스트림 EC2 인스턴스 또는 서버들로 전달하는 역할
부하를 다수의 다운스트림 인스턴스로 분산하기 위해 필요함
로드 밸런서가 상태 확인 메커니즘으로 장애가 발생한 인스턴스를 확인하고, 사용 가능한 인스턴스로 부하를 분산시킴
SSL 종료 가능 = HTTPS 트래픽 사용 가능
EC2, ECS, ACM, CloudWatch, Route53, WAF, Global Accelerator 등과 함께 사용 가능
ELB SG로 HTTP, HTTPS를 가능하게 하고, EC2는 ELB만 접근 가능하게 하여 보안성 확보 가능
상태 확인: ELB가 EC2 인스턴스의 작동이 올바르게 되고 있는지의 여부를 확인하기 위해 사용됨
상태 확인은 포트와 라우트에서 이뤄짐
HTTP 상태 코드 200으로 응답하지 않으면 인스턴스가 제대로 작동하지 않는다고 판단함
로드 밸런서 종류
- ALB - HTTP, HTTPS, WebSocket 프로토콜 지원
- NLB - TCP, TLS, secure TCP, UDP 프로토콜 지원
- GWLB - 네트워크 3계층 - IP 프로토콜에서 작동
Application Load Balancer (ALB) 개요
7계층, HTTP 전용 로드 밸런서
- 대상 그룹 간 HTTP 애플리케이션 라우팅에 사용됨
- 마이크로 서비스나 컨테이너 기반 애플리케이션에 적합함 - 포트 매핑 기능
- HTTP → HTTPS로 트래픽 리다이렉트 가능
- 경로 라우팅, URL의 호스트 이름에 기반한 라우팅 지원
- 쿼리 문자열과 헤더(매개변수)에 기반한 라우팅 지원
- 사설(Private) IP 주소 앞에 위치할 수 있음
- 고정 호스트 이름이 부여됨
- 클라이언트의 IP가 로드 밸런스와 직접 통신하고, 로드 밸런스 IP를 통해 애플리케이션 서버와 통신
- 클라이언트의 IP는 X-Forwarded-For 헤더에 삽입됨
Application Load Balancer (ALB) 실습
EC2 인스턴스 > HTTP, SSH 트래픽 허용한 보안그룹 생성 후 해당 보안 그룹으로 EC2 생성
#!/bin/bash
# Use this for your user data (script from top to bottom)
# install httpd (Linux 2 version)
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "<h1>Hello World from $(hostname -f)</h1>" > /var/www/html/index.html
Load Balancer > Application Load Balancer
- Scheme: Internet-facing
- Ip address type: IPv4
- HTTP 트래픽 허용한 보안그룹 생성
- 대상 그룹 생성 > 위에서 생성한 EC2 2개 등록
- Listener HTTP:80 대상 그룹 선택
DNS 이름을 복사해서 로드 밸런서에 연결하면 EC2 인스턴스로 요청을 전송할 수 있음
대상 그룹 > Targets > health check 결과 healthy 확인 가능
네트워크 보안 강화
- Internet > ALB > EC2로 액세스되도록 설정하는 것이 좋음
- EC2 인스턴스 SG의 인바운드 규칙으로 로드 밸런서의 SG만 허용
애플리케이션 로드 밸런서 규칙
- 리스너 규칙을 수정하여 원하는 곳으로 트래픽을 보낼 수 있음
- Condition(조건)으로 Host header, Path, HTTP, Source IP, HTTP header, Query string 선택 가능
- Action으로 조건이 일치하는 경우 전달할 대상을 선택할 수 있음
- target group, URL redirect, 응답 반환이 가능함
Network Load Balancer (NLB) 개요
4계층, TCP와 UDP 트래픽 처리 로드 밸런서
- 높은 성능 - 초당 수백만 건의 요청 처리, 짧은 지연 시간
- 가용 영역당 하나의 고정 IP만 가지며, 탄력적 IP 할당 가능 → 고정 IP로 애플리케이션 노출 시 유용
프론트엔드에서는 TCP 사용, 백엔드에서는 HTTP도 사용 가능
EC2 인스턴스로 구성된 대상 그룹 생성 가능
NLB가 EC2 인스턴스로 리디렉션하여 TCP 또는 UDP 트래픽을 보낼 수 있음
Private IP 주소를 하드 코딩으로 등록할 수도 있음
NLB 뒤에 ALB를 배치하여 고정 IP 주소로 들어오는 HTTP 트래픽 처리 가능
NLB의 상태 검사로는 TCP, HTTP, HTTPS 프로토콜을 지원함
Network Load Balancer (NLB) 실습
Load Balancer > Network Load Balancer
- Scheme: Internet-facing
- Ip address type: IPv4
- 선택한 가용영역마다 AWS로부터 고정 IPv4 주소 할당 - 탄력적 IP 대신 사용 가능
- 보안 그룹 사용 가능 (추천사항, 필수 X)
- Listener에게 TCP, TCP_UDP, TLS, UDP 프로토콜 전송 가능
- NLB의 DNS로 확인 가능
Gateway Load Balancer (GWLB) 개요
GWLB의 기능
- 투명 네트워크 게이트웨이 - VPC의 모든 트래픽이 GWLB가 되는 단일 엔트리와 출구를 통과함
- 로드 밸런서 - 검사를 통과한 트래픽을 대상 그룹의 가상 어플라이언스 집합에 분산시킴
- 네트워크 트래픽 분석에 사용
- 배포, 확장, AWS의 타사 네트워크 가상 어플라이언스의 플릿 관리에 사용됨
- 네트워크의 모든 트래픽이 방화벽을 통과하게 하거나 침입 탐지 및 방지 시스템에 사용됨
- L3 계층에서 실행됨
- 6081번 포트의 GENEVE 프로토콜 사용
- 타사 어플라이언스로는 EC2 인스턴스, IP 주소를 사용할 수 있음
애플리케이션으로 이동하기 전에 모든 트래픽을 검사하려면?
GWLB 생성 시 라우팅 테이블이 업데이트됨
사용자 → GWLB → 가상 어플라이언스의 대상 그룹 전반으로 트래픽 확산, 모든 트래픽이 어플라이언스(방화벽, 침입 탐지)에 도달 → 어플라이언스가 트래픽 분석 및 처리
→ 이상이 있음 → 트래픽 드롭
→ 이상이 없음 → GWLB → EC2(목적지)
Elastic Load Balancer - Sticky Sessions(고정 세션)
- 로드 밸런서에 두 번의 요청을 할 때 백엔드에서 동일한 인스턴스가 요청에 응답하도록 하는 것
- Application Balancer, Network Load Balancer 사용 가능
- 작동 방식: 클라이언트가 로드 밸런서로 요청을 보낼 때 **쿠키(고정 세션, 만료 날짜 포함)**를 전송
- 사용자가 동일한 백엔드 인스턴스에 연결되어 세션 데이터(ex. 사용자 로그인)을 잃지 않음
- 일부 인스턴스에 사용자가 몰리는 경우 백엔드 EC2 인스턴스의 부하가 불균형해질 수 있음
타겟 그룹 > 속성 편집 > 타겟 선택 구성 > 스티키 세션 설정
고정 세션 쿠키
AWSALB, AWSALBAPPOR, AWSALBTG는 예약어이므로 이름으로 사용 X
CloudFront에서 사용됨
- 애플리케이션 기반 쿠키
- 애플리케이션에서 생성하는 사용자 정의 쿠키
- 애플리케이션에서 필요로 하는 모든 사용자 정의 속성을 포함할 수 있음
- 애플리케이션에서 지정한 지속 시간에 따라 만료됨
- 쿠키 이름은 각 타겟 그룹마다 개별적으로 지정
- ALB에서 사용하는 쿠키 이름: AWSALBAPP
- 지속 시간 기반 쿠키
- 로드 밸런서에서 생성하는 사용자 정의 쿠키
- 로드 밸런서에서 지정한 지속 시간에 따라 만료됨
- ALB에서 사용하는 쿠키 이름: AWSALB
Elastic Load Balancer - Cross Zone Load Balancing
각 가용 영역 로드 밸런서 인스턴스가 모든 가용 영역에 등록된 모든 인스턴스에 부하를 고르게 분배
해당 기능을 사용하지 않으면 각 가용 영역 안에서 부하가 분산됨
ALB는 교차 영역 로드 밸런싱이 기본으로 활성화 → AZ 간의 데이터 이동에 비용 X
NLB, GWLB는 교차 영역 로드 밸런싱이 기본으로 비활성화 → AZ 간의 데이터 이동에 비용 O
로드 밸런서 > 속성 > 편집 > 활성화/비활성화 가능
Elastic Load Balancer - SSL 인증서
SSL/TLS
- 클라이언트와 로드 밸런서 사이에서 트래픽이 이동하는 동안 암호화 (전송 중(in-flight) 암호화)
- 데이터는 네트워크를 이동하는 중에는 암호화되고, 송신자와 수신자만 복호화 가능
- SSL: 보안 소켓 계층, 연결을 암호화하는 데 사용함
- TLS: 새로운 버전의 SSL로 전송 계층 보안을 의미함,
- 퍼블릭 인증서는 인증 기관(CA)에서 발급, 만료 날짜가 있으므로 주기적으로 갱신 필요
- 퍼블픽 SSL 인증서를 로드 밸런서에 추가하면, 클라이언트와 로드 밸런서 사이의 연결을 암호화함
- AWS 인증서 관리자(ACM)으로 인증서 관리 가능
사용자가 HTTPS로 접속 → 로드 밸런서 도달 → 로드 밸런서 내부적으로 SSL 종료 수행, 백엔드와 HTTP로 통신
Elastic Load Balancer - SNI
TLS(SSL) 프로토콜의 확장 기능
여러 개의 SSL 인증서를 하나의 웹 서버에 로드해 하나의 웹 서버가 여러 개의 웹 사이트를 지원
= 하나의 IP 주소로 여러 개의 HTTPS 사이트를 운영할 수 있도록 해주는 기술
HTTPS는 TLS 핸드셰이크 초반에 서버 인증서(SSL 인증서)를 먼저 보내는데, SNI는 TLS 핸드셰이크에서 클라이언트가 접속하려는 호스트 이름(도메인)을 서버에 먼저 알려줘서 도메인의 맞는 인증서로 대응할 수 있음
ALB, NLB, CloudFront만 지원함
Elastic Load Balancer - SSL 인증서 실습
Load balancer > 리스너 > 리스너 추가
HTTPS 프로토콜 추가 시 리스너 보안 설정에서 SSL 보안 정책 선택 가능
ACM 혹은 인증서 개인 키, 인증서, 인증서 체인을 붙여넣어 외부에서 가져올 수도 있음
Elastic Load Balancer - 등록 취소 지연
인스턴스가 등록 취소, 혹은 비정상인 상태에 있을 때 인스턴스에 어느 정도의 시간을 주어 활성 요청을 완료할 수 있도록 하는 기능
인스턴스가 드레이닝되면 ELB는 등록 취소 중인 EC2 인스턴스로 새로운 요청을 보내지 않음
연결 드레이닝 파라미터는 1부터 3,600초 사이의 값으로 설정할 수 있으며 기본값은 300초
짧은 요청의 경우에는 파라미터를 낮은 값으로 설정하고, 긴 요청의 경우에는 파라미터를 높은 값으로 설정함
Auto Scaling Group (ASG) 개요
스케일 아웃(증가한 로드에 맞춰 EC2 인스턴스를 추가) 혹은 스케일 인(감소한 로드에 맞춰 EC2 인스턴스를 제거) 기능을 수행함
ASG에서 실행되는 EC2 인스턴스의 최소 및 최대 개수를 보장함
ASG를 로드 밸런서와 페어링하는 경우 ASG에 속한 모든 EC2 인스턴스가 로드 밸런서에 연결됨
인스턴스가 비정상이면 종료하고 이를 대체할 새 EC2 인스턴스를 생성함
인스턴스 속성을 기반으로 ASG를 생성하려면 시작 템플릿을 생성해야 함
스케일링 쿨다운 - 스케일링 작업이 발생한 후에 인스턴스를 추가하거나 제거할 때마다 기본적으로 5분 쿨다운 시간이 발생함. 쿨다운 시간 동안 ASG는 추가 인스턴스를 개시하거나 종료 X.
쿨다운을 통해 메트릭 안정화 및 새로운 인스턴스 적응 시간을 가질 수 있고, 동적으로 확장 및 축소하기 위해서는 쿨다운 시간을 줄이거나 없앨 수 있음
최소 용량, 희망 용량, 최대 용량을 설정할 수 있음
희망 용량에서 트래픽이 증가할 경우 스케일 아웃을 통해 인스턴스가 추가되고, 트래픽이 감소할 경우 스케일 인을 통해 인스턴스가 감소함
최소 용량보다 인스턴스 수가 적어지지 않고, 최대 용량보다 인스턴스 수가 많아지지 않음
또한 일반적인 경우 희망 용량의 인스턴스 개수를 유지함
스케일링 정책은 CloudWatch 경보를 기반으로 ASG를 스케일 인 및 스케일 아웃함
CloudWatch 경보로는 평균 CPU나 사용자 지정 지표를 선택할 수 있음
Auto Scaling Group (ASG) 실습
오토 스케일링 그룹 > 오토 스케일링 그룹 생성 > 시작 템플릿 생성 (머신 이미지, 인스턴스 타입, 키 페어, 네트워크 세팅, 유저 데이터 등) > 로드 밸런서 연결 > 추가 설정(EC2 상태 점검, ELB 상태 점검) > ASG 그룹 크기 설정(최소 용량, 최대 용량, 원하는 용량)
생성한 ASG에 의해 EC2 인스턴스가 생성됨
오토 스케일링 그룹 크기를 편집하여 스케일링을 할 수 있음
ASG를 종료한 뒤 인스턴스를 종료해야 과금을 멈출 수 있음
Auto Scaling Group (ASG) 스케일링 정책
stress를 이용해 테스트 가능
동적 스케일링
- CPU 사용률과 같은 ASG에 대한 메트릭과 목표 값을 정의
- 자동으로 ASG가 확장되거나 축소되어 메트릭을 유지
- CloudWatch alarm을 연동하여 ASG 그룹에 액션이 생기면 알림 발생 추가 가능
예약 스케일링
- 사용 패턴을 기반으로 스케일링을 예상
- ex. 금요일 오후 5시에 매번 새로운 사용자가 발생하므로 최소 용량을 10으로 늘리는 경우
예측 스케일링
- 지속적으로 부하를 예측한 다음 미리 예약을 시작하는 경우
- 자동으로 과거 부하를 분석한 다음 예측치를 생성하여 예측치를 기반으로 스케일링 작업을 예약
- 주기적인 데이터가 있는 경우 매우 유용
스케일링 지표
- CPU 사용률
- 타깃당 요청 수
- 평균 네트워크 업로드/다운로드
Auto Scaling Group (ASG) 스케일링 정책 실습
예약 스케일링
- 희망 용량, 최소 용량, 최대 용량 설정
- 시작 시간, 완료 시간 및 반복 시간 설정 가능
- 사전에 알고 있는 이벤트에 대해서 작업 예약
예측 스케일링
- 머신 러닝 예측을 토대로 스케일링 수행
- CPU 사용률, 네트워크 입출력량, 애플리케이션 로드 밸런서 요청 수를 참고하여 예측 생성
- 예측에 따라 ASG가 스케일링됨
동적 스케일링
- 단순 스케일링 - 경보가 발생했을 때 인스턴스 추가 설정
- 단계 스케일링 - 경보 값을 기준으로 여러 단계를 갖도록 다수의 경보를 설정
- 대상 추적 스케일링 정책 - 정책을 통해 CloudWatch 경보 생성, 경보 발동 시 대상 추적 정책으로 인스턴스 용량 변화