【한글자막】 AWS Certified Solutions Architect Professional | Udemy
2023.01.06 - [DevOps/aws] - Udemy | AWS Certified Solutions Architect Associate 강의 | Section1~2
2023.01.09 - [DevOps/aws] - AWS Certified Solutions Architect Associate 강의 Udemy | Section 5: EC2 기초
69. 고가용성 및 스케일링성
Scalability & High Availability
확장성은 애플리케이션 시스템이 조정을 통해 더 많은 양을 처리할 수 있음을 의미
확장성의 두가지 종류
1. 수직 확장성- 인스턴스의 크기를 확장
2. 수평 확장성- 탄력성이라고 불림
확장성과 고가용은 다른 개념이다
Vertical Scalability
ex 신입 전산원은 1분에 전화 5통 소화 가능하지만
경력직은 1분에 전화 10통을 소화한다.
-> 더 빠르고 능숙함.
t2.micro -> t2.large 로 교체
언제?사용
데이터베이스와 같이 분산되지 않은 시스템에 유용하다.
RDS, ElasticCache 등에서 사요ㅇ
하위 인스터스의 유형을 업그레이드해 수직적으로 확장할 수 있는 시스템이다.
일반적으로 확장할 수 있는 정도에는 한계가 있다.
Horizontal Scalability
ex) 전산원을 늘리는 것
수평 확장을 했다는 것은 분배 시스템이 있다는 것을 의미
현대 애플리케이션은 대부분 분배 시스템으로 이루어져 있다.
ec2에서 매우 쉽다.
High Availability
고가용성이란 애플리케이션 또는 시스템을 적어도 둘 이상의 aws의 az 나 데이터 센터에서 가동 중이라는 것을 의미한다.
고가용성의 목표는 데이터 센터에서의 손실에서 살아남는 것으로 센터 하나가 멈춰도 계속 작동이 가능하게 끔하는 것
예를 들어 뉴욕에도 콜센터가 있고 샌프란시스코에도 콜센터가 있다.
뉴욕 지사에 문제가 생길 경우 샌프란시스코에서 처리를 해줄 수 있다.
RDS 다중 az를 갖추고 있다면 수동형 고가용성(수평형 확장)을 확보한 것이다.
활성형 고가용성 ( 수직적 확장)
High Availability Scalability For EC2
현재 가장 작은 인스턴스는 t2.nano 0.5 gb 램에 1v cpu 이고
가장 큰 인스턴스는 u-t12tb1.metal로 12.3 tb 램을 갖춘 450vCpus 가 있다.
수평확장 은 스케일 아웃 스케일 인
스케일 아웃: 인스턴스 수를 늘림
스케일 인 : 인스턴스 수를 줄임
다른 스케일링 그룹이나 로드 밸런서에도 사용한다.
고가용성은 같은 애플리케이션의 동일 인스턴스를 다수의 AZ 에 걸쳐 실행하는 경우를 의미한다.
다중 AZ 가 활성화된 자동 스케일러 그룹이나 로드밸런서에도 사용된다.
70. Elastic Load Balancing (ELB) 개요
what is load balancing?
로드 밸런서는 서버 혹은 서버셋으로 트래픽을 백엔드나 다운스트림 EC2 인스턴스 또는 서버들로 전달하는 역할을 한다.
ELB는 첫번째 유저는 첫번째 인스턴스
두번째 유저는 두번째 인스터스로 ... 연결한다
유조들은 자신들이 백엔드 인스턴스 중 어떤 것에 연결되어 있는지 알 수 없다.
자신들이 ELB 에 연결되면 한 엔드 포인트에 연결이 된다는 것만 안다.
Why use a load balancer?
1. 부하를 다수의 다운스트림 인스턴스로 분산하기 위해서이다.
2. 단일 액세스 지저 (DNS) 를 노출한다.
3. 다운스트림 인스턴스의 장애를 원활히 처리할 수 있다.
4. LB가 상태확인 메커니즘으로 어떤 인스턴스로 트래픽을 보낼 수 없는지 확인해준다.
5. SSL 종료도 할 수 있으므로 웹사이트에 암호화된 HTTPS 트래픽을 가질 수 있다.
6. 쿠키로 고정도를 강화할 수 있고
7.여러 az에 걸쳐 고가용성 확보도 가능하며
8. 공용 트래픽과 사설 트래픽을 분리할 수 있다.
ELB는 완전 관리형 로드 밸런서이다 .
aws 가 관리하며 어떤 경우에도 작동할 것을 보장한다.
업그레이드와 유지 관리 및 고가용성을 책임지며 로드 밸런서의 작동 방식을 수정할 수 있게끔 일부 구성 놉(knobs)도 제공한다.
자체 로드 밸런서를 마련하는 것보다 저렴하고 확장성도 용이하다.
다수의 aws 서비스와 통합되어 있다. (뛰어난 확장성)
ECS, ACM, CloudWatch, Route 53 , WAF Global Accelerator 등
ELB 를 쓰는것이 무조건 이득이다.
Health Checks 상태 확인
상태 확인은 ELB가 EC2 인스턴스의 작동이 올바르게 되고 있는지의 여부를 확인하기 위해 사용된다.
상태 체크를 통해 해당 인스턴스로 트래픽을 보낼지 말지 여부를 정한다.
상태 확인은 포트와 라우트에서 이루어진다.
예를 들어 HTTP 프로토콜, 포트는 4567 엔트포인트는 /health 가 있다.
HTTP 상태코드 200으로 응답하지 않는다면 인스턴스 상태가 좋지 않다고 기록된다.
그리고 ELB는 그쪽으로 트래픽을 보내지 않게 된다 .
Types of load balancer on AWS
4개의 관리형 로드 밸런서가 있다.
1세대
v1, 2009년
CLB 라고 불림 classic
http, https, tcp ,ssl , secure tcp 를 지원
권장하지 않음.
사용이 가능하긴하마.
애플리케이션 로드밸런서 V2
v2, 2016
HTTP, HTTPS, websocket
네트워크 로드 밸런서
v2 , 2017
TCP, TLS (secure TCP), UDP
게이트웨이 로드밸런서
GWLB, 2020
3계층과 ip 프로토콜에서 작동
웬만해선 최신형 LB를 사용하자!
일부 로드 밸런서들은 내부에 설정 될 수 있어 네트워크에 개인적 접근이 가능하고
웹사이트와 공공(public) 애플리케이션 모두에 사용이 가능한 외부 (private)공공 로드 밸런서도 있다.
Load Balancer Security Groups
1. LB의 SG는 ...
[SGforLB]
http, tcp, 80, 0.0.0.0/0
https, tcp, 443, 0.0.0.0/0
이라면 해당 LB와 연결되는 인스턴스의 sg는
2. 인스턴스의 SG는
http, tcp, 80 , SGforLB
인스턴스의 소스는 SGforLB가 된다. -> elb에서만 접근할 수 있다.
강화된 보안 매커니즘이다. SG가 연동된다!
71. Classic Load Balancer (CLB 공지)
Note: About the Classic Load Balancer (CLB)
The Classic Load Balancer is deprecated at AWS and will soon not be available in the AWS Console.
The exam also has removed any references to it, so we will not cover it in depth in the course, nor the hands-on
Happy learning!
classic loadbalancer는 시험에 나오지 않는다.!
72,73 은 clb 관련된 내용이라서 건너 뛰겠습니다.
74. Application Load Balancer (ALB) 개요
Application Load Balancer (v2)
애플리케이션 로드 밸런서는 7계층이다.
머신 간 다수의 HTTP 애플리케이션의 라우팅에 사용된다.
이러한 머신들은 대상 그룹이라는 그룹으로 묶이게 된다.
동일 EC2 인스턴스 상의 여러 애플리케이션에 부하를 분산한다.
(컨테이너와 ECS를 사용하게 된다.)
HTTP/2, WebSocket을 지원하며 리다이렉트도 지원하므로
HTTP에서 HTTPS 로 트래픽을 자동 리다이렉트 하려는 경우
로드밸러서 레벨에서 가능하다.
경로 라우팅을 지원
Routing tables to different target groups: 대상 그룹에 따른 라우팅으로
1. URL 대상 경로에 기반한 라우팅이 가능하다.
example.com/users & example.com/posts
2.host name에 기반한 라우팅
one.example.com & other.example.com
3. Query String, Headers 에 기반한 라우팅
example.com/users?id=123&order=false
애플리케이션 로드 밸런서의 약자로 ALB
마이크로 서비스, 컨테이너 기반 애플리케이션에 가장 좋은 로드밸런서
Docker ,ECS 와 가장 적합한 LB
포트 매핑 port mapping 기능이 있어 ECS 인스턴스의 동적 포트로의 리다이렉션을 가능하게 해준다.
CLB 에서 구현하려면 다수의 LB가 필요하지만 ALB는 하나만으로 다수의 애플리케이션을 처리할 수 있다.
Application Load Balancer (v2) HTTP Based Traffic
외부 ALB 가 있고 뒤에 EC2 인스턴스로 구성된 대상그룹이 2개 있다.
Route/user 는 1번째 인스턴스로 라우팅 되고
Route/search 는 2번째 인스턴스로 라우팅 된다.
URL 에서 사용되는 라우팅을 기반으로해 각 대상 그룹을 지능적으로 라우팅한다. (ALB의 역할)
대상 그룹이란? target group?
EC2 가 될 수도 있다. (ASG 도 대상 그룹이 될 수 있다.)
ECS 작업이 될 수도 있다.
람다함수도 가능하지만 잘안쓰임. HTTP 요청이 JSON 이벤트로 변환된다.
IP 주소 앞에 ALB를 둘 수 있지만 무조건 사설 네트워크 여야한다
ALB는 여러개의 대상 그룹으로 라우팅 할 수 있으며
상태 확인 (health check)는 대상 그룹 레벨에서 이루어진다. ?
Application Load Balancer( v2) Query String/ Parameters Routing
첫번째 대상 그룹은 EC2
두번째 대상 그룹은 온프레미스라고 하자
대상 그룹이 존재하기 위해서는 , 등록을 위해서는 서버의 사설 IP 가 대상 그룹에게 지정되어야한다.
-> 대상그룹 2를 쓰고 싶으면 사설 IP를 등록해야한다.
쿼리 내용을 기반으로 다른 대상 그룹을 연결 시키는 예시이다.
Application Load balancer (v2) Good to know
로드 밸런서를 사용하는 경우에도 고정 호스트 이름이 부여된다.
애플리케이션 서버는 클라이언트의 IP를 직접 보지 못한다.
클라이언트의 실제 IP는 X-Forwarded-For 라고 불리는 헤더에 삽입된다.
X-Forwarded-Port 를 사용하는 포트와 X-Forwarded-Proto 에 의해 사용되는 프로토콜을 얻는다.
즉 클라이언트의 IP인 12.34.56.78 가 로드밸런서와 직접 통신해 연결 종료라는 기능을 수행한다.
로드밸런서가 EC2 인스턴스와 통신할 때에는 사설 IP인 로드밸런서 IP를 사용해 EC2 에 들어가게 된다.
EC2 인스턴스가 클라이언트의 IP를 알기 위해서는 HTTP 요청에 있는 추가 헤더인 X-Forwarded-port, proto를 확인해야한다. (간접적으로 확인)
75. Application Load Balancer (ALB) 실습 Part 1
ALB 생성하기
HTTP, HTTPS를 고르자
1단계 : Load Balancer 구성
DemoALB
인터넷 경계
IPv4
가용 영역 선택
가용 영역당 1개의 서브넷만 지정할 수 있다.
리스너 구성
2단계는 보안 설정 구성인데
뒤에 가서 하자.
3단계 : 보안 그룹 구성
4단계: 라우팅 구성
새 대상 그룹을 만든다. my-first-target-group
상태 검사 옵션 값은 위와 같이 한다.
5단계: 대상 등록
대상 그룹에 등록할 인스턴스가 없기 때문에 생성하러 가자
인스턴스 등록
#!/bin/bash
# Use this for your user data (script from top to bottom)
# install httpd (Linux 2 version)
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "<h1>Hello World from $(hostname -f)</h1>" > /var/www/html/index.html3개 만들기 , 같은 서브넷으로 만든다.
대상 그룹에 인스턴스 2개만 추가하자.
ALB 체크하기
생성된 DNS 로 접속해보자
계속 타임 아웃이 뜨길래 보안그룹 문제라고 생각했다.
alb의 보안그룹은 80번 포트로 모든 소스에 열려있다.
인스턴스의 보안그룹은 22번 포트로 모든 소스에 열려있다.
alb에서 인스턴스로 들어갈려면 80번 포트를 열고 alb의 sg를 소스로 하는 인바운드 규칙을 추가한다.
하나의 주소로 두개의 인스턴스에 접속 가능하다.
또다른 대상 그룹 생성하기
아무 인스턴스나 등록해서 second-target-group 을 생성했다.
리스너 설정하기
demo alb로 이동한다. 규치 보기/편집으로 간다 ( 현재 DemoELB는 first-target-group 으로 연결된다.)
만약 /test 경로를 입력하면 second-target-group으로 연결되게 한다.
/constant 에 연결하면 고정 에러 페이지가 나오게 한다.
여러가지 다른 방식으로 응답하게 설정했다.
test 로 접속하면 두번째 대상 그룹 화면이 떠야하는데 오류가 뜬다.
EC2 인스턴스가 /test 유형의 쿼리에 응답하도록 구성되지 않았기 때문이다.
정리
리스너 삭제
대상 그룹 두번째 삭제
첫번째 대상그룹에 나머지 인스턴스 추가
76. Network Load Balancer (NLB) 개요
Network Load Balancer (v2)
네트워크 로드 밸런서는 L4 로드 밸런서이미로 TCP, UDP 트래픽을 다룰 수 있다.
HTTP를 다루는 L7보다 하위 계층이다.
네트워크 로드 밸런서의 성능은 매우 높다.
초당 수백만 건의 요청을 처리할 수 있다.
애플리케이션 로드 밸런서에 비해 지연 시간도 짧다.
ALB는 400밀리초지만 NLB는 100 밀리 초이다.
가용 영역별로 하나의 고정 IP를 갖는다. NLB has one static IP per AZ, and supports assigning Elastic IP
탄력적 IP 주소를 각 AZ에 할당할 수 있다.
여러개의 고정 IP를 가진 애플리케이션을 노출할 때 유용하다.
1~3개의 ip로만 액세스할 수 있는 애플리케이션을 만들라는 문제가 나오면 네트워크 로드 밸런서를 옵션으로 고려하자!
고성능, TCP, UDP는 다 네트워크 로드 밸런서의 키워드이다.
NLB는 프리티어에 포함되지 않는다.
Network Load Balancer (v2) TCP (Layer 4 ) Based Traffic
대상 그룹을 생성하면 NLB 가 대상그룹을 리다이렉트한다.
백엔드, 프론트엔드 모두 TCP 트래픽을 사용하거나
백엔드에서는 HTTP를 , 프론트엔드에서는 TCP 를 사용할 수 있다.
Network Load Balancer - Target Groups 대상 그룹 유형
EC2 인스턴스 - 네트워크 로드밸런서가 TCP 또는 UDP 트래픽을 EC2 인스턴스로 리다이렉트 할 수 있다.
IP 주소 - IP주소는 반드시 하드코딩 되어야하고 프라이빗 IP여야한다. 주로 온프레미스가 대상이된다.
ALB - NLB는 고정된 IP를 가지고 ALB는 HTTP 유형의 트래픽을 처리할 수 있다.
상태 체크는 TCP, HTTP, HTTPS 프로토콜을 지원한다. (시험에 나온다.)
77. Gateway Load Balancer (GWLB) 개요
GWLB는 배포 및 확장과 aws의 타사 네트워크 가상 어플라이언스의 플릿 관리에 사용된다.
GWLB는 네트워크의 모든 트래픽이 방화벽을 통과하게 하거나 침입 탐지 및 방지 시스템에 사용한다.
IDPS 나 심층 패킷 분석 시스템 또는 일부 페이로드를 수정할 수 있지만 네트워크 수준에서 가능하다.
alb에서 애플리케이션으로 이동할 때 모든 트래픽을 검사하게 할려면 ?
유저와 어플리케이션 사이에 GWLB를 둔다. + 타사 가상 어플라이언스 배포
GWLB를 생성하면 이면에서는 VPC 에서 RT (라우팅 테이블) 이 업데이트 된다.
RT 가 업데이트 되었으므로 사용자의 모든 트래픽은 GWLB를 통과하고 -> 타사 가상 어플라이언스 -> GWLB -> 애플리케이션 순으로 트래픽이 이동한다.
방화벽이나 침입 탐지와 같은 것이다 .
원리는
GWLB는 IP 패킷의 네트워크 계층인 L3 이다.
기능
1. 투명한 네트워크 게이트웨이 ( 하나의 출입문 역할)
2. 로드 밸런서
6081 번 포트의 GENEVE 프로토콜
Gateway Load balancer - Target Groups
1. EC2 - 타사 어플라이언스
2. IP 주소 - 이 경우 개인 (private)IP 여야한다. 자체 네트워크나 자체 데이터 센터에서 이런 가상 어플라이언스를 실행하면 IP로 수동 등록할 수 있다.
78. Elastic Load Balancer - 스티키 세션(Sticky Sessions)
It is possible to implement stickiness so that the sam client is always redirected to the same instance behind a a load balancer
로드 밸런서에서 2가지 요청을 수행하는 클라이언트가 요청에 응답하기 위해 백엔드에 동일한 인스턴스를 갖는 것이다.
클라이언트의 요청에 대한 응답을 동일한 인스턴스가 담당하도록 LB 에 조정하는 일
clb, alb 에서 가능하다.
client1 의 요청은 1번 ec2 에서 고정하고
다른 client의 요청은 다른 ec2에서 기억하고 응답한다.
쿠키: 클라이언트에서 로드 밸런서로 요청의 일부로 전송된다.
고정성과 만료 기간도 있다.
쿠키가 만료되었을시 다른 EC2 인스턴스로 리디렉션 된다
고정성을 활성화하면 백엔드 EC2 인스턴스 부하에 불균형을 초래할 수 있다.( 응답한 놈만 응답하기 때문에)
Sticky sessions - cookie Names
고정 세션에는 애플리케이션 기반 쿠키와 기간 기반의 쿠키가 있다.
애플리케이션 기반 쿠키
사용자 정의- 사용자 정의 쿠키로 애플리케이션에서 생성된다.
애플리케이션에 필요한 모든 사용자 정의 속성을 포함할 수 있다.
쿠키 이름은 각 대상 그룹별로 개별적으로 지정해야하는데
AWSALB, AWSALBAPP, or AWSABLTG 등의 이름을 사용할 수 없다.
애플리케이션 쿠키
로드밸런서가 생성하며 쿠키이름은 AWSALBAPP 이다 .
기간 기반 쿠기 Duration-based Cookies
로드밸런서가 생성하는 쿠키이다.
쿠키이름은 AWSALB for ALB, AWSELB for CLB 이다.
실습- 쿠키 이용하기
위에서 생성한 ALB 의 주소로 접속하면
매번 다른 인스턴스로 접속한다.
고정 세션 활성화 하기
원래 옵션이 더 많은데
일단 진행
계속 똑같은 인스턴스만 응답
AWSALB 쿠키가 생겼으므로 세션기반 쿠키
고정성 삭제하고 마무리
79. Elastic Load Balancer - 크로스존 로드밸런싱( Cross Zone Load Balancing)
교차 영역 로드 밸런싱에 관해 알아보자
교차 영역 로드 밸런싱을 하면 모든 인스턴스에 고르개 트래픽을 분산 시킨다.
로드밸런서로는 50 ,50 씩 분배하지만
모든 인스턴스를 묶어서 10개니까 10%씩 고르게 분산 시킨다 .
교차 영역 로드 밸런싱을 꺼버리면 로드밸런서 50, 50 씩 트래픽을 가져가고
로드 밸런서 기준으로 분배한다.
특정 인스턴스에만 부하가 걸린다.
ALB 에서는 교차 영역 로드 밸런싱이 늘 활성화 되어있고 비활성화할 수 없다.
보통 데이터가 한 가용 영역에서 다른 가용 영역으로 이동하면 비용을 지불해야한다.
하지만 활성화되어 비활성화할 수 없으니 ALB에서 AZ간 데이터 전송에 관한 비용이 업삳.
NLB는 교차 영역 로드 밸런싱이 비활성화되어 있기 때문에 az 간 데이터 이동에 대한 비용을 지불해야한다.
CLB 는 비활성화가 디폴트 이지만 활성화 후 az 간 데이터 전송은 무료이다.
80. Elastic Load Balancer( ELB) - 연결 트레이닝
연결 드레이닝 - Connection Draining
CLB - 연결 드레이닝
ALB, NLB- 등록 취소 지연 이라고 불린다.
인스턴스가 등록 취소, 혹은 비정상 상태에 있을 때 인스턴스에 어느 정도의 시간을 주어
인-플라이트 요청(in-flight request), 즉 활성 요청을 완료할 수 있도록 하는 기능이다.
ELB는 등록 취소 중인 EC2 인스턴스로 새로운 요청을 보내지 않는다.
1초에 3600초 까지 지연시간을 설정할 수 있다.
지연 시간을 0으로 설정하면 이 기능을 비활성화 할 수 있다.
짧은 요청의 경우에는 낮은 값으로 설정한다.
1초보다 적은 아주 짧은 요청인 경우에는 연결 드레이닝 파라미터를 30초 정도로 설정한다.
요청 시간이 매우 긴 요청은 높은 값을 지정한다.
81. Auto Scailing Group (ASG) 개요
What's an Auto Scaling Group?
웹사이트 방문자가 갈수록 많아지면서 워크로드가 바뀔 수 있다.
AWS 에서 EC2 인스턴스 생성 API 호출을 통해서 서버를 빠르게 생성하고 종료할 수 있다.
ASG는 해당 작업을 자동화한다.
ASG의 목적
Scale out - EC2 인스턴스를 늘리는 것
Scale in - EC2 인스턴스를 줄인다.
최소, 최대 인스턴스 수를 보장한다.
로드 밸런서와 페어링하는 경우 ASG에 속한 모든 EC2 인스턴스가 로드 밸런서에 연결된다.
인스턴스에 문제가 생기면 종료하고 새로운 인스턴스를 실행한다.
ASG 는 무료이다. 실행되는 ec2 인스턴스는 유료
Auto Scaling Group in AWS
minimum size : 최소
actual Size/ Desired capacity : 희망
Maximum size : 최대
Auto Scaling Group in AWS With Load Balancer
ASG는 LB와 좋은 조합이다.
사용자 -> ELB -> ASG -> EC2
ELB에서 EC2 instance 상태 체크가 가능하다.
상태에 문제가 있으면 종료 시키고 새로운 인스턴스를 생성하거나,
ELB가 트래픽을 ASG의 인스턴스로 분배한다.
Auto Scaling Group Attributes
ASG 에서 인스턴스를 추가할때 탬플릿을 기반으로 생성한다.
탬플릿에는 AMI, 인스턴스 타입, 사용자 데이터 ,EBS 볼륨, 보안 그룹, SSH key pair, IAM Roles for your EC2 Instances
Network + Subnets Information
Load balancer Information
등 다양한 정보를 가진다.
asg에서 최소, 최대, 초기 용량을 정해야한다.
스케일링 정책도 정해야한다 .
Auto Scaling - CloudWatch Alarms & Scaling
클라우드 워치 알람을 이용하여 asg의 스케일링을 이용할 수 있다.
metric 지표에 의해 경보를 울린다. ( average CPU, or a custom metric)
경보에 따라 인스턴스를 늘리거나 줄인다.
82. Auto Scaling Group ( ASG 실습)
오토 스케일링 그룹을 생성해보자!
1. 기존의 인스턴스 삭제
모두 종료
2. ASG 생성하기
DemoASG 로
2-1 시작 템플릿 생성
#!/bin/bash
# Use this for your user data (script from top to bottom)
# install httpd (Linux 2 version)
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "<h1>Hello World from $(hostname -f)</h1>" > /var/www/html/index.html
2-2 인스턴스 시작 옵션 선택
가용 영역은 3개 선택
시작 탬플릿 재정의에 여러 옵션을 덮어쓰기 할 수 있으나 패스한다.
2-3 고급 옵션 구성
기존 로드밸런서에 연결한다.
이미 생성했던 DemoALB 에 연결한다 .
ELB 에서도 상태 확인을 한다.
2-4 그룹 크기 및 크기 조정 정책 구성
asg의 크기를 정한다.
2-5 생성완료
생성 완료 되었다.
3. ASG 확인하기
최소 를 1로 했기 때문에 인스턴스가 작동한다.
DemoASG 인스턴스가 생성되었다.
asg 설정에서 ELB 를 선택했고 해당 ELB는 first-target-group 에 연결되어있고
해당 그룹은 DemoASG 인스턴스와 연결되어있다.
alb에 접속할 수 있다.
3-1 그룹 크기 변경해보자
2,2,4 로 변경했다..
인스턴스가 두개나 실행된다 .
인스턴스 2개에 접속한다.
마지막으로 크기를 1,1,1 로 변경한다.
83. Auto Scaling Groups - Dynamic Scaling Policies
동적 확장 정책의 종류
1. 대상 추적 스케일링
가장 쉽다.
기본 기준선을 세우고 상시 가용 가능하도록한다.
ex) asg 평균 cpu 사용률이 40% 가 유지되게 한다.
2. 단순과 단계 스케일링
좀 복ㄱ잡하다
CloudWatch 경보를 설정하고 다음과 가팅
전체 ASG 에 대한 CPU 사용률이 70%를 초고하는 경우 용량을 두 유닛 추가하도록 설정한다.
~~ 30% 이하로 떨어지면 유닛 하나를 제거한다.
등의 설정을 할 수 있다.
단 CloudWatch 경보를 설정할 때에는 한 번에 추가할 유닛의 수와 한번에 제거할 유닛의 수를 단계별로 설정할 필요가 있다.
3. 예약된 작업 reserved Scaling
나와 있는 사용 패턴을 바탕으로 스케일링을 예상하는 것.
예를 들어 금요일 오후 5시에 큰 이벤트가 예정되어 있으니 여러 사람들이 애플리케이션을 사용하는 데에 대비해 여러분의 ASG 최소 용량을 매주 금요일 오후 5시마다 자동으로 10까지 늘린다.
4. 예측 스케일링 Predictive Scaling
예측 스케일링을 통해서 AWS 내 오토 스케일링 서비스를 활용하여 지속적으로 예측을 생성할 수 있다.
로드를 보고서 다음 스케일링을 예측한다.
시간에 걸쳐 과거 로드를 분석하고 예측이 생성된다.
해당 예측을 기반으로 사전에 스케일링 작업이 예약된다.
Good Metrics to scale one
지표로 삶기 좋은 항목
1. CPU 사용량
2. 요청 회수
3. 네트워크 입출력 ( 네트워크 과부하)
4. cloudWatch 에서 별도 지표를 직접 설정
Auto Scaling Groups - Scaling Cooldowns
스케일링 휴지 (Scaling cooldown)
- 스케일링 작업이 끝날 때마다 인스턴스의 추가 또는 삭제를 막론하고 기본적으로 5분 혹은 300초의 휴지 기간을 갖는다.
휴지 기간에는 ASG가 추가 인스턴스를 추가 또는 종료할 수 없다.
이는 지표를 활용하여 새로운 인스턴스가 안정화될 수 있도록 하며 어떤 새로운 지표의 양상을 살펴보기 위함이다.
따라서 스케일링 작업이 발생할 때에 기본으로 설정한 휴지가 있는지 확인해야한다.
조언: 즉시 사용이 가능한 AMI 를 이용하여 EC2 인스턴스 구성 시간을 단축하고 이를 통해 요청을 좀 더 신속히 처리하는 것이 좋다.
84. Auto Scaling Group (ASG) - 스케일링 정책 실습
동적 크기 조정 정책만 실행할 것이다.
(예측 크기 조정 정책은 머신 러닝으로 1주일 이상 돌려야한다. )
동적 크기 조정 정책 생성
대상 추적 크기 조정, 단계 크기 조정, 단순 크기 조정이 있다.
단계를 여러 조건을 단계 단계 지정할 수 있고
단순 크기 조정은 1개
여기서는 대상 추적 크기 조정만 할거다.
생성되었다.
asg 크기를 1,1,3으로 변경
EC2 스트레스 테스트 하기
인스턴스에 접속해서 해당 명령을 해보자
sudo amazon-linux-extras install epel -y
sudo yum install stress -y
stress -c 4 명령어를 하면 CPU 의 모든 코어를 100% 쓸 때까지 과부하를 준다 .
자세히 보면 점으로 CPU 사용률이 증가한 것을 볼 수 있다.
작업 기록을 보면 대상 추적 알람이 실행되고 capa 를 늘렸다 .
인스턴스를 종료 하거나 재부팅 하면 명령어가 초기화 되니까 cpu 사용률이 낮아진다.
Quiz 5: 고가용성 & 확장성 퀴즈
1. EC2 인스턴스를r4.large에서 r4.4xlarge로 확장하는 것은 .....................(이)라고 합니다.
2. EC2 인스턴스의 수를 스케일링하는 오토 스케일링 그룹을 실행하는 것은 .....................(이)라고 합니다.
3. Elastic Load Balancer는 .......................(을)를 제공합니다.
AWS에서 관리하는 기반 인프라가 변경되었다고 하더라도, AWS가 정적 엔드 포인트를 사용해 로드 밸런스로 액세스할 수 있기를 원하는 이유입니다.
4. Elastic Load Balancer가 관리하는 10개의 EC2 인스턴스 상에서 웹사이트를 실행 중입니다. 웹사이트의 사용자들은 웹사이트에서 다른 페이지로 이동할 대마다 새로 인증을 해야한다는 점에 대해 불만을 토로하고 있습니다. 하지만 여러분의 기기와 하나의 EC2 인스턴스를 지닌 개발 환경에서는 아무 문제 없이 작동을 하고 있기 때문에 곤혹스러운 상황입니다. 무엇이 원인일까요?
ELB 고정 세션 기능은 동일한 클라이언트에 대한 트래픽이 항상 동일한 대상으로 리다이렉트되도록 해줍니다(예: EC2 인스턴스) 이는 클라이언트들이 세션 데이터를 소실하지 않게 해줍니다.
5. Application Load Balancer를 사용해 EC2 인스턴스에서 호스팅된 웹사이트의 트래픽을 분배하고 있습니다. 그런데 여러분의 웹사이트가 Application Load Balancer의 IP 주소인 사설 IPv4 주소에서 들어오는 트래픽만을 확인하고 있는 것으로 나타났습니다. 이런 경우, 웹사이트로 연결된 클라이언트들의 IP 주소를 받으려면 어떻게 해야 할까요?
Application Load Balancer를 사용하여 EC2 인스턴스에 트래픽을 배분하는 경우, 요청을 받게 되는 IP 주소는 ALB의 사설 IP 주소가 됩니다. 클라이언트의 IP 주소를 받기 위해, ALB는 클라이언트의 IP 주소를 포함하고 있는 X-Forwarded-For라는 헤더를 추가합니다.
6. Elastic Load Balancer가 관리하는 한 세트의 EC2 인스턴스 상에 애플리케이션을 호스팅했습니다. 일주일 후, 사용자들은 가끔씩 애플리케이션이 작동하지 않는다며 호소하기 시작했습니다. 문제점을 조사한 결과, 일부 EC2 인스턴스가 이따금 충돌한다는 문제점이 발견되었습니다. 사용자들이 충돌하는 EC2 인스턴스에 연결되지 않도록 보호하기 위해서는 어떻게 해야 할까요?
ELB 상태 확인을 활성화하면, ELB가 비정상(충돌) EC2 인스턴스로는 트래픽을 보내지 않게 됩니다.
7. 어떤 기업에서 솔루션 아키텍트로 근무하고 있는 여러분은 1초에 수백만 개의 요청을 받게 될 고성능의, 그리고 지연 시간이 적은 애플리케이션을 위한 아키텍처를 설계해달라는 요청을 받았습니다. 다음 중 어떤 종류의 Elastic Load Balancer를 사용해야 할까요?
Network Load Balancer는 애플리케이션이 필요로 할 경우 가장 높은 성능과 가장 낮은 지연 시간을 제공합니다.
8. Application Load Balancer가 지원하지 않는 프로토콜을 고르세요.
9.Application Load Balancer는 트래픽을 다른 대상 그룹으로 라우팅할 수 있습니다. 이때 확인할 내용으로 사용할 수 없는 것을 고르세요
ALB는 URL 경로, 호스트 이름, HTTP 헤더 및 쿼리 문자열을 기반으로 트래픽을 다른 대상 그룹으로 라우팅할 수 있습니다.
10. Application Load Balancer의 대상 그룹에 등록된 대상이 될 수 없는 것을 고르세요.
11. 규정 준수를 위해, 고정된 정적 IP 주소를 최종 사용자에게 노출하여 사용자들이 안정적이고, 규제 기관의 승인을 받은 방화벽 규칙을 작성할 수 있도록 하려 합니다. 이런 경우, 다음 중 어떤 종류의 Elastic Load Balancer를 사용해야 할까요?
Network Load Balancer는 AZ 당 하나의 정적 IP 주소를 가지며, 여기에 탄력적 IP 주소를 연결할 수 있습니다. Application Load Balancer와 Classic Load Balancer를 정적 DNS 이름으로 사용할 수 있습니다.
12. Application Load Balancer 내에 사용자 지정 애플리케이션 기반 쿠키를 생성하려 합니다. 다음 중 쿠키의 이름으로 사용 가능한 것은 무엇인가요?
다음의 쿠키 이름은 ELB가 선점하고 있습니다(AWSALB, AWSALBAPP, AWSALBTG).
13. us-east-1에 있는 한 세트의 EC2 인스턴스에 트래픽을 배분하는 Network Load Balancer가 있습니다. us-east-1b AZ에 2개의 EC2 인스턴스, us-east-1e AZ에는 5개의 EC2 인스턴스가 있습니다. 여러분은 us-east-1b AZ에 있는 EC2 인스턴스의 CPU 사용률이 더 높다는 것을 발견했습니다. 조사를 거친 결과, 두 개의 AZ에 걸쳐 분배된 트래픽의 양은 동일한 것으로 나타났습니다. 이 경우, 어떻게 문제를 해결해야 할까요?
영역간 로드 밸런싱을 활성화하면, ELB가 모든 AZ에 있는 등록된 EC2 인스턴스 전체에 동등하게 분배됩니다.
14. 다음 중 하나의 리스너로 다수의 SSL 인증서를 가져올 수 있도록 해주는 Application Load Balancer와 Network Load Balancer의 기능은 무엇인가요?
15. 다음과 같은 호스트 이름을 기반으로, 트래픽을 3개의 대상 그룹으로 리다이렉팅하도록 구성된 Application Load Balancer가 있습니다: users.example.com, api.external.example.com, checkout.example.com. 이 각각의 호스트 이름에 HTTPS를 구성하려 합니다. 이런 작업을 위해서는 ALB를 어떻게 구성해야 할까요?
서버 이름 표식(SNI)을 사용하면 동일한 리스너 상에 있는, 자체 SSL 인증서를 가진 다수의 HTTPS 애플리케이션을 노출시킬 수 있습니다. 더 많은 정보는 여기를 참고하세요: https://aws.amazon.com/blogs/aws/new-application-load-balancer-sni/
Application Load Balancers Now Support Multiple TLS Certificates With Smart Selection Using SNI | Amazon Web Services
Today we’re launching support for multiple TLS/SSL certificates on Application Load Balancers (ALB) using Server Name Indication (SNI). You can now host multiple TLS secured applications, each with its own TLS certificate, behind a single load balancer.
aws.amazon.com
16. 원하는 용량과 최대 용량을 모두 3으로 구성한 오토 스케일링 그룹에 의해 관리되고 있는, 한 세트의 EC2 인스턴스에 호스팅된 애플리케이션이 있습니다. 또한, CPU 사용률이 60%에 이르면 ASG를 스케일 아웃하도록 구성된 CloudWatch 경보도 생성해 뒀습니다. 해당 애플리케이션은 현재 갑자기 많은 양의 트래픽을 전송 받아 80% CPU 사용률에서 실행되고 있는 상태입니다. 이런 경우, 무슨 일이 일어나게 될까요?
오토 스케일링 그룹은 스케일 아웃 시, (구성된) 최대 용량을 넘어설 수 없습니다.
17. Application Load Balancer가 관리하는 오토 스케일링 그룹이 있습니다. ASG가 ALB 상태 확인을 사용하도록 구성을 해둔 상태인데, EC2 인스턴스가 비정상인 것으로 보고되었습니다. EC2 인스턴스에는 무슨 일이 일어나게 될까요?
오토 스케일링 그룹이 EC2 상태 확인(기본 설정)이 아닌 Application Load Balancer의 상태 확인을 기반으로 EC2 인스턴스의 상태를 판단하도록 구성할 수 있습니다. EC2 인스턴스가 ALB의 상태 확인에 실패할 경우, 이는 비정상인 것으로 표시되어 종료되며 ASG는 새로운 EC2 인스턴스를 실행합니다.
18. 여러분의 상사가 애플리케이션이 데이터베이스로 보내는 분당 요청 수를 기반으로 오토 스케일링 그룹을 스케일링하라고 요청했습니다. 어떻게 해야 할까요?
백엔드-데이터베이스 연결에는 ‘분당 요청'에 해당하는 CloudWatch 지표가 존재하지 않습니다. CloudWatch 경보를 생성하려면 CloudWatch 사용자 지정 지표를 먼저 생성해야 합니다.
19. 오토 스케일링 그룹 (ASG)에서 관리하는 EC2 인스턴스 플릿이 호스팅하는 웹 애플리케이션이 있습니다. 여러분은 애플리케이션 로드 밸런서 (ALB)를 통해 이 애플리케이션을 노출하고 있습니다. EC2 인스턴스와 ALB는 모두 다음 CIDR 192.168.0.0/18을 사용하여 VPC에 배포됩니다. ALB만 포트 80에서 액세스할 수 있도록 EC2 인스턴스의 보안 그룹을 구성하려면 어떻게 해야 할까요?
ALB만이 EC2 인스턴스로 액세스할 수 있게 할 수 있는 가장 안전한 방법입니다. 규칙에서 보안 그룹을 참조하는 것은 매우 강력한 규칙으로, 이 내용을 바탕으로 많은 시험 문제가 출제됩니다. 그러니 이에 관련된 내용은 반드시 숙지하도록 하세요!
20. eu-west-2 리전에서 실행되는 오토 스케일링 구성이 있는데, 두 개의 가용 영역인 eu-west-2a 와 eu-west-2b 를 생성하도록 설정되어 있습니다. 현재 eu-west-2a에는 3개의 EC2 인스턴스가 실행 중이며, eu-west-2b에는 4개의 EC2 인스턴스가 실행 중입니다. ASG는 스케일 인을 하려 합니다. 이들 중 어떤 EC2 인스턴스가 종료되게 될까요?
오토 스케일링 그룹의 기본 종료 정책을 반드시 기억해두세요. 이 정책은 우선 AZ에 걸친 밸런싱을 시도하며, 실행 구성이 오래된 순으로 종료합니다.
실행 템플릿이 제일 오래된 순으로 종료한다!
21. 애플리케이션은 Application Load Balancer와 오토 스케일링 그룹과 함께 배포됩니다. 현재 ASG를 수동으로 스케일링하고 있는 상태에서, EC2 인스턴스로의 평균 연결의 수를 1,000회 정도로 유지하기 위한 스케일링 정책을 정의하려 합니다. 이 중에서 어떤 스케일링 정책을 사용해야 할까요?
22. 오토 스케일링 그룹이 관리하는 EC2 인스턴스에 호스팅된 애플리케이션으로 들어오는 트래픽이 급격하게 증가하여, ASG가 스케일 아웃되고 새로운 EC2 인스턴스가 실행되게 되었습니다. 트래픽은 계속해서 증가하지만, ASG는 5분이 지나기 전까지는 새로운 EC2 인스턴스를 곧바로 실행하지 않습니다. 이런 경우, 가능성이 있는 원인은 무엇일까요?
오토 스케일링 그룹에는 각 스케일링 조치 이후 냉각 기간을 갖습니다. ASG는 냉각 기간 동안 EC2 인스턴스를 실행하거나 종료하지 않습니다. 이를 통해 지표들을 안정화시킬 수 있는 기간을 갖습니다. 냉각 기간의 기본 값은 300초(5분)입니다.
23. 지난 달, 어느 기업이 보유한 오토 스케일링 그룹 내의 무작위 EC2 인스턴스가 갑자기 충돌을 일으켰습니다. ASG가 비정상 EC2 인스턴스를 종료하고 이를 새로운 EC2 인스턴스로 대체하고 있는 관계로, EC2 인스턴스가 충돌하게 된 원인을 찾을 수 없는 상태입니다. 이 문제를 해결하고 ASG가 비정상 인스턴스를 종료하는 것을 막기 위해서는 어떤 문제 해결 조치를 취해야 할까요?
asg 수명 주기 후크? Amazon EC2 Auto Scaling 수명 주기 후크 - Amazon EC2 Auto Scaling
Amazon EC2 Auto Scaling 수명 주기 후크 - Amazon EC2 Auto Scaling
이 페이지에 작업이 필요하다는 점을 알려 주셔서 감사합니다. 실망시켜 드려 죄송합니다. 잠깐 시간을 내어 설명서를 향상시킬 수 있는 방법에 대해 말씀해 주십시오.
docs.aws.amazon.com
Amazon EC2 Auto Scaling은 오토 스케일링에 수명 주기 후크를 추가할 수 있는 기능을 제공합니다. 이러한 후크를 사용하면 Auto Scaling 인스턴스 수명 주기의 이벤트를 인식하는 솔루션을 생성한 다음 해당 수명 주기 이벤트가 발생할 때 인스턴스에 대한 사용자 정의 작업을 수행할 수 있습니다. 수명 주기 후크는 인스턴스가 다음 상태로 전환되기 전에 작업이 완료될 때까지 대기할 지정된 시간(기본적으로 1시간)을 제공합니다.