티스토리 뷰
가용성
서비스 가용성이라고도 표현
워크로드를 사용할 수 있는 시간의 비율이다.
가용성 99% = 3일 15시간
99.999% = 5분
High Availability(고가용성)
- 높은 가용성
- 지속적으로 구현한 시스템이 정상적으로 운영이 되는 성질
- 장애 또는 고장이 나더라도 복구를 해서 서비스를 지속할 수 있는 능력이다.
로드 밸런서 - ELB
Auto scaling group
Rigion
AWS는 Region과 Availability Zone으로 이루어져 있다.
리전은 전 세계에서 데이터센터를 클러스터링하는 물리적 위치이다.
어떤 지역으로 서비스하느냐에 따라, 지리적으로 가까운 Region을 선택한다.
Region code
AWS는 Region 다누이로 별로 서비스되는 형태이다.
Resource는 Region 내 Availability zone 단위로 배포된다.
Availability Zone
Region 내 물리적으로 분리된, 전력 네트워킹 장치가 분리된 영역이다.
보통 AZ 별 데이터 센터가 분리된 구조이다.(AZ 사이는 물리적으로 100km 이내 존재)
AZ 간의 구성
Region은 보통 2~3개의 Availability Zone으로 구성된다.
동일 Region 내 AZ는 전용 광 네트워크로 구성되어, 매우 낮은 지연 속도와 높은 처리량을 보장한다.
AZ간 모든 데이터 트래픽은 기본 암호화되어 있다.
AZ 분산 배치
만약 동일 AZ 내 모든 인스턴스를 배치하는 경우,
해당 AZ 장애 발생시, 본인이 구축한 서비스도 장애로 이어질 수 있다.
동일 역할을 수행하는 인스턴스의 경우, AZ를 분산 배치하여 서비스 가용성을 높이는 것이 좋다.
즉, 같은 Region을 가지나, 가용 영역은 다른 곳에 있는 인스턴스로 일단 서비스를 이어갈 수 있다.
AZ와 VPC
Region은 vpc와 맵핑
AZ는 subnet과 맵핑
인스턴스 생성시, VPC와 subnet을 선택하여 배포하면 된다.
vpc 선택을 할때, 리전을 먼저 선택하고 했다.
subnet을 AZ를 2개 이상을 구성했다. -하나는 a, 하나는 c.
VPC 구성 예
public subnet : 외부 통신용(웹에서 80포트로 접근)
private subnet : public과 private 간 연동용이다.
기본적으로는 인터넷 게이트웨이로 연동되어 있지 않으나, NAT gateway를 통해서 개구멍을 다고 나가게 된다.
보통 프라이빗은 퍼블릭과 연동되어 있다.
외부 통신시 NAT gateway를 통한 단방향 허용
Private subnet 2 : 외부 통신이 안 된다.(아예 단절이 된 것으로 만든다)
이렇게 3개로 나눠서 구성한다.
3tier 구성 = 웹서버, WAS, DB
외부와 통신이 가능 = 웹 서버는 public에 배치,
WAS, DB는 private에 적용한다.
AZ별 subnet 구성
어떤 가용영역에 private이냐 public이냐를 설정한다.
VPC 구성 시, AZ에 따라 subnet을 구성한다.
Total subnet 수 = AZ count * 용도별 subnet을 만든다.
인스턴스 생성시 각 사용처에 맞는 subnet을 선택 후, AZ 별로 분산 구성한다.
각각의 subnet을 AZ 수 만큼 생성한다.
1번 가용영역, 2번 가용영역이 있다.
1번 안에 publuc, private,private2를 만들고,
2번 안에 publuc, private,private2를 만든다.
그렇게 분산해서 구성한다.
서울 리전의 예
ap-northeast-2a, ap-northeast-2b, ap-northeast-2c, ap-northeast-2d
각각 가용영역이 있고,
그 안에 각각 publuc, private,private2(3개 subnet)을 배치한다.
그러면 3*4개 subnet 생성
그리고 나서 각 subnet에 서버를 분산 배치, web 서버는 public subnet에, application 서버는 private subnet에서,
DB는 private2 subnet에 배치한다.
대신에 4중화를 하면 관리 비용이 많이 든다.
그런데 이러면, 분산 배치된 인스턴스로 어떻게 트래픽을 분배할 것인가에 대한 문제가 생긴다.
이래서 로드 밸런서를 쓴다.
로드 밸런서
인입되는 트래픽을 특정 알고리즘 기반으로, 다수의 서버로 분산 시켜주는 장비
AWS ELB(Elastic Load Balancer (ELB)가 있다.
ELB의 특징
- Region 내 인스턴스 및 다양한 서비스로 트래픽 분배 서비스
- 다수의 Availability Zone 으로 트래픽 분배
- HTTP/S 웹 기반 트래픽, TCP/S 프로토콜 기반
- Backend 인스턴스에 대한 Health Check 수행(일을 할 수 있는지에 대해서 체크)
- 고가용성 기반 L4/L7 서비스(네트워크와 어플리케이션)
- Availability Zone 분산 및 Traffic 증가 시 자동 Scale-out 기능 지원
ELB는 4가지 type이 있다.
ALB, NLB, GLB, CLB
ALB는 HTTP의 트래픽 처리가 특화된 L7 로드밸런서
NLB는 TCP/UDP 처리가 특화된 고정 IP 주소 사용 가능한 로드밸런서
GLB는 third-party 가상 어플라이언스 관리를 위한 gateway용 로드밸런서
CLB는 구 로드 밸런서라 사용권장하지 않는다.
Scale-out
트래픽 증가시, 서비스에 투입되는 서버를 증설하여, 각 서버가 처리하는 부하를 낮는 방식이다.
Web based 서비스의 경우 많이 사용하는 구성으로, Session이나 Data 처리 영역 없이 Stateless한 서버에서 주로 사용한다.
Scale in은 반대로 트래픽 감소 시, 배포된 서버를 제거하는 방식이다.
낭비되는 리소스를 줄임으로서, 비용 최적화를 목적으로 한다.
ELB 알고리즘
어떤 규칙으로 트래픽을 인스턴스로 분배할 것인가
- Roud Robin - 기본적인 형태. 공평하게 각각의 연결된 서버들에게 한번씩 일을 하라고 나눠준다.
- Hashing
- Weighted RR - 가중치 라운드 로빈. 라운드 로빈 형태로 분산 시키기 위해서는 모든 서버의 사양이 동일해야 한다.
- ㅇ그렇기에 서버의 성능이 다르면, 그걸 고려해서 분산시켜준다.
- Least Connection
- Weighted LC
NLB(Net work Load Balancer)
L4 로드 밸런서이다, TCP/UDP
ALB(Application Load Balancer)
L7 로드 밸런서이다. Http/https
ELB 헬스체크 기능
주기적으로 서버가 정상 상태인지 확인하고, 정상상태가 아닌 서버에게는 트래픽을 전달하지 않게 하는 기능이다.
NLB의 경우, TCP/UDP 포트 alive check
ALB의 경우, URL 기반 응답 체크(200)
ELB AZ 분산배치
활성화된 Availbility zone에는 로드 밸런서 노드가 자동으로 생성되어 배치된다.
기본적으로 해당 AZ에 배치된 타겟(인스턴스)는 해당 AZ의 로드밸런서 노드가 트래픽을 처리한다.
ELB 생성시 AZ 활성화가 필요하다.
체크만 잘 해주면 된다.
LB 등록시 활성화하지 않은 AZ에 배치된 타겟(인스턴스)에는 트래픽이 수신되지 않는다.
Cross-Zone Load Balancing
교차 영역의 로드 밸런싱이 활성화 되면, 로드 밸런서가 위치한 Availability zone과 상관 없이 타겟 Availability zone에 있는 모든 인스턴스에 트래픽 라우팅이 가능하다.
Application LoadBalancer (ALB)는 Cross-Zone LB가 기본 활성화
Network LoadBalancer(NLB)는 기본 비활성화
트래픽이 전달이 되면, 원래는 가용영역 a에만 전달되나, a에 전달이 되더라도, b에도 전달되도록 한다.
NLB는 활성화 시켜 줘야 한다.
역시 마찬가지로 LB 등록시 활성화하지 않은 AZ에 배치된 타겟(인스턴스)에는 트래픽이 수신되지 않는다.
만약 비활성화 상태이면, 로드 밸런서 노드가 위치한 AZ에 상주하는 타겟 인스턴스에게만 라우팅 가능
AZ에 위치한 인스턴스마다 균일한 부하 분산이 어렵다.
모든 AZ에서 각각의 인스턴스들이 공평하게 부하 분산을 하려면, 켜져 있는 게 맞다.
Auto Scaling Group
Scaling을 자동으로 : Auto Scaling
Scale-out과 Scale-in
1. Auto sclaing은 무엇으로 대상을 할 것인가?
Launch Template : AMI, Instance, Type 등 Instance에 대한 정의
어떤 가게에 적용하는가
2. 자동 설정 정책을 어떻게 설정할 것인가?
알바를 해고할 조건, 고용할 조건
Auto Scaling Group : Desired Capacity, Min/Max size, Target Group 등 자동 확장에 대한 정의
Launch Template
인스턴스를 배포하기 위한 정보들의 묶음
AMI, Instance Type, Keypair, Security Group, Network 와 같은 기본 정보
IAM Role, Userdata, Tags, 등 추가 정보를 미리 Template 으로 정의 가능
사용자는 해당 Template 을 그대로 인스턴스로 배포 하는데 사용
해당 인스턴스가 가져야 하는 역할들
Auto Scaling Group의 구성 단계
1. Launch Template 고르기
2. ELB 구성
3. Auto Sclaing Group
특정 부하가 많아지면 자동으로 확장을 하거나 축소를 한다.