본문 바로가기

KOSA 클라우드 솔루션즈 아키텍트 양성과정

[6.15] 퍼블릭 클라우드(Auto Scaling)

 # Origin Server 만들기

 

EC2가 퍼블릭 서브넷에 있어도, 퍼블릭 IP를 받지 않으면 인터넷을 할 수 없다.

 

알리바바 클라우드 DNS셋팅에서 ORIGIN의 퍼블릭 IP 넣기


# 오리진 서버의 AMI를 만들고, 해당 AMI로 템플릿을 만들자(오토 스케일링을 위한 사전 작업)

 

AMI를 만들고 그 안에는 스냅샷이 있어야 한다.

 

이미지 만들기 끝

 

시작 템플릿 생성

 

템플릿에 키 페어를 설정해 놓으면, EC2를 만들 때마다 자동으로 퍼블릭 키를 넣어줌

 

만약 WEB01이라는 태그를 주면 모든 인스턴스가 WEB01 태그를 달고 생성됨

 

고급 세부 정보 설정할 것 없음

 

시작 템플릿 완성


# 시작템플릿 만들었으니, 이제 오토 스케일링 만들자

 

ASG의 작동 방식

* 실무에서는 SPOF를 피하기 위해 Minimum size와 Desired capacity를 두 개 이상으로 주는 것이 좋다.

* 실습 환경에서는 그림과 같이 미니멈, 디자이어드, 멕시멈 설정할 것

* CPU 사용률을 Cloud Watch가 모니터링

* CPU 사용률의 평균 값을 계산하려면 그룹을 지정해야 해서 오토 스케일링 그룹이라는 이름을 가지게 됨

 

* 시작 구성과 시작 템플릿은 유사, 최근에는 시작 템플릿을 더 많이 사용

* 시작 템플릿은 버전 관리 기능을 제공해서 시작 구성 보다 유용

 

 

* 로드 밸런싱은 선택 사항 : 가용성을 높이기 위해 로드 밸런서를 사용

* 로드 밸런서를 미리 만들기 보다는, ASG를 생성하는 과정에서 새 로드 밸런서에 연결을 통해 새로 만드는 것이 좋음

 

* Internet-facing(인터넷 경계) : 엔드 유저의 접속 포인트가 인터넷일 경우

* Internal : 엔드 유저의 접속 포인트가 VPC 내부만 있을 경우

* 리스너 및 라우팅 : 백엔드 대상 그룹이 없으면, 대상 그룹 생성해야 함

 

즉석에서 대상 그룹 생성

 

유예 시간은 그대로 두기

* 상태 확인 유예 시간 

-> 리전 별로 많은 사용자들이 접속 시 레이턴시 발생하는데 그러한 레이턴시를 기다릴 유예 시간을 주지 않으면 오류 발생 확률 높아짐

 

 

* 원하는 용량(Desired capacity)에 정한 개수에 따라 시작 템플릿을 이용해서 자동으로 EC2가 만들어 짐

* 최소 용량(Minimum)은 원하는 용량(Desired capacity)보다 커질 수 없음

 

 

* 부하가 발생하면 CPU가 메트릭 중에서 가장 빠르게 반응

* 크기 조정 정책은 향후 Cloud Watch에서 설정할 것

* 대상 추적 크기 조정 정책 : 잘 사용하지 않는 정책, 대상 값 하나만 기준으로 스케일 아웃과 스케일 인이 실행 됨

* 인스턴스 축소 보호 활성화 : 스케일 아웃만 하고, 스케일 인은 하지 않겠다는 것

 

 

* SNS(Simple Notification Service) - 이메일이나 단문 메시지(SMS) 등으로 알림을 보내주는 서비스

* 이벤트 유형에 선택된 항목이 발생하면 알림을 보내줌

 

태그는 그대로 두기, 7단계 검토에서 검토 후 생성

 

생성 완료

 

ORIGIN을 제외한 두 개의 인스턴스(Desired capacity)가 생성됨

 

SNS서비스를 통해 메일 수신, Confirm subscription을 눌러야 앞으로도 메일이 옴

 

앞으로 SNS 알림을 받을 수 있게 됨

 

ASG가 두 개의 인스턴스를 만들면서 자동으로 대상 그룹에 넣어줌

 

DNS이름 엔드포인트 주소를 복사해서 DNS서비스에 넣어줘야 함

 

알리바바에서 Edit 클릭

 

CNAME을 선택하고 ALB의 엔드포인트 주소 붙여 넣기

 

브라우저에서 접속이 안 되면 보안 그룹을 SG-WEB으로 설정해줘야 함

 

 

## Scale Out 정책 생성

동적 크기 조정 정책 생성 클릭

 

* 대상 추적 크기 조정 : 하나의 값을 기준으로 스케일 아웃과 인을 진행하는 정책

* 정책 유형 : 단순 크기 조정 선택

* CloudWatch 경보 생성해서 언제 알람을 받을지 정해야 함

 

언제 알람을 줄 지 지표 선택

 

지표에서 EC2 선택
Auto Scaling 그룹별 선택

 

지표 이름 : CPUUtiolizaion 선택

 

지표의 기간이 5분 미만일 경우 비용이 발생

 

임계값을 70으로 선택

* CPU 사용률이 70% 이상 되면 알람을 보내줌

 

지표의 그래프에서 빨간색 줄이 70%

 

CloudWatch 경보 생성 완료, 이제 다시 동적 크기 조정 정책 생성으로 돌아가기

 

* 작업 수행 : 드롭 다운 메뉴에서 추가, 숫자 1은 하나 더 추가하겠다는 의미

* 그런 다음 대기(유휴 시간)

-> 작업 수행 추가 했는데 또 다시 접속량이 폭주하면, 얼마나 더 있다가 하나 더 추가할 것인지 정하기

-> 인스턴스 추가에도 시간이 걸리기 때문에 그러한 시간을 고려해서 설정해야 함

 

동적 크기 조정 정책 생성 완료, 증가 조건을 넣었으니 이제 축소 조건(스케일 인)을 넣을 것

 

 

## Scale In 정책 생성

 

CloudWatch 경보 생성 클릭

 

CPUUtilization

 

임계값 30% 보다 작거나 같을 때 알람이 오도록 설정

 

스케일 인 알람 생성 완료, 이제 동적 크기 조정 정책 생성으로 다시 돌아 가기

 

스케일 아웃, 인 정책 모두 생성 완료

 

현재 CPU 사용률이 30% 이하라서 경보 상태 표시됨, 인스턴스 하나가 줄어들 것 예상할 수 있음


# ASG의 스케일 아웃 기능을 작동 시키기 위해 임의로 부하를 줄 것

 

SSH세션 접속후 top명령어 통해 CPU 사용량 확인, q를 눌러서 top모드에서 나올 수 있음

Desired capacity로 생성된 인스턴스의 퍼블릭IP로 세션 접속

* yes > /dev/null & 명령어를 통해 CPU 사용률을 증가시키기

* dev 밑에 null이라는 휴지통에 계속해서 로그를 버리는 작업

* & 기호는 백그라운드 실행을 위한 것

 

yes > /dev/null & 실행 후 CPU 사용량 폭증 확인

 

# 오토스케일링 스케일 아웃 시 가용성을 유지하기 위해서 어느 한쪽으로 스케일 아웃 하는 것이 아니라 가용 영역을 분산시키면서 스케일 아웃한다. 스케일 인도 마찬가지


# 22번 포트 아웃바운드 트래픽이 막혀 있는 경우

 

마침을 누르는 순간 SSH 세션 다 연결 끊김

 

연결 클릭

 

연결 클릭

 

aws에서 접속

* 여기서 ssh 포트를 22번에서 다른 것으로 바꾸면 됨

* vi /etc/ssh/sshd_config 로 접속해서  Port 221로 바꿔주기

* systemctl restart sshd

* ss -ant 를 통해 221번 포트가 오픈되었는지 확인

 

mobaXterm에서 221번 포트로 세션 생성


# 베스천 호스트(Bastion Host)

* 일단 DB서버로 사용할 인스턴스 생성(퍼블릭 ip 할당하고, 프라이빗 서브넷 내에 생성)

* NAT게이트웨이는 무조건 퍼블릭 서브넷에 셋팅해야 함(NAT의 역할을 하려면 퍼블릭 IP를 필요로 하기 때문)

* ~~ 게이트웨이를 생성할 때는 반드시 라우팅 테이블(RTB)에서 넥스트 홉을 셋팅해야 함

 

ssh를 이용해 프라이빗 서브넷에 있는 DB서버에 접속

* 퍼블릭 서브넷에 있는 ORIGIN VM을 베스천 호스트로 하여 프라이빗 서브넷에 있는 DB서버에 접속


# NAT Gateway 생성

 

* 탄력적 IP (= 공인 IP)

* 무료로 제공하는 퍼블릭 IP가 없고, 탄력적 IP를 적용해야 함

 

프라이빗 서브넷 RTB에 NAT 게이트웨이 정보 넣어줘야 함

 

모든 소스에서 NAT게이트웨이로 향하게 함

* 프라이빗 서브넷 내의 모든 vm에서 NAT게이트웨이로 트래픽 보내고, NAT 게이트웨이가 해당 트래픽을 퍼블릭 IP를 이용해 인터넷에 뿌림, 예를 들어 구글로 ping을 쐈다면 구글로 보내고 받는 역할을  NAT 게이트웨이가 수행

 

DB서버에 설치할 것들 설치 끝나면, NAT 게이트웨이 삭제

* NAT게이트웨이 삭제해도 탄력적 IP는 지워지지 않으니까, 좌측 메뉴의 탄력적 IP로 가서 탄력적 IP 릴리즈 해줘야 함

* 탄력적 IP를 릴리즈 하지 않으면 과금됨

 

 

만약 NAT게이트웨이 지웠는데 인터넷 연결이 또 필요할 경우

* 프라이빗 서브넷 라우팅 테이블에 인터넷 게이트웨이 정보를 넣어주면 됨 -> 바람직하지는 않음

* 이러한 경우, 미리 프라이빗 서브넷에 서버를 구축할 때, 퍼블릭 IP를 할당해야 함


# EFS(Elastic File System)

EFS에는 퍼블릭 IP를 줄 수 없음, 따라서 EFS는 프라이빗 네트워크에서만 작동

-> 하지만, VPN연결을 통해 프라이빗 네트워크 외부에서도 실행 가능

-> 내 PC에 있는 VM과 AWS의 VPC를 VPN으로 연결하면 내 PC에서도 AWS VPC 내에 있는 EFS를 이용할 수 있음

-> VPN TUNNELING 연결은 암호화 되어 있음, VPC PEERING이 암호화되지 않는 것과 차이

-> 일종의 하이브리드 클라우드를 구축하는 방법

* 완전 관리형 서비스 : 고가용성, 자동백업, 자동조정

* 리눅스의 SAMBA와 윈도우의 SMB는 동일한 서비스, AWS는 FSx라는 이름으로 동일 서비스 제공

 

 

EC2용으로 명시되어 있음

 

EFS 생성 완료 : 보안 그룹이 디폴트로 잡히기 때문에 새로 보안 그룹 만들어 줘야 함

 

NFS접근 소스를 SG-ALB로 설정

 

관리 클릭

* 네트워크 관리에서 디폴트 보안 그룹 전부 지워주기

 

디폴트 보안 그룹 대신 SG-EFS 보안그룹으로 지정

 

NFS 클라이언트 사용 복사

 

보안그룹 소스를 SG-ALB로 해서 접속 안 됨

 

소스에 SG-WEB을 설정해서 해당 보안 그룹의 적용을 받는 서버가 접속할 수 있게 해줌

 


* RestfulAPI : URL을 통해 파일을 내려 받을 수 있게 해주는 api

-> 객체 스토리지와 유사


두 번째 프로젝트 개요

* ESXI : Storage Gateway를 통해 aws와 연동

* VPN을 통한 연결

* route53의 GSLB 로드밸런싱 기능, Failover 기능 : aws, gcp, azure를 openstack과 연동