ELB / ASG
고가용성 및 확장성
수직적 확장 vs 수평적 확장
수직적 확장은 EC2 인스턴스의 사양을 높이는 것으로, t2.nano(0.5G RAM + 1 vCPU) 부터 시작해 u-t12tb1.metal(12.3TB RAM + 448 vCPUs) 까지 올릴 수 있다.
수평적 확장은 동일한 사양의 EC2 인스턴스의 개수를 늘리는 것이다.
고가용성
두 개 이상의 AZ 혹은 데이터 센터에서 동일한 애플리케이션이 가동중이어야 고가용성이 보장된다.
보통 수평적 확장으로 보장된다.
ELB
Elastic Load Balancer
AWS가 업그레이드와 유지보수 및 고가용성을 책임진다.
로드밸런서 동작 방식을 설정할 수 있는 knobs를 제공한다.
EC2 인스턴스가 올바르게 동작하는지 여부를 헬스 체킹하여 정상 인스턴스로만 트래픽을 전달한다.
헬스 체크는 port와 route를 통해 이뤄진다.
내부 용도의 로드밸런서와 외부 공개 용도의 로드 밸런서를 각각 제공한다.
EC2 인스턴스는 로드밸런서로부터 온 트래픽을 처리하기 위해 EC2의 보안 그룹을 로드밸런서의 보안 그룹으로 연결한다.
4가지 종류의 로드밸런서를 제공한다.
CLB
Classic Load Balancer
HTTP, HTTPS, TCP, SSL
ALB
Application Load Balancer
HTTP, HTTPS, WebSocket
NLB
Network Load Balancer
TCP, TLS, UDP
GWLB
Gateway Load Balancer
3계층 IP 프로토콜
ALB
7계층 HTTP/HTTPS 애플리케이션을 위한 로드밸런싱을 제공한다.
머신 간 다수 HTTP 애플리케이션의 라우팅에 사용된다. 머신은 대상 그룹으로 묶인다.
대상(target) 그룹
다음과 같은 리소스들을 하나의 그룹으로 묶어 로드밸런서에 등록할 수 있다.
EC2 인스턴스 (ASG에 의해 관리될 수 있다.)
ECS 태스크
람다 함수
사설(내부) IP 주소
여러 대상 그룹으로 라우팅할 수 있으며 헬스 체크는 대상 그룹 단위로 이뤄진다.
고정 호스트 이름이 부여된다.
실제 요청을 보낸 클라이언트의 IP는 X-Forwarded-For 헤더에 삽입된다. Port는 X-Forwarded-Port, 프로토콜은 X-Forwarded-Proto에 삽입된다.
컨테이너와 ECS를 사용해 동일 EC2 인스턴스 상의 여러 애플리케이션에 부하를 분산한다.
HTTP/2와 WebSocket을 지원한다.
리스너 규칙
URL 기반 리다이렉트를 지원한다. HTTP에서 HTTPS로 리다이렉트할 수도 있다.
URL 경로, hostname, query string, header 등을 기준으로 하여 서로 다른 대상 그룹에 라우팅할 수 있다.
마이크로서비스나 컨테이너 기반 애플리케이션을 사용할 경우 URL 경로를 기반으로 처리할 대상 그룹을 지정할 수 있다.
고정된 HTTP 응답을 반환할 수 있다.
리스너 규칙의 우선순위를 지정할 수 있다.
포트매핑 기능이 있어 ECS 인스턴스의 동적 포트로 리다이렉트할 수 있다.
보안 그룹
EC2의 보안 그룹 설정을 로드밸런서의 트래픽만 허용하도록 수정해주어야 한다.
로드밸런서의 보안 그룹을 Source로 설정하면 된다.
NLB
4계층 TCP/UDP 로드밸런싱을 제공한다.
초당 수백만건의 요청을 처리한다.
지연이 매우 적다.
기본적으로 가용 영역 당 하나의 고정 IP를 AWS로부터 부여받는다. 혹은 각 가용 영역에 Elastic IP를 할당할 수 있다.
따라서 일부 IP로만 네트워크 로드밸런서에 접근 가능하게 된다.
대상(target) 그룹
다음과 같은 리소스들을 하나의 그룹으로 묶어 로드밸런서에 등록할 수 있다.
EC2 인스턴스
사설(내부) IP 주소
애플리케이션 로드 밸런서
헬스 체크 시 TCP, HTTP, HTTPS 프로토콜을 사용할 수 있다.
인스턴스 ID를 이용하여 대상을 명시하면, 인스턴스의 기본 네트워크 인터페이스에 명시된 기본 사설 IP 주소를 이용하여 트래픽을 라우팅한다.
IP 주소를 이용하여 대상을 명시하면 하나 이상의 네트워크 인터페이스에서 온 사설 IP 주소를 이용해서 인스턴스로 트래픽을 라우팅할 수 있다. 각 네트워크 인터페이스는 각자의 보안 그룹을 가질 수 있다. 로드 밸런서는 데이터 패킷의 출발지/목적지 IP 주소를 자신의 것으로 바꾼 후 타깃 인스턴스 혹은 사용자에게 전달한다.
GWLB
배포 및 확장, AWS의 타사 네트워크 가상 어플라이언스의 플릿 관리에 사용된다.
모든 트래픽이 방화벽을 통과하게 하거나 침입 탐지 및 방지 시스템에 사용한다.
IDPS나 심층 패킷 분석 시스템 또는 일부 페이로드를 네트워크 수준에서 수정하는 기능을 제공할 수 있다.
트래픽이 애플리케이션에 도달하기 전에 EC2 인스턴스와 같은 타사 가상 어플라이언스를 배포했고 트래픽의 애플리케이션에 도달 전에 트래픽을 통과하기 위해 사용된다.
GWLB를 생성하면 VPC에서 라우팅 테이블이 업데이트된다.
라우팅 테이블을 기반으로 모든 사용자 트래픽은 GWLB를 통과한다.
GWLB는 가상 어플라이언스의 대상 그룹 전반으로 트래픽을 확산한다.
모든 트래픽은 어플라이언스에 도달하고 어플라이언스는 트래픽을 분석하고 처리한다.
이상이 없으면 트래픽을 다시 GWLB로 보내고, 이상이 있으면 트래픽을 드롭한다.
GWLB는 살펴봤었던 모든 로드 밸런서보다 낮은 수준인 네트워크 3계층에서 수행된다.
기능
투명한 네트워크 게이트웨이
VCP의 모든 트래픽이 하나의 GWLB를 통과한다.
로드밸런서
대상 그룹의 가상 어플라이언스 집합에 트래픽을 분산한다.
6081번 포트의 GENEVE 프로토콜을 사용하면 된다.
대상(target) 그룹
다음과 같은 리소스들을 하나의 그룹으로 묶어 로드밸런서에 등록할 수 있다.
EC2 인스턴스
자체 네트워크나 자체 데이터 센터에서 실행된 가상 어플라이언스의 사설(내부) IP 주소
세션 기능
Sticky Session
한 사용자가 여러 번 요청을 보냈을 때 늘 동일한 인스턴스에 요청을 보내도록 하는 기능을 제공한다.
ALB, NLB에서 동작 가능하다.
쿠키에 매핑 정보와 만료 날짜를 담아 Sticky Session 용도로 사용한다.
쿠키가 만료되면 다른 인스턴스로 요청이 갈 수 있다.
쿠키 유형
애플리케이션 기반 쿠키
애플리케이션 자체에서 생성하는 사용자 정의 쿠키
사용자 정의 속성들을 담을 수 있다.
쿠키 이름을 각 타겟 그룹마다 개별적으로 지정해야 한다.
AWSALB,AWSALBAPPOR,AWSALBTG를 쿠키 이름으로 사용하면 안된다.
지속 시간 기반 쿠키
로드밸런서에서 생성하는 쿠키
쿠키 이름은 ALB에서 생성할 경우
AWSALB, CLB에서 생성할 경우AWSELB가 된다.sticky session 만료 시간을 지정할 수 있다.
Cross-Zone Load Balancing
여러 AZ에 로드밸런싱할 경우 로드밸런서 인스턴스가 AZ마다 존재하고, 각 로드밸런서 인스턴스에는 요청이 고르게 들어온다.
하나의 로드밸런서 인스턴스가 동일 AZ에 있는 EC2 인스턴스에만 트래픽을 분배하고 각 AZ에 존재하는 인스턴스의 개수가 서로 다르다면, 하나의 EC2 인스턴스 당 받아들이는 요청이 특정 AZ에서 높아질 수 있다.
교차 영역 로드밸런싱은 이러한 불균형을 막기 위해 하나의 로드밸런서 인스턴스가 모든 EC2 인스턴스로 트래픽을 균등하게 분배한다.
일반적으로 AWS에서 데이터가 다른 AZ로 넘어가면 비용이 발생되는데, 로드밸런서가 다른 AZ로 트래픽을 보내기 때문에 비용이 발생될 수 있다.
ALB의 경우 기본적으로 이 옵션이 활성화되어 있으며, managed service이기 때문에 데이터가 다른 AZ로 넘어가는 것에 대한 비용은 부과되지 않는다. 대상 그룹마다 활성화/비활성화할 수 있다.
NLB, GWLB의 경우 이 옵션을 활성화하면 비용이 발생된다.
SSL
사용자가 HTTPS를 통해 로드밸런서에 연결하면 로드밸런서는 SSL 종료를 한다.
로드밸런서와 EC2 인스턴스가 통신 시에는 VPC(Virtual Private Network)를 통해 전송되므로 HTTP를 이용한다.
로드 밸런서는 SSL 혹은 TLS 서버 인증서라 불리는 X.509 인증서를 로딩한다. AWS에서는 ACM을 활용해 SSL 인증서를 관리한다.
HTTPS 리스너 설정
기본 인증서를 지정해야 한다.
인증서 목록을 추가해 여러 도메인을 지원할 수 있다
HTTPS에 특정 보안 정책을 설정해서 SSL과 TLS의 구버전(legacy clients)을 지원할 수도 있다.
SNI(Server Name Indication)
TLS 초기 단계에 접근하려는 호스트 이름(도메인)을 지정한다.
하나의 웹 서버에 여러 SSL 인증서를 로드해 웹 서버가 여러 웹사이트를 지원하게 만든다.
클라이언트가 초기 SSL 핸드셰이크에서 대상 서버의 호스트 이름을 표시해야 하는 새로운 프로토콜이다.
서버는 사용자 요청에 담긴 호스트 이름에 매칭되는 인증서를 찾는다.
ALB, NLB, CloudFront 에서만 사용할 수 있다.
Connection Draining (Deregistration Delay)
인스턴스가 등록 취소, 혹은 비정상인 상태에 있을 때 인스턴스에 어느 정도의 시간을 주어 in-flight 요청을 완료할 수 있도록 한다.
인스턴스가 드레이닝되면 ELB는 등록 취소 중인 EC2 인스턴스로 새로운 요청을 보내지 않는다.
EC2 인스턴스에 이미 연결된 유저는 드레이닝 시간을 통해 기존 연결 및 기존 요청을 완료할 수 있다.
만약 새로운 유저가 ELB에 연결하려고 하면 ELB는 드레이닝 상태의 인스턴스를 제외한 나머지 인스턴스에 요청을 전달한다.
1부터 3,600초 사이의 값으로 설정할 수 있다. 기본적으로는 300초(5분)이다. 값을 0으로 설정하면 드레이닝 기능을 비활성화할 수 있다.
짧은 요청의 경우에는 낮은 값으로 설정하고, 요청 시간이 긴 경우 높은 값으로 설정한다.
ASG
Auto Scaling Group
부하에 따라 EC2 인스턴스의 개수를 자동으로 늘리고 줄이는 기능을 제공한다. (Scale Out/In)
ASG 생성 시 스케일링 할 때 변경될 최소 및 최대 EC2 인스턴스 수, 현재 생성할 EC2 인스턴스 수를 지정할 수 있다.
ASG 단위로 로드 밸런서에 연결할 수 있어 편리하다.
특정 인스턴스가 비정상이면 종료하고 새 EC2 인스턴스를 만들어 대체할 수 있다.
오토 스케일링 그룹은 무료이며, 그 아래에 생성되는 EC2 인스턴스와 같은 리소스에 대해서만 비용을 내면 된다.
ELB에서 상태 확인 기능으로 EC2 인스턴스의 상태도 점검하여 ASG에 전달할 수 있다.
CloudWatch 알람을 기반을 ASG에서 스케일 인, 스케일 아웃을 할 수 있다. 평균 CPU 지표나 원하는 사용자 지정 지표를 기준으로 알람을 설정하면 해당 알람이 발동될 때 스케일링된다.
스케일링 정책
동적 스케일링
Target Tracking 스케일링
설정이 매우 간단하다.
예를 들면, CPU 사용률이 평균 40% 정도에 머물도록 조건을 정의해 ASG가 자동으로 스케일링되도록 할 수 있다.
Simple/Step 스케일링
CloudWatch 알람을 정의하여, 알람을 기반으로 오토 스케일링 그룹에 용량 단위를 추가하거나 제거하도록 한다.
예약 스케일링
이미 잘 알고 있는 사용 패턴을 기반으로 스케일링을 예상할 수 있을 때 적합하다.
예측 스케일링
과거 부하 패턴을 활용해 부하를 예측한 다음 스케일링을 예약하는 방식이다.
주기적이고 반복되는 패턴이 있을 때 적합하다.
ASG는 자동으로 과거 부하를 분석한 다음 예측치를 생성하여 예측치를 기반으로 스케일링 작업을 예약한다.
스케일링을 위한 메트릭 종류
CPU 활용도
EC2 인스턴스의 평균 CPU 사용률
타겟 당 요청 수
EC2 인스턴스 당 들어오는 요청의 개수
평균 네트워크 In/Out
평균 네트워크 사용량
스케일링 쿨다운
스케일링 작업으로 인스턴스가 추가/제거되었을 때 기본적으로 5분동안 쿨다운 시간이 생긴다.
쿨다운 시간 동안 ASG는 추가 인스턴스를 개시하거나 종료하지 않는다.
메트릭이 안정화되도록 하고 새로운 인스턴스가 적용되어 새로운 메트릭이 어떻게 변할지를 지켜보는 시간을 가지는 것이 목적이다.
쿨다운 이후에도 문제가 있는 상황이라면 스케일링 작업을 다시 진행한다.
AMI를 사용하여 EC2 인스턴스의 설정 시간을 줄여 인스턴스 추가/제거 작업을 빠르게 처리하면 즉시 스케일링 효과가 나타나므로 좋다.
ASG가 1분마다 하위 수준의 메트릭에 액세스할 수 있도록 상세한 모니터링과 같은 기능을 활성화하고, 메트릭이 충분히 빠르게 업데이트되도록 해야 한다.
Instance Refresh
인스턴스를 시작하기 위해 설정했던 템플릿이 변경되어 기존 인스턴스들을 이에 맞게 재실행해야 하는 경우, 이 기능을 이용하면 된다.
예를 들어 EC2 인스턴스의 기본 AMI를 업데이트 하고 난 후에는 StartInstanceRefresh라는 API를 호출하여 Instance Refresh를 수행할 수 있다.
minimum healthy percentage를 설정하여 모든 인스턴스가 동시에 내려가는 일이 없도록 한다.
기존 인스턴스가 종료되면 새로운 템플릿을 기준으로 인스턴스가 생성된다.
점차 기존 시작 템플릿을 가진 인스턴스가 모두 사라지고, 새 인스턴스로 대체된다.
새 EC2 인스턴스를 사용할 준비가 될 때까지 대기 시간을 지정할 수 있다.
Last updated