AWS - Auto Scaling

구축할 네트워크 망도

---

Auto Scaling

AutoScaling이란?

애플리케이션의 로드를 처리할 수 있는 정확한 수의 인스턴스를 보유하도록 보장할 수 있다.

Auto Scaling 그룹이라는 인스턴스 모음을 생성한다. 각 Auto Scaling 그룹의 최소 인스턴스 수를 지정할 수 있으며, Auto Scaling에서는 그룹의 크기가 이 값 아래로 내려가지 않는다.

각 Auto Scaling 그룹의 최대 인스턴스 수를 지정할 수 있으며, Auto Scaling에서는 그룹의 크기가 이 값을 넘지 않는다.

원하는 용량을 지정한 경우 그룹을 생성한 다음에는 언제든지 Auto Scaling에서 해당 그룹에서 이만큼의 인스턴스를 보유할 수 있다.

 

Cloud Watch를 통해 CPU의 사용률을 감시하고, 설정한 임계값을 넘기면 알람을 울린다. 그 후, Auto Scaling을 통해 새로운 인스턴스를 생성하는 하여 ALB 헬스 체크를 정상으로 판단하면 해당 인스턴스를 포워딩하는 방식으로 작동한다. 이를 Scale Out(수평적 확장)이라 한다.

반대로, 여유가 있는 경우 인스턴스를 지워나가는 것을 Scale In(수평적 축소)라고 한다. 하지만, 다 지우는 것은 불가능하고, 최소값(Minimum) 밑으로는 지우지 못한다.

 

다른 방법으로, 인스턴스가 아닌 CPU나 메모리 등, 하드웨어의 스펙을 올려줄 수도 있는데, 이를 Scale UP(수직적 확장)이라 한다.

반대로, 하드웨어 스펙들을 낮추는 것을 Scale Down(수직적 축소)라고 한다.

 

---

오토 스케일링 생성

'Auto Scaling 그룹 생성' 클릭

---

---

인스턴스가 생성될 리전을 'my-pvt-2a'와 'my-pvt-2c' 로 설정

---

ALB를 새로 생성할 것이며, 이 ALB는 내부가 아닌 인터넷과 연결된 로드 밸런서이므로 'Internet-facing)을 선택

가용 영역은 선택한 영역으로 자동으로 선택되어 있으며, 서브넷도 프라이빗으로 자동으로 선택되어있다. 대상 그룹은 새로 생성한다.

상태 확인 유예 기간은 너무 짧으면 생성이 끝나기 전에 상태를 판단해서 비정상이 뜰 수 있다. 반대로, 너무 길면 상황 대처에 느려진다.

---

크기 조정 정책을 사용하기는 다소 부정확하다는 평가가 많다. 그러므로 추후에 Cloud Watch를 이용할 것이다.

---

이벤트가 발생할 때 마다 받을 알림을 설정.

해당 메일로 메일이 오는데, 해당 메일에서 수락을 해야 알림이 정상적으로 온다.

---

오토 스케일링 그룹이 만들어졌으며, 인스턴스 2개가 업데이트 됐다.

인스턴스를 확인해보면, 실제로 새 인스턴스 2개가 생성됐다. 각각의 이름을 'asg01', 'asg02'로 변경.

---

하지만, 위의 사진에서 오류가 나타났듯이, 대상 그룹에서 대상을 지정 못했으므로 대상을 지정해야한다.

대상 등록이 안됐음을 확인했다. 수동으로 추가를 해준다. '대상 등록' 클릭

---

'asg01', 'asg02'를 대상으로 등록한다.

---

대상 등록 성공.

---

로드 밸런서는 정상적으로 생성됐다. Route 53에 가서 기존의 A레코드 'blog.kyoung222.shop'의 값을 해당 DNS 이름 주소로 변경할 것이다.

---

'레코드 편집' 클릭

'my-alb-asg'로 변경

---

 다시 돌아와서, 템플릿을 사용하다보니 의도치 않은 보안 그룹을 사용 중이므로 보안 그룹을 수정해준다.

---

---

서브넷 부분도 템플릿을 사용해서  'public'이 아닌 'private로 되어있다. 이를 수정해준다.

'서브넷 편집' 클릭

public 으로 수정

---

ALB를 통해 접속 성공.

---

오토 스케일링 (ScaleOut) 생성

이제 CPU 사용률이 증가하면 인스턴스를 늘릴 오토 스케일링(ScaleOut)을 생성한다.

'동적 크기 조정 정책 생성'

---

'CloudWatch 경보 생성' 클릭

---

'Cloud Watch 경보'를 새로 생성한다.

'지표 선택'을 눌러 'CPUUtilization'을 선택.

5분내 70%보다 크거나 같은 경우에 Clouds Watch 경보 발생

CloudWatch 경보 생성 완료

---

다시 돌아와서,

• 단계 크기 조정: 여러 특정 기준에 맞춰 값이 하나 이상 추가 혹은 감소( ex: 70%:1개 추가 / 80%: 2개 추가/ 90%: 3개 추가 / 30%: 1개 제거 / 20%: 2개 제거....)
• 단순 크기 조정: 특정 기준에 맞춰 값이 하나씩 늘거나 줄어든다.

---

동적 크기 조정 정책 생성 완료. 하나 더 추가하기 위해 '동적 크기 조정 정책 생성' 다시 클릭

---

오토 스케일링 (ScaleIn) 생성

이제 CPU 사용률이 감소하면 인스턴스를 줄일 오토 스케일링(ScaleIn)을 생성한다.

똑같이 ' CloudWatch 경보 생성' 클릭

---

'보다 작거나 같음'으로 설정

---

---

---

생성 완료.

---

300초동안 CPU 사용률이 30 이하이면 인스턴스 1개를 제거한다.

---

생성 완료.

---

'CloudWatch'를 보면 경보가 울렸다고 뜬다.

하지만, 인스턴스의 개수는 변하지 않는다. '최소 개수' 때문이다.

---

오토 스케일링 테스트

터미널을 이용해 과부화를 줄 예정이다. 그럴려면 터미널로 접근을 해야하므로, 프라이빗에 접근하기 위한 '베스천 호스트'를 생성한다.

베스천 호스트는 외부와 연결되므로 'public'이여야 한다.

---

생성된 퍼블릭 아이피를 통해 MobaXterm으로 접속

---

키 인증 방식을 위해 키를 업로드한다.

# 키파일의 퍼미션을 400으로 수정 (키 파일은 ReadOnly만 돼야한다.)
sudo chmod 400 my-key.pem

---

# 베스천 호스트를 통해 ssh로 키 인증 방식 접속
ssh -i my-key.pem ec2-user@[asg01/02의 프라이빗 주소]

asg01 접속

asg02 접속

---

 접속에 성공했으니, 이제 본격적으로 부하를 줘서 일부러 경보를 울릴 것이다.

# 'yes'라는 커맨드를 실행해서 그 출력을 '/dev/null' (휴지통과 같은 역할)에 계속 버린다
# 쓸데없는 행위지만, 이러한 반복으로 인해 CPU 사용량이 증가한다. (두 서버에 다 쳐주자)
sudo yes > /dev/null &

# 'top'명령어를 통해 CPU 사용률을 실시간으로 볼 수 있다.
top

Cpu 사용률이 굉장히 높게 올라갔다.

이렇게 자동으로 인스턴스가 증가한다.

'2c'에 새로운 인스턴스가 생겼다. 만일 계속 증가시킨다면 다음은 '2a'에 생길 것이다. 그 이유는 가용성을 위해 지역마다 균등하게 생겨야 하기 때문.

 

---

# 'yes'커맨드르 멈춘다.
sudo pkill -9 yes

Cpu 사용률이 정상화됐다.

---

시간이 지나니 다시 인스턴스가 2개로 줄어들었다.

종료되는 인스턴스는 랜덤으로 결정된다.

---

각각의 상황을 그래프로 보면 다음과 같다.

빨간 구간(30퍼 미만)이 계속 유지되며 인스턴스 감소

빨간 구간(70퍼 이상)이 유지되며 인스턴스 증가

---

 오토 스케일링 그룹의 특징

오토 스케일링 그룹은 모든 인스턴스가 종료되더라도 최소 크기를 지키기 위해 자동으로 인스턴스를 다시 재생성한다.

오토 스케일링 그룹의 인스턴스를 모두 종료한다.

자동으로 인스턴스를 생성했다.

최소 크기인 '2' 만큼 늘린다.

---

상태 확인에서 Elastic LoadBalancer 상태 확인 켜기

대상이 'unhealthy'의 경우에도 오토 스케일링

---

httpd를 중단하여 의도적으로 'unhealthy' 유발

오토 스케일링으로 새로운 인스턴스를 생성한다.

 

대상 그룹도 자동으로 교체된다.