Scalability & High Availability
확장성은 애플리케이션 시스템이 조정을 통해 더 많은 양을 처리할 수 있다는 의미
두 가지 종류의 확장성:
Vertical Scalability 수직확장성
Horizontal Scalability 수평확장성, 탄력성
확장성과 고가용성은 서로 다른 개념이다 linked but different
Vertical Scalability 수직확장성
인스턴스의 크기를 확장하는 것
ex) t2.micro에서 구동되던 애플리케이션을 t2.large에서 구동하게끔 스케일링 업
데이터베이스와 같은 분산되지 않은 시스템에서 사용 RDS, ElasticCache 하위 인스턴스의 유형을 업그레이드 해 수직적으로 확장할 수 있는 시스템들
일반적으로 확장할 수 ㅣㅇㅆ는 정도에 한계가 있다 hardware limit
주니어 전화교환원을 시니어 전화교환원으로 대체하는 것
Horizontal Scalability 수평확장성
애플리케이션에서 인스턴스나 시스템의 수를 늘리는 방법
주니어 전화교환원을 더 채용해서 두배의 작업량을 처리하는 것
수평 확장을 한다는 것은 분배 시스템이 있다는 것
very common for web applications / modern applications
EC2 같은 서비스 덕분에 수평 확장을 쉽게 할 수 있다
High Availability 고가용성
고가용성은 수평확장성과 같이 사용되는 개념이지만 늘 그런것은 아님
고가용성이란 애플리케이션 또는 시스템을 적어도 둘 이상의 AZ나 데이터 센터에서 가동중이라는 것을 의미함
고가용성의 목표는 데이터 센터에서의 손실에서 살아남는 것
(센터 하나가 멈춰도 계속 작동이 가능하게끔)
The high availability can be passive (for RDS Multi AZ for example)
The high availability can be active (for horizontal scailing)
High Availability & Scalability for EC2
vertical scaling: Increase instance size ( =scale up/down)
From: t2.nano TO: u-t12b1.metal
Horizontal scaling: Increase number of instances (= scale out / in) 아웃이 늘어나는거 인이 줄어드는 거
High Availability: Run instances for the same application across multi AZ
Auto scailing Group multi AZ
Load Balancer multi AZ
What is Load Balancing?
Load Balances are servers that forward traffic to multiple servers downstream
부하를 다수의 다운스트림 인스턴스로 분산하기 위해 필요함
Expose a single point of access(DNS) to your application
Seamlessly handle failures of downstream instances
로드밸런서가 health check 매커니즘으로 어떤 인스턴스로 트래픽을 보낼 수 없는지 확인해줌
Do regural health checks to your instances
Provide SSL termination (HTTPS) for your websites
쿠키로 고정도를 강화할 수 있고 영역에 걸친 고가용성을 가짐
클라우드 내에서 개인 트래픽과 공공 트래픽을 분리할 수 있음
Why use an ELB?
ELB는 관리형 로드 밸런서임
aws가 관리하며 어떤 경우에도 작동할 것을 보장함
aws가 업그레이드와 유지 관리 및 고가용성을 책임짐
로드밸런서의 작동 방식을 변경할 수 있는 a few configuration knobs를 제공함
자체 로드밸런서를 구성하는 것보다 저렴하고 자체 로드밸런서를 직접 관리하려면 확장성 측면에서 번거로움
로드 밸런서는 다수의 AWS 서비스들과 통합되어 있음
EC2 인스턴스, EC2 Auto Scailing Groups, Amazon ECS
AWS Certificate Manager (ACM), CloudWatch
Route53, AWS WAF, AWS Global Accelerator
Health Checks
헬스체크는 로드밸런서에게 중요하다 > 만약 제대로 작동하는 중이 아니라면 해당 인스턴스에는 트래픽을 보내면 안되기 때문
The health check is done on a port and a route (Protocol: HTTP , port : 4567, Endpoint: /health)
인스턴스가 200으로 response 하지 않으면 인스턴스는 unhealty > ELB는 그 쪽으로 트래픽을 보내지 않음
Types of load balancer on AWS
AWS has 4 kinds of managed Load Balancers
Classic Load Balancer (v1, old generation)-2009-CLB
: HTTP, HTTPS, TCP, SSL( secure TCP)
Application Load Balancer (v2, new generation)-2016-ALB
: HTTP, HTTPS, Websocket
Network Load Balancer (v2, new generation)-2017-NLB
: TCP, TLS(secure TCP), UDP
Gateway Load Balancer-2020-GWLB
: Operates at layer3 (Networ layer) - IP protocol
신형으로 써라 ~
일부 로드밸런서는 내부에 설정될 수 있어 네트워크에 개인적인 접근이 가능하고 웹사이트와 공공 애플리케이션 모두에 사용이 가능한 외부 공공 로드밸런서도 있음
유저는 HTTP나 HTTPS 를 사용해 어디서든 로드 밸런서에 접근이 가능하다
EC2 인스턴스의 보안 규칙이 포트 에서 HTTP 트래픽을 허용하며 소스는 IP 범위가 아니라 보안 그룹이 되어야함
Classic Load Balancer (v1)
Supports TCP (Layer 4), HTTP & HTTPS (Layer 7)
헬스체크는 TCP or HTTP based 기반
클래식 로드 밸런서로부터 고정 호스트 이름을 부여받음
세번 확인해서 정상이면 인스턴스는 정상인 것이고
연속으로 두번 비정상이 나오면 비정상으로 간주함
클래식 로드밸런서의 DNS 이름을 입력해 접근
인스턴스의 HTTP 인바운드 규칙 제거 > 인스턴스가 공공 인터넷은 물론이고 개인 인터넷에서도 접근을 차단할 것
인스턴스와 로드밸런서 DNS 주소 둘 다 접속이 가능한 문제
(유저들이 직접 인스턴스에 접근하는 것은 차단하자)
인스턴스의 인바운드 규칙을 아까 생성한 로드밸런서의 보안그룹에서만 오도록 지정함
세 개의 인스턴스를 만듦
새로고침할때마다 요청이 다른 EC2 인스턴스로 보내짐
로드밸런서가 요청을 분산시키고 있음
Application Load Balancer (v2)
7계층 HTTP 전용 로드 밸런서
머신 간 다수 HTTP 애플리케이션 라우팅에 사용됨
이러한 머신들은 대상그룹 target group 으로 그룹핑 됨
Load balancing to multiple applications on the same machine ex container ecs
HTTP/2 와 웹소켓을 지원함
리다이렉트를 지원하므로 HTTP에서 HTTPS 로 트래픽을 자동 리다이렉트하는 경우 로드 밸런서 레벨에서 가능함
경로 라우팅 지원
Routing tables to different target groups:
Routing based on path in URL (example.com/users & example.com/posts)
Routing based on hostname in URL (one.example.com & other.example.com)
Routing based on Query String, Headers (example.com/users?id=123&order=false)
ALB 는 마이크로 서비스나 컨테이너 기반 애플리케이션에 가장 적합한 로드밸런서 (ex Docker & Amazon ECS)
포트 매핑 기능이 있우 ECS 인스턴스의 동적 포트로의 리다이렉션이 가능함
클래식 로드 밸런서와 비교를 해보면 다수의 애플리케이션이 있는 경우 여러 개의 클래식 로드밸런서가 필요함(실제 애플리케이션의 개수만큼 로드밸런서 필요)
BUT 애플리케이션 로드 밸런서는 하나만으로도 다수의 애플리케이션을 처리할 수 있음
ALB Target Groups 대상 그룹
EC2 인스턴스들(can be managed by an Auto Scailing Groups) - HTTP
ECS tasks (managed by ECS itself) - HTTP
Lamda 함수 - HTTP request is translated into a JSON event
( * 람다함수는 AWS에서 무서버로 불리는 모든 것들의 기반이 되는 함수임
IP adresses - must be private IPs
ALB 는 여러 대상 그룹으로 라우팅할 수 있으며
상태 확인은 대상 그룹 레벨에서 이뤄짐
애플리케이션 로드밸런서를 사용하는 경우에도 고정 호스트네임이 부여됨
애플리케이션 서버는 클라이언트의 IP를 직접 보지 못함 >
클라이언트의 실제 IP는 X-Forwarded-FOr 라고 불리는 헤더에 삽입됨
We can also get Port(X-Forwarded-Port) and proto (X-Forwarded-Proto)
로드밸런서가 인스턴스와 통신할 때 로드 밸런서 IP(사설 IP)를 사용함
인스턴스가 클라이언트의 IP를 알기 위해서는 HTTP 요청에 있는 추가 헤더인 X-Forwarded-Port와 Proto를 확인해야 함
누군가가 80번 포트에서 HTTP 프로토콜로 접속을 시도하면 허용해줌
Create Target Group
로드밸런서에 생성한 타겟 그룹 지정
누락한 인스턴스 포함한 대상 그룹 하나 더 생성
리스너 규칙 추가
/test 와 경로가 일치하면 second-target-group 으로 이동
인스턴스가 /test 유형의 쿼리에 응답하도록 구성되지 않았기 때문에
/test 시 NOT FOUND
/constant 에는 응답함
Network Load Balancer v2
4계층의 로드밸런서 : TCP나 UDP 기반의 트래픽을 인스턴스로 전달
낮은 계층의 밸런서
초당 수백만건의 요청을 처리할 수 있어 매우 고성능
Less latency ~ 100 ms (vs 400 ms for ALB) ALB 보다 평균 지연시간이 훨씬 작다
NLB has one static IP per AZ, and supports assingning Elastic IP
외부의 가용 영역당 한 개의 고정 IP를 노출함 > 특정 IP를 화이트리스트에 추가할 때 유용함
NLB 자체의 IP를 가져오는 대신 일래스틱 IP 할당을 지원함 (엔트리 포인트를 두 개 얻고자 할 때 NLB를 사용하면 됨)
ex 애플리케이션 전용의 특정 IP를 지정하면 NLB가 해당 트래픅을 인스턴스로 보냄
ALB CLB와의 차이점 > 고정 IP가 없고 고정 호스트 네임만 있음
고성능이나 TCP, or UDP 수준의 트래피을 원할 때 사용됨
NLB - Target Groups
인스턴스
IP 주소 - must be private IPS
자체 데이터 센터에 서버가 있는 경우에는 가급적이면 그대로 개인 IP가 있는 서버의 로드 밸런서를 사용함
Application Load Balancer NLB와 ALB 를 결합할 수 있음 > NLB의 기능을 활용해서 고정 IP를 가질 수 있음
AWS에서 할당한 IPV4를 사용하거나 자체 일래스틱 IP 주소를 할당할 수 있음
가용 영역 당 한 개의 고정 IP 할당 가능함
리스너 관련해서는 80번 포트
HTTP 실행에 TCP 의존함으로써 작동
Gateway Load Balancer
GWLB 는 배포 및 확장과 AWS 의 타사 네트워크 가상 어플라이언스의 플릿 관리에 사용됨
네트워크의 모든 트래픽이 방홥벽을 통과하게 하거나 침입 탐지 및 방지 시스템에 사용됨
IDPS나 심증 패킷 분석 시스테 또는 일부 페이로드를 수정할 수 있지만 네트워크 수준에서 가능함
3계층 네트워크 계층에서 실행됨 > L3 IP
Transparent Network Gateway - single entry/exit for all traffic
대상 그룹의 가상 어플라이언스 집합에 전반적으로 그 트래픽을 분산해 로드 밸런서가 됨
Uses the 6081번 포트의 GENEVE 프로토콜
도표에 3rd party security virtual applicanes 가 존재함
GWLB - Target Groups
EC2 인스턴스
IP 어드레스 must be private IPs
Sticky Sessions Session Affinity
It is possible to implement stickiness so that the same client is always redirected to the same instance behind a load balancer
로드 밸런서 2가지 리퀘스트를 보내는 클라이언트가 리스폰스로서 동일한 인스턴스를 응답받는 것을 의미함
클라이언트3 인스턴스2 이 있을때
1번 클라이언트가 요청을 생성해 첫번째 인스턴스를 통과하면
로드밸런서에서 두번째 요청을 실행할 때도 동일한 인스턴스로 이동함
CLB와 ALB 에서 설정 가능한 동작
The cookie used for stickness has an expiration date you control
고정성과 만료기간 존재 > 쿠키 만료시 클라이언트가 다른 인스턴스로 리다이렉션
사용 예 : make sure the user doesn't lose his session data
세션 만료를 사용시에는 사용자의 로그인과 같은 중요한 정보를 취하는 세션 ㅔ디엍를 잃지 않기 위해 사용자가 동일한 백엔드 인스턴스에 연결됨
고정성을 활성화하면 백엔드 ec2 인스턴스 부하에 불균형을 초래할 수 있음
Stick Sessions - Cookie Names
애플리케이션 기반 쿠키 Application based Cookies
Custom cookie
Generated by target
Can include any custom attributes required by the application
쿠키 이름은 각 대상 그룹별로 개별적으로 지정해야함
Don't use AWSALB, AWSALBAPP, AWSALBTG (ELB에서 사용되는 예약어)
Application cookie
Generated by the load balancer
Cookie name is AWSALBAPP
애플리케이션에서 기간 지정이 가능함
기간 기반의 쿠키 Load balancer generated cookie
Coolie generated by the load balancer 로드밸런서에서 생성되는 쿠키
Cookie name is AWSALB for ALB, AWSELB for CLB
특정 기간을 기반으로 만료되며 그 기간이 로드밸런서 자체에서 생성되는 것
Cross zone Load Balancing
AZ 1 : instance 2개 로드밸런서 1개
AZ 2 : instance 8개 로드밸런서 1개
with cross zone Load Balancing:
each load balancer instances distributes evenly across all registered instances in all AZ
동일한 로드 밸런서 인스턴스로 일반적인 로드 밸런서
클라이언트는 두 로드 밸런서에 엑세스
교차 영역 로드 밸런싱을 사용하면 각 로드밸런서는 전체 가용 영역에 등록된 모든 인스턴스에 전반적으로 고르게 분산됨 > 클라이언트는 50%의 트래픽을 첫번째 ALB 인스턴스에, 나머지 트래픽을 다른 ALB 인스턴스에 보냄
BUT 각 ALB 는 가용 영역에 상관 없이 10개의 인스턴스에 트래픽 리다이렉션
첫번째, 두번째 ALB는 전체 인스턴스에 자기가 받은 트래픽에 10 퍼센트씩을 보냄 >
without Cross zone load balanceing :
Requests are distributed in the instances of the node of the Elastic Load Balancer
첫번째 ALB는 자신이 받은 50 퍼센트의 트래픽을 두개의 인스턴스에 25퍼센트씩 나눠 보냄
두번째 ALB는 자신이 받은 50퍼센트의 트래픽을 8개의 인스턴스에 6.25씩 나눠보냄
교차영역 로드밸런싱 없이도 각 가용영역에 트래픽이 포함됨
BUT 각 가용 영역에 인스턴스 수가 불균형하면 특정 가용영역에 인스턴스가 트래픽을 더 많이 수신함
CLB
애플리케이션 로드 밸런서:
항상 활성화 (비활성화 불가능)
데이터가 한 AZ에서 다른 AZ로 이동히면 원래 비용을 지불해야 하지만 비활성화 옵션이 없으므로 AZ간 데이터 전송에 관한 비용이 없음
네트워크 로드 밸런서:
기본적으로 비활성화
교차 영역 로드 밸런싱 활성화에 비용을 지불해야함
클래식 로드 밸런서:
기본적으로 비활성화
활성화하면 가용 영역 간 데이터 전송에 비용이 발생하지 않음 (비용없이 활성화)
SSL/TLS
SSL 인증서를 사용하면 클라이언트와 로드 밸런서 사이에 전송 중에 있는 트래픽을 암호화 가능함 > in-flight encryption 인플라이트 암호화
SSL은 보안 소켓 계층을 뜻하며 연결을 암호화하는 데 사용됨
TLS는 SSL의 최신 버전 (TLC를 대부분 SSL로 지칭함) 전송계층 보안
Public SSL certificates are issued by Certificate Authorities (CA)
Comodo, Symantex, GoDaddy, GlobalSign, Digicert, Letsencrypt, etc... 등의 CA
웹 사이트에 접속했을 때 초록색 자물쇠가 보이는 경우 트래픽이 암호화되었다는 뜻이고
트래픽이 암호화되지 않은 경우에는 빨간색 표시가 나타나며 신용 카드나 로그인 정보를 넣지 말라는 경고가 나옴
SSL certificates have an expiration date (you set) and must be renewed
로드 밸런서 관점에서의 인증서 작동
USER -HTTPS Over www - LOAD BALANCER - HTTP over private VPC - EC2 instances
유저가 httpS 를 통해 연결
이때 s는 SSL 인증서를 사용하고 있다는 의미임 > 암호화되어 안전한 상태
공용 인터넷을 통해 로드밸런서와 연결됨 (로드밸런서는 내부적으로 SSL 인증서 종료라는 작업을 수행함)
백엔드에서는 인스턴스와 통신할 수 있는데 HTTP를 사용하기 때문에 암호화되어 있지 않음 BUT 트래픽은 어느 정도의 안정성을 보장하는 사설 네트워크인 VPC 를 통해 전송됨
SSL - Server Name Indication
