AWS ELB, ASG

High availability & Scalablity

High availability(고가용성) 과 Scalablity(확장성)은 연관되어있지만 다른 개념이다.

 

Scalablity

Scalablity는 애플리케이션 시스템이 조정을 통해 더 많은 양을 처리할 수 있도록 하는 것이다. 두가지 종류가 있다.

1. 수직 확장성

인스턴스의 크기를 확장하는 것을 의미한다. 

1분에 5개를 처리하는 인스턴스를 수직확장시키면 1분에 10개를 처리할 수 있게된다.

2. 수평 확장성 

인스턴스의 수를 늘리는 것을 의미한다.

혼자서 10개의 일을 하는 것을 수평확장시켜 한명을 더 추가하면 혼자서 5개의 일을 하게되는 것이다.

이건 분배시스템이 있다는 것을 의미한다.

 

 

High availability

High availability이란 애플리케이션을 둘 이상의 AZ나 데이터센터에서 가동시키는 것을 의미한다.

이것의 목표는 데이터 센터에서의 손실에서 살아남는 것을 의미한다. 센터하나가 멈춰도 계속 동작이 되도록 하는 것이다.

서울 부산의 지점이 있다고 가정하자. 서울에 연결이 끊기면 부산으로 보내면 되니까 크게 문제가 없다. 이걸 고가용성이 높다라고 한다. 

 

스케일 업, 스케일 다운 ( 수직 확장성을 의미)

스케일 아웃(증가), 스케일 인(감소) ( 수평 확장성을 의미 )

 Auto scale group, Load balance에서 사용

 

Load Balance

로드 밸런싱이란 트래픽을 서버로 전송하는 것을 의미한다.

3개의 인스턴스가 있고 하나의 Elastic Load Balancer가 있다고 가정하자.

이 때 유저는 서버로 직접 접근을 하는 것이 아니라, 먼저 ELB로 접근을 한다. 그리고 ELB는 이 3개의 인스턴스를 보고

여유가 있는 인스턴스로 트래픽을 보낸다.

여기서 유저는 자신이 어떤 인스턴스로 보내질 지 모른다.

 

로드밸런서는 왜 필요할까?

트래픽을 여러 인스턴스로 분산시키기 위해 필요하다.

또 로드밸런서는 각 인스턴스의 상태체크를 함으로써 인스턴스에 보낼 수 있는지 아닌지 또한 체크하고있다.

SSL터미네이션을 가지고 있어서 https 트래픽도 가질 수 있다고 한다.

퍼블릭 트래픽과 프라이빗 트래픽을 구별할 수 있다.

고가용성을 높일 수 있다. 

다수의 AWS 서비스 와도 연관되어있고,

자체 로드 밸런스를 사용하는 것 보다 저렴하다. 

무조건 사용하는 것을 추천한다.

 

로드밸런서의 종류

4가지의 종류가 있다.

 

1.Classic Load Balancer (CLB)

HTTP,HTTPS,SSL,TCP, secure TCP를 지원한다.

AWS는 이 로드 밸런서를 권장하지 않는다.

 

2.Application Load Balancer (ALB)

HTTP,HTTPS,WEB Socket을 지원한다.

 

3.Network Load Balancer (NLB)

TCP,TLS (Secure TCP),UDP을 지원한다.

 

4.Gateway Load Balancer (GWLB)

3계층과 IP프로토콜에서 작동한다.

 

로드밸런서는 외부에서 사용할 수있는 것과 내부에서 사용할 수 있는 것이 있다.

 

로드밸런서의 보안그룹에서는 http, https로 들어오는 통신을 0.0.0.0/0 아이피로 모두 열어 두고, 

인스턴스에서는 로드밸런서의 보안그룹을 보안그룹으로 지정함으로써, 로드밸런서에서의 트래픽만 받도록 해야한다,

 

Application Load Balancer 

 7계층, HTTPS 전용 로드밸런서이다. 대상그룹에 있는 인스턴스에 트래픽을 분산시킨다. 컨테이너와 ECS라는 것을 사용한다, 

http로 접근하면 https로 리다이렉팅 하는 것도 로드밸런서에서 가능하다.

경로 라우팅을 지원한다.   

1. URL경로를 기준으로 라우팅이 가능하다.

만약 /users, /post라는 URL이 존재하고 이 둘을 구분시켜 각각 다른 인스턴스로 보낼 수도 있다., 

2.Host name기준으로 라우팅이 가능하다.

one.example.com, two.example.com이 있다고 가정할 때 각 호스트 네임에 따라서 다른 인스턴스로 보낼 수 있다,

3.쿼리스트링, 헤더에 따라 라우팅이 가능

/users?platform=desktop

/users?platform=mobile 

각 쿼리스트링의 값에 따라서 다른 대상그룹으로 트래픽을 분산 시킬 수도 있다.

Target group

EC2인스턴스가 대상그룹안에 속할 수 있다. ( 오토 스케일링에 의해 관리될 수 있다 )

람다함수,

프라이빗 아이피,

등이 될 수 있다고 한다.

 

ALB는 여러 대상그룹으로도 라우팅이 가능하다고 한다. 헬스체크는 대상그룹 레벨에서 이루어진다.

 

NLB

Network Load Balancer

L4로드 밸런서이므로 TCP/UDP 트래픽을 다룰 수 있다. HTTP를 다루는 L7보다 하위 계층이다.

낮은 지연시간을 자랑한다 ALB보다 4배 빠름

가용영역별로 고정 아이피를 가질 수 있다.

elastic IP를 각 가용영역에  할당할 수 있다.

1~3개의 아이피로만 액세스 할 수 있는  애플리케이션을 만들라고 하면 NLB를 사용해야 한다.

고성능, UDP, TCP, 고정 아이피 -> NLB

 

Target group

타겟그룹으로 인스턴스

프라이빗 아이피

ALB로드밸런서를 가질 수 있고

헬스체크로 tcp, http, https를 지원한다.

 

NLB로드밸런서를 만들어 실습을 하는 도중 의문이 들었다.

NLB를 생성할 때 가용영역을 설정하는데, 그 때 가용영역당 하나의 서브넷을 선택한다.

나는 4개의 서브넷이 있었다, 1a (퍼블릭, 프라이빗), 1c(퍼블릭, 프라이빗)

나는 일부러 둘다 퍼블릭으로 설정하였다, 그 이유는 인스턴스 하나를 프라이빗 서브넷에 만들었기에, 로드밸런서가 그 인스턴스로 라우팅을 시켜주지 못할 것이라 예상하고 그걸 확인하기 위해서였다.

 

그런데 예상을 뒤엎고, 로드밸런서는 프라이빗 서브넷에있는 인스턴스에도 연결을 시켜주었다.

이게 어떻게 가능한것인가? 한 가용영역에서 특정 서브넷을 선택하는 이유는 과연 무엇인가?

그냥 넘어가야겠다.

 

GWLB 

GateWay Load Balancer

네트워크의 모든 트래픽이  방화벽을 통과하게 하거나 침입 탐지 및 방지 시스템에 사용한다.

네트워크 트래픽을 분석하고 이상이 없으면 애플리케이션에 라우팅한다.

 

사용자 -> 라우팅 테이블 -> 게이트웨이 -> 타사 가상 애플리케이션? -> 문제 있으면 드롭, 문제없으면 목적지인 애플리케이션에 라우팅

모든 로드밸런서중에 제일 낮은 계층인 L3에서 이루어진다.

 

2가지 기능이 있다.

1. 투명 네트워크 게이트웨이

vpc의 모든 트래픽이 gwlb가 되는 단일 엔트리 출입구를 통과하기때문  

대상그룹의 가상 어플리언스 집합에 전반적으로 그 트래픽을 분산해 로드밸런서가 된다??

 

6081 GENEVE포트를 사용한다고 한다/

 

Targetgroup

타사의 ec2? (뭔소리인지...)

private ip 

 

 

Sticky Session

유저가 두명 있고 인스턴스가 두개 있고 그걸 라우팅해주는 로드밸런서가 있다고할때

만약 한 유저가 인스턴스와 연결이 되면 다음 요청을 할 때에도 똑같은 인스턴스에 요청을 보낸다고한다.

그걸 스티키 세션이라고 하고 ALB에서 설정가능하다고한다. 이 것이 가능한 이유는 쿠키때문이고 쿠키가만료되면 그 유저는 다른 인스턴스와도 연결될 수 있다.

 

쿠키의 종류는 2가지가 있는데 애플리케이션 기반 쿠키, 듀레이션 기반 쿠키가있다.

 

Cross Zone Load Balancing

 

두개의 로드밸런서가 있다고하자 a,b

a로드 밸런서안에는 2개의 인스턴스가

b로드 밸런서안에는 8개의 인스터스가 있다고 가정하자

 

with cross zone load balancing을 사용하면

로드밸런서에 상관없이 모든 트래픽이 모든 인스턴스에 골고루 분배된다.

즉 각 인스턴스가 10%씩 나누어 분담한다.

 

하지만 

without cross zone load balancing을 사용하면

두개의 로드 밸런서에 각 50%씩 트래픽이 간다고하면

a로드 밸런서에 있는 2개의 인스턴스는 각각 25퍼센트씩 부담하고

b로드 밸런서에 있는 8개의 인스턴스는 각 6.25%씩 부담한다.

ALB에서는 with cross zone load balancing이 기본값이다.

그리고 가용영역간에 데이터 이동이 무료이다. 

 

NLB, GWLB는 기본값이 with out이다.

이 경우 가용영역간 데이트 이동이 유료이다.

 

SSL/TLS

ssl인증서는 트래픽이 클라이언트와 로드밸런서 사이에 이동하는 동안 암호화를 해준다.

이걸 이동중 암호화라고 한다. in flight encryption 이걸 송신자와 수신자 측에서만 복호화 할 수 있다. 
SSL secure socket layer 연결을 암호화 하는데 사용함

TLS는 새로운 버전의 SSL이고 Transport Layer Security 

 

퍼블릭 SSL인증서는 기관에서 발급한다. 이 인증서를 로드 밸런서에 추가하면 클라이언트와 로드밸런서 사이의 연결을 암호화할 수있다, 이건 만료 날짜가 있어 주기적으로 갱신해주어야한다.

 

사용자가 HTTPS를 사용하여 로드밸런서로 접근하면 내부적으로 SSL Termination을 수행한다. 백엔드 에서는 HTTP(노 암호화)로 백엔드와 통신을 한다. ( 암호화 되지 않은 상태로 ) 하지만 vpc로 이동하는 트래픽은 프라이빗 네트워크를 사용하기에 안전하게 보호된다.

로드밸런서는 X.509라는 인증서를 사용하는데, 이걸 ssl또는 tls라고 부른다.

aws에서는 이 인증서들을 관리할 수 있는 ACM이 존재한다.

원한다면 자신이 가지고 있는 인증서를 ACM에 업로드 할 수도 있다.

 

HTTP리스너를 구성할 때에는 반드시 HTTPS로 해야한다.

기본인증서를 정해야한다.

클라이언트는 SNI를 사용하여 접속할 호스트의 이름을 알릴 수 있다.

 

 

SNI

여러개의 인증서를 하나의 웹서버에 로드하여 하나의 웹서버가 여러개의 웹사이트를 지원할 수 있게 해준다.

클라이언트가 어떤 웹사이트에 접속을 할 때 서버는 어떤 인증서로 로드해야하는지를 알 수 있다. 

이건 ALB, NLB에서만 지원한다. 따라서 어떤 로드밸런서가 여러개의 SSL을 가지고 있다면 그건 둘 중 하나다.

 

번역체가 매끄럽지 않은데.

 

예를들어 로드밸런서가 호스트네임을 기준으로 라우팅을 하는 룰을 가지고 있다고 가정해보자

abc.com로 요청이 오면 a대상그룹에,  zxc.com로 요청이오면 b대상그룹에,

그리고 로드 밸런서에는 2개의 ssl인증서가 있다. abc.com에 해당하는 인증서과 zxc.com에 해당하는 인증서

클라이언트에서 abc.com으로 요청이 왔다면 로드밸런서는 자신이 가지고 있는 인증서중에 해당하는 도메인을 찾고 그 트래픽을 암호화 시켜 라우팅을 시켜준다.

 

 

ALB와 NLB는 여러개의 인증서를 두고 여러개의 리스너를 지원한다.

거기에 ssl을 사용한다.

 

 

Connection Draining

ALB, NLB에서는 Deregistration delay  등록 취소 지연라고 한다. 

 

 인스턴스가 등록 취소되거나 비정상으로 표시되는 동안 인스턴스가 진행 중인 요청 또는 활성 요청을 완료하는데 약간의 시간을 준다는 개념

소프트웨어 유지보수 등에서 사용할 수 있는 기능입니다. ELB로부터 분리해도 요구중의 인스턴스에 지정 초수의 사이는 통신은 끊어지지 않습니다. 새 요청이 있더라도 이미 분리된 인스턴스에 액세스할 수 없습니다.

 

• Connection Draining: Auto Scaling이 사용자의 요청을 처리 중인 EC2 인스턴스를 바로 삭제하지 못하도록 방지하는 기능입니다. 예를 들어 사용자 수가 줄어들면 Auto Scaling이 EC2 인스턴스를 삭제합니다. 마침 사용자가 해당 EC2 인스턴스에서 파일을 다운로드하고 있었는데 EC2 인스턴스가 삭제되어버리면 파일 다운로드는 중간에 끊어집니다. EC2 인스턴스를 삭제하기 전에 사용자의 요청을 처리할 수 있도록 지정한 시간만큼 기다립니다. 그리고 기다리는 동안에는 새로운 커넥션을 받지 않습니다 다른 인스턴스와 연결되도록 한다. 1~ 3600초 까지 지정가능

 

 

ASG

인스턴스를 트래픽의 양에 따라 자동으로 생성하고 줄여주는 역할이다. ASG의 목표는 스케일 아웃, 스케일 인이다. ( 수평 확장 ) 인스턴스의 최소 갯수, 최대 갯수를 정할 수 있다.

로드밸런서와 연결 할 수도 있다.  로드밸런서가 ASG안에 있는 인스턴스들에게 트래픽을 분산하면서 헬스 체크도 해주고 불량인 상태가 있다면 ASG에게 말해줌으로써 ASG는 그 인스턴스를 관리할 수 있게된다. 로드밸런서와 ASG는 좋은 조합이다.

 

하나의 인스턴스가 만약 불량의 상태라면 이를 새로운 인스턴스로 대체하는 작업또한 해준다. 

 

ASG를 만드려면 시작 템플릿을 통해 만들어야 한다. 

거기서 EC2를 시작하는 방법에 대한 정보도 들어있다. AMI 및 인스턴스의 유형 , EC2 유저 데이터, EBS볼륨 , 시큐리티 그룹, SSH키페어, 인스턴스를 위한 IAM역할, 네트워크 및 서브넷 정보, 로드밸런서 정보 등이 있다.    

 

스케일링 폴리시도 적용해야 하는데 , 

클라우드 워치와 조합할 수도 있다. 

클라우드 워치를 기반으로 스케일 인, 스케일 아웃을 할 수 있다. 

예를들어 ASG에 인스턴스가 3개 있는데 클라우드 워치에서 경보가 오면 이걸 스케일 아웃하여 인스턴스를 늘릴 수 있다. 

CPU사용량이라던지 커스텀으로 어떤 지표를 사용하여 그걸로 기준을 삼을 수 있다. ( 인스턴스 평균 cpu가 높을경우 경보가 울리고 인스턴스 생성 ) 반대로 사용량이 낮으면 스케일 인을 할 수도 있다.  

 

ASG 스케일링 정책  

1. dynamic scale policy 

-target tracking scaling

대상 그룹의 평균 cpu 사용률이 40%에 머무르도록 하고싶은 경우

-simple / step scaling

 전체 ASG의 CPU사용률이 70%를 초과하는 경우 인스턴스를 2개 늘리도록 하는 것

반대로 CPU가 30퍼센트를 밑돌면 2개를 지우게 할 수도 있다.  이 때 클라우드 웟치라는 것을 사용한다. 

스텝은 단계적으로 몇번 실행할 수 있다 50% 60% 70% 이럴 때..

-scheduled actions 

금요일날 이벤트를 하는데 이 때 많은 사용자가 몰릴 것으로 예상이 되므로 이 때  매주 10시에 인스턴스를  최소 10개로 늘리는 것 

 

2.predictive scaling 

과거부터 현재까지의 로드사용량을 바탕으로 분석하여 앞으로의 상황을 미리 예측하여 스케일링 하는 것

 

metrics to scale on ( asg에 사용할 지표들 )

CPU사용량  

인스턴스로 들어오는 리퀘스트 수 

평균 네트워크 입출력 량   averate of nework in / out 

커스텀 ( 자기가 원하는 지표 사용 가능 ) 

 

scaling cooldown 

ASG가 오토 스케일링을 하고 나서 약 5분정도 휴지 기간을 갖는다. ( 지워지거나, 생성되거나 )

그 때에는 인스턴스가 추가로 생성되거나 삭제되지 않는다.

따라서 스케일링 액션이 실행될 때 휴지기간에 있는 인스턴스가 있다면 생성 혹은 삭제를 무시한다.

 

AMI를 사용하면 인스턴스 구성시간이 확 줄어들기 때문에 이 휴지기간 또한 줄어든다. 따라서 훨씬 동적인 오토스캐일링이 될 수 있다고 한다.