최적화 필요성
차이부스터 서비스 출시 직후 별도의 홍보를 하지 않다보니 매우 낮은 수준의 MAU를 유지하고 있었고, Firebase Cloud function이나 Firestore 사용량은 무료 플랜 수준으로 사용하고 있었습니다.
화력이 좋았는지 MAU가 100명 정도였던 수준의 서비스가,,,, 하루 다운로드수가 150을 찍어버리는 기록을 세워버리고 말았습니다.
몇분 뒤 이 기쁨은 초조함으로 바뀌었습니다.
예산 경고 알림이 오더니,, 순식간에 유료 플랜으로 전환되고 과금이 시작됐습니다.
Firestore의 사용 가격은
•
1일 5만 document read 무료, 이후 문서 100,000개당 $0.036 으로 그리 비싼 비용은 아니지만 최적화 하지 않는 경우 과금 폭탄이 될 수 있습니다.
사용자가 몰린 그 날, 단 3시간만에 읽기 횟수는 100만회가 넘었습니다. 한화 약 360원. 당장은 360원이지만 빠르게 계산했습니다. 이게 한달이 되면 얼마의 비용이 나오는지.
•
1달 ⇒ 30일 ⇒ 1일 * 30 ⇒ 24시간 * 30 ⇒ 3시간 * 8 * 30 ⇒ 360원 * 8 * 30 ⇒ 86,400원
한달에 8만원, 감당할 수 있지만 광고 하나 없이 무료로 서비스 하고 있는 앱에서 8만원은 조금.. 아픕니다.
최적화 할 수 있는 부분
Firestore의 과금 대상은 read, write, delete 3가지로 구분되어 있습니다. 주로 read 횟수가 많아 과금은 read 에서 발생하기 쉽습니다. 과금 최적화를 위해서 read 를 중점적으로 보는게 좋습니다.
개인화 데이터 vs 비 개인화 데이터
차이부스터 서비스에서 과금을 줄인 방법은 '비 개인화 데이터'를 캐싱하는 방법입니다.
'비 개인화 데이터는' 유저A, 유저B, ... 유저Z 서비스를 사용하든 모든 유저에게 동일하게 보이는 데이터를 의미합니다. 차이부스터 서비스를 예로 들면 "오늘의 혜택" 입니다. 누구에게나 동일한 혜택을 제공하기 때문에 user id 를 이용해 개인의 데이터를 조회할 필요가 없죠.
그러면 이 부분을 캐싱하여 document 조회를 줄일 수 있습니다.
메모리에 "오늘의 혜택" 이 있는지, 있다면 바로 return, 없다면 firestore 에서 조회
물론!!! 이 코드는 REST API가 가져야 할 stateless 특성에 위배되는 코드입니다.
하지만 안정적인 서비스, 더 높은 사용성, 품질을 챙길 수 있는 부분을 REST의 특성을 어긴다고 해결하지 않는 것은 더 용납할 수 없습니다.
결과
사용자 수도 조금 줄긴 했지만, Firestore의 Read 카운트는 80%가 감소한 수준이 되었습니다. 
Firebase의 공식문서를 보면, 전역변수를 사용하는 방법, Cold Start 에서 응답을 빠르게 하는 방법 등 추가적인 방법들이 있으니 이 부분들도 한번 읽어보세요.