AWS - Autoscaling Group, Bastion host

0. Autosacling 설명

-  애플리케이션의 로드를 처리할 수 있는 정확한 수의 인스턴스를 보유하도록 보장할 수 있다. Auto Scaling 그룹이라는 인스턴스 모음을 생성한다. 각 Auto Scaling 그룹의 최소 인스턴스 수를 지정할 수 있으며, Auto Scaling에서는 그룹의 크기가 이 값 아래로 내려가지 않는다. 각 Auto Scaling 그룹의 최대 인스턴스 수를 지정할 수 있으며, Auto Scaling에서는 그룹의 크기가 이 값을 넘어가지 않는다. 원하는 용량을 지정한 경우 그룹을 생성한 다음에는 언제든지 Auto Scaling에서 해당 그룹에서 이 만큼의 인스턴스를 보유할 수 있다.

 

1. AutoScaling

1.1. AutoScaling Group 생성

* 시작 템플릿은 자동으로 버전 관리가 가능하다.

- 왼쪽 탭에서 Auto Scaling 그룹을 선택하고 Auto Scaling 그룹 생성 버튼을 클릭한다.

 

- 그룹 이름 : my-asg

- 템플릿 : my-temp-wp

 

- vpc를 선택하고

- 가용 영역을 인스턴스를 생성할 서브넷으로 설정한다.

- alb는 public 영역에 있어야한다.

- Auto Scaling Group 생성시 로드 밸런서 생성이 가능하다.

- ALB 생성을 Aplication Load Balancer 클릭

- 로드 밸런서 체계 : 외부(Internet-facing)을 선택한다. 사용자가 인터넷 게이트웨이를 타고 ALB로 접근하기 때문이다.

 

- 자동으로 가용 영역을 Public으로 설정해야한다. (my-pub-2a, my-pub-2c)

- 대상 그룹에 인스턴스를 수동으로 넣을 필요가 없다.

- Autoscaling 그룹이 알아서 대상그룹에 인스턴스를 넣어준다.

 

- 인스턴스가 만들어지고 있는데 상태 검사를 하면 Fail로 처리될 수 있다.

- 따라서 상태 검사를 하기 전까지 일정 시간 텀을 둘 수 있는데 그게 상태 확인 유예기간이다.

 

- 원하는 용량( desired capacity) : 2

- 최소 용량(minimum value) : 2

- 최대 용량(maximum value) : 4

- 크기 조정 정책 : scale in, scale out 조정 정책 -> 일단은 없음으로 표시

- ex) Cpu 사용량이 50% -> sacle out

- 축소 보호 : scale out된 상태에서 scale in 되는 걸 막는다(아직 scale out된 상태가 필요하기 때문에)

 

- SNS : Simple Notification Service

 

- Autoscaling Group을 생성하면서 만들어진 2개의 인스턴스를 확인할 수 있다.

- 처음에는 태그가 없지만 asg01, asg02로 추가해주었다.

 

- AutoScaling target 그룹을 생성하고 대상그룹을 확인했지만 생성된 인스턴스들이 자동으로 들어가져 있지 않다.

- AutoScaling target 그룹을 생성하자마자 위에 빨간 에러 화면이 나타났는데 그것 때문에 그런것 같다

- 처음에는 번거롭지만 수동으로 인스턴스들을 대상그룹에 넣어줘 본다.

 

- blog DNS 엔드포인트 주소를 ALB의 주소로 변환한다.

- Route53 서비스로 이동하여 blog.yunhyeong.shop의 레코드 편집

 

- template의 보안그룹이 web이었기 때문에 자동으로 my-sg-web으로 설정되었다.

- 이를 my-sg-alb로 바꿔주었다.

 

1.2. ScaleOut 동적 크기 조정 정책

- 단순 크기 조정 : 단계 크기에 따라 인스턴스의 생성이나 삭제 수를 자동으로 조정한다.

- ex) CPU 사용량이 : 20% -> 인스턴스 1개 추가

- CPU 사용량이 : 80% -> 인스턴스 24개 추가

- CloudWatch 경보 :  경보가 울리면 Autoscaling이 작업을 수행( 이 경우는 Scale Out)

 

1.2.1. CloudWatch ScaleOut 경보 생성

- CloudWatch를 활용해서 Cpu 사용률 체크

- 일정 사용률이 높아지면 경보를 주기 위해서

- 측정 기간을 5분단위로 한다.

- 1분 이하의 측정 기간은 비용이 발생한다.

- CPU 사용률이 70%이상으로 설정한다.

- 앞선 설정을 정리해보면, CPU 사용률이 70%인 상태로 5분이 유지되야 경보음을 준다는 뜻이다.

 

- 계정을 선택하고 경보이름을 설정하여 최종적으로 알람 설정을 만든다.

 

1.3. ScaleIn 동적 크기 조정 정책

- 5분간  설정한 최소 임계값(CPU 사용률 30%)이 유지되면 3개의 인스턴스를 제거하도록 설정

 

1.3.1. CloudWatch ScaleIn 경보 생성

- 최소 CPU 사용률을 30%로 설정한다.

- 기간을 5분으로 설정한다.

- CPU 사용률이 30%이하로 5분동안 유지되면 경고 알람을 주도록 설정했다.

 

- 경보를 받을 메일을 선택하고 경보이름을 설정한 다음 최종적으로 알람 설정을 마친다. 

2. Bastion Host 만들기

2.1 인스턴스 생성

- OS 이미지를 Amazon Linux 2AMi로 설정한다

- Amazon 2023 OS는 최신 버전이라 쓰기 좀 까다롭다

- 보안 그룹을 반드시 웹 보안그룹으로 설정한다. 그래야 bastion host의 역할을 할 수 있다.

- my-key.pem을 활용해서 asg01 접근

- ec2-user만이 키를 읽을 수 있도록 허용(chmod 400 my-key.pem)

 

- sudo yes > /dev/null & -> 로그를 null 폴더에 버리는 명령어

- &(백그라운드 실행) : prompt를 떨어트리기 위해

- CPU 부하를 올리기 위해서 위의 명령어를 사용

- CPU 사용률이 99%가 넘는걸 볼 수 있다.

- 5분이상 이 상황이 유지되면 ScaleOut(인스턴스 수를 증가)시키고 알람 메일을 보내다

- 이 과정을 asg02에서도 실행한다.

 

- 원하는 용량이 늘어나고 인스턴스가 만들어지는 것을 볼 수가 있다.

- 실제 인스턴스가 하나 더 생겨나고 이 인스턴스의 태그를 asg03으로 수정했다.

 

 

- asg03의 세션에서 asg01, asg02와 마찬가지로 CPU 부하를 준다.

 

- 원하는 용량이 4 개로 늘어나고 인스턴스가 3개에서 하나더 늘어나 4개가 된 것을 볼 수 있다.

- AutoScalling으로 만들어진 인스턴스들은 가용성을 지키면서 생성된다.

- 하지만 ScaleIn의 경우는 무작위로 인스턴스들을 줄인다.

 

- sudo pkill -9 yes

- asg01, asg02, asg03의 MobaXterm 세션에서 위의 명령을 실행시켜 프로세스를 중지시킨다.

- 시간이 지나 인스턴스 2개가 지워진 것을 확인할 수 있다.

- AutoScalling 그룹 생성시 최소 인스턴스의 수를 2개로 설정했기 때문에 2개만 남는다.

 

 

- CloudWatch 서비스에서 그래프를 통해 CPU 사용률의 변화를 관찰할 수 있다.

 

- 남아있는 인스턴스 2개를 지우면 AutoScalling 그룹이 자동으로 인스턴스를 다시 생성한다.

- AutoScalling 그룹의 인스턴스 최소 크기가 2이기 때문에 인스턴스 2개를 생성한다.