What is load balancing?

로드 밸런싱은 server 혹은 server set 으로 traffic 을 backend 나 downstream ec2 instance 또는 Server 로 전달하는것이다.

이렇게 말하면 무슨말인지 하나도 모른다.
여러개의 Instance 앞에 ELB(Elastic Load Balancer) 를 붙이고 사용자가 들어오면 여러개의 Instance 중 하나로 연결해주는것을 의미한다.

이렇게 해줌으로써 Ec2 Instance 로 가는 부하가 분산될수 있다.

Why use a Elastic Load Balancer?

결국 부하를 다수의 downsteram instance 로 분산시키기 위해서 사용한다.

이런 Elastic Load Balancer 는 관리형 로드 밸런서 라고도 불린다.
AWS 가 고가용성을 책임지고 사용자들이 수정하라고 일부 구성 놉 도 제공해준다.

그리고 자체의 Load balancer 보다 더 저렴하고, ELB 보다 확장성 면에서 번거로움이 많다고 한다.
또한 ELB 는 많은 AWS 서비스랑 연결 가능해서 ELB 가 더 좋다고 함!

Health Checks

ELB 가 EC2 Instnace 의 작동이 올바르게 되는지 확인하는것이다.
Port, Router 에서 이뤄진다고 한다.
ELB가 EC2 Instance의 상태를 확인하면서 200(Ok) 이면 정상, 아니면 비정상이라고 한다.

Types of load balancer on AWS

4가지의 load balancer 가 있는데 시험에도,AWS에서도 없어진 Classic Load balancer(CLB) 는 제외하고 설명한다.

Application Load Balancer(ALB)
Network Load Balancer(NLB)
Gateway Load Balancer(GWLB)
이렇게 나뉘고 새로운 버전의 LB를 사용하는것이 더 많은 기능을 담고 있기에 무조건적으로 좋다고 한다. 그리고 내부에서도 수정이 가능하다고 한다. 그말은 Network 개인 접근 가능하다.

Load Balancer Security Groups

User 는 이제 부터 LB 를 통해서 EC2 를 접근하게될것이고.
Ec2 는 LB 를 통해서 들어오는 Traffic 만 접근허용해줘야한다.
그렇기에 기존 Ec2 Instance Security Gruop 에서 HTTP 에 대한 보안 그룹 을 0.0.0.0/0 (모두) 에 대해 허용해주었지만 이제는 LB Security Group 으로 설정해줘야한다는 말이다.

Application Load Balancer(v2)

Application 이라는 말 처럼 7계층 전용 LB 이다. 머신간 다수 HTTP Application 의 Routing 에 사용된다.

ALB 는 대상 그룹으로 묶이게 되고, 동일 EC2 Instance 상의 여러 Application 에 부하를 분산하게 한다.

HTTP,HTTPS/WebSocket 을 지원한다고 한다.

또한 경로 ROuting 도 가능하다고 하는데,,,
URL,Query,String header 를 통해서도 접근이 가능하다고 한다.
on.example.com & other.example.com 이 다르게 접근될수 있고
example.com/users?id=123&order=false 이렇게 쿼리를 통해서도 접근이 달라질수 있다는 뜻이다.

이러한 ALB 는 Micro Service, Container 기반 Application 에 좋다고 한다.
그리고 Port Mapping 이 있어서 ECS Instance 동적 Port 로 redirection 가능하게 해준다.

HTTP Based Traffic

Route/user 는 첫번째 대상그룹
Route/search 는 두번쨰 대상그룹으로 연결된다.

두개의 독립된 Micro service 가 서로 다른 작업을 처리한다.

Target Groups

이러한 대상 그룹에는
Ec2 Instnaces, EC2 Tasks, Lambda functions, Ip Address 가 될수있다.

그리고 ALB 는 여러 대상 그룹으로 Routing 할수 있다.
상태 확인은 대상 그룹 Level 에서 진행된다.

Query Strings/Parameters Routing

Requests 가 외부 ALB 에 들어오게 되면 쿼리에 따라 다른 작업을 처리한다는 말이다.

?Platfor=Mobile 은 Target Group1 로 ?Platform=Desktop 은 Target Group2 로 보내진다.

Good to Know

ALB 생성하면 고정 Host name 이 부여된다고 한다.
실제로 실습떄 ALB 생성하면 어떤 DNS 가 부여되서 그거 복사해서 붙여넣으면 접속이된다.
Application 서버는 클라이언트 IP 를 못본다.
그걸 보고 싶으면 HTTP Header 에 있는 X-forwarded-for 로 부터 받을수 있고
Port,prototype 보고 싶으면 X-forwarded-port, X-forwarded-proto 로 부터 받을수 있다.

Network Load Balancer(v2)

TCP,UDP Traffic을 다를수 있다.
ALB 와는 다르게 매우 성능이 좋다
ALB 는 400ms 의 지연 시간을 가진다면 NLB는 100ms 의 지연시간을 가진다.

그리고 NLB 는 가용영역 당 하나의 정적 IP를 가진다. 그리고 탄력적 IP 주소를 각 AZ 에 할당가능하다.
AWS 에서 Free tier에 포함되지 않다고 한다....

이러한 NLB 는 여러개의 고정 IP를 가진 Application 노출할떄 사용한다고 한다.

TCP(Layer 4) Based Traffic

ALB는 어떠한 URL,QUery,parameter 에 따라서 다른 작업을 처리할수있는데 NLB 는 Backend 에선 HTTP , Frontend 에서는 TCP 이렇게 작업할수있다.

Target Groups

NLB 는 배포할 가용영역마다 고정 IP 주소가 있다.
Target Group 으로는
Ec2 Instance
IP Address
APplication Load Balancer
이 있고

Health Check 도 TCP,HTTP,HTTPS 를 지원한다.

Netwokr Load Balancer 는 보안그룹을 정의하지 않는다.
LB로 들어온 Traffic 이 곧장 Ec2 Instance 로 간다...

Gateway Load Balancer

배포 및 확장과 AWS 의 타사 네트워크 가상 어플라이언스 Fleet 관리에 사용한다.
모든 Traffic 이 방화벽을 통과하게 하거나 침입 방지,방지시스템에서 사용한다.

3계층에서 작동하게 되고 이러한 GWLB 는 Network Gateway , Loadbalancer 의 역할을 한다.

사진을 이해해야 하는데 USer 가 Traffic 을 보내고 GWLB 에서 그것을 Appliance 로 보낸다.
Appliance 는 Traffic 분석하고 처리한다 ( 방화벽,침입감지 ) 그리고 다시 GWLB 로 보내고 괜찮다고하면 Application 으로 이동한다.

결국 GWLB 는 Network Traffic 을 분석하는 것이다.

Target Groups

Ec2 Instance(타사 Appliance)
IP Address - 반드시 사설 IP 이여야한다.

Stick Sessions (Session Affinity)

고성세션 or 세션 밀접성 이라고 한다.
LB에 2가지 요청을 하는 Client 가 요청에 응답하기 위해 Backend 에 동일한 Instance 를 제공한다.

Client 에서 LB 로 요청의 일부로 전송한다. 이떄 cookie 라는 것을 사용하는데 cookie 가 만료되면 client 가 다른 ec2 Instance 로 redirect 된다.

Cookie 는 2가지 종류가 있는데

Application-based Cookies , Duration-based Cookies 두개로 나뉘고
Application-based Cookies 는 Custom cookie,Application cookie 로 나뉜다.

custom cookie 는 대상 으로 생성된 사용자 정의 cookie 이고
application 은 LB 자체에서 생성된다.

Cross-Zone Load Balancing

위 사진이 Cross-zone LB 가 활성화 되어있을땐데 두개의 LB에 포함된 모든 Instance 들이 동일한 Traffic 을 분산받을수 있다.

Cross-zone LB가 활성화 되지 않은것인데 영역을 교차하지않고 요청을 분산하면 ELB instance 로 분산한다.

둘 중에 답은 없다.
상황에 맞게 사용하면 된다.

ALB 는 기본 활성화이고
NLB,GWLB 는 기본 비활성화이다.

SSL/TLS Basics

Client 와 LB 사이에 Traffic이 이동하는 동안 암호화 해준다고 한다.

SSL 는 보안 소켓 계층이고
TLS 는 전송계층 보안이라고 한다.
Public SSL certificates 는 CA 에 의해 정리된다고 한다...

User는 HTTPS 를 LB로 요청하면 LB는 HTTP 요청을 EC2 Instance 로 보낸다.

SSL - server Name Indication (SNI)

SNI 는 중대한 문제의 해결책이다.
여러개의 SSL 인증서를 하나의 Webserver 에 로드해서 하나의 웹 서버가 여러개의 웹 사이트 지원할수 있게 해준다.
ALB,NLB 에서만 작동한다.

결국 SNI 사용해서 여러개의 대상 그룹과 웹사이트를 지원할수있다.

CLB 는 한개의 SSL 만 지원하고 ALB,NLB 는 여러개 SSL 지원 가능하다. 거기에 SNI 사용한다.

Connection Dranning(수정필)

Instnace 가 등록 취소 or 비정상 상태일때 instance에 시가을 줘서 활성요청을 완료할수 있는 기능,,,
정확하게는 모르겠다,,,,,,
이부분은 다시 수정해야겠다.

Auto Scaling Group

말에서 보이는것 처럼 Instnace 를 삭제/생성하는것을 자동화할수 있게 해주는 기능이다.
Scale IN/OUT 을 해주고 자동으로 LB에 연결도 해준다. 또한 한개가 비정상이면 종료하고 새 Instance 생성해준다.

최소 개수 2개가 있고 희망개수,최대개수를 설정한다.
그리고 이때 최대에서 희망을 더 높게 설정하면 Scale out 이 자동으로 된다.

ELB 가 모든 instance 에 Traffic 을 즉시 분산해서 사용자가 LB 된 웹사이트에 Access 가능하게 한다.

ELB 가 상태확인하고 ASG 에 전달한다.
Scale out 되면 ELB 가 Traffic 보내고 코드 분산한다.

또한 Cloud watch 경보를 가지고 ASG 를 Scale out/in 할수 있다.

Scaling Policies

Scaling Policies 도 2개가 있다.

하나는 Dynamic Scaling Policies 이고 다른건 Predictive Scaling 이다

Dynamic Scaling Policies 는 또 3가지 유형으로 나뉜다.
대상 추적 Scaling 은 그냥 AVG CPU 사용률 추적해서 40%에 머물게 하는것이고
Simple/step Scaling 은 CPU 사용률이 70% 이상이면 2개를 추가하고 30% 미만이면 하나를 삭제한다.
Scheduled Actions 는 나와있는 사용 패턴을 바탕으로 Scaling 예상하는것이다.

Predictive Scaling 은 예측 Scaling 으로 load를 보고 다음 Scaling 을 에측하는것이다.
시간을 들여서 Load 를 분석하고 예측으로 Scaling 한다.

Good metrics to scale on

지표로 되는것들이다.

CPUUtilization - CPU 사용량이다.
RequestCountPerTrage - 대상별 요청수이다.
Average Network IN /OUT - 얼만큼 Application 이 BOund 됬냐이다.
Any custome metric - 자신이 원하는 어떤거든 된다고 한다.

Scaling Cooldowns

Scaling 끝날때 마다 instance 추가 또는 삭제 막론하고 5분의 Cooldown 기간이다.
이때는 추가 Instance 실행 또는 종료 하지않는다.