<aside> ✨ EC2 중단 배경

</aside>

• User Test를 위해 EC2(t2.micro) 단일 ****인스턴스에 서비스를 배포했었다.
• Docker Compose를 이용하여 RabbitMQ, Springboot 컨테이너를 동시에 관리하였고, Redis는 EC2 인스턴스 내부에 설치해둔 상태였다.
• User Test 시작 후 약 40명 가량의 사용자가 서비스를 이용했고, CPU 사용량이 최대치로 치솟아 결국 인스턴스가 중단되었다.

<aside> ✨ AutoScaling 도입

</aside>

• 예상보다 더 적은 인원에도 서버가 다운되는 것을 직접 경험하고, 팀원들과 협의하여 Scale-up을 통한 서버 부하 분산 처리를 하기로 결정했다.
• Scale-up을 사용한 수직적 확장을 고려했을 때, 서버 비용 증가의 부담이 커 Scale-out을 통한 수평적 확장을 선택하였다.
• 여러 대의 서버에 분산 처리 되어 대량의 데이터 처리를 이뤄낼 수 있다는 장점이 있으며, 기존 배포 방식과 다르게 한 대의 서버가 다운돼도 다른 서버가 대체할 수 있다는 점에서 큰 메리트가 있다고 생각했다.
• 추가로, AutoScaling을 도입하면서 서버 부하가 커질 때 자동으로 인스턴스가 증가하도록 하여 운영 서버의 안정성을 높일 수 있었다.

<aside> ✨ LoadBalancer 도입

</aside>

Amazon ALB 사용

• AutoScaling과 Scale-out을 통한 서버 부하 분산 처리 이후, 사용자의 요청이 하나의 서버가 아닌 여러 대의 서버에 분산 돼야 할 필요가 생겼다고 인지했다.
• 따라서, LoadBalancer를 도입하여 여러 대의 서버에 Client의 요청이 자동으로 분산 되어 사용자의 요청을 처리할 수 있도록 하였다.