240202 Cloud

KDT/Cloud

240202 Cloud

001cloudid 2024. 2. 2. 13:54

728x90

AWS Auto Scaling

기준값에 따라 서버의 수를 '자동'으로 늘렸다 줄였다 하는 서비스
사람이 아닌 AWS에서 자동으로 추가/삭제

절차

EC2 인스턴스 스냅샷 생성
시작 템플릿 생성
Auto Scaling 생성

1. EC2 인스턴스 스냅샷 생성

※과금이 발생할 수 있으니 사용 후 반드시 종료(삭제)

EC2 인스턴스 - 인스턴스 - exercise-instance1 중지 상태 확인(중지)
우클릭 - 이미지 및 템플릿 - 이미지 생성
이미지 이름 exercise-image
나머지는 기본값으로
-> 이미지 생성
상단에 '현재 AMI 생성중...(생략)' 메세지 표시
이미지 - AMI - exercise-image

2. 시작 템플릿 생성

인스턴스 - 시작 템플릿 - 시작 템플릿 생성
시작 템플릿 이름 : exercise-launch-template
템플릿 버전 설명 : initial version
Amazon Machine Image(AMI) - 내 AMI - exercise-image 선택
인스턴스 유형 : t2.micro
키 페어 : 기존에 있는 키 페어 사용
기존 보안 그룹 선택 : ssh, web
나머지 설정은 기본값
-> 시작 템플릿 생성

3. Auto Scaling 생성

좌측 바 가장 아래 Auto Scaling - Auto Scaling 그룹 - Auto Scaling 그룹 생성(총 7단계로 구성)

시작 템플릿 또는 구성 선택
Auto Scaling 그룹 이름 : EXERCISE-GROUP
시작 템플릿 : exercise-launch-template
-> 다음
인스턴스 시작 옵션 선택
VPC : 기본값 사용
가용 영역 및 서브넷 : ap-northeast-2a, 2c 선택
-> 다음
고급 옵션 구성
기본값으로 설정
-> 다음
그룹 크기 및 크기 조정 구성
원하는 용량 : 1
원하는 최소 용량 : 1
원하는 최대 용량 : 2
==================================================
원하는 용량 : 목표로 하는 인스턴스의 수
최소 용량 : 최소로 유지할 인스턴스의 수
최대 용량 : 크기 조정 정책에 따라 최대로 늘릴 수 있는 인스턴스 개수
==================================================
크기 조정 정책 : 대상 추적 크기 조정 정책
크기 조정 정책 이름 : Scale Group Size

지표 유형 - 대상값 : 80
->다음
알림 추가
설정 없이 다음
태그 추가
추가 - 키 Name, 값 exercise-group
-> 다음
검토 단계
정보 확인 후 Auto Scaling 그룹 생성

EC2 인스턴스 - 인스턴스 선택 exercise-group이라는 이름의 인스턴스가 동작

=> Auto Scaling group의 원하는 용량이 1이기 때문임

만약, exercise-group 인스턴스가 동작하지 않게 하려면 Auto Scaling 그룹의 용량을 원하는 용량 0, 최소 용량 0, 최대 용량 0으로 설정

=> Auto Scaling 그룹 -> EXERCISE-GROUP 선택 후 편집

Auto Scaling 동작 확인

CPU의 사용량을 인위적으로 높이는 stress 라는 패키지를 exercise-group 인스턴스에 설치
stress 프로그램 동작
CPU의 사용량이 80%가 넘어서면 최대 용량 2 설정값에 의해 exercise-group 인스턴스가 하나 더 생성

원격접속프로그램

sudo amazon-linux-extras install epel -y

=> 외부 저장소에서 패키지를 받을 수 있도록 설정

sudo yum install stress -y

=> CPU 사용량을 강제로 높이는 stress 패키지를 설치

stress --cpu 1 --timeout 600

=> CPU 하나를 600초(10분) 동안 100%로 만듦

=> 10분 설정 이유는 사용량 지표를 5분에 한 번씩만 모니터링 서버로 전송하기 때문

=> Auto Scaling 생성 시 [세부 모니터링 활성화] 옵션을 활성화하면 인스턴스가 1분마다 지표를 보냄

=> 단, 이 설정은 추가 비용이 발생(필요없으면 할 필요없음)

stress 프로그램(패키지) 동작 시작 후 5~10분 정도 기다리면 exercise-group 인스턴스가 하나 더 생겨남

그 이유는 모니터링 시점(5분에 한 번씩)에 stress 프로그램에 의해 CPU가 80% 넘어선 100%로 유지되기 때문

10분 동안 동작하던 stress 프로그램이 종료되면 다음 번 모니터링 시점에서 exercise-group 인스턴스 하나를 종료(삭제) 시킴

이 과정이 자동으로 이루어짐

=> Auto Scaling

로드밸런서 구성

p.62

클라이언트 요청을 직접 받고, 로드 밸런서가 관리하는 서버들에게 요청을 골고루 전달해주는 역할
ELB에는 ALB, NLB, CLB 세 종료가 있음
-ALB
HTTP 및 HTTPS에 가장 적합한 로드 밸런서
OSI 모형의 애플리케이션 계층(구체적인 통신을 제공하는 계층)에서 동작
요청되는 명령어의 내용을 보고 판단하기 때문에 URL 디렉터리 단위로 분배하는 것이 가능
인스턴스와 로드밸런서 사이의 통신은 암호화가 가능하다는 특징
지원 프로토콜 : HTTP, HTTPS
*OSI 7 Layer
OSI 7 계층
통신 : 보내는 사람(송신, source) <-> 받는 사람(수신, destination)
IOS(국제 표준 기구) => OSI 7 Layer
1계층 물리계층(Physical Layer)
=> 케이블(Cable)

2계층 Data Link Layer
=> MAC(Machine Access Control) IEEE단체에서 관리
=> 16진수, 48bit로 된 주소
=> cmd - ipconfig /all - 물리적 주소 12개 HEX(12*4=48bit)
=> 앞의 6자리 OUI(회사에 부여되는 ID), 뒤의 6자리 NIC

3계층 Network Layer
=> IP(Internet Protocol)

4계층 Transport Layer(전송 계층)
=> TCP, UDP
=> HTTP(80/TCP), HTTPS(443/TCP), FTP(20,21/TCP), SMTP(25/TCP),

5계층 Session Layer(세션 계층)
=> 논리적인 연결

6계층 Presentation Layer(표현 계층)
=> 암호화/복호화, 인코딩/디코딩

7계층 Application Layer(응용 계층)
=> 사용자가 집접적으로 사용하는 계층

-NLB
OSI 모형의 전송 계층(전송된 데이터의 제어 담당)에서 동작
지원 프로토콜 : TCP, TLS

-CLB
오래된 유형의 로드 밸런서
지원하는 프로토콜이 많다는 장점이 있지만 이제 사용하지 않음
지원 프로토콜 : TCP, SSL/TLC, HTTP, HTTPS

로드 밸런싱 - 로드 밸런서 - 로드 밸런서 생성 - Application Load Balancer
로드 밸런서 이름 : exercise-lb
체계(scheme) : 기본값
IP 주소 유형 : 기본값
매핑 : ap-northeast-2a, ap-northeast-2c 체크
보안그룹 : web 추가 ※ELB는 ssh 접속이 되지 않음. ssh추가 불필요
리스너 및 라우팅 : 타겟 그룹(로드 밸런서가 클라이언트로부터 받은 요청을 전달할 대상 그룹)이 설정되어 있지 않음
=>대상 그룹 생생

1단계(그룹 세부 정보 지정)
기본 구성
대상 유형 선택 : 기본값
대상 그룹 이름 : exercise-target-group
프로토콜 : 포트 : 기본값
IP 주소 유형 : 기본값
VPC : 기본값
프로토콜 버전 : 기본
상태 검사(Health Checks) : 상태 검사 경로 : /health
=> 다음

2단계(대상 등록)
인스턴스를 직접 선택해서 추가할 수 있음

Auto Scaling으로 인해 자동으로 만들어질 인스턴스를 타겟 그룹으로 할 것이므로 선택하지 않고, 타겟 그룹 생성 클릭

돌아가서 기본 작업에서 새로고침 한 후 exercise-target-group 선택
=> 로드 밸런서 생성

생성한 로드 밸런서의 대상 그룹에 앞에서 만든 Auto Scaling 그룹인 EXERCISE-GROUP에 등록

EC2 Auto Scaling - Auto Scaling 그룹 - EXERCISE-GROUP 체크 - 세부 정보 탭에서 스크롤하면 로드 밸런싱 항목에 편집

애플리케이션, 네트워크 또는 게이트웨이 로드 밸런서 대상 그룹 체크

대상 그룹 선택 : exercise-target-group

업데이트

설정 확인

로드밸런싱 - 대상 그룹 - exercise-target-group 체크 - Targets 탭으로 이동하면 Registered targets에 exercise-group이 추가

로드 밸런싱 -> 로드 밸런서 -> exercise-lb의 DNS name을 복사

복사된 내용을 웹 브라우저의 주소창에 넣음
=> 화면에 'AWS Exericse의 A Project" 문장 확인!

==========================================

p74. Auto Scaling 그룹과 로드 밸런서를 통한 장애 조치

1. 로드밸런싱 -> 대상 그룹 -> □exercise-target-group 선택 -> 아래쪽 상태검사(Health Checks) 탭 클릭

2. 빠른 결과를 보기 위해서 '편집' 버튼을 눌러 기본설정값을 변경
▶ 고급 상태 검사 설정 펼침
- 정상 임계값 : 2
- 비정상 임계값 : 2
- 제한시간 : 2
- 간격 : 5
- 성공코드 : 200

설정이 완료되면 '변경 내용 저장' 버튼 클릭

장애조치 실습을 위해 2대의 서버가 동작할 수 있도록 설정
=> Auto Scaling 용량을 변경
=> 원하는 용량 : 2, 최소 용량 : 2, 최대용량 : 2로 변경

Auto Scaling -> Auto Scaling 그룹 -> □EXERCISE-GROUP 체크 -> 세부정보탭 -> 그룹 세부 정보 항목의 '편집' 클릭
=> 2 2 2 로 변경 한 후 업데이트 클릭

시간이 좀 지나면 exercise-group 이 하나 더 생겨남!

이제 원격접속 프로그램(MobaXterm)을 통해 각각 원격접속을 함
ex) exercise-gorup1, exercise-group2

로그 확인
cd /opt/nginx/logs
=> access.log 파일이 있는 위치로 이동

tail -f access.log
=> 본래 tail 명령어는 파일의 내용을 맨 아래에서 위쪽으로 10줄을 보여주는 명령어
=> -f 옵션을 사용하면 실시간으로 로그의 내용을 화면에 보여줌

윈도우의 웹브라우저에서 주소창에 로드밸런서(exercise-lb)의 DNS 주소를 입력하면 서버의 샘플 프로젝트의 app.js 내용이 보임

새로고침(F5)을 누를 때마다 로드밸런서가 두 대의 서버를 번갈아가면서 통신을 시키는 것을 볼 수 있음!

그러면 하나의 서버가 다운된다면??
둘 중 하나의 서버로 이동하여 Ctrl +C 를 입력하여 실시간 로그 보기 종료

해당 서버에서
sudo service nginx stop
=> 웹 서비스 중단!

중단시키고 윈도우의 웹브라우저에서 F5를 몇 번 누르면 '502 Bad Gateway' 메서지가 뜸!
=> 500번대의 상태 코드는 서버의 오류가 있을 때 발생!

시간이 지나면 새로고침을 해도 502 에러가 발생하지 않음.
그 이유는 로드밸런서가 하나의 서버에서 문제가 발생했음을 인지했기 때문이고, 요청을 해당 서버로 보내지 않기 때문!
즉, 나머지 하나의 서버로만 요청을 전달