Firebase 과금 체계
Firebase Cloud function 을 이용하려면 Spark 요금제(무료)에서 Blaze(종량제) 요금제로 변경이 필요하다.
Google 에서 주기적으로 실시간 트렌드 키워드를 가져오고, 유튜브 검색을 Batch 작업을 위해서 Firebase Cloud function 이 필요했고, 현재 Blaze 요금제를 사용하고 있다.
현재 간단한 Text 데이터만 저장하기에 거의 요금이 발생하진 않는다. (무료 요금제 pool 내에서 이용중)
이제 유저관련 서비스와 NEIS OpenAPI 를 모두 Firebase cloud function 으로 전환한다.
이제 다음 주 이 버전의 iOS 앱이 출시되면 사용량이 어마어마하게 증가할 듯 한데, 이제 슬슬 사용량, 과금 압박이 오기 시작한다 (사용자가 그만큼 많았으면 좋겠다)
Medium 에서 Firebase 과금 관련 내용들을 찾아보니. 한 큐의 실수로 한화로 수백 수천만원에 이르는 과금을 때려 맞은 사례도 많이 찾아볼 수 있었다.
내용 추가. 2021년 업데이트
Firebase Cloud functions 를 이용해 마이크로 서비스 패턴을 구현해보면서 굉장히 작은 단위로 함수들을 만들었습니다. 각 함수는 Firestore 로부터 데이터를 가져오도록 개발했습니다.
목록을 조회하고, 목록에 포함된 id 를 이용해 전체 정보 목록을 만들고.... 이 과정에서 Entity 하나를 만드는데 Firestore 에 총 3번의 접근이 발생했고, 결국 List 의 Element 가 100 개면 총 300번의 Firestore request 가 추가로 발생했습니다.
MAU 는 3,000 정도로 높지 않았지만 상당한 API Request, 그리고 그 Request 마다 딸려오는 Firestore request... 다행히 예산 알림 설정을 해두어서 경고 알림을 미리 받을 수 있었고.. 폭탄 과금은 피했습니다. 대충 2만원 언저리 과금 되었던 듯.
위 사건으로,,, Medium 에서 봤던 직원 실수로 수천, 수만달러가 과금되었던 썰들이 와닿게 됐네요.
이번 사건으로 API call 최적화와, Firestore 를 사용하는 API 를 설계할 때 어떤 방식으로 요금 최적화를 할 수 있을지 고민해 보는 계기가 되었습니다.
Cloud functions, Firestore 최적화
서비스에서 가장 많이 사용되는 부분(= 과금이 많이 발생할 수 있는 부분) 은 Cloud function 과 Firestore 입니다. 이 부분에서 과금 최적화를 하기 위해 먼저 Firebase 의 과금 체계에 대해서 이해해야 합니다.
FYI) region, functions 의 RAM 등 price 에 영향을 주긴 하지만 main 항목이 아닌 내용들은 다루지 않습니다.
Price 의 메인이 되는 Cloud functions, Firestore 의 request 갯수에만 초점을 맞춥니다.
1건의 Firestore request 로 해결이 가능한 부분을 나눠서 호출하는 부분이 있다면 수정하자
firestore 는 request 를 통해 가져온 데이터의 갯수만큼 과금하지 않습니다. request 갯수로 과금합니다. 즉 내가 필요한 정보를 한번에 가져오는 firestore request 를 만들 수 있다면 그렇게 해야 합니다.
entity 다수개를 가져올 때 id 를 통해 단건 request 를 N건을 요청하지 않고, firestore query 를 통해 조건에 부합하는 데이터를 모두 가져오고 id 를 통해 filter 하여 사용하도록 합니다.