[AWS] SNS와 Cloudwatch를 이용한 모니터링과 오토스케일링

728x90

지난 포스팅에서 로드밸런서를 이용해 두 개의 퍼블릿 서브넷에 있는 인스턴스에 부하 분산하는 방법을 알아보았습니다.

이제는 특정 인스턴스(서버)에 부하가 발생할 때 SNS와 Cloudwatch를 통해 알림을 수신하는 방법, 인스턴스에 부하가 기준 이상으로 생성될 때 오토스케일링으로 인스턴스의 수를 조절하는 방법을 알아보겠습니다.

https://hgk5722.tistory.com/571

[AWS] ALB를 이용한 EC2 부하 분산

AWS 콘솔로 Application Load Balancer를 이용한 퍼블릭 서브넷에 있는 EC2에 부하 분산하는 방법을 알아보겠습니다. *서울 리전(ap-northeast-2)를 기준으로 진행합니다. 1. VPC 생성 먼저 VPC를 생성

hgk5722.tistory.com

위에 있는 링크를 들어가 마지막 결과까지 따라하신 것을 기준으로 시작하겠습니다.

1. Amazon SNS(simple notification service)

아마존 SNS는 발행/구독(Pub/Sub)모델을 가지고 있으며, 발행자(Publishers)가 메시지를 주제(Topic)에 발행합니다. 그리고 구독자(subscriber)가 관심 있는 주제를 구독하여 메시지를 받습니다.

사진에서 보듯이 SQS, Lambda, Email 등의 다양한 구독자를 가질 수 있습니다. Fan-Out 패턴으로 Cloudwatch 경보와 연동하여 시스템 알림을 설정할 수 있습니다.

2. SNS 생성, 이메일 구독

콘솔에서 SNS를 입력해 메뉴판에서 주제를 클릭

주제 생성을 클릭합니다.

유형은 "표준" 이름은 admin-topic으로 합니다. 그리고 주제 생성을 클릭합니다.

이제 구독자(Subscriber)를 만들겁니다.

생성된 admin-topic 주제에 대해 구독 > 구독 생성을 클릭합니다.

구독할 엔드포인트 유형으로는 이메일을 선택하고 자신이 수신받을 수 있는 실제 이메일을 입력합니다.

이제 확인 대기 중이 뜨는데 "확인 요청"을 눌러줍니다.

이런 이메일을 받게 되는데 "Confirm subscription"을 클릭합니다.

상태가 "확인됨"으로 변경된 것을 확인할 수 있습니다.

3. 인스턴스에 Cloudwatch 경보 관리

EC2 콘솔로 돌아가서 인스턴스 > 모니터링 및 문제 해결 > cloudwatch 경보 관리

경보 생성으로 선택하고 경보 알림은 admin-topic으로 합니다.

처음엔 %가 0.99로 되어 있는데, 30으로 바꿔주면 경보 설명도 변경됩니다.

그리고 생성을 눌러줍니다.

인스턴스의 경보 보기를 누르면 경보가 생성된 것을 확인할 수 있습니다.

Cloudwatch에서도 확인 가능합니다.

생성했던 로드 밸런서의 DNS 주소로 들어가서 창을 열어줍니다.

이제 LOAD TEST를 눌러 부하를 일부러 가해줍니다.

Generation CPU Loading > Under High CPU Load!가 됩니다.

그리고 시간이 좀 걸리는데 기다리시면 아래와 같은 이메일을 받게됩니다.

저는 5분 정도 걸린 것 같습니다. LOAD TEST 버튼을 몇 번 더 눌러봤네요.

cloudwatch도 변한 것을 확인할 수 있습니다.

이렇게 SNS를 생성하고 구독자에 이메일을 넣어 EC2 부하로 오는 경보 이메일이 오는 것까지 확인했습니다.

로드 밸런서 DNS는 5초마다 새로고침 되는데 타겟 그룹을 해제하면서 종료시켜주겠습니다.

EC2 메뉴바 > 대상 그룹 > webserver-tg > 대상 선택 > 등록 취소

상태 확인 부분인 Draining으로 바뀌는데 시간이 지나면 타겟 그룹에서 인스턴스 2개가 제거됩니다.

그리고 로드 밸런서 DNS도 이런 모습으로 변경됩니다.

4. 시작 템플릿 생성

인스턴스간에 스케일 인/아웃을 시켜주는 오토스케일링을 해보겠습니다.

EC2 오토스케일링을 하기 위해선 먼저 시작 템플릿을 생성해 주어야 합니다.

생성을 누르고

템플릿 이름은 webserver-template 그리고 Auto Scaling 지침에 체크해줍니다.

시작 템플릿 콘텐츠에 내 AMI를 들어가 만들어 두었던 AMI를 선택합니다.

인스턴스 유형은 t2.micro로 하겠습니다.

보안그룹은 기존 보안 그룹 중에 인스턴스의 보안 그룹이었던 webserver-sg로 선택합니다.

이제 이렇게 만든 템플릿을 이용해 오토 스케일러가 새로운 인스턴스를 생성할 때 시작 템플릿을 사용합니다.

5. 오토 스케일링

Auto Scaling 그룹 생성 클릭

그룹 이름은 web-asg, 시작 템플릿은 생성했던 webserver-template를 선택합니다.

2단계 인스턴스 시작 옵션 선택에서는 VPC는 VPC-Lab, 가용영역은 public subnet A, C를 선택합니다.

그러면 오토 스케일링 그룹은 서브넷 A, C를 감싸며 그 안에 있는 인스턴스를 스케일링 하게 됩니다.

기존 로드밸런서에 연결을 선택하고 태상 그룹은 webserver-tg를 선택합니다.

맨 아래로 내려서 CloudWatch 내에서 그룹 지표 수집 활성화도 클릭해줍니다.

원하는 용량은 2개, 크기 조정에서 최소는 2, 최대는 4로 지정합니다.

대상 추적 크기 조정 정책을 선택하고 지표 유형은 평균 CPU 사용률로 선택한 뒤 대상 값을 30으로 설정합니다.

그러면 평균 CPU 사용률이 30을 넘을 경우 인스턴스 수를 늘리게 됩니다.

알림 추가로 생성해 둔 SNS 주제를 선택합니다.

이제 쭉 내려서 다음을 누르고 오토 스케일링 그룹 생성을 누릅니다.

EC2 콘솔을 보시면 2개의 인스턴스가 생성되었습니다.

그리고 대상 그룹에 asg-web 인스턴스 2개가 추가된 것도 확인할 수 있습니다.

6. 부하 테스트

로드 밸런서 DNS로 접속해서 LOAD TEST를 해줍니다.

이번에도 기다려 줍니다. 10분 정도 걸렸습니다.

오토 스케일링 그룹의 기록을 보면 10분 뒤에 인스턴스를 추가 생성한 기록을 볼 수 있습니다.

EC2 콘솔에서도 2 -> 4개로 늘어난 인스턴스를 확인할 수 있습니다.

인스턴스를 증가시켰다는 이메일도 받을 수 있습니다.

2 -> 4개로 증가되었기 때문에 public subnet A, C에 각각 2개씩의 인스턴스가 존재합니다. 서브넷 간의 인스턴스 수도 동일하게 맞춰줍니다.

7. 자원 삭제

만든 순서의 반대로 Auto Scaling Group > 로드 밸런서 > 대상 그룹 > EC2 > 시작 템플릿 > AMI 순서로 삭제해 줍니다.

그리고 SNS와 Cloudwatch, VPC도 같이 삭제합니다.