[71일 차] 21.11.03 : DevOps 12

Auto Scaling Policy

AWS CloudWatch Alarm

---

1교시

 

 

어제는 로드 밸런서와 오토 스케일링을 통한 동기식 디커플링

-> 요청 정보와 응답 장비를 디커플링 하기

 

웹 서버와 트래픽을 디커플링 하는 오토 스케일링 그룹의 앞단을 ELB로 묶고, 오토 스케일링 그룹은 서버의 실행을 보장한다. 오토 스케일링 그룹에서 시작되는 서버는 자동으로 ELB에 등록된다.

 

CPU 사용량이 일정 기준을 넘거나 미만일 때 확장 또는 축소를 진행하는데, 바로 진행하는 것이 아니다. 일정 시간 지켜보는데, 여기에 걸리는 시간은 Cooldown 지시자의 값으로 결정된다.

Cooldown: 10

이면 10분 동안 지켜보는 것.

(AWS::AutoScaling::AutoScalingGroup 작업에서 작성된다)

오토 스케일링 그룹은 인스턴스의 상태를 모니터링하고, 용량을 조정한다.

보통 확장은 빠르게, 축소는 천천히 하는 것을 권장한다.

 

어제는 사용량이 기준치를 넘으면 인스턴스가 확장되는 것을 봤다면, 이번에는 정책을 보자.

Auto Scaling Policy

어제 CPU 사용량이 5%를 넘으면 인스턴스가 추가되었는데, 이 값이 TargetValue에 있다.

 

인스턴스 체크 > 모니터링 탭 > 세부 모니터링 관리 > 활성화

-> 1분 기간으로 모니터링 지표를 보고받을 수 있다(유료)

기본 모니터링 지표는 5분 간격으로 보고받는다.

---

2교시

 

 

요점은 오토 스케일링 그룹이 클라우드와치로부터 지표를 받는 것

 

시작 구성 빠르게 하기

여러 가지 스케일 정책 및 CloudWatch 연동

 

어제처럼 인스턴스 4개 중 1~2개가 사용량이 99%를 찍는다. 인스턴스 내에서 프로세스가 죽지 않아서 가끔 있는 오류라는데....

 

퍼블릭 주소가 없는 인스턴스에 접속하기 위해 접속용 인스턴스 하나 생성

-> 개인 키 = 키 파일(.pem)의 내용을 복사 후 만든 인스턴스에 접속

-> 홈 디렉터리의 .ssh 디렉터리 밑에 .pem 파일 생성 후 내용 붙여넣기

-> 파일 권한을 600으로 변경

-> ssh -i .ssh/[키 파일].pem [접속할 사용자명]@[대상 인스턴스의 사설 주소]

-> 접속 후 root 권한으로 top 실행해서 프로세스 확인

 

어쨌거나 과부하된 인스턴스를 종료시키고 적당히 기다리니 Auto Scaling 그룹에서 수정을 시작하는 것이 보인다.

칼같이 5분 재서 사라지고 그러진 않는 것 같다.

-> 쭉 기다리니 4개로 늘어났던 인스턴스가 2개로 줄어든 것을 확인했다.

---

3교시

 

 

시작 구성의 설정으로 인스턴스의 구성을 만들 수도 있고, 커스텀 된 AMI를 만들어서 사용할 수도 있다.

CloudFormation으로 AMI를 만드는 작업도 있다고는 하는데, 일단 넘기자.

 

지금 하는 방법들은 부하 분산 시 인스턴스가 새롭게 시작되는데 걸리는 시간을 단축시키기 위한 방법들이다.

1. 시작 구성에 설정을 마쳐놓은 AMI를 사용한다.

인스턴스 > 작업 > 이미지 및 템플릿 > 이미지 생성 > 이름 작성 후 이미지 생성

만들어진 AMI의 ID를 Auto Scaling의 시작 구성에 작성하면 되는데, 시작 구성은 수정이 안된다.

-> 기존 시작 구성 복사 > AMI만 바꿔서 복사

-> 아니면 CloudFormation 템플릿 파일의 시작 구성 부분에 있는 AMI ID 수정

 

2. Warm Pool

https://docs.aws.amazon.com/ko_kr/autoscaling/ec2/userguide/ec2-auto-scaling-warm-pools.html

Amazon EC2 Auto Scaling의 웜 풀 - Amazon EC2 Auto Scaling

생긴 지 얼마 되지 않은 기술이라는데, 무조건 사용할 필요는 없다. 

웜 풀은 오토 스케일링 그룹과 함께 있는 미리 초기화된 EC2 인스턴스의 풀이다.

 

오토 스케일링 그룹 > 인스턴스 관리 탭 > 웜 풀에서 웜 풀 생성이 가능.

웜 풀을 생성하면 웜 풀 인스턴스가 생성되는데, 여기에 있는 인스턴스 ID를 기억해놓자.

-> 부하 증가로 인스턴스가 증가할 때, 새로 생긴 인스턴스의 ID 확인

---

4교시

 

 

AWS::AutoScaling::LaunchConfiguration 타입에서

1. AssociatePublicIpAddress 지시자의 값을 true로 지정하면 오토 스케일링 그룹의 각 인스턴스가 고유한 퍼블릭 IP를 받을 수 있다.

2. IamInstanceProfile 지시자는 IAM 역할의 ARN값 또는 ID값을 받아서 링크된 IAM 역할을 생성될 인스턴스 프로필에 넣을 수 있다.

3. EbsOptimized 지시자의 값을 true로 설정하면 AMI 이미지에 정의된 IOPS와 EBS 루트 볼륨 전체 처리량을 제공하는 EC2 인스턴스에 대한 EBS 최적화를 활성화할 수 있다.

 

AWS::AutoScaling::AutoScalingGroup 타입에서

1. DesiredCapacity : (처음 시작할 때) 원하는 가상 서버 수

2. MaxSize : 가상 서버의 최대 수(스케일링 임계값)

3. MinSize : 가상 서버 최소수(스케일링 임계값)

4. Cooldown(재사용 대기 시간) : 스케일 작업 간 최소 시간 간격(초 단위)

5. HealthCheckType : 오토 스케일링 그룹이 가상 서버의 상태를 확인하는 방식(EC2/ELB)

6. HEalthCheckGracePeriod(유예기간) : 새로운 인스턴스가 시작된 후 인스턴스가 정말 부팅될 때까지 기다리기 위해 헬스 체크를 멈추는 시간(초 단위)

7. TerminationPolicies : 먼저 종료할 인스턴스를 정하는 데 사용하는 정책

 

Cooldown, HealthCheckGracePeriod 값을 합리적으로 정해야 한다. 최근에는 2가지 값을 짧게 해주는 추세.

-> Cooldown이 너무 짧으면 너무 일찍 서버를 늘리거나 줄이게 된다.

-> HealthCheckGracePeriod가 너무 짧으면 새로 시작한 인스턴스가 부팅되기 전에 오토 스케일링 그룹이 또 다른 인스턴스를 실행하게 된다.

(인스턴스가 시작하기도 전에 헬스 체크를 실행하고, 시작을 안 했으니 실패하고, 실패하니 또 인스턴스를 만드니까)

---

5교시

 

 

https://docs.aws.amazon.com/ko_kr/autoscaling/ec2/userguide/schedule_time.html#create-sch-actions

Amazon EC2 Auto Scaling에 예약된 조정 - Amazon EC2 Auto Scaling

오토 스케일링 그룹 조정 관련 문서

 

지표와 스케줄로 스케일링 트리거하기

 

- 지표

클라우드 와치 알람 -> 오토 스케일 시작 구성 -> 생성 -> EC2 인스턴스

- 스케줄

특정 시간에 서버를 추가하거나 삭제

 

1. 스케줄 기반 스케일링

 

워드프레스 기반 블로그 플랫폼을 운영하면 반복적인 부하 패턴을 알 수 있다고 가정.

1) 많은 사람이 점심시간인 오전 11시에서 오후 1시 사이에 기사를 읽는 것으로 보인다.

2) 회원 등록 요청은 저녁 TV 광고 후 급격히 증가한다.

 

예약 스케줄링 작업을 운영할 수 있다.

1회성 작업 : starttime 매개변수를 사용해서 생성

반복 작업 : recurrrence 매개변수를 사용해서 생성

 

---

6교시

 

 

* 스케줄 기반 스케일링

스택 생성 후 오토 스케일링 그룹 > 자동 조정 탭 > 예약된 작업 > 예약된 작업 생성 > 내용 대충 작성

 

클라우드 와치 알람 -> 지표 모니터링 -> 클라우드 와치 지표(CPU 사용량, 네트워크 사용량, 사용자 정의 지표)

-> 오토 스케일링 -> EC2

알람 부분

CloudWatch > 경보 > 모든 경보에서 설정했던 알람들을 볼 수 있다.

경보 생성에 필요한 값들을 보면 각 지시자들이 무엇을 지칭하는지 알 수 있다.

경보 생성 1단계 '지표 및 조건 지정'이 위 코드에 해당한다.

---

7~8교시

 

 

오토 스케일링 그룹 > 자동 조정 탭 > 동적 스케일 정책 생성

동적 조정 정책 생성 부분

정책 유형은 단순 조정, 정책 이름은 AutoScalingGroup, 콘솔에서 CloudWatch 경보는 동적 스케일 정책 생성 시 지정하는데, 코드에서는 AWS::CloudWatch::Alarm에서 연동. 대기 60초, 작업 수행은 '1'

 

 

상태 서버와 무상태 서버

상태 서버는 데이터를 로컬 스토리지에 기록

무상태 서버는 RDS/S3 버킷에 데이터를 기록

-> 가용 영역에 문제가 생겨도 데이터 보존 가능

 

 

wordpress-loadtest.yml 파일로 스택을 업데이트 : 부하 발생 인스턴스 생성

-> 생성된 인스턴스에서 부하를 발생시키면 High 알람 정책에 의해 지표에서 감지, 오토 스케일링 그룹에 전달, 인스턴스 생성

-> 다시 부하나 낮아지면 Low 알람 정책에 의해 지표에서 감지, 오토 스케일링 그룹에 전달, 인스턴스 삭제

 

 

모놀리식 아키텍처, MSA 방식으로 애플리케이션 내부 구성의 요소들을 디커플링 가능

 

내일은 비동기 디커플링, ACM, Server Migration Service

파이썬은 미뤄졌다.

---

1교시 후반 빠르게 훑기

2교시(10:30~11:00) 키 만들어서 접속

6~8교시 빠르게 훑기

 

다음 주부터 AWS 공인 강사님이 오시는데, 그동안 배웠던 AWS 서비스들 따로 적어놓자.

강사님이 이거 배웠냐고 물어보면 대답해야 한다.