다른 부서에서 푸시알림을 전송할 때 앱이 느려진다는 피드백을 받았었다.
Auto Scaling 설정되어있다고 들었었는데, 실서버의 자원을 거의 전부 쓰고 있어서 혹시나 하는 마음에 Auto Scaling 로그를 확인해보았다. EC2 인스턴스가 여러개 생성된 기록이 없어서 작동이 제대로 안되고 있다는 의심은 확신이 되었다.
그래서 Auto Scaling 설정을 다시 해주게 되었다.
1. 기존 설정에서 어떻게 바꾸었나?
기존 ASG(Auto Scaling Group) 설정에서 수정했는데 밑 스크린샷처럼 그룹크기, 상태확인, 자동조정의 동적크기조정정책을 만들어주었다. (AWS콘솔 - EC2 - Auto Scaling 메뉴 중 Auto Scaling Group, 만약 없으면 그룹 생성눌러서 아래 설정만 해주어도 된다)



수정하기 전에는 그룹크기 최대용량이 1로, 상태확인은 ELB(Elastic Load Balancer)체크가 안되어있었고 동적크기조정정책 또한 설정이 안되어있는 상태였다.
두 번째 스크린샷의 상태확인의 ELB 체크하게된다면, ELB에서 auto scaling에 의해 만들어진 인스턴스가 Unhealthy(비정상)하다면 Auto Scaling에서도 Unhealthy하도록 나타내주는 optional 기능이다.
💡 Auto Scaling을 제외한 다른 이유(네트워크, 보안 등의 설정이나 인스턴스타입 부족, 기타 설정 등)에 의해 인스턴스에 문제가 있으면 먼저 ELB에 Unhealthy 가 뜨는데, Auto Scaling에 관련된 오류가 아니라면 Auto Scaling에서는 Healthy하다고 판단한다. Auto Scaling 입장에서는 정상적이어서 실제로 문제있는 인스턴스를 지우지않고 새로운 인스턴스도 띄우지 않기 때문에, 상태확인의 ELB를 체크하는 것이 좋다.
2. 삽질의 시작, Unhealsy 오류가 왜 뜰까?
LB(Load Balancer)에서 Auto Scaling에 의해 만들어진 인스턴스가 자꾸 Unhealsy 뜨고, Auto Scailing가 Unhealsy한 인스턴스를 파악해 자동으로 지우고 새 인스턴스를 띄우는데 또 LB에서 Unhealsy 뜨고 계속 지우고 생성되는 반복 현상이 일어났다.
AWS 콘솔에서의 설정 이슈라는 생각이 강하게 들어서 모든 설정을 꼼꼼히 파악해본 후, 없는 AMI을 시작 템플릿으로 지정하기 때문이라는 것을 알게 되었다.
Auto Scaling으로 인스턴스를 생성할 때, 시작템플릿과 동일한 설정 및 사양을 가져와서 생성하기 때문에 시작템플릿 설정을 해주어야한다.
2-1) 문제의 정의
첫번째 문제는 존재하지않는 AMI로 지정이 되어있었기 때문에, 문제가 있는 인스턴스가 생성이 되어서 Auto Scaling이 작동안됐다.
두번째 문제는 지정된 AMI가 너무 오래된 AMI이다. 예전에 만들었던 AMI들로 인스턴스를 띄우게되면 AMI가 만들어졌던 그 시점의 코드를 사용하기 때문에 현재 실서버의 코드와 다를거고 이로인해 어딘가에서 에러가 나오게 될 가능성이 높다.
2-2) 첫번째 문제의 해결 과정 : AMI
- 메인 인스턴스의 AMI를 생성한다. 인스턴스 중지 및 재시작 안하려면 ‘재부팅 안 함’을 활성화해주면 된다. (라이브 서비스는 꼭 체크해야한다)
- 시작템플릿에서 만든 AMI를 지정해준다.
- ASG의 최소 용량을 변경해줌으로 인스턴스를 일부러 띄어보았고, Auto Scailing과 LB 둘다 Healsy하다는 것을 확인 및 서버접속되는 것도 확인이 되었다.
이제 Auto Scaling이 정상적으로 작동된다! 🙌🏻
2-3) 두번째 문제의 해결 과정 : 시작템플릿의 사용자데이터
Auto Scaling이 띄울 인스턴스와 앞으로 수정하거나 추가될 최신 서버코드와 동일하게 맞추기 위해서는 인스턴스를 시작할 때, 코드를 pull 받고 reload하는 스크립트를 돌릴 필요가 있다.
이에 몇가지 방법이 존재하는데 AWS 콘솔에서 해줄 수 있고, 서버가 시작될 때 작동하게 할 스크립트를 서버 내에서 직접 작성하는 방법 등 이 있는데, AWS 콘솔에서 쉽게 사용 가능하므로 AWS 콘솔에서 설정해보았다.
- 아까 설정한 시작템플릿 - 고급세부정보 - 사용자데이터 에 들어가서 shell 스크립트를 적어주면 된다.

시작템플릿 사용자 데이터에 넣은 스크립트가 잘 돌아가는지 확인해보기 위해서 우선 위의 내용대로 서버에서 실행되는지 테스트할 필요가 있었다. 그래서 실서버에 test.sh 이란 실행파일을 만들고 위의 내용을 입력하고 실행해보았다.
- test.sh 파일을 만들고
- chmod +x test.sh 커맨드로 파일을 실행파일로 바꿔주었다.
- sh test.sh 커맨드로 파일을 실행해보았다.
💡 처음에는 복붙한 -- 바가 하나의 긴 바(—)로 자동입력이 되어서 스크립트 실행이 실패되다가 코드들을 직접 입력해주어 작동이 되는 것을 확인했다.
3. 문제해결 완료!

파란색은 메인 인스턴스의 cpu 사용률, 주황색은 Auto Scaling에 의해 띄어진 인스턴스의 cpu 사용률이다. 주황색이 나오고나서는 cpu 뿐만이 아니라 메인인스턴스의 모든 사용률이 줄어들었다. 그 말은, 서버 퍼포먼스 향상되어 부하가 덜 걸린다는 것을 의미한다.
평소에는 트래픽이 ELB를 통해 두 인스턴스로 분배되기 때문에 주황색이 나온 것처럼 계속 지속될 것이다.
여기서 사용자가 급증하게 되면, 인스턴스 하나 더 생성될 것이고 트래픽도 적절히 분배되기 때문에 고가용성 서비스라고 충분히 부를 수 있다.
서비스 사용자의 경험을 염두에 두고 작업해야한다
'개발 > AWS' 카테고리의 다른 글
[AWS] CloudFront+S3 배포했는데 하위페이지에서 access denied에러날 때 (0) | 2022.10.24 |
---|