본문 바로가기
서비스 머니터링

Devops Day 61 (6.1) 서비스 모니터링_Sprint Auto Scaling + CloudWatch를 이용한 알림

by Jackykim 2023. 6. 1.

Bare Minimum Requirement

·  EC2 서버를 ASG를 통해 구성합니다. 구성은 다음을 따릅니다.

·  CloudWatch 알람을 통해 ASG의 스케일 인/아웃을 진행합니다.

·  스케일 인/아웃이 진행될 때 디스코드에 알림을 보냅니다.

·  메트릭을 바탕으로 장애 발생 예상 시점에 디스코드에 알림을 보냅니다.

·  CPU 사용률(CPUUtilization) 값이 특정 값 이상일 때 경보가 발생하게 하세요

 
Getting Started

시작 템플릿 구성
ASG를 위한 시작 템플릿 구성은 다음을 따릅니다.

·         그룹 정보

o    원하는 용량: 1

o    최소 용량: 1

o    최대 용량: 3

·         시작 템플릿은 다음 구성을 따릅니다.

o    Ubuntu Server (LTS)

o    t2.nano

o    기존 혹은 신규 키 페어를 사용합니다

o    보안 그룹: 인바운드 HTTP 및 SSH 허용

o    사용자 데이터


CloudWatch와 조정 정책

·         CloudWatch를 통한 Auto Scaling 그룹 지표 수집 활성화 필요

·         Scale-in 조건: CPU 40% 이하

·         Scale-out 조건: CPU 50% 이상


기타

·         로드 밸런서는 설정하지 않아도 좋습니다.

 

Step 1 : Auto Scaling Group / Template 생성
- ASG 그룹 이름 기입 하고 시작 템플릿 생성


- AMI 는 Ubuntu 20.04 로 서정하고 인스턴스는 t2.micro로 설정
- 키페어는 기존거 사용하고 HTTP + SSH 가능한 보안 그룹 선택 및 생성
- 고급 설정 부분에서 추가 설정 -> 모니터링에 Cloudwatch 내에서 그룹 지표 수집 활성화 선택

- 사용자 데이터에 주어진 코드 기입 합니다.

 

Template 생성 후
- 로드 밸런서는 설정하지 않아도 좋습니다
- 그룹 크리 선택


Step 2 :
자동 크기 조정
2.1 생성한 Auto Scaling Group 들어가서 자동 크기 조정 들어가 “동적 크기 조정 정책 생성” 들어가 Scale-in / Scale-out 각 하나씩 생성합니다.

- 단계 크기 조정으로 선택하고 Cloudwatch 에서 생성한 경보하고 연결합니다.
- CloudWatch 경보는 EC2 -> auto Scale Group 선택하고 나서 CPU Utilization 선택 후 원하는 값 기입해서 생성합니다.

- Scale in / Scale-out 모두 생성하면 하단 사진처럼 나옵니다.

- Cloudwatch 기준

2.2 Cloudwatch 경보 알람과 연결 하기 위해 AWS SNS 새로 생성하여 연결합니다.

 

Step 3 : Lambda 함수 생성
3.1 Lambda 함수 생성 후 코드 편집에 들어가 SNS to discord 코드 기입합니다.
코드 참고 : https://gist.github.com/gotoweb/0f993bdc19833e76f7860608181bedac
- hook_URL 은 원하는 주소로 설정 (이번에는 디스코드로 발송)
- 코드에 username 변경

3.2 아까 생성한 SNS 하고 Lambda 함수 하고 연결

 

Step 4 : 인스턴스 하고 연결 및 접속 하고 나서 cpu stress test 진행합니다.
- stress -c 1 으로 test 진행하여 scale-in / scale-out 트리거

Discord Scale-in
Discord Scale-out

 

지표 수집 과정
EC2 수집 주기의 기본값은 5분입니다. ASG의 경우 [지표 수집 활성화]를 통해 지표를 CloudWatch에 기록합니다.

이러한 기록을 이용해 시간에 따른 메트릭 추이를 확인할 수 있습니다. 이때 경보를 통해 임계치에 따른 메시지가 SNS로 전달됩니다. 또한 ASG에서 발생하는 스케일링 이벤트를 트리거하기 위해 경보 두 개(스케일 인/아웃)를 자동으로 생성합니다.

Error :
1.
람다 생성할 때 phyton 3.10 을 선택 하지 않고 node.js으로 선택 해서 코드 error가 생김

- 그 이유는 SNS 에서 디스코드 가는 코드가 파이썬 코드라서 문제 생김

2. 람다 함수에 환경 변수 -> Hook_URL 값을 지정 하지 않아 문제 발생 및 디시코드로 메시지가 발송 안함
3. 파일 수정 후 압축해서 업로드 했을 때 기본 설정 “sns to discord”으로 업로드 했을 때 Runtime. Error가 떴습니다
.

- 문제 해결하기 위해 압축 파일 이름을 “lambda_function”으로 변경 하니깐 module error 가 없어졌습니다.  

 

Cloudwatch 참고 : https://aws.amazon.com/ko/cloudwatch/faqs/#AWS_resource_.26_custom_metrics_monitoring

 

Amazon CloudWatch FAQ – Amazon Web Services(AWS)

 

aws.amazon.com

CPU Utilization 참고 : https://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/US_AlarmAtThresholdEC2.html

 

CPU 사용량 경보 생성 - 아마존 CloudWatch

이 페이지에 작업이 필요하다는 점을 알려 주셔서 감사합니다. 실망시켜 드려 죄송합니다. 잠깐 시간을 내어 설명서를 향상시킬 수 있는 방법에 대해 말씀해 주십시오.

docs.aws.amazon.com

 

모니터링 관련 복습 / 공부

1. AWS Cloudwatch :
- 메트릭 : 주요 메트릭 수집 및 추적
- 로그 : 로그 파일 수집, 모니터링, 분석 및 저장
- 이벤트 : AWS 에서 특정 이벤트 발생 시 알림 전송
- 알람 : 메트릭 / 이벤트에 대한 실시간 대응

 

2. AWS X-Rays :
- 애플리케이션 성능 및 오류 문제 해결
- 마이크로서비스 분산 추척


3. AWS CloudTrail :

- API 호출에 대한 내부 모니터링
- 사용자에 의한 AWS 리소스 변경 감사

 

AWS CloudWatch Metric
- Cloudwatch는 AWS의 모든 서비스에 대한 지표를 제공
- 모니터링 할 변수 (CPU Utilization, NetworkIn, etc)
- 메트릭은 네임스페이스에 속함
- 디멘션은 메트릭 (인스턴스 ID, 환경 등)의 속성
- 메트릭당 최대 10개의 디멘션
- 측정항목 중 타임스탬프가 가장 유용
- 메트릭으로 Cloudwatch 대시보드 생성 가능



AWS Cloudwatch logs agent & unified agent
- 가상 서버용 (EC2 인스턴스, 온프레미스 서버..등)
- Cloudwatch 로그 에이전트
 - 구 버전의 에이전트
 - Cloudwatch logs로만 보낼 수 있음
- Cloudwatch 통합 에이전트
- RAM, 프로세스 등과 같은 추가 시스템 수준 메트릭 수집
 - Cloudwatch logs로 보낼 로그 수집
 - SSM Parameter Store

 

AWS Cloudwatch – EC2 상세 모니터링
- EC2 인스턴스 메트릭을 “5분마가” 수집 (기본)
- 상세 모니터링(유료)으로 “1분마다” 데이터 수집
- ASG에 대해 더 빠르게 확장하려면 상세 모니터링 사용
- AWS 프리 티어를 통해 10개의 세부 모니터링 지표를 보유할 수 있음
- EC2 메모리 사용량은 기본적으로 푸시되지 않음 (인스턴스 내부에서 사용자 지정 메트릭으로 푸시해야 함)

 

AWS Cloudwatch logs – 소스
- SDK, Cloudwatch logs 에이전트, Cloudwatch 통합 에이전트
- Elastic Beanstalk : 애플리케이션에서 로그 수집
- ECS : 컨테이너 수집
- AWS Lambda : 함수 로그에서 수집
- VPC flow 로그 : VPC별 로그
- API 게이트웨이
- 필터 기반 cloudtrail
- Route 53 : 로그 DNS 쿼리

 

AWS cloudtrail vs Cloudwatch vs X-ray
CloudTrail
- API 호출 감시
- 무단 호출 또는 변경의 근본 원인을 감지하는데 유용


Cloudwatch
- 모니터링을 위한 시간 경과에 따른 메트릭
- 애플리케이션 로그 저장을 위한 로그
- 예상치 못한 메트릭 발생시 알림 전송

 

X-Ray
- 자동화된 추적 분석 및 중앙서비스 맴 시각화
- 지연시간, 오류 및 결함 분석
- 분산된 시스템 전반의 요청 추적