슬롯

슬롯 (Slots)

BigQuery의 슬롯(slot)은 쿼리나 파이썬 코드 같은 작업을 실행하는 데 쓰는 가상 컴퓨팅 단위예요. 쿼리를 실행할 때 BigQuery가 얼마나 많은 슬롯을 쓸지는 자동으로 정하고, 그 값은 처리하는 데이터량·쿼리 복잡도·가용 슬롯 수에 따라 달라져요. 일반적으로 슬롯이 많을수록 더 많은 쿼리를 동시에 돌릴 수 있고, 복잡한 쿼리도 더 빨리 끝날 수 있어요. 슬롯 수를 수동으로 바꾸는 방법은 없어요.

출처: Understand slots

온디맨드 vs 용량 기반 과금

모든 쿼리가 슬롯을 쓰긴 하지만, 그 사용량을 어떻게 과금할지에 두 가지 모델이 있어요. 온디맨드(on-demand) 모델과 용량 기반(capacity-based) 모델이죠.

기본값은 온디맨드 모델이에요. 이 모델에서는 쿼리가 처리한 데이터량(TiB 단위)만큼 비용을 내요. 온디맨드 프로젝트는 일시적 버스트 능력을 가진 프로젝트·조직 단위 슬롯 한도가 적용돼요. 대부분의 온디맨드 사용자는 슬롯 용량 한도가 충분하다고 느끼지만, 워크로드에 따라 슬롯이 더 많으면 쿼리 성능이 좋아질 수도 있어요.

용량 기반 모델에서는 쿼리 시간에 걸쳐 할당한 슬롯 용량만큼 비용을 내요. 총 슬롯 용량을 명시적으로 조절할 수 있고, 예약(reservation) 을 통해 사용할 슬롯 수를 정해요. 예약의 슬롯 수는 항상 할당되는 기준(baseline) 값으로, 또는 필요할 때만 할당되는 자동 확장(autoscaled) 값으로 지정할 수 있어요. 자동 확장 슬롯이 있는 예약은 워크로드 수요에 맞춰 용량을 확장하죠.

슬롯을 이용한 쿼리 실행

BigQuery가 쿼리 잡을 실행하면 SQL 문을 일련의 쿼리 스테이지(stage) 로 구성된 실행 계획으로 바꿔요. 각 스테이지는 다시 여러 실행 스텝(step) 으로 이뤄져요. BigQuery는 분산 병렬 아키텍처로 쿼리를 실행하는데, 스테이지가 병렬로 실행될 수 있는 작업 단위를 나타내고, 스테이지 사이 데이터는 분산 셔플 아키텍처로 전달돼요.

쿼리 실행은 동적이에요. 쿼리 플랜은 처리 중에 수정될 수 있고, 다른 쿼리가 시작·종료되거나 자동 확장기가 예약에 슬롯을 추가하면 쿼리 실행 용량도 바뀔 수 있어요.

슬롯 리소스 경제

쿼리가 사용 가능한 것보다 더 많은 슬롯을 요청하면, BigQuery는 개별 작업 단위를 큐에 넣고 슬롯이 생길 때까지 기다려요. 쿼리 진행으로 슬롯이 풀리면 큐에 있던 작업 단위를 동적으로 가져와 실행해요.

워크로드 요구가 예약에 가용한 슬롯보다 크면, 잡이 슬롯을 기다리며 실행 시간이 늘어날 수 있어요. 이걸 슬롯 경합(slot contention) 이라고 해요. 워크로드 수요가 예약 가용 슬롯보다 훨씬 크면 경합도 커질 수 있어요.

용량 우선순위

한 지역에서 슬롯 리소스 수요가 높을 때 BigQuery는 용량 우선순위를 적용해 경합을 관리해요. 더 높은 등급의 용량 모델을 쓰는 고객이 영향이 덜 받게 하기 위해서인데, 우선순위는 다음과 같아요.

  1. Enterprise Plus·Enterprise 에디션 기준 및 커밋 용량
  2. Enterprise Plus 자동 확장 용량
  3. Enterprise 에디션 자동 확장 용량
  4. Standard 에디션 및 온디맨드 용량

지역에서 경합이 생기면 Standard 에디션·온디맨드 용량 요청이 접근 지연을 겪을 가능성이 커요. 시스템이 상위 등급 에디션에 리소스를 먼저 배분하거든요.

페어 스케줄링 (Fair Scheduling)

BigQuery는 하나의 예약 안에서 페어 스케줄링이라는 알고리즘으로 슬롯 용량을 할당해요. 스케줄러는 예약 안에서 쿼리를 실행 중인 프로젝트들 사이에, 그리고 한 프로젝트의 잡들 사이에 슬롯을 공평하게 나눠주는 걸 강제해요.

스케줄러는 궁극적 공평성(eventual fairness)을 제공해요. 짧은 시간 동안 어떤 잡이 슬롯을 유난히 많이 가져갈 수도 있지만, 결국 균형을 되찾아요. 목표는 실행 중인 작업을 과격하게 축출해 슬롯 시간을 낭비하는 것과, 너무 관대해 오래 걸리는 작업이 슬롯 시간을 과하게 차지하게 하는 것 사이의 균형을 찾는 거예요.

새 쿼리가 제출될 때, 쿼리가 완료될 때, 쿼리 용량 수요가 바뀔 때마다 BigQuery는 슬롯을 자동으로 재배분해요. 항상 모든 활성 쿼리가 가용 슬롯 전부를 쓸 수 있는 상태를 유지하는 거죠.

예를 들어 기준 1,000 슬롯(자동 확장 없음)인 예약 A에 프로젝트 A와 B가 배정돼 있다고 해볼게요. 프로젝트 A에서 슬롯을 많이 쓰는 쿼리 하나를, 프로젝트 B에서는 동시 쿼리 20개를 돌리면, 프로젝트 A는 500 슬롯을 받아 쿼리가 500 슬롯으로 실행되고, 프로젝트 B는 그 20개 쿼리가 나눠 쓰는 500 슬롯을 받아요.

중요한 잡이 스케줄러가 주는 것보다 꾸준히 더 많은 슬롯을 필요로 한다면, 필요한 슬롯 수의 별도 예약을 만들고 그 잡을 배정하는 걸 고려해 보세요.

슬롯 할당량과 한도

슬롯 할당량·한도는 BigQuery의 안전장치예요. 과금 모델마다 쓰는 할당량 유형이 달라요.

  • 온디맨드 모델: 일시적 버스트 능력을 가진 프로젝트·조직 단위 슬롯 한도가 적용돼요.
  • 용량 기반 모델: 예약 할당량·한도가 한 위치의 모든 예약에 걸쳐 할당할 수 있는 최대 슬롯 수를 정의해요. 자동 확장을 쓰면 예약 최대 크기의 합이 이 한도를 넘을 수 없어요. 과금은 할당량이 아니라 예약·커밋 기준으로만 돼요.

유휴 슬롯

특정 시점에 일부 슬롯은 유휴 상태일 수 있어요. 예를 들어 어떤 예약 기준에도 할당되지 않은 슬롯 커밋, 또는 예약 기준에 할당됐지만 사용되지 않는 슬롯이 있죠. 온디맨드 모델에서는 유휴 슬롯 개념이 적용되지 않아요.

자동 확장 (Autoscaling)

자동 확장 기능으로 작업이 요구하는 최대·최소 슬롯 범위를 설정할 수 있어요. 자동 확장 슬롯은 완료된 쿼리·처리된 데이터 등 과거 사용량을 참고해 필요할 때만 할당되고, 필요 없어지면 해제돼요. 몇 가지 유의점이 있어요.

  • 슬롯 사용량이 기준+확장 슬롯 합을 넘는 경우는 가끔 발생하며, 그 초과분은 과금되지 않아요.
  • 자동 확장기는 동시 쿼리가 여러 개인 무겁고 오래 걸리는 워크로드에 가장 효과적이에요. 쿼리를 하나씩 보내지 마세요 — 쿼리마다 예약이 최소 1분 동안 확장 상태로 남거든요.
  • BigQuery 자동 확장은 용량 가용성의 영향을 받아요. 용량을 보장받으려면 기준 슬롯 수를 설정하세요. 기준 슬롯은 즉시 사용 가능하고, 쓰든 안 쓰든 비용이 들어요.
  • 기준 슬롯은 항상 과금돼요. 용량 커밋이 만료되면 원치 않는 비용을 피하려고 예약의 기준 슬롯 수를 수동 조정해야 할 수 있어요.

초과 슬롯 사용

잡이 슬롯을 너무 오래 붙들면 슬롯의 부당한 몫을 가져갈 수 있어요. 지연을 막기 위해 BigQuery는 다른 잡이 추가 슬롯을 빌려 쓰게 해서, 총 슬롯 사용량이 지정 용량을 잠시 넘는 일이 생겨요. 초과 슬롯 사용량은 공정한 몫보다 더 받은 잡에게만 귀속돼요.

이 추가 슬롯은 직접 과금되지 않아요. 잡은 공정한 몫의 슬롯 사용량이 지정 용량으로 모두 덮일 때까지 계속 돌면서 사용량을 쌓아요. 초과 슬롯은 세부 실행 통계 같은 특정 경우를 제외하면 보고된 슬롯 사용량에서 제외돼요.

더 알아보기