# 태스트 내용
- 일단 AWS에서 오토스케일링은 AMI로 생성된 이미지가 스케일 IN - OUT이 된다고 보면 된다.
- 그래서 시작 템플릿을 최신의 AMI로 설정해 놓는 이유는 바로 이런 이유이기 때문이다.
- 이미 구성된 정보를 불러와 Elastic Beanstalk를 구성하고, 구성된 환경에서 테스트를 해보자.
> Elastic Beanstalk는 생각해보니... key_pair 파일이 생성된게 없으니, SSH 접근 자체가 불가능...
1. 오토스케일링 그룹을 생성하자
2. 오토스케일링된 서버에 SSH로 접근을 해보자
# 테스트 결과
1. 스케일 아웃을 통한 인스턴스 2개 증가
- Name 이 있는 인스턴스가 오리지널 인스턴스 이고, 그 아래의 2개의 인스턴스가 스케일 아웃으로 인해 생성된 인스턴스 이다. 여기서 주목할점은 Name 이 있는 인스턴스 즉 오리지널 인스턴스만 Public IP가 존재하고, 나머지 스케일 아웃된 인스턴스는 Public IP가 존재하지 않는다.
- 스케일 아웃된 인스턴스를 SSH로 접근 했을때의 모습
- 그렇다면, 오리지널 인스턴스를 SSH로 접근해보자 > 오리지널 인스턴스는 정상적으로 접근이 되는것을 확인 할 수 있다.
2. 그렇다면, 인스턴스 내부의 데이터를 변경하고 다시 스케일링 시킬때 어떻게 해야할까?
- 간단하다, 오리지널 인스턴스의 내용을 변경하고, 시작 템플릿을 최신화 해주면 된다.
3. 로드밸런서와 오토스케일링 그룹은 무엇이 다른가?
- 로그밸런서 : 말그대로 부하 분산을 해주는 역할이다. 스케일 아웃 및 인 과는 아무 관련이 없다.
- 오토스케일링 : 일정 조건 이상이 됐을때 인스턴스를 동일하게 복제해주는 역할을 한다. 부하에 따라 서버를 동적으로 생산하고 삭제하는 역할이다.