🖊️

Vercel Serverless function(Lambda) 비용 줄이기

개요

rebitly 는 bitly 처럼 링크 쇼트너이자, 사용자가 원하는 트래킹 서비스(pixel 등)를 이용할 수 있게 해주는 서비스다. 현재 rebitly 서비스는 Vercel 을 이용해서 서비스 중이다. 그런데 어느 순간부터 vercel 에서 $1,000 가 넘는 billing 이 나왔다. 기존에는 Team seat 으로 팀원 당 $20 로 $80 만 나왔는데 갑자기 Billing 이 높게 나왔다. 더불어서 AWS 에서 사용하는 리소스(Dynamo) 비용도 갑자기 불어났다.

원인

갑자기 늘어난 트래픽

21년 12월을 기점으로 갑자기 폭발적으로 늘어난 rebit.ly 링크 유입. 알고 보니 특정 업체가 마케팅을 엄청 하면서 rebitly short link 를 사용하면서 트래픽이 엄청 늘어난 것이다. 한 업체가 거의 하루에 몇 십만 단위의 트래픽을 몰고오니 트래픽이 폭증할 수 밖에 없었다.

vercel 을 확인해보니 비용이 추가된 부분은 Serverless function execution 부분이었다.

먼저 Serverless execution 이 왜 이렇게 많이 나온 것을 이해하기 위해서는 rebitly 서비스의 구조를 알아야한다.

rebitly 개선 전 서비스 구조

위에서 보다시피 Vercel 의 Serverless function 을 사용하는 부분은 두 가지가 있다. 처음의 요청을 통해서 이 유저가 요청한 주소의 original link 를 AWS dynamo db 에서 가져와서 original link 를 포함한 empty page 를 사용자에게 반환한다. (getServersideProps 함수가 serverless function) 이 empty page는 브랜드가 저장한 pixel 을 실행한 후 각종 데이터를 저장하도록 또 다른 serverless function에 request 를 한다. 그 후 original link 로 redirect 된다.

위의 플로우가 몇십만, 백만 단위로 실행이 되니 Execution 이 높게 나올 수 밖에 없었던 것이다.

그리고 AWS 의 경우 log 량이 폭증하면서 dynamo 의 저장 비용이 늘어났다.

어떻게 해결할 수 있을까? 해결!

vercel

cache 정책 사용

vercel 에서는 Edge 라는 CDN 캐시가 존재한다. 이 캐시를 사용하는 경우 serverless execution 에 포함이 되지 않는다. 때문에 serverless 에 요청해서 empty page 를 반환하는 로직에서 cache 를 사용하면 execution 이 많이 줄 것이다.

사실 이전에는 cache 가 있었는데 Facebook pixel 효율을 높이기 위해서 empty page 에 IP 정보를 전달하기 위해서 cache 를 제거했었다. 캐시를 다시 넣기 위해서 facebook pixel 은 conversion api 를 사용함으로써 pixel 효율 문제를 해결했다. (save log 부분에서 conversion api 실행)

rebitly 개선 후 서비스 구조

execution lambda memory 용량 변경

Vercel 에서는 실행되는 Serverless function 의 실행환경 메모리 세팅에 따라서 execution 의 계산 결과가 달라진다. (vercel execution 참고) 기본적으로 1G 메모리로 세팅이 된다. 그러나 log를 저장하는 함수는 그렇게 많은 메모리를 필요로 하지 않았다. vercel 에서 function 을 모니터링 하면서 지켜본 결과 일반적으로 100 ~ 120 MB 를 사용을 했다. 때문에 메모리 설정을 256MB 로 설정하기로 했다. (128MB 도 설정 가능하지만 여유를 두도록 설정하고 싶었다.)

// vercel.json
{
	...
	"functions": {
		"pages/api/logPageView.ts": {
			"memory": 256
		}
	}
}
JavaScript
복사

위 두 가지를 실행해서 2/17 배포 후 결과를 보았다.

17일을 전후로 캐시 사용량, 그리고 execution 량이 현저히 변화한 모습을 볼 수 있다.

효과가 있다!!!

AWS

AWS 의 경우 저장비용이 문제였기 때문에 단순하게 저장하는 로그의 크기를 줄이면 되는 문제였다. JSON 형태의 로그를 base64(byte) 형태의 배열로 변환하고 저장을 하도록 했다.