Side Project Journey - 4. cut corners with serverless

사이드 프로젝트 여정 제 4탄의 주제는 AWS 비용을 줄여보자! 이다. Back-end Spring boot 와 Docker 와 ECR 등 정리해야 될 것들이 남아 있지만.. 그동안 너무 글을 쓰는게 귀찮았다. 그러다가 요 몇달동안 AWS 비용이 부담스러워서 비용절감을 하는 과정을 정리한다. 

우선 아래는 그동안 1~3탄의 내용이다.

1탄 : SSO

2탄 : AWS Amplify

3탄 : CORS && SOP with Spring Boot

2021년 3월 AWS 사용 요금이다. 10만 7천원 가량 나왔다.. RDS 는 익히 가격이 비싸다는 것은 알고 있지만, ELB 가 이렇게 비싼줄 몰랐다.

2월 보다 더 나온 이유는 당연히 3월은 31일 까지 있으니.. 2월 보다 가동시간이 많다. 

 

아래는 2021년 2월 요금이다. 2월 부터 1 ~ 말일 까지 풀로 24시간 내내 돌린 비용이다..

아래는 2021년 1월 요금이다. 1월 초중순에 서비스를 출시 했었나?,, 기억이 정확하게 안나지만,, 1월 내내 풀로 가동한것이 아니기 때문에 제일 비용이 낮다.

my.new 서비스의 처음 출시 아키텍쳐 다이어그램이다. 인증 서버와 자원(Resource) 서버를 나누어서 만들었다.

인증서버는 user.my.new 라는 도메인을 사용했고, ALB 와 ACM 을 통해서 SSL 을 적용했다.

자원(Resource) 서버는 app.my.new 라는 도메인으로 그리고 마찬가지로 ALB 와 ACM 을 통해서 SSL 적용했다.

이처럼 ALB 2개, 인증 서버 EC2 t3.micro, 자원 서버 t3.small 을 프로비저닝 했다.

위에 1월, 2월, 3월 요금 내역을 보면 ELB 가 가장 많은 비용이 든다.

ELB 를 사용한 이유는 1가지 뿐이였다. 

바로 CORS 를 위해서 SSL 적용이다. 물론 이 서비스가 진짜 잘되서 EC2 하나로 트래픽을 감당하지 못해서 Auto Scale group 을 사용하기위해서 ELB 를 사용할 수 도 있지만, 그럴 일은 빨리 찾아오지 않을 것 같다.

인증 서버와 자원 서버를 처음에 분리해서 설계한 것은 혹시 모를 기능 확장성을 위해서 분리해서 개발했지만,  너무 멀리 갔다고 느꼈다. 분리를 통해 얻는 이점보다 잃는 단점이 더 컸다. 

제일 처음으로 인증 서버와 자원 서버를 통합하는 작업을 했다. 백엔드의 경우 2 개의 jar artifact 가 아닌 통합된 하나의 jar artifact 로 변경했다. 그리고 프론트엔드에서는 인증과 관련된 api 는 user.my.new 가 아니라 app.my.new 를 하나만 바라보도록 environment 만 간단하게 변경했다.

그리고 그후로 user.my.new 를 완전히 사용하지 않도록 폐기하는 작업을 진행했다.

1차적으로는 아래와 같은 아키텍쳐로 변경했다.

현재 이 글을 작성하는 시점은 2021년 4월 27일이다. 4월은 30일 까지니까 72시간 정도 남았다.

아래의 예상 4월 요금을 보면 63.68 달러로 3월달 94.62 달러보다 30% 정도 절감을 했다.

역시 로드 밸런서는 너무 비싸다. 그래서 로드 밸런서를 완전히 사용하지 않도록 백엔드를 apigateway 와 lambda 로 포팅을 결정했다. 결정에 가장 큰 이유는 역시 LB 가 24시간 떠있는 비용이 너무 비쌌고, 또한 EC2 도 24시간 떠있으면서 비용을 지불하기에는 아깝다고 생각했다.

또한 Lambda 의 경우 Lambda 가 동작한 시간 만큼 비용을 내기 때문에 Serverless 의 장점을 느껴보기 위해서 결정했다.

또한 Lambda function 한 개 단위로 독립적인 배포가 가능하기 때문에 변경에 따른 부수효과를 최소화하고 빠른 시간안에 포팅이 가능했다. 물론 혼자 개발하는거라서 크게 의미는 없지만 ㅋㅋ

기존에 java spring boot 로 만든 어플리케이션을 lambda 로 포팅할 때 우선 제일 먼저 고려했던게 언어의 변경이였다.

aws lambda 의 고질적인 문제는 cold start 인데, cold start 의 단점을 가장 보완해줄 수 있는 언어가 node 와 python 이다. 하지만 개인적으로 타입 동적 언어보다 정적 언어를 선호하기 때문에 node 와 python 보다는 cold start 가 느리지만, java 보다는 빠른 go 를 선택했다.

그리고 api gateway 와 lambda 및 iam 과 sqs 등의 resource 를 프로비저닝 하기 위해서 terraform 을 했다.

최종 아키텍쳐 다이아그램은 아래와 같다.

트래픽이 증가할 수록 lambda container 수도 증가하고 이에 따라서 mysql connection 도 증가하게 되는데, 사실 트래픽이 그만큼 증가할 걱정은 너무 앞서갔다.

트래픽이 증가한다면 RDS proxy 도입을 고려할 수 있을 것이다. 하지만 RDS proxy 비용도.. 쎄기 때문에 ㅎㅎ

아래는  aws lambda 로 전환하고 나서 5월의 비용이다. 18.79 2만원 초반대이다.

10만원을 내던 가격에서 80% 절감했다. : )

aws Cost Management 를 통해서 4개월 반? 동안의 요금 그래프이다.

1월 중순부터 서비스를 돌리기 시작했다. 

다음 계획은 rds 에서 dynamo db 로 전환을 해볼 생각이다.

전환에 성공한다면 거의 공짜로 운영을 할 수 있을것이라고 예상한다. : )

추후에 다이나모 디비 전환에 성공하면 업데이트를 해보겠다.