Scalability & Availability
Scalability(확장성)은 얼마나 많은 load를 감당할 수 있는지이다.
Vertical Scalability와 Horizontal Scalability(=elasticity)가 있다
- Vertical scalability는 데이터베이스와 같은 non distributed system에 주로 쓰인다.(보통 vertical scale의 hardware limit이 존재한다)
- Horizontal scaling은 distributed system을 내포한다. Web application에 주로 쓰인다.
높은 Availability(가용성)은 여러 data center(AZ)에 application이 돌고있는걸 의미한다. (data center loss에서 살아남기 위해)
- horizontal scaling과 밀접한 연관이 있다.
EC2에서 생각해보면
- Vertical Scaling: Increase instance size (scale up/down)
- Horizontal Scaling: Increase number of instances (scale out/in)
- High Availability: run instances across multi AZ
Load Balancer
Load Balance는 들어오는 traffic을 여러 서버(e.g. EC2 instances)에 forward한다.
- AWS Elastic Load Balancer는 managed load balancer이다.
- Load Balancer에서 Health Check를 통해 instance가 available한 상태인지 체크한다.
AWS Elastic Load Balancer의 종류는 다음 4가지다.
- Classic Load Balancer (v1): deprecated
- Application Load Balancer (v2): HTTP, HTTPS, WebSocket
- Network Load Balancer (v2): TCP, TLS(secure TCP), UDP
- Gateway Load Balancer: layer 3(Network Layer)
Security Group을 설정할 때, EC2에서는 Load Balancer에서 오는 트래픽만 허용하면 된다.(Load Balancer Security Group에서 Port들 설정하고)
Application Load Balancer (v2)
Application load balancers is Layer 7 (HTTP)
- 여러 machine들의 HTTP application으로 로드밸런싱할 수도 있고,
- 한 machine안의 여러 application으로 로드밸런싱할 수도 있다.
- HTTP/2와 WebSocket을 지원한다.
- redirect를 지원한다(e.g. HTTP to HTTPS)
ECS안의 dynamic port로 redirect가 가능하다.
여러 Target group으로 다음의 기준들을 통해 routing할 수 있다.
- URL Path
- Hostname
- HTTP Headers
- Query Strings
URL 기반 ALB 예시
ALB는 여러 target group으로 라우팅할 수도 있다.
Health check는 target group레벨에서 수행된다.
Target Group이 될 수 있는 것들은 다음과 같다.
- EC2 instances
- ECS tasks
- Lambda functions
- IP Addresses : private IP들이어야 한다.
Query String/Parameter 기반 ALB 예시
client는 ELB와만 소통하고, ELB가 EC2와 소통한다. 이때, EC2에서 client의 true IP는 header의 X-Forwarded-For에 들어있다.
(Port는 X-Forwarded-Port에, proto는 X-Forwarded-Proto에)
Network Load Balancer (v2)
Layer 4에서 TCP/UDP trafic을 instance에 forwarding할 수 있다.
- NLB는 AZ당 하나의 static IP를 가지고, Elastic IP 할당을 지원한다.
(ALB는 static DNS만 제공) - highest performance와 lowest latency를 제공한다.(millions of request per seconds 감당 가능)
NLB의 Target Group이 될 수 있는 것들은 다음과 같다.
- EC2 instances
- IP Addresses : private IP들이어야 한다.
- Application Load Balancer
Gateway Load Balancer
모든 traffic을 먼저 3rd Party Security Virtual Appliances에 보내고, 체크가 끝난 뒤에 application에 보낸다.(체크에서 실패하면 drop)
즉, 다음 두 기능을 수행한다.
- Transparent Network GateWay = 모든 traffic에 대해 single entry/exit
- Load Balancer = traffic 분산
GLB에서는 6081 port에서 GENEVE protocol을 이용한다.
GLB의 Target Group이 될 수 있는 것들은
- EC2 instances
- IP Addressed : private IP들이어야 한다.
Sticky Session(Session Affinity)
한 client가 항상 한 instance에 요청을 보내도록 설정할 수 있다.
- Classic Load Balancer와 Application Load Balancer에서 가능하다.
- stickness에 사용되는 cookie에 만료기간을 설정할 수 있다.
Cookie에는 Application-based cookie와 Duration-based Cookie가 있으며 load balancer로부터 만드는 cookie 이름은 AWSALBAPP, AWSALB, AWSELB이다.
Cross Zone Load Balancing
AZ에 상관없이 Load balancing하는 것이 Cross Zone Load Balancing이다.
- Application Load Balancer: 항상 O(못끔), inter AZ 추가요금 X
- Network Load Balancer: 꺼져있는게 default, 킬 수 있고 inter AZ 추가요금 O
- Classic Load Balancer: 꺼져있는게 default, 킬 수 있고 inter AZ 추가요금 X
SSL/TLS Certificate
TLS가 SSL의 상위호환이고, TLS가 주로 쓰이지만 언급할 때 SSL로 이야기를 많이 한다.
Load Balancer가 HTTPS로 받고, 그 뒤는 HTTP로 통신하게 설정한다.
ACM(AWS Certificate Manager)를 통해 certificate를 관리한다.
SNI(Server Name Indication)을 통해 한 web server에 여러 SSL certificate를 load할 수 있게 된다.
- initial SSL handshake에서 원하는 hostname을 명시하면, server가 그에 맞는 certificate를 찾는다.
- ALB, NLB, CloudFront에서만 가능하다.(CLB는 구버전이라 지원X)
Connection Draining
instance가 de-registering중이거나 unhealthy일때 진행중인 request에 대해 완료할 시간을 주는걸 의미한다.
CLB에서는 Connection Draining이라 부르고
ALB, NLB에서는 Deregistration Delay라 부른다.
default는 300초이고, 1~3600초로 설정가능하다.(0으로 설정하면 disabled)
- request가 짧으면 적게 설정해도 좋다.
Auto Scailing Group(ASG)
변화하는 load에 따라 Scale in/out을 할 수 있도록 해준다.
- minimum size, maximum size, desired capacity를 설정해둘 수 있다.
CloudWatch alarm에 의해 scale in/out을 하도록 설정가능하다.
- CPU Usage, Network 등 원하는 rule을 설정할 수 있다.
- custom metric을 둘 수도 있다.
ASG 자체는 무료이고, 그 아래에서 사용되는 resource에 대해서 비용이 지불된다.
Scaling Policy
Scaling Policy 중 하나인 Dynamic Scaling Policy는 다음 3가지가 있다.
- Target Tracking Scaling: 가장 간단하고 설정하기 쉬움. ex. average CPU
- Simple / Step Scaling: CloudWatch alarm을 trigger로 사용하여 2개 증가, 1개 감소
- Scheduled Actions: 사용 패턴에 맞게 예정된 scaling
Predictive Scailing은 load의 history를 분석하여 미래를 예측하는 것이다.
Scaling Cooldown
scaling activity(instance 늘리거나 줄이기)가 일어나고 몇초간 아무런 액션을 취하지 않는 시간이 필요하다. 변화가 일어난 뒤의 metric을 관찰해야 하므로
- default는 300초
- ready-to-use AMI를 이용하면 이러한 시간을 단축 가능하다.
ASG for Solutions Architects
ASG의 default Termination Policy는 AZ간 instance 수의 균형을 맞추려 한다.
(+ Launch Template의 구버전, 신버전이 섞여있으면 구버전 삭제)
Pending State나 Terminationg State에 Lifecycle Hook을 추가할 수 있다.
종료전에 데이터들을 따로 저장해야 한다거나 할 때 필요한 기능이다.
Launch Template(newer) vs Launch Configuration(legacy)
- 구버전인 Launch Configuration은 매번 새로 만들어져야 하고, 최신버전인 Launch Template은 여러 버전을 가질 수 있다.
구버전을 사용할 이유가 없고 최신 버전을 항상 이용하자!
