37일차) 2025-02-20(Auto-scaling, CloudWatch, 시작 템플릿)

풀이)

최소 각각 1쌍 이상(web두개, was두개)의 web,was를 생성하며 DB는 제외한 2 tier구조를 만들어보세요. ELB를 사용해야한다면 ALB를 사용하세요. 사용자는 web의 /tomcat 경로로 접속했을때 was로 리버스 프록시 되어야합니다.  tomcat은 systemd를 통해 데몬으로 만드세요.

 

1. was서버 구성 - tomcat 설치, systemd에 등록, enable, index.jsp 파일 구성

2. was 테스트 및 이미지 생성

# 재부팅 후에 접속되는지 테스트 후 was-img 생성

3. was-alb(internal)

# 타겟그룹을 비워두고 생성 및 로드밸런서에 등록

 

• 아무 퍼블릭인스턴스에 접근해서 was-alb가 유효한지 확인

# 내부에 만든 was-alb가 잘 동작하는것을 확인

4. web서버 구성 - nginx 설치, enable, was-alb로 리버스프록시

• 헬스체크를 목적으로 index.html 파일 생성

root@ip-10-10-1-200:~# apt update -y && apt install -y nginx
root@ip-10-10-1-200:~# systemctl restart nginx
root@ip-10-10-1-200:~# systemctl enable nginx
root@ip-10-10-1-200:~# echo test > /var/www/html/index.html

root@ip-10-10-1-200:~# vi /etc/nginx/conf.d/proxy.conf

root@ip-10-10-1-200:~# vi /etc/nginx/sites-enabled/default

root@ip-10-10-1-200:~# systemctl restart nginx

# 리버스 프록시가 잘 되는걸 확인 및 재부팅 후에도 접속되는지 확인

 

5. web 테스트 및 이미지 생성

6. web-alb 생성

---

HAProxy

기존의 하드웨어 스위치를 대체하는 오픈소스 소프트웨어

웹서버의 로드밸런싱 + 고가용성 제공하는 프록시 서버

고성능, 안정성, 낮은 메모리 공간, 수만개의 동시 연결 처리

---

이미지에는 인스턴스 유형이나 보안그룹같은 설정이 포함되어있지 않음

→ 오토스케일링을 통해 서버가 생성될때마다 보안그룹을 일일이 지정을 하는게 현실적으로 불가능

→ 이미지와 '인스턴스를 생성할때 설정했던 내용'들을 미리 정의하고 싶음

시작 템플릿

인스턴스 시작을 효율화, 간소화, 표준화

인스턴스를 쉽게 원하는 환경으로 생성할 수 있음

 

index.html을 배포하는 간단한 웹서버 인스턴스 띄우기

root@ip-10-10-1-31:~# apt install -y nginx

root@ip-10-10-1-31:~# systemctl enable nginx
root@ip-10-10-1-31:~# apt update -y && apt install -y stress

# stress: 10분(600초)동안 1 core에 대한 부하가 100% 발생

# 나중에 오토스케일링을 하면, cpu사용량을 지표로 해서 scale in-out이 트리거도 되도록 하고 싶기 때문

# 꼭 이미지를 만들기전에 재부팅을 해서 재부팅 후에도 잘 동작하는지 확인

 

이렇게 만든 이미지로 시작 템플릿을 만들기

 

 # 서브넷은 지정하지 않음 → 생성되는 서버들이 여러 서브넷에 고루 배치되도록 하고싶기 때문

Auto-scaling

1. Scale out - 서버의 갯수가 늘어남 ↔ 줄어들면 Scale in
2. Scale up - 서버의 리소스가 증가함
   ex. vcpu가 2core 였다가 4core가 된다 ↔ Scale down

구성 순서

1. ELB를 생성하면서 ‘빈 타겟그룹’을 생성
2. 빈 타겟그룹으로 로드밸런서를 완성
3. 오토스케일링 그룹을 만든후 빈 타겟그룹에 넣어준다

1. 로드밸런서 생성

 

# 타겟그룹을 비워둔채 생성

3. 오토스케일링 그룹 생성

 

 

 

 

 

 

# 트래픽을 발생시키기 위해서 서버에 접속

 

퍼블릭아이피로  ssh 접속

# cpu에 부하를 주고

# top 명령으로 cpu 사용량도 동시에 확인

# 10분 이상 걸릴 수 있다.

---

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

혹시 ‘단순크기조정정책’으로 안되시면

 

scale-out 정책을 ‘대상추적크기조정’ 이렇게 만드셔서 cloudwatch에 ‘경보’가 뜨고, 인스턴스가 증가하는지 확인해보세요.

1. 경보를 만들때 오토스케일링 그룹을 잘못 지정하는경우

2. CPU 사용량 모니터링 방식이 내가 생각했던것과는 달라서

3. 서버가 문제가 있어서 부하가 충분히 주어지지 않는경우.

=> 한 번 싹 다시.

 

---

이번엔 축소정책(scale-in)을 만들자.

 

 

 

 

알림제거하고

 

 

 

 

# 2개 감소

# 3개 감소

실습)

web서버를 ubuntu 24.04 기반으로 생성하여 오토스케일링을 구성해보세요.

min 1대 ~ max 3대

 

가용영역 최소 2개 이상(a,c)으로 하는 오토스케일링 가능한 web서버들을 프라이빗 서브넷에 두세요. (템플릿을 만들때는 퍼블릭으로 하셔도 됩니다. 가능하다면 stress 패키지가 재부팅시에도 자동으로 부하가 걸리게끔 만들어도 보세요. 물론 하던대로 해도 됩니다.)

 

외부(노트북의 브라우저)에서 웹페이지가 보이도록 만들어보세요.

 

풀이)

사전에 시작템플릿이 만들어져 있다면,

 

1.퍼블릭 서브넷에 ALB를 만든다

2.프라이빗서브넷에 오토스케일링 그룹을 둔다.

3.두개를 연결한다.

 

 

 

 

 

 

• 시작템플릿을 만들 서버 생성 및 설정

root@ip-10-10-1-32:~# apt update -y && apt install -y stress nginx

# 스트레스 패키지 및 웹서버 배포환경 구성.

root@ip-10-10-1-32:~# systemctl restart nginx
root@ip-10-10-1-32:~# systemctl enable nginx

# apt install -y stress해서 생긴 명령어. 이 명령을 systemd에 등록을 해주면 된다.

 

root@ip-10-10-1-32:~# vi /etc/systemd/system/stress.service

[Unit] After=network.target [Service] ExecStart=/usr/bin/stress --cpu 1 --timeout 300 Restart=always User=root [Install] WantedBy=multi-user.target

root@ip-10-10-1-32:~# systemctl daemon-reload
root@ip-10-10-1-32:~# systemctl enable stress

재부팅 후 동작하는지 확인

 

# 재부팅 후 접속한 서버에서 top 명령으로 cpu의 부하가 발생하는지 확인

이렇게 만든 서버를 토대로 이미지 및 시작템플릿을 만든후 프라이빗 서브넷에 두면 된다.