들어가며
본 <BigQuery 가격 체계를 알아보자> 포스팅은 BigQuery 가격 체계 공부한 것을 정리하는 목적으로 작성한 것입니다. 공식 문서를 바탕으로 정리하였으나, 틀린 부분이 있을 수 있으므로 정확한 최신 정보는 공식 문서를 확인 부탁드립니다 🙂
BigQuery 가격 체계를 알아보자 1편 – 가격 체계
BigQuery 가격 체계를 알아보자 2편 – 비용 최적화하는 법 (예정)
BigQuery 가격 체계 요약
BigQuery의 가격 체계는 크게 다음과 같이 분류할 수 있습니다.
Storage : 데이터를 저장하는 비용
Query processing : 쿼리를 처리하는 비용
BigQuery 가격 체계 세부설명
1. Storage 가격 – 링크
Storage 가격은 BigQuery에 로드한 데이터를 저장하는 데 드는 비용입니다. 크게 Active storage, Long-term storage으로 나누어집니다.
Storage 가격 체계 세부정보 – 링크
스토리지 가격은 압축되지 않은 상태에서 테이블에 저장된 데이터의 양을 기준으로 책정됩니다.
- 스토리지 사용량 단위 : 스토리지 사용량은 GiB로 계산됩니다.(1TB는 1024GB입니다.)
- 스토리지 요금 단위 : 스토리지 요금은 초 단위로 계산됩니다.
Streaming inserts : 스트리밍 삽입에 성공한 행의 요금만 청구됩니다. 각 행은 최소 1KB로 계산되며, 가격 책정은 서울 리전 기준으로 20MB당 $0.012입니다.(리전 별 스트리밍 삽입의 가격은 여기서 확인하세요.)
Active storage
Active storage는 지난 90일 동안 수정된 모든 테이블 또는 파티션을 포함합니다.
10GB 이후 Active storage의 가격 책정은 서울 리전 기준으로 1GB당 $0.023입니다.
리전 별 Active storage의 가격은 여기서 확인하세요.
Active storage의 테이블을 연속으로 90일 동안 수정하지 않으면 Long-term storage 요금이 청구됩니다.
Active storage와 Long-term storage 모두 성능, 내구성, 가용성은 동일합니다.
Long-term storage
Long-term storage는 연속으로 90일 동안 수정되지 않은 모든 테이블 또는 파티션을 포함합니다.(테이블이 결제 주기 중간에 90일에 도달하면 그에 비례해서 요금이 계산됩니다.)
10GB 이후 Long-term storage의 가격 책정은 서울 리전 기준으로 1GB당 $0.016입니다.
리전 별 Long-term storage의 가격은 여기서 확인하세요.
파티션 단위로 Long-term storage 가격이 적용됩니다. 동일 테이블이라 하더라도 테이블 내 파티션 별로 가격이 다르게 적용될 수 있습니다. 파티션 중 하나가 90일 동안 수정되지 않을 경우, 해당 파티션의 데이터가 Long-term storage로 간주되어 할인 가격이 적용됩니다.
다음 작업과 같이 Long-term storage의 테이블을 수정하면 Active storage 요금으로 돌아가며, GCP의 타이머가 다시 0일부터 90일까지 세기 시작합니다.
- 테이블에 데이터 로드
- 테이블에 데이터 복사
- 테이블에 쿼리 결과 쓰기
- 데이터 조작 언어(DML) 사용
- 데이터 정의 언어(DDL) 사용
- 테이블에 데이터 스트리밍
2. Query processing 가격 – 링크
Query processing 가격은 SQL 쿼리, 사용자 정의 함수, 스크립트, DML(데이터 조작 언어), DDL(데이터 정의 언어)문을 포함한 쿼리를 처리할 때 발생하는 비용입니다.
사진 출처 : Workload management using Reservations
On-demand(주문형)
On-demand 가격 모델을 사용하면 각 쿼리에서 처리된 byte 수에 대한 요금이 부과됩니다.
매월 처리되는 쿼리 데이터 중 처음 1TB는 무료입니다.
On-demand 모델은 효율적이라는 장점이 있습니다.
Query processing 비용은 기본적으로 On-demand 가격 모델을 사용합니다.
On-demand 가격 모델은 데이터 소스가 BigQuery든 Storage든, Googel Drive든 관계없이 처리된 byte수에 대한 요금만 청구됩니다. 가능하면 항상 파티션을 나누거나 클러스터링을 하는 것이 On-demand 비용 절감에 좋습니다.
Flat-rate(정액제)
Flat-rate 모델은 비용을 예측할 수 있다는 장점이 있습니다.
Flat-rate 가격 모델에서는 가상 CPU인 슬롯을 구매합니다.
슬롯을 구매하면 쿼리를 실행하는 데 사용할 수 있는 전용 처리 용량을 구매하는 것입니다. 슬롯은 다음 약정 요금제에서 사용할 수 있습니다.
- Flex Slot
- 처음 60초 동안 약정
- 약정이 배포된 시간 동안만
- 몇초, 몇분, 몇시간, 몇일 사용할 때 권장
- Monthly Commitment
- 처음 30일 동안 약정
- Yearly Commitments
- 365일 동안 약정
- 워크로드가 지속적일 때 가장 비용 효율적인 선택지
특히, Flex Slot은 다음과 같이 몇분에서 며칠동안 단기 사용하는 사례에서 적합합니다.
- 주요 일정 : 세금 신고 기간, 블랙 프라이데이, 인기 미디어 이벤트, 비디오 게임 출시
- 주기적인 처리 : 매주 월요일 아침과 같이 분석 수요가 많은 날
참고 : Reservations details and limitations
❗️Query processing 가격에 대해서 알아둘 것
1. 쿼리를 처리하는 비용은 기본적으로 On-demand 입니다.
2. On-demand 로 설정된 프로젝트는 Flat-Rate인 프로젝트의 약정 용량과 별개의 용량을 사용합니다. 또한, On-demand 인 프로젝트는 약정 용량의 가용성에 영향을 미치지 않습니다.
3. 리전 별로 Flat / On-demand 구분해서 설정할 수 있습니다.
- 한 리전에서는 Flat-rate를, 다른 리전에서는 On-demand를 사용할 수 있습니다.
- US멀티리전에 Flat-rate를 설정하고 조직을 기본 예약에 할당하면, 조직은 US멀티리전에만 Flat-rate를 사용할 수 있습니다. 이 경우, 다른 리전에서는 On-demand를 사용하게 됩니다.
4. Hierarchy 구조를 따르되, 하위 프로젝트에서 설정을 따로 할 수 있습니다.
- 조직이나 폴더는 Flat-rate로 선택했지만 일부 하위 프로젝트에 On-demand를 사용하는 경우, 해당 프로젝트에 예약 ID ‘none’을 할당하면 해당 프로젝트에만 On-demand를 사용하도록 설정할 수 있습니다.
- 예약 ID를 할당되지 않은 모든 프로젝트는 On-demand로 유지됩니다.
참고 링크
- BigQuery 제품 페이지
- GCP 공식 문서 > BigQuery 가격 정책
- GCP 공식 블로그 > BigQuery의 비용 최적화 권장 사항
- GCP 문서 > BigQuery 비용 관리