운영 서버 배포 사전 성능 테스트

기존 상황 및 문제 정의

기존 인프라 비용이 달마다 30만원 이상이 소요되고 있었으며, 딱히 트래픽을 받지 않는 상황에서 과하게 인프라 자원을 사용 중이었다.

(ecs-fargate 를 과하게 사용하고 있었다.)

이러한 인프라 구성을 개편하여 비용을 줄이고 우리가 예상하는 운영 시 트래픽에 맞게 사용하고 싶었다.

이를 위해 작업한 내용을 공유하고자 한다.

 

다음과 같은 예상되는 초기 유저 수를 고려하고 있으며, 인스턴스의 크기와 개수는 경험을 토대로 프리티어 인스턴스로 충분할 것으로 예상하여 프리티어를 초기 테스트용 인스턴스로 설정했다.

예상 유저 수: 100명
원하는 처리량: 50 ~ 100tps
사용 중인 인스턴스: aws t2.micro (프리티어)
메모리: 1GB + swap memory 2GB
vCPU: 1

• 성능 테스트 툴의 경우, Locust를 선택하였다.
  • 지속적으로 부하를 발생시키는데에 적합하며, 각 API에 우선순위를 지정할 수 있다는 장점이 있기에 선택했다.

시나리오

• 각 유저는 초기 1회 로그인을 시도한다.
• 이후 백엔드 서버의 모든 API를 1 ~ 2 초에 1번씩 랜덤하게 호출하며, 쓰기 API에 비해 읽기 API를 비교적 높은 우선순위로 호출한다.
  • 실제 서버 운영을 하게 되면 읽기 작업이 더 많을 것으로 예상했다.

 

스크립트 예시

• 스크립트의 경우 다음 Repository에 정리해두었다.

showpot-archive-BE/load-test/locustfile.py at main · AlreadyTakenSeat/showpot-archive-BE

 

• 글의 상단에 작성해둔 AWS 인스턴스에 약 10분 가량 부하를 주었고, 결과는 다음과 같다.

 

전체 API와 vus 현황

• 요청을 꾸준히 보냈을때 에러는 발생하지 않았으며, API Latency가 안정적으로 유지되었다.

각 API 기록

• API 들을 고르게 요청 중임을 알 수 있다.
• Requests 가 적은 API의 경우 url path가 매번 달라져 다르게 나타나는 것이며, Locust 특성 상 이렇게 보여줄 뿐이다.

 

• AWS의 하드웨어 자원 사용량 또한 확인했다.
• 10분 동안 호출하는 작업을 두 번 진행했으며, 두 번 모두 20% 이하의 cpu 사용률을 보였다.
  • 크게 문제 되지 않을 수치라고 판단했다.

AWS CPU 사용량 (18.4%)

AWS CPU 사용량 (18.9%)

 

테스트 결론

• 현재 인프라로 원하는 tps를 만족한다는 점을 확인했다.
• 서비스 초기 단계에서 예상한 수치 기반으로 테스트한 부분임으로, 예상보다 많은 호출이 발생하거나 유저가 빠르게 늘어나는 등의 상황이 생길 때의 대처 방안도 추후 고민해보고자 한다.

인프라 비용이 어느정도 절감되었는가?

• 안드로이드 어플로 출시되어 유저가 두자릿수로 들어온 현 상황에서 인프라 비용은 다음과 같이 절감되었다.
  • 기존: 약 300,000원
  • 개선 이후: 약 20,000원
• 팀원 중에 아직 취준생인 분들도 있다는 점에서 비용 부담을 줄이는 것도 중요했는데, 예상보다도 훨씬 많이 절감되었다.
• 정말 유의미한 작업이었다. 그리고 트래픽에 알맞은 인프라에 대해 다시 한 번 생각해보는 계기가 되기도 하였다.

 

---

• 추가로, 출시된 어플이 궁금하다면, 다음 링크에서 안드로이드 기기로 받을 수 있다.
• https://play.google.com/store/apps/details?id=com.alreadyoccupiedseat.showpot

쇼팟(Showpot) - 내한 공연 정보, 티켓팅 알림 - Google Play 앱