서버리스 적용 실패기

수년 전에 Ruby on Rails로 제작한 서비스가 있는데, Ruby는 제대로 공부해본 적이 없어 새로운 기능을 추가하는데 제한이 생겨 next.js로 포팅하기로 계획했다.

최종적으로 vercel, neon, upstash 서비스를 이용했는데, 속도가 말도안되게 느려서 서버리스는 포기하게 된 케이스이다.

서버리스

작업을 어느정도 완료하고 배포를 어떤걸로 할까 고민하게 되었다. 사용한만큼 비용이 청구되는게 매력적으로 보였다. 그리고 next.js는 워낙 인기있어서 이를 쉽게 배포해주는 서비스가 여럿 있었다.

AWS를 사용하고 있었는데, 수익은 없고 매달 200달러가 청구되는게 부담이 느껴져 이를 줄일 수 있는 방법으로 생각해낸게 서버리스였다. 개발환경과 운영환경을 운영했고, 각각 Load Balancer, RDS, Elasticache도 따로 생성하다보니 이 정도 금액이 청구되었다.

여태 인스턴스들 CPU 사용량을 봐선 최저 유료플랜만 사용해도 충분할거라는 판단이 들었고, 비용은 4분의 1로 줄일 수 있을 것 같았다. 그리고 트래픽이 몰려도 서버가 뻗을 일은 없었다.

aws amplify hosting

기존에 AWS를 이용중이었기 때문에 이전에 사용해본 적 있는 amplify hosting을 적용해보기로 했다. 이전에 시행착오도 몇번 겪어봐선지 금방 설정을 완료했다.

그러나 시작부터 문제가 발생했다. elasticache에 접속을 할 수 없는 것이다. 찾아보니 VPC 내부에서만 접근이 가능했다. 어떻게 저떻게 하면 해결할 수 있을거라는 생각은 드는데 굳이 시간을 쏟을 필요는 없었다.

빌드도 너무 오래걸렸다. next.js 빌드는 2분이 안걸리는데, 빌드환경 셋팅하는 작업이 오래걸려서 배포하는데 10분이 소요되었다. 2~3년 전에는 이정도로 오래 걸리진 않았는데, 바뀐게 있는 것 같다. 가격은 USD0.01 per minutes for BuildDuration인데, 10분 걸리니까 한번 빌드하는데 200원 정도 소요된다.

vercel

vercel로 빌드하니 배포가 1분 30초만에 끝났다. 브랜치 설정이 익숙하지 않아서 조금 해맸다.

서버리스다보니 DB에 커넥션이 엄청 쌓일거라는 판단이 들었다. 그래서 RDS에 Proxy를 적용해보려 했는데, 복잡해서 제쳐두고 neon을 사용했다. redis는 upstash로 적용했다. 설정은 간편했고, 데이터베이스에 브랜치가 있다보니 환경별로 따로 추가를 해주지 않아도 됐다.

잘 해결 되었나 생각하던 찰나에 기존 서비스랑 비교하면 서비스가 조금 느린게 느껴졌다. 사실 실 사용에는 크게 느끼지 못할 수 있지만, 비교군이 있다보니 차이가 확연했다. 기존 서비스에선 60ms만에 처리되는 작업이 새로 작업한 서비스에선 1.3s가 소요되었다.

로그를 여기저기 심어봤는데, 결과가 충격적이었다. redis get이 100ms가 소요되었고, db도 비슷한 시간이 소요되었다. upstash가 한국리전이 없어서 vercel, neon, upstash를 싱가포르 리전으로 설정했는데도 응답시간이 오래 걸렸다.

다시 Elastic Beanstalk로

원래 사용하던 EB로 배포를 해봤다. 기존 서비스와 응답속도가 비슷했다.