# Origin Server 만들기
# 오리진 서버의 AMI를 만들고, 해당 AMI로 템플릿을 만들자(오토 스케일링을 위한 사전 작업)
# 시작템플릿 만들었으니, 이제 오토 스케일링 만들자
* 실무에서는 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) 등으로 알림을 보내주는 서비스
* 이벤트 유형에 선택된 항목이 발생하면 알림을 보내줌
## Scale Out 정책 생성
* 대상 추적 크기 조정 : 하나의 값을 기준으로 스케일 아웃과 인을 진행하는 정책
* 정책 유형 : 단순 크기 조정 선택
* CloudWatch 경보 생성해서 언제 알람을 받을지 정해야 함
* CPU 사용률이 70% 이상 되면 알람을 보내줌
* 작업 수행 : 드롭 다운 메뉴에서 추가, 숫자 1은 하나 더 추가하겠다는 의미
* 그런 다음 대기(유휴 시간)
-> 작업 수행 추가 했는데 또 다시 접속량이 폭주하면, 얼마나 더 있다가 하나 더 추가할 것인지 정하기
-> 인스턴스 추가에도 시간이 걸리기 때문에 그러한 시간을 고려해서 설정해야 함
## Scale In 정책 생성
# ASG의 스케일 아웃 기능을 작동 시키기 위해 임의로 부하를 줄 것
* Desired capacity로 생성된 인스턴스의 퍼블릭IP로 세션 접속
* yes > /dev/null & 명령어를 통해 CPU 사용률을 증가시키기
* dev 밑에 null이라는 휴지통에 계속해서 로그를 버리는 작업
* & 기호는 백그라운드 실행을 위한 것
# 오토스케일링 스케일 아웃 시 가용성을 유지하기 위해서 어느 한쪽으로 스케일 아웃 하는 것이 아니라 가용 영역을 분산시키면서 스케일 아웃한다. 스케일 인도 마찬가지
# 22번 포트 아웃바운드 트래픽이 막혀 있는 경우
* 여기서 ssh 포트를 22번에서 다른 것으로 바꾸면 됨
* vi /etc/ssh/sshd_config 로 접속해서 Port 221로 바꿔주기
* systemctl restart sshd
* ss -ant 를 통해 221번 포트가 오픈되었는지 확인
# 베스천 호스트(Bastion Host)
* 일단 DB서버로 사용할 인스턴스 생성(퍼블릭 ip 할당하고, 프라이빗 서브넷 내에 생성)
* NAT게이트웨이는 무조건 퍼블릭 서브넷에 셋팅해야 함(NAT의 역할을 하려면 퍼블릭 IP를 필요로 하기 때문)
* ~~ 게이트웨이를 생성할 때는 반드시 라우팅 테이블(RTB)에서 넥스트 홉을 셋팅해야 함
* 퍼블릭 서브넷에 있는 ORIGIN VM을 베스천 호스트로 하여 프라이빗 서브넷에 있는 DB서버에 접속
# NAT Gateway 생성
* 탄력적 IP (= 공인 IP)
* 무료로 제공하는 퍼블릭 IP가 없고, 탄력적 IP를 적용해야 함
* 프라이빗 서브넷 내의 모든 vm에서 NAT게이트웨이로 트래픽 보내고, NAT 게이트웨이가 해당 트래픽을 퍼블릭 IP를 이용해 인터넷에 뿌림, 예를 들어 구글로 ping을 쐈다면 구글로 보내고 받는 역할을 NAT 게이트웨이가 수행
* NAT게이트웨이 삭제해도 탄력적 IP는 지워지지 않으니까, 좌측 메뉴의 탄력적 IP로 가서 탄력적 IP 릴리즈 해줘야 함
* 탄력적 IP를 릴리즈 하지 않으면 과금됨
* 프라이빗 서브넷 라우팅 테이블에 인터넷 게이트웨이 정보를 넣어주면 됨 -> 바람직하지는 않음
* 이러한 경우, 미리 프라이빗 서브넷에 서버를 구축할 때, 퍼블릭 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라는 이름으로 동일 서비스 제공
* 네트워크 관리에서 디폴트 보안 그룹 전부 지워주기
* RestfulAPI : URL을 통해 파일을 내려 받을 수 있게 해주는 api
-> 객체 스토리지와 유사
두 번째 프로젝트 개요
* ESXI : Storage Gateway를 통해 aws와 연동
* VPN을 통한 연결
* route53의 GSLB 로드밸런싱 기능, Failover 기능 : aws, gcp, azure를 openstack과 연동
'KOSA 클라우드 솔루션즈 아키텍트 양성과정' 카테고리의 다른 글
[6.16] Openstack (복습) (0) | 2022.06.16 |
---|---|
[6.16] 퍼블릭 클라우드(Route 53, S3, CloudFront) (0) | 2022.06.16 |
[6.14] 퍼블릭 클라우드(RDS, ELB) (0) | 2022.06.14 |
[6.13] 퍼블릭 클라우드(AWS 복습) (0) | 2022.06.13 |
[5.27] 퍼블릭 클라우드 스토리지 (0) | 2022.05.27 |