Elastic Load Balancing (ELB)
확장성의 종류
수직 확장성, 수평 확장성.
수직 확장성 ()
- 인스턴스의 크기를 확장하는 것 의미
전화 교환원으로 예를 들었을 때 Junior Operator는 1분에 5통을 받을 수 있다.
Senior Operator는 1분에 10통을 받을 수 있다.
Junior Operator를 Senior Operator로 전환하는 것이 수직 확장성이다.
이는 데이터베이스와 같이 분산되지 않은 시스템에서 흔히 사용된다.
RDS나 ElastiCache 등의 데이터베이스에서 쉽게 찾아볼 수 있다.
이 서비스들은 하위 인스턴스의 유형을 업그레이드해 수직적으로 확장할 수 있는 시스템들이다.
하지만 하드웨어의 제한이 있을 수 있다.
수평 확장성
- 애플리케이션에서 인스턴스나 시스템의 수를 늘리는 방법
- 수를 늘리면 스케일 아웃
- 수를 줄이면 스케일 인
같은 능력치의 전화 교환원을 여러명 고용하는 것이다. 수평 확장을 했다는 건 분배 시스템이 있다는 걸 의미한다.
고가용성
애플리케이션 또는 시스템을 적어도 둘 이상의 AWS의 AZ나 데이터 센터에서 가동 중이라는 걸 의미한다.
고가용성의 목표는 데이터 센터에서의 손실에서 살아남는 것으로 센터 하나가 멈춰도 계속 작동이 가능하게 것이다.
뉴욕지사에 콜센터 3명, 샌 프란시스코 지사에 3명이 있다고 가정할 때 뉴욕지사와의 연결이 끊겼다고 하더라도 샌 프란시스코 지사에서 업무가 가능하므로 이 콜센터는 가용성이 있다고 볼 수 있다.
고가용성도 수동적일 수 있다.
예를 들면 RDS 다중 AZ를 갖추고 있다면 수동형 고가용성을 확보한 것이다.
하지만 수평 확장을 한다면 활성형도 될 수 있다.
로드 밸런싱
- 애플리케이션에 단일 액세스 지점 (DNS)을 노출하게 되고 다운스트림 인스턴스의 장애를 원활히 처리할 수 있다.
- health check 가능
- 클라우드 내에서 개인, 공공 트래픽 분리 가능
- 쿠키를 사용하여 stickiness 가능
- SSL 종료 가능으로 웹 사이트에 암호화된 HTTPS 트래픽을 가질 수 있다.
ELB는 관리형 로드 밸런서 이기도하다.
로드 밸런서의 종류
- Classic Load Balancer CLB
기존세대나 V1이라고도 하며 2009년에 만들어졌고 HTTP, HTTPS, TCP, SSL, Secure TCP 지원
- 하지만 AWS에서는 이 로드밸런서의 사용을 권장하지 않아 콘솔에서 더 이상 사용할 수 없는 것으로 나오지만 사용이 가능하긴 하다.
IPv6 지원 X
- Application Load Balancer ALB
V2, 2016 출시
- HTTP, HTTPS, WebSocket 프로토콜 지원
- Network Load Balancer NLB
V3, 2017
- TCP, TLS (secure TCP), UDP 지원
- Gateway Load Balancer GWLB
3계층(네트워크)에서 작동하므로 3계층과 IP 프로토콜에서 작동함.
로드밸런서 보안 그룹
여기서 EC2 인스턴스는 로드 밸런서를 통해 곧장 들어오는 트래픽만을 허용해야 하기 때문에 EC2 인스턴스의 보안 그룹 규칙은 포트 80에서 HTTP 트래픽을 허용하며 소스는 IP 범위가 아니라 보안 그룹이 된다.
EC2 인스턴스의 보안 그룹을 로드 밸런서의 보안 그룹으로 연결하는 것이다.
- 기존 http 규칙 삭제
- "source"가 CLB 보안 그룹인 새 규칙 생성
ALB
7계층 HTTP에서 사용되며 머신 간 다수 HTTP 애플리케이션의 라우팅에 사용이 된다.
- URL 대상 경로에 기반한 라우팅 가능
- URL의 호스트 이름에 기반한 라우팅 가능
- 쿼리 문자열과 헤더에 기반한 라우팅
마이크로 서비스나 컨테이너 기반 애플리케이션에 가장 좋은 로드 밸런서
왜냐하면, 포트 매핑 기능이 있어 ECS 인스턴스의 동적 포트로의 리다이렉션을 가능하게 해줌.
지연시간 400ms
- ALB는 IP 주소들의 앞에도 위치할 수 있는데 꼭 사설 IP여야만 한다.
-> ALB는 여러 대상 그룹으로 라우팅할 수 있으며 상태 확인은 대상 그룹 레벨에서 이뤄진다.
애플리케이션 서버는 클라이언트의 IP를 직접 보지 못하며 클라이언트의 실제 IP는 X-Frowarded-For 이라고 불리는 헤더에 삽입된다.
X-Forwarded-Port를 사용하는 포트와 X-Forwarded-Port에 의해 사용되는 프로토콜도 얻게 된 다.
NLB
4계층 네트워크 로드밸런서로 TCP나 UDP 기반의 트래픽을 인스턴스로 전달하는 것이다.
초당 수백만 건의 요청을 처리할 수 있어 매우 고성능, ALB보다 지연 시간이 훨씬 짧다.
지연시간 100ms
외부의 가용 영역 당 1개의 고정 IP를 노출하며 특정 IP를 화이트리스트에 추가할 때 유용하다.
NLB 자체의 IP를 가져오는 대신 EIP 할당을 지원한다.
이는 엔트리 포인트 2개를 얻고자 할때 NLB를 사용할 수 있다.
애플리케이션 전용의 특정 IP를 지정하면 NLB가 해당 트래픽을 EC2 인스턴스로 보내는 것이다.
- 인스턴스를 등록하여 NLB에서 트래픽 전송 방법을 파악
- 고정 IP와 개인 IP를 지정해서 NLB에서 직접 트래픽 전송
ec2의 경우 자체 데이터 선터에 서버가 있는 경우에는 가급적으로 그대로 개인 IP가 있는 서버의 로드 밸런서를 사용한다. - NLB + ALB 결합 가능
NLB의 기능을 활용해서 고정 IP를 가질 수 있기 때문입니다.
NLB는 AZ마다 고정 IPv4 주소나 Elastic IP가 있다.
NLB에서 TCP 기반의 대상 그룹을 실행하면 보안 그룹에서 고려하는 것은 EC2 인스턴스의 보안 그룹이기 때문이다.
GWLB
GWLB는 배포 및 확장과 AWS의 타사 네트워크 가상 어플라이언스의 플릿 관리에 사용한다
네트워크의 모든 트래픽이 방화벽을 통과하게 하거나 침입 탐지 및 방지 시스템에 사용한다.
1. 모든 사용자 트래픽은 GWLB를 통과한다.
2. GWLB는 가상 어플라이언스의 대상 그룹 전반으로 트래픽을 확산하여 모든 트래픽은 어플라이언스에 도달하여 트래픽을 분석하고 처리한다. ex) 방화벽이나 침입 탐지와 같다.
3. 이상이 없으면 다시 GWLB로 보내고 이상이 있으면 트래픽을 드롭한다.
4. 이상이 없으면 GWLB이 애플리케이션으로 트래픽을 보낸다.
GWLB는 모든 로드밸런서보다 가장 낮은 수준에서 실행된다. IP 패킷의 네트워크 계층이 L3이다.
GWLB의 2가지 기능
- 투명 네트워크 게이트웨이
VCP의 모든 트래픽이 GWLB가 되는 단일 엔트리와 출구를 통과하기 때문이다. - 대상 그룹의 가상 어플라이언스 집합에 전반적으로 그 트래픽을 분산해 로드 밸런서가 된다.
6081번 포트의 GENEVE 프로토콜을 사용한다.
ELB의 Sticky Sessions
Sticky Sessions은 2가지 종류의 쿠키가 있다.
애플리케이션 기반 쿠키
- 사용자 정의 쿠키
애플리케이션에서 생성되고 애플리케이션에 필요한 모든 사용자 정의 속성을 포함할 수 있다.
쿠키 이름은 각 대상 그룹별로 개별적으로 지정
AWSALB, AWSALBAPP, AWSALBTG는 ELB에서 사용하기 때문에 사용 금지❌
-
애플리케이션 쿠키
로드 밸런서 자체에서 생성, ALB의 쿠키 이름은 AWSALBAPP -
기간 기반의 쿠키
로드 밸런서에서 생성되는 쿠키로 ALB에서는 AWSALB, CLB에서는 AWSELB
특정 기간을 기반으로 만료되며 그 기간이 로드 밸런서 자체에서 생성
Cross Zone Load Balancing
Cross Zone Load Balancing이 있다면 모든 트래픽이 고르게 분배되지만 없다면 5 : 5로 나뉘어서 균등하게 분배되지 않는다.
Application Load Balancer
- Cross Zone Load Balancing은 항상 활성화 되어있고 비활성화 할 수 없다.
- 보통 데이터가 한 AZ에서 다른 AZ로 이동하면 비용을 지불해야 하지만 비활성화를 할 수 없어 비용 지불을 할 필요 없다.
Network Load Balancer
- 기본적으로 Cross Zone Load Balancing 비활성화
- Cross Zone Load Balancing 활성화에 비용을 지불해야한다.
Classic Load Balancer
- 기본적으로 Cross Zone Load Balancing 비활성화
- Cross Zone Load Balancing 활성화에 비용 지불 ❌
SSL 및 TLS 인증서
SNI : Server Name Indication
SNI를 사용하면 한 웹 서버 상에서 다수의 SSL 인증서를 발급해 단일 웹 서버가 여러 개의 웹 사이트를 제공하도록 하는 문제를 해결해 준다.
이를 위해서는 클라이언트가 초기 SSL 핸드셰이크 에서 대상 서버의 호스트 이름을 명시해야 한다.
즉, 클라이언트가 연결하고자 하는 웹 사이트의 이름을 얘기하면 서버가 어떤 인증서를 불러올지 알 수 있다.
최신 프로토콜이기 때문에 모든 클라이언트가 이를 지원하지는 않는다.
이 프토코로은
- ALB나 NLB와 같은 최신 버전의 LB나 CloudFront에서만 작동한다.
- CLB에서는 작동하지 않는다.
따라서, 로드 밸런서에 SSL 인증서가 여럿이라면 ALB or NLB 둘 중 하나라고 생각하면 된다.
CLB
- 하나의 SSL 인증서만 지원
- 여러 SSL 인증서가 있는 다중 호스트 이름이 필요한 경우에는 다수의 CLB를 사용하는게 좋다.
ALB
- 다중 SSL 인증서를 가진 다수의 리스너를 지원할 수 있어서 유용하다.
- SNI 사용
NLB
- 다중 SSL 인증서를 가진 다수의 리스너를 지원하며 SNI 사용
Connection Draining
CLB 에서는 연결 드레이닝
ALB, NLB 에서는 등록 취소 지연
인스턴스가 등록 취소, 혹은 비정상인 상태에 있을 때 인스턴스에 어느 정도의 시간을 주어 인-플라이트 요청, 즉 활성 요청을 완료할 수 있도록 하는 기능
인스턴스가 드레이닝 되면 ELB는 등록 취소 중인 EC2 인스턴스로 새로운 요청을 보내지 않는다.
1번째 인스턴스를 드레이닝 모드로 설정
드레이닝 모드에 이미 연결된 유저는 충분한 드레이닝 시간을 얻게될 것 이고 기존 연결 및 기존 요청을 완료할 수 있을 것이다. 그리고 작업이 끝나면 모든 연결이 정지된다.
만약 새로운 유저가 ELB에 연결하려고 하면 ELB는 기존의 인스턴스가 드레이닝 상태에 있으므로 새로운 연결은 다른 인스턴스와 수립될 거라는 점을 알고 있다.
따라서, 2번째나 3번째 인스턴스를 사용할 것이다.
연결 드레이닝 파라미터는 매개변수로 표시할 수 있다. range는 1 ~ 3,600 초 인데 default 값은 300초이다. 이 값을 0으로 설정하면 전부 다 비활성화할 수 있다.
짧은 요청의 경우에는 낮은 값으로 설정하면 좋다.
예를 들어 1초보다 적은 아주 짧은 요청인 경우에는 파라미터를 30초 정도로 설정하면 된다.
그래야 인스턴스가 빠르게 드레이닝 될 것이고 그 후에 오프라인 상태가 되어 교체 등의 작업을 할 수 있다.
요청 시간이 매우 긴, 즉, 업로드 또는 오래 지속되는 요청 등의 경우에는 어느 정도 높은 값으로 설정
그러면 인스턴스가 금방 사라지지 않는다. 연결 드레이닝 과정이 완료되기를 기다려야한다.
Auto Scaling
Scale out : EC2 증가, 추가
Scale In : EC2 감소, 제거
ASG는 로드 밸런서에 자동으로 새 인스턴스를 등록해 주는 기능이 있다.
Auto Scaling Group
최소 크기, 기대 용량, 최대 크기 파라미터
AGS 속성
- 시작 구성 : AMI, 인스턴스 타입, EC2 유저 정보, EBS 볼륨 보안 그룹, SSH 키 쌍
네트워크와 서브넷
CloudWatch 알람
Custom Metric 이용시 PutMetric API를 사용해 CloudWatch에 보낸다
ASG는 AWS의 노출된 메트릭에 결부되어 있지 않으며 어떤 메트릭이든 관계가 없고 어떤 것도 커스텀 메트릭이 될 수 있다.
- ASG에 스케일링 정책 생성 가능 (어떠한 정책이든 가능하다.)
ASG 스케일링 정책
- 동적 스케일링 정책
대상 추적 스케일링 : ASG의 평균 CPU 사용률을 추적하여 이 수치가 40% 대에 머무를 수 있도록 할 때 사용한다.
단순/단계 스케일링 : CloudWatch 경보를 설정하고 전체 ASG에 대한 CPU 사용률이 70%를 초과하는 경우 용량을 두 유닛 추가
전체 ASG 내의 CPU 사용률이 30% 이하로 떨어지면 유닛 하나를 제거
단, CloudWatch 경보를 설정할 때에는 한 번에 추가할 유닛의 수와 한 번에 제거할 유닛의 수를 단계별로 설정
예약된 스케일링 : 나와 있는 사용 패턴을 바탕으로 스케일링 예상
예측 스케일링 : 시간에 걸쳐 과거 로드를 분석하고 예측
- 스케일링 기반
- CPU 사용률
- 테스트를 기반으로 하는 대상 별 요청의 수 (EC2 인스턴스는 한 번에 대상별로 1000개의 요청까지만 최적으로 작동)
- ASG for Solutions Architects
- 인스턴스가 종료되는 방식에 규칙이 있다.
