Web Google Firebase 조직 내 개발자
It’s time to build app with AI!!
서버비용과 방문자수는 비례하는데, AII API를 사용하다보면, 훨씬 더 비용 부담이 증가함 프로젝트를 성공적으로 만들면, AI API 가격에 의한 비용 부담이 급증하므로, 과금때문에 급하게 프로젝트를 내리는 경우가 빈번함.
그래서, 많은 트래픽을 감당하지만 지갑에 부담이 되지 않는 방법은 있을까? (그런 방법은 없겠지만, 최소화하는 방법에 대해 살펴봅시다)
<aside> ⚠️ Client → Server → Gemini(AI)의 구조를 예로 생각 (또한, 파이어베이스 기준으로 설명 : 플랫폼마다 차이가 있을 수 있음)
</aside>
파이어베이스의 철학 : 백엔드 서비스가 필요없다 ****어뷰저가 통신 내용을 보고 악의적인 Request를 할 수 있다 (요청 폭발시키기)
보통 두 가지 솔루션 방식 존재
할당량, 속도 제한, IP 감지, 허용/거부 목록이 포함된 Proxy/API Gateway를 생성하고 유지관리
API 남용을 줄이기 위한 자체 앱 식별 솔루션 제작
Process
Attestation Request
Attestation Provider가 체크
캡챠 같은 것들
Attestation Assessment
Exchange assessment for a token
여기서 받아낸 토큰을 토대로 요청 인증 체크
대시보드를 제공하기 때문에, App Check을 사용하면, 비정상 트래픽을 시각적으로 확인 가능
이건 어찌됐든 Extra Request 과정이므로 성능 자체는 조금 떨어질 지는 모르겠으나, 비싼 API 요청에 대한 과금을 방어하는 데에 매우 유용(놀랍게도 무료니까)
어뷰저를 다 막았어도, 인기가 많아서 실제 유저들이 많으면 결국 사용량 자체가 늘기에 첫 방법만으론 부족하다
이때, **Queue**를 이용
우선 받을 수 있는 트래픽만큼만 요청을 처리
큐를 백엔드 서비스에 도입하려면, 다음 서비스를 활용해보세요
**대량 분산형 테스크**의 실행, 디스패치, 전송을 관리하는 완전 관리형 서비스
클라우드에 있고 분산관리형이라서 우리가 아는 일반적인 큐 구조는 아님(FIFO가 아님). 유한한 용량이 아닌, 유동적인 사이즈 조절 항목들을 영구적으로 저장
사용하는 이유 | 비동기 처리를 위해서
두 서비스(Tasks & Pub)는 비슷해보이나, 기능적으로 다름 아래 예시의 UseCase는 Cloud Tasks가 유용할 겁니다
Google Cloud Tasks
명시적 호출
Google Cloud Pub
암시적 호출
나중에 한 번 살펴보세요
Token Bucket Algorithm
Queue Configuration
<aside>
❗ Client → Server → Gemini(AI)의 구조를 예로 생각해봅시다
이제는, Client → Server → API 방어 → Gemini 가 되었습니다
</aside>
이때, **비동기 API 호출**을 사용해주셔야합니다
비동기 api 호출 아키텍쳐는 다양한 방식이 있습니다 핵심은 중간과정을 두어서 방어하시면 됩니다
@danielylee : 이다니엘