Firebase Summit에서 발표된 모든 내용을 살펴보고 Firebase로 앱을 빠르게 개발하고 안심하고 앱을 실행하는 방법을 알아보세요. 자세히 알아보기

실시간 데이터베이스 청구 이해

컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

Firebase는 OSI 모델의 세션 계층(계층 5)에서 데이터베이스에 저장한 데이터와 모든 아웃바운드 네트워크 트래픽에 대해 요금을 청구합니다. 스토리지는 매일 평가되는 GB/월당 5달러로 청구됩니다. 청구는 데이터베이스 위치에 영향을 받지 않습니다. 아웃바운드 트래픽에는 모든 데이터베이스 작업의 연결 및 암호화 오버헤드와 데이터베이스 읽기를 통해 다운로드된 데이터가 포함됩니다. 데이터베이스 읽기 및 쓰기 모두 청구서에 연결 비용이 발생할 수 있습니다. 보안 규칙에 의해 거부된 작업을 포함하여 데이터베이스를 오가는 모든 트래픽은 청구 가능한 비용으로 이어집니다.

청구 트래픽의 몇 가지 일반적인 예는 다음과 같습니다.

  • 다운로드한 데이터: 클라이언트가 데이터베이스에서 데이터를 가져오면 Firebase는 다운로드한 데이터에 대해 요금을 청구합니다. 일반적으로 이것은 대역폭 비용의 대부분을 차지하지만 청구서의 유일한 요소는 아닙니다.
  • 프로토콜 오버헤드: 세션을 설정하고 유지하려면 서버와 클라이언트 간의 일부 추가 트래픽이 필요합니다. 기본 프로토콜에 따라 이 트래픽에는 Firebase 실시간 데이터베이스의 실시간 프로토콜 오버헤드, WebSocket 오버헤드 및 HTTP 헤더 오버헤드가 포함될 수 있습니다. 연결이 설정될 때마다 SSL 암호화 오버헤드와 결합된 이 오버헤드는 연결 비용에 기여합니다. 이것은 단일 요청에 대해 많은 대역폭이 아니지만 페이로드가 작거나 자주 짧은 연결을 만드는 경우 청구서의 상당한 부분이 될 수 있습니다.
  • SSL 암호화 오버헤드: 보안 연결에 필요한 SSL 암호화 오버헤드와 관련된 비용이 있습니다. 평균적으로 이 비용은 초기 핸드셰이크의 경우 약 3.5KB이고 각 발신 메시지의 TLS 레코드 헤더의 경우 약 10바이트입니다. 대부분의 앱에서 이것은 청구서의 작은 비율입니다. 그러나 특정 사례에 많은 SSL 핸드셰이크가 필요한 경우 이 비율이 커질 수 있습니다. 예를 들어 TLS 세션 티켓 을 지원하지 않는 장치에는 많은 수의 SSL 연결 핸드셰이크가 필요할 수 있습니다.
  • Firebase 콘솔 데이터: 일반적으로 실시간 데이터베이스 비용의 상당 부분은 아니지만 Firebase는 Firebase 콘솔에서 읽고 쓰는 데이터에 대해 요금을 청구합니다.

청구 사용량 추정

현재 실시간 데이터베이스 연결 및 데이터 사용량을 보려면 Firebase 콘솔에서 사용량 탭을 확인하세요. 현재 청구 기간, 지난 30일 또는 지난 24시간 동안의 사용량을 확인할 수 있습니다.

Firebase는 다음 측정항목에 대한 사용 통계를 보여줍니다.

  • 연결: 데이터베이스에 대한 동시, 현재 열려 있는 실시간 연결 수입니다. 여기에는 WebSocket, 긴 폴링 및 HTML 서버 전송 이벤트와 같은 실시간 연결이 포함됩니다. RESTful 요청은 포함되지 않습니다.
  • 저장소: 데이터베이스에 저장되는 데이터의 양입니다. 여기에는 Firebase 호스팅이나 다른 Firebase 제품을 통해 저장된 데이터는 포함되지 않습니다.
  • 다운로드: 프로토콜 및 암호화 오버헤드를 포함하여 데이터베이스에서 다운로드한 모든 바이트.
  • 부하: 이 그래프는 지정된 1분 간격 동안 요청을 처리하면서 사용 중인 데이터베이스의 양을 보여줍니다. 데이터베이스가 100%에 가까워지면 성능 문제가 나타날 수 있습니다.

사용량 최적화

데이터베이스 사용 및 대역폭 비용을 최적화하기 위해 사용할 수 있는 몇 가지 모범 사례가 있습니다.

  • 네이티브 SDK 사용: 가능하면 REST API 대신 앱의 플랫폼에 해당하는 SDK를 사용하세요. SDK는 열린 연결을 유지하여 일반적으로 REST API에 추가되는 SSL 암호화 비용을 줄입니다.
  • 버그 확인: 대역폭 비용이 예기치 않게 높은 경우 앱이 원래 의도한 것보다 더 많은 데이터를 동기화하거나 더 자주 동기화하지 않는지 확인합니다. 문제를 정확히 찾아내려면 프로파일러 도구 를 사용하여 읽기 작업을 측정하고 Android , Objective-C SDK에서 디버그 로깅을 켭니다. 앱의 백그라운드 및 동기화 프로세스를 확인하여 모든 것이 의도한 대로 작동하는지 확인하세요.
  • 연결 줄이기: 가능하면 연결 대역폭을 최적화하십시오. 빈번하고 작은 REST 요청은 기본 SDK를 사용하는 단일 연속 연결보다 비용이 더 많이 들 수 있습니다. REST API를 사용하는 경우 SSL 핸드셰이크 비용을 줄일 수 있는 HTTP 연결 유지 또는 서버 전송 이벤트 사용을 고려하십시오.
  • TLS 세션 티켓 사용: TLS 세션 티켓 발행하여 재개된 연결에서 SSL 암호화 오버헤드 비용을 줄입니다. 이는 데이터베이스에 대한 빈번하고 안전한 연결이 필요한 경우에 특히 유용합니다.
  • 쿼리 인덱싱: 데이터를 인덱싱 하면 쿼리에 사용하는 총 대역폭이 줄어들어 비용 절감과 데이터베이스 성능 향상이라는 두 가지 이점이 있습니다. 프로파일러 도구를 사용하여 데이터베이스에서 인덱싱되지 않은 쿼리를 찾으 십시오.
  • 리스너 최적화: 쿼리를 추가하여 수신 작업이 반환하는 데이터를 제한하고 데이터 업데이트만 다운로드하는 리스너를 사용합니다(예: once() on() ). 또한 동기화하는 데이터의 양을 제한하기 위해 가능한 한 경로 아래에 수신기를 배치합니다.
  • 스토리지 비용 절감: 정기적인 정리 작업을 실행하고 데이터베이스의 중복 데이터를 줄입니다.
  • 규칙 사용: 잠재적으로 비용이 많이 들고 데이터베이스에서 무단 작업을 방지합니다. 예를 들어 Firebase 실시간 데이터베이스 규칙을 사용하면 악의적인 사용자가 전체 데이터베이스를 반복적으로 다운로드하는 시나리오를 피할 수 있습니다. Firebase 실시간 데이터베이스 규칙 사용 에 대해 자세히 알아보세요.

앱에 대한 최상의 최적화 계획은 특정 사용 사례에 따라 다릅니다. 모범 사례의 전체 목록은 아니지만 Slack 채널 또는 Stack Overflow 에서 Firebase 전문가의 조언과 팁을 더 많이 찾을 수 있습니다.