Auto Scaling, Capacity Provider, Discord WebHook

필너츠 프로젝트는 ECS로 배포하면서 여러가지의 문제에 봉착했다. 그 중 하나가 ECS로 무중단 배포를 적용 시킬 수 있으며, 블루 / 그린, 롤링 중 하나를 설정할 수 있지만 블루 그린은 자원이 비교적 많이 필요하기에 롤링으로 선택했다.

 

배포 자동화에 대해 자세히 알고싶으면 https://youngjae0412.tistory.com/52 를 참고하면 된다.

 

롤링은 배포가 진행되는 동안 구버전과 신버전이 공존하기 때문에 호환성 문제가 발생할 수 있지만 가용 자원이 제한적이기때문에 알맞는 배포방식이었다고 생각한다.

 

가용 자원이 한정적이어서 롤링을 선택하였지만 우리는 t3a.small로 배포하여 cpu가 2048mb였다. 여기서 컨테이너의 CPU의 할당을 1024로 하게 되면 신버전을 배포할 때 CPU가 모자르는 상황이 발생하게 된다. AWS의 CPU 할당 추천에 따라 512MB로 설정하였고 최소 컨테이너를 두개로 하였다. 이렇게 되면 결국 우리는 CPU의 절반 밖에 쓰지 못 하고 있는거여서 손해를 보고 있는 것이다.

 

그래서 준비한게 오토스케일링이다. 만약 평상시에 컨테이너 두개로 트래픽을 잘 견디면 아무 문제 없다. 프리티어랑 동일한 스펙을 돈 주고 쓰는거니 비용적 손해가 발생하는 것이 아니냐 라고 할 수 있지만, 우린 채팅 서버를 t2.micro로 돌리고 있기에 t3a.small 비용 - t2.micro인데 솔직히 그정도의 손해는 눈 감아줄 정도의 수준이다. 하지만 만약 유저가 몰린다면? 결과적으로는 서버는 터지게 되고 유저들은 사용에 불편함을 표시할 수밖에 없다. 그래서 도입한게 Auto scaling, Capacity Provider이다. 개인적으로 영어보단 한글이 편하기에 오토스케일링, 용량공급자라고 부르겠다.

 

오토스케일링은 CPU, 메모리, 디스크, 네트워크 트래픽과 같은 시스템 자원들의 메트릭 값을 모니터링하여 서버 사이즈를 자동으로 조절하는 기술이다. 지금 상황에서 딱 필요한 기술이었다. 우선 부하테스트를 해보았을 때 서버가 터질 때 메모리가 부족해 터지는게 아닌 CPU가 부족해 터지는 상황이 나왔다. 그래서 우선 Cloud watch에 들어가 경보 시스템을 만들었다. CPU의 사용량이 40% 이상이 되면 경보가 울리게 설정하고 Scale-Out으로 이름을 붙이고 CPU의 사용량이 30% 이하가 되면 경보가 울리게 설정하고 Scale-In이라는 이름을 붙였다. 그후 ECS 서비스에 가 오토스케일링에 가서 설정을 해주었다. Scale-out은 경보가 울리면 1개의 컨테이너가 추가되게끔, Scale-In은 경보가 울리면 하나가 제거되게끔 하여 이제 우리는 트래픽이 몰려 컨테이너의 CPU가 40% 이상을 쓰게 된다면 컨테이너를 하나 더 쓰게되어 전보다 트래픽 감당이 가능해졌다. 

 

하지만 문제가 있었다. 유저가 많이 몰려 오토스케일링이 되었을 때 배포가 진행된다면 컨테이너에 할당해줄 CPU가 모자라 에러가 날 것이다. 배포할 때마다 오토스케일링이 되었나 확인하는거는 매우 비효율적이다. 그래서 오토스케일링이 될 때 알람을 받을 수 있게 구현하기로 하였다. 그래서 오토스케일링이 된다는 건 Cloud Watch의 경보가 울렸다는 것이고 그 경보가 울릴 때 SNS로 메세지를 받는다. 그 메세지를 다시 Lambda로 보내고 함수는 discord 웹훅으로 짜 그 이벤트를 그대로 보낸다. 그럼 오토스케일링이 될 때마다 우리는 디스코드로 알람을 받을 수 있어 grafana나 ECS를 통해 확인하지않아도 편하게 확인이 가능하다. 그라파나를 통해서도 알람을 받을 수는 있지만, 그라파나 도입 전에 구현하여 이런 방식으로 구현하였다.

 

슬프게도 오토스케일링이 진행되는 일은 없었다.. 하지만 만약에 우리 서비스가 정말 잘 되어 트래픽이 몰려 오토스케일링이 되었음에도 CPU가 부족하다면 어떡할까..? 그럴 때 쓰는 것이 Capacity Provider(용량공급자)이다. 용량공급자가 출시 전에는 ec2를 직접 오토스케일링을 세팅하고 그 후 컨테이너의 오토스케일링을 진행했다고 한다. 하지만 컨테이너 즉, 작업은 오토스케일링 되는데 정말 빠르다. 꺼지는게 오래 걸리지 켜지는데는 30초도 안 걸린다. 하지만 EC2는 최소 2~3분은 걸린다. 이 간극을 전에는 단순하게 EC2의 오토스케일링의 트리거를 낮게 잡고 작업은 그것보다 더 높게 잡아 맞췄다고 한다. 이렇게 하는게 맞나? 싶을정도로 조금 의문이 생기는 방법이었다. 그래서 나온 것이 용량공급자이다.

 

용량공급자는 먼저 계획을 짠다. 실행해야 하는 작업의 개수가 있고 EC2가 얼마나 필요한 지 계산을 한다. 작업은 ECS에게 필요한 리소스를 요청하고 클러스터는 용랑관리자에게 리소스를 준비하도록 시킨다. 만약 EC2가 없으면 자신에게 배정된 오토스케일링 그룹에 맞춰 작동하고 필요한 서비스를 확보한다. 그 후 EC2가 실행되면 미리 계획했던 작업들은 EC2에 배치함으로 마무리 된다. 

 

이 얼마나 획기전인 서비스인가? 우리야 솔직히 크게 필요없는 서비스지만, 만약 피크타임 때 정말 많은 트래픽이 몰리고 그 외에 트래픽이 몰리지않는다면 기본적으로 낮은 사양의 인스턴스를 쓰고 오토스케일링 그룹을 만들 때 피크타임이 감당가능한 사양으로 선택해서 만들면 높은 사양의 인스턴스를 쭉 쓰는거보다 비용절감에 효과를 확실히 볼 것이다. 클러스터를 만들 때 내가 만든 사양과 동일한 오토스케일링 그룹이 만들어졌고 클러스터에 적용 시킴으로 세팅이 되었다. 하지만 이 역시 배포 중에 보는 일은 없었다.. 

 

그래도 다양한 트래픽에 감당하는 방법을 알아보고 이것이 최선이라 생각하여 적용시켰다. 용량공급자에 관련된 블로그가 많은건 아니지만 잘 정리해준 블로그들이 많은데 뭔가 나는 대충 겉에 느낌은 알겠는데 속에 핵심을 모르는 느낌이 들어 해외 블로그까지 찾아봤지만 이해가 어려웠다. 그 와중 AWS 공식 유투브에 올라온 강의가 있는데 정말 명강의다. 솔직히 내 블로그 읽는거보다 강의 한번 듣는게 더 도움 될거다. 

 

용량공급자뿐만 아니라 컨테이너에 관련된 기초적인 내용을 잘 설명해주시니 한번쯤 컨테이너에 대해 관심 있다면 꼭 보는 것을  추천한다.