사이드프로젝트 아키텍트와 비용 최적화

취미로 티모지지(TMO.GG)라는 사이드프로젝트를 운영하고 있다.

TMO.GG - 게임 퀘스트, 미션, 배틀 보상

 

 

MAU는 지금은 조금 떨어져서 3.5만 정도 수준이지만, 서비스가 잘될 때에는 MAU 4~5만+, DAU는 8천+, QPS는 500~2500까지 왔다갔다 했었다.

애드센스 광고로 MRR이 높은 수준으로 유지되고 있는 상황이었지만 현재 서비스만으로 유저의 캡은 정해져있었기 때문에 비용 최적화를 해서 이익을 늘려야 하는 상황이 되었다.

 

이 글에서는 아키텍처가 어떻게 구성되었고, 서버비 최적화를 위해 서비스 아키텍처가 어떻게 변화해 왔는지 소개해 보고자 한다.

"이렇게까지 한다고?" 라는 생각이 들만한 재미있는 내용만 추려서 적어보려고 한다.

 

 

1. 두 개의 CDN을 사용하다

 

초기에는 Cloudflare만 사용했었으나 Cloudflare와 Origin 사이에 AWS CloudFront를 추가로 사용하게 되었다.

CDN을 두 개를 사용하기 때문에 꽤나 기형적이게 보일 수도 있겠으나, 여기에는 사정이 있다.

우선, Cloudflare는 Flooding 방어 용도로 꼭 이용을 해야 하는 사정이 있었다.

(참고: https://changmyeong.tistory.com/77)

 

서버비 Metric을 관찰하다 보니 AWS Origin(API Gateway)의 Data Transfer-out 비용이 꽤 크게 과금되고 있는걸 확인했다.

 

Data Transfer-out 비용은 CloudFront를 연동하면 꽤 크게 절감할 수 있다.

CDN을 2개를 사용해야 한다는 점에서 기형적인 구조가 되므로 꺼렸으나, 비용이 저렴해지는데 하지 않을 이유는 없기 때문에 적용하였고, 결과적으로 큰 이득을 보았다.

 

2. NAT Gateway 제거

티모지지는 AWS Origin으로 서버리스인 Lambda를 사용한다.

(현재 티모지지는 검색엔진을 제외하고 DB를 포함한 전체 컴포넌트가 서버리스로 구성되어 있다. 온프레미스라면 모를까 클라우드를 사용한다면 서버리스를 사용한다고 꼭 더 비싸지만은 않다. 오히려 더 싼 경우도 많은데 티모지지는 서버리스라서 더 싸게 유지하고 있다)

 

AWS Lambda는 Public Subnet에 배포하더라도 Public IP 할당이 되지 않기 때문에 다른 AWS 컴포넌트 및 인터넷과 통신이 불가능하다. (AWS 시스템에 의한 인바운드 호출 제외)

보안상 검색엔진 등과 같은 다른 컴포넌트를 Private Subnet에 두고 싶었고, Lambda도 이 컴포넌트들과 통신이 필요했기 때문에 VPC 설정이 필요했다.

 

VPC를 설정하면 앞서 이야기 했던 것처럼 인터넷 통신을 위해 NAT Gateway를 달아야 한다.

 

그런데 티모지지에서는 인터넷 통신을 해야 하는 포인트가 대단히 제한적이다.

예를 들면, 유저가 소셜 로그인을 할 때 검증을 위해 소셜 API를 호출하는 경우가 있다. 그런데 유저가 로그인을 하는 시나리오는 서비스 진입 후 최초 1번밖에 없고, 그 뒤 로그인은 유지되어 있을 것이다.

 

NAT Gateway는 유지비용이 크다. 이런 제한적인 시나리오들로 인해 NAT를 사용하는 것은 대단히 큰 낭비라고 생각했다.

 

우선 NAT Gateway를 사용하다가 어떻게 할까 잔머리를 계속 굴려봤고 결과적으로 아래와 같은 아키텍처를 적용했다.

 

 

Serverless에서 path로 분기하여 일반적인 상황에서는 Server로, 외부 통신이 필요한 상황에서는 External Server로 라우팅을 시켰다.

External Server는 VPC 설정을 제거하여 외부 통신이 가능하다.

결과적으로 보안 정책의 Best Practice도 유지하며, 인터넷 통신도 저렴한 비용으로 가능한 구조가 되었다.

 

물론, 이 구조면 External Server Lambda에서 검색엔진 등과 같은 내부 컴포넌트와 통신이 불가하다는 제약이 있다.

하지만 우리는 비즈니스 로직 시나리오상 인터넷과 내부 컴포넌트를 동시에 사용할 일이 없어서 문제가 없었다. (있었더라도 어떻게든 분리는 했을 것이다.)

 

 

3. CORS Preflight 호출 제거

사실 좀 뻔한 내용이라 넣을까말까 하다가 넣었다.

트래픽이 올라가면 슬슬 API 호출 횟수도 부담이 되고 비용으로서 생각해야 할 포인트가 된다.

 

페이지에서 보여주는 내용을 summary해서 API 호출 횟수를 줄이는 액션도 해야겠지만, 브라우저에서 Preflight 호출을 하는 횟수도 무시하지 못한다.

간단하게 Next.js의 Rewrites 기능을 활용하여 API와 브라우저에서 접속한 Origin을 통일화 시켰다.

 

 

4. 기타

나머지는 위보다 더 뻔한 내용들이다.

1) UX에 방해되지 않도록 곳곳에 캐시를 박아넣어서 DB Hit rate를 줄이고,

2) 트래픽이 어느정도 예상할 수 있는 범주에 들어왔기에 Reserved Instance를 구입하였고,

3) Windows Client에서 유저의 게임 기록을 캡처하여 저장을 하기도 하는데 압축해서 저장하기도 한다.

 

더 있겠지만 두서 없이 쓰느라 기억은 안 나는데, 결과적으로 비용을 원하는 수준까지 낮추었다.

 

올해의 목표는 1) 다른 게임들 온보딩  2) MAU 10만+ 달성  3) PC 게임 액션 트래킹 및 리워드 서비스 구축이다.

서비스가 한 단계 더 성장을 하며, 또다시 서버 비용을 최적화 하게 되는 날이 왔으면 좋겠다.