해당 포스팅은 '쉽게 설명하는 AWS 기초강좌 12: EC2 Autoscaling'을 시청하고 작성되었습니다.
Scaling?
: 인스턴스 또는 컴퓨팅 파워를 늘리는 것
- Vertical Scale(=Scale up) : CPU가 1개 짜리의 1GB 메모리의 컴퓨터 자체의 성능을 16배 하는것
- 단점 : 성능과 비용이 비례하지 않는다. 컴퓨터 자체를 늘렸다보니, 탄력성이 사라짐. 필요하지 않을경우에
- Horizontal Scale(=Scale out) : CPU가 1개 짜리의 1GB 메모리의 컴퓨터를 16개를 구매하는 것
- 장점 : 성능과 비용이 비례해지고, 수없이 필요해도 충분히 가능해진다.
- 단점 : SW적으로 구현하기 위해 고민을 많이 해야함
Auto Scaling
→ 어플리케이션을 모니터링하고 용량을 자동으로 조정하여, 최대한 저렴한 비용으로 안정적이고 예측 가능한 성능을 유지한다. AWS Auto Scaling을 사용하면, 몇 분 만에 손쉽게 여러 서비스 전체에서 여러 리소스에 대해 어플리케이션 규모 조정을 설정할 수 있는 것이다. 즉, 간략하게 말하자면, Horizontal scale을 위해 나온 서비스라고 말할 수 있다.
→ EC2 Auto Scaling, DDB Auto Scaling, Spot Fleet Auto Scaling, Aurora Auto Scaling, ECS Auto Scaling 등이 있다.
EC2 Auto Scaling
- 목표
- 정확한 수의 EC2 인스턴스를 보유하도록 보장하는 것
- 그룹의 최소 인스턴스 숫자 및 최대 인스턴스 숫자 즉, min/max값을 지정해두고 이 값 이하 또는 이상 늘어나지 않도록 유지하는 것.
- 다양한 스케일링 정책 적용이 가능하다. ex) CPU의 부하에 따라 인스턴스 크기를 늘리는 등
- 가용 영역에 인스턴스가 골고루 분산될 수 있도록 인스턴스를 분배 하는 것
- 이에따라 가용영역에 장애가 발생했을 때, 서비스 장애를 최소화 할 수 있음.
- 구성
- 시작 구성(launch config) / 시작 템플릿 - 무엇을 실행 시키고 싶은지
- EC2의 타입 및 사이즈, AMI, 보안 그룹, Key, IAM, 유저 데이터
- 모니터링 - 언제 실행 시킬 것인지 + 상태 확인
- ex) CPU 점유율이 일정 %를 넘어섰을 때 추가로 실행할 것인지 2개 이상이 필요한 스택에서 EC2 하나가 죽었을 때
- CloudWatch(모니터링 역할) + ELB(부하 분산 역할)와 연계를 함
- 설정 - 얼마나 어떻게 실행 시킬 것인지
- 최대 / 최소 / 원하는 인스턴스 숫자 및 ELB 연동 등
- 동작 방식
- 시나리오 : 어떤 임의의 인스턴스 하나가 어떠한 이유로 인해 죽었다고 가정 → 시작 구성에 맞춰둔 EC2의 타입 및 사이즈, AMI, 보안 그룹, Key, IAM, 유저 데이터 등에 맞춰 AutoScaling Group에서 감지하고 새로운 인스턴스를 만든다.
AWS console에서 시작 템플릿 및 auto scaling group
시작템플릿으로 이동하기
시작템플릿 생성하기
템플릿 이름 및 설명 작성하기
그에따른 시작 구성을 설정해준다.
여기서 보안그룹을 설정하지 않는 이유는 아래 네트워크 인터페이스에서 보안그룹을 설정할 것이기 때문에 설정하지 않고 넘어가는 것 입니다.
보안그룹은 default로 퍼블릭 IP 자동 할당은 활성화와 종료시 자동 삭제는 꼭 "예"를 설정해주세요.
시작 템플릿 완성
대쉬보드 좌측 탭에서도 Auto Scaling 그룹에서 올 수 있음
Auto Scaling으로 넘어오면
만들어둔 시작 템플릿을 검색을 하면 그에 대한 정보가 아래 자동으로 뜸
다음으로 넘어가서 인스턴스 시작 옵션 설정. 프리티어의 경우에는 아마 4개 선택이 안될 가능성도 있음
아직 load balancing을 하는 단계는 아니기 때문에 이렇게 해두고 넘어간다.
여기서 얼마나 실행시킬 것인지 최대 최소값을 설정하는 곳
알림과 태그는 선택이므로 스킵하였습니다. 그리고 이제 정말로 Auto Scaling 그룹을 생성합니다.
여기에서 볼 수 있음
