안정성: 데이터 쿼리

이 문서에서는 BigQuery를 사용하여 안정적인 솔루션을 구축하는 방법과 BigQuery 환경 내에서 데이터를 안정적으로 쿼리하는 방법을 설명합니다.

슬롯 이해

BigQuery는 쿼리 작업 실행 시 제출된 선언적 SQL 문을 실행 그래프로 변환하고 일련의 쿼리 스테이지로 세분화합니다. 각 쿼리 스테이지는 더 세분화된 실행 단계 집합으로 구성됩니다. BigQuery는 크게 분산된 병렬 아키텍처를 사용하여 이러한 쿼리를 실행하며, 스테이지는 많은 잠재적 작업자들이 동시에 실행할 수 있는 작업 단위를 모델링합니다. 이러한 작업자의 리소스를 슬롯이라고 합니다.

간단히 말해 BigQuery 슬롯은 BigQuery가 SQL 쿼리를 실행하는 데 사용하는 가상 CPU입니다. 슬롯 및 슬롯 작동 방식에 대한 자세한 내용은 슬롯 이해를 참조하세요.

BigQuery는 두 개의 개별 영역에 중복 슬롯 용량을 제공하여 쿼리에 대해 99.99% SLA를 달성할 수 있습니다. 이러한 분산은 영역 장애로부터 고객을 보호합니다.

쿼리를 실행하는 데 사용되는 컴퓨팅 리소스는 주문형 또는 정액제 가격 책정 모델로 구매됩니다. 주문형 모델의 경우 컴퓨팅 리소스는 제출된 쿼리로 처리된 바이트 수에 따라 요금이 청구됩니다. 정액제 모델에서는 안정적인 비용 모델을 제공하는 전용 쿼리 처리 용량을 구입합니다.

주문형 분석 모델

BigQuery의 주문형 가격 책정 모델을 사용하면 제출한 쿼리에서 처리된 바이트 수('읽은 바이트'라고도 함)에 따라 사용량에 대해서만 요금이 청구됩니다. BigQuery 주문형 가격 책정 모델을 사용하는 프로젝트는 기본 슬롯 용량에 액세스할 수 있습니다. 이 용량은 일반적으로 충분하고도 남으며 프로젝트당 슬롯 할당량이 적용됩니다.

정액제 슬롯 모델

주문형 가격 모델보다 고정적인 쿼리 요금을 선호하는 고객은 정액제 가격 책정 모델을 사용하는 것이 좋습니다. 정액제에 등록하면 BigQuery 슬롯으로 측정되는 전용 쿼리 처리 용량을 구매하게 됩니다. 쿼리가 이 용량을 소비하며 처리한 바이트에 대해서는 요금이 청구되지 않습니다.

정액제 구조를 사용하면 고객은 원하는 길이의 약정 기간(연간, 월간 또는 약정 없음)으로 슬롯을 구매하고, 슬롯 예약이 있는 지정된 프로젝트 또는 폴더에 대해 슬롯 우선순위를 정하고, 유휴 슬롯을 여러 예약에 공유할 수 있습니다. 자세한 내용은 예약 소개를 참조하세요.

정액제 모델은 폴더 또는 프로젝트에서 사용할 수 있는 최대 슬롯 리소스 수를 명시적으로 설정합니다. 따라서 너무 적은 슬롯을 구매하면 쿼리 성능에 영향을 미칠 수 있지만 너무 많은 슬롯을 구매하면 유휴 처리 용량을 발생시켜 리소스가 활용되지 않으며 불필요한 비용이 발생합니다.

정액제 슬롯 모델의 고려사항

주문형 모델과 정액제 모델 선택에 영향을 주는 가장 큰 요인은 비용 고려사항이지만, 이 결정은 신뢰성에 영향을 미칠 수도 있습니다. 예를 들어 최대 부하 상태 중에 프로젝트당 사용 가능한 슬롯 2,000개를 기본적으로 제공하는 주문형 가격 책정 모델과 수십만 개의 슬롯까지 구성될 수 있는 정액제 모델 간에는 확장성이 다를 수 있습니다. 프로젝트에서 소비하는 슬롯 수는 쿼리 복잡성, 스캔되는 데이터 양, 사용자 정의 함수(UDF)와 같은 특수 함수 사용, 제출된 동시 쿼리 수에 따라 달라집니다. 그러나 주문형 고객에게 제공되는 2,000개 슬롯은 일반적으로 BigQuery를 시작하는 사용자에게 충분하고도 남습니다. BigQuery 주문형 모델과 정액제 모델 중에서 선택하는 방법에 대한 자세한 내용은 BigQuery 주문형 및 정액제 가격 책정 모델 선택을 참조하세요.

BigQuery의 99.99% 가용성 SLA는 주문형 모델과 정액제 모델 모두에 적용되지만 주문형 모델은 공유 슬롯 리소스의 풀을 사용하므로 정액제 모델에서만 슬롯 리소스 수가 보장됩니다. BigQuery는 예약된 슬롯을 구매하고 프로비저닝할 때까지 가용성에 대한 보장을 제공하지 않습니다. 따라서 비즈니스에 중요한 워크로드에 예약된 슬롯을 적시로 획득하는 것에 의존하지 않는 것이 좋습니다. 슬롯 요청이 클수록 슬롯 리소스를 프로비저닝하는 데 리드 타임이 필요할 가능성이 높아집니다.

필요에 따라 조직 또는 프로젝트 내에서 주문형 모델과 정액제 모델을 모두 결합할 수 있습니다. 이는 BigQuery의 BigQuery 예약 개념을 통해 가능합니다. 예를 들어 프로덕션 미국 멀티 리전 데이터 세트에 정액제 예약을 사용하고 대체 리전을 기반으로 하는 더 작은 개발 데이터 세트에 주문형 용량을 사용할 수 있습니다.

예약

BigQuery 예약을 사용하면 조직 전체에서 슬롯 용량 할당을 맞춤설정할 수 있으며 이를 통해 워크로드에 따라 리소스의 우선순위를 지정할 수 있습니다. 예를 들어 프로덕션 워크로드용으로 prod라는 이름의 예약을 만들고 테스트용으로 test라는 별도의 예약을 만들 수 있습니다. 이렇게 하면 프로덕션 워크로드에 필요한 리소스를 테스트 작업이 경합하지 않을 것입니다. 예약은 할당된 프로젝트, 폴더 또는 조직에 슬롯 리소스의 우선순위를 지정합니다. 리소스 계층의 각 수준은 재정의되지 않는 한 상위 수준에서 할당을 상속합니다. 즉, 프로젝트는 상위 폴더의 할당을 상속하고 폴더는 해당 조직의 할당을 상속합니다.

BigQuery 예약은 기본적으로 다른 예약 간에 유휴 슬롯 리소스도 공유하여 리소스 사용률을 최적화합니다. 따라서 프로덕션 예약이 완전히 활용되지 않을 수 있는 동안 개발/테스트 환경과 같이 우선순위가 낮은 워크로드의 쿼리 성능이 향상됩니다. 개발/테스트 워크로드가 프로덕션 예약에서 미사용 슬롯을 사용하고 이제 프로덕션 예약이 완전히 활용되는 경우 BigQuery 슬롯 스케줄러는 진행 중인 개발/테스트 쿼리에서 슬롯 리소스를 지능적으로 가져와 프로덕션 예약에 사용할 수 있도록 합니다. 개발/테스트 쿼리는 계속 실행되지만, 사용할 컴퓨팅 리소스가 적기 때문에 천천히 실행됩니다.

분석 요구사항의 특성에 따라 비즈니스 단위, 함수(프로덕션과 개발/테스트 비교) 또는 애플리케이션 유형(비즈니스 인텔리전스 대시보드, 예약된 쿼리/작업, 사용자의 임시 쿼리 비교)을 기준으로 워크로드를 분리하여 환경 내에서 여러 BigQuery 예약을 생성하는 것이 합리적인 경우가 많습니다.

유휴 슬롯은 단일 BigQuery 관리 프로젝트 내에서 생성된 예약 내에서만 공유됩니다.

예약 크기 조정

예약의 크기를 정확하게 조정하는 작업은 일반적으로 BigQuery 관리자 리소스 차트 또는Cloud Monitoring 대시보드를 통해 현재 및 이전 BigQuery 슬롯 사용량을 모니터링하는 것이 가장 좋습니다. 관리자 리소스 차트는 조직, 폴더, 프로젝트, 예약, 사용자, 작업 수준에서 슬롯 사용량, 작업 동시 실행, 작업 성능에 대한 세부정보와 함께 실시간 및 14일 이전의 이전 데이터를 제공합니다.

작업 안정성 최적화

데이터 분석을 위해 두 가지 유형의 쿼리를 제출할 수 있습니다.

  • 대화형 쿼리: 제출된 대화형 쿼리가 실행을 위해 즉시 전달됩니다.
  • 일괄 쿼리: 제출된 일괄 쿼리는 사용할 수 있는 슬롯 리소스가 충분할 때 즉시 큐에 추가되고 시작됩니다. 24시간 내에 쿼리를 시작하지 못한 경우 BigQuery는 작업 우선순위를 대화형으로 변경하고 즉시 쿼리를 전달합니다.

대화형 및 일괄 쿼리 모두 동일한 슬롯 리소스를 사용합니다. 실제로 일괄 쿼리가 BigQuery 스케줄러에 의해 시작된 후에는 대화형 쿼리와 일괄 쿼리 간의 우선순위에 차이가 없습니다. 그러나 대화형 쿼리와 일괄 쿼리는 쿼리 한도 및 할당량에 다르게 영향을 미칩니다. 대화형 쿼리는 동시 쿼리 비율 한도에 포함되지만 일괄 쿼리는 포함되지 않습니다.

동시 쿼리 한도에 도달하면 추가 대화형 쿼리가 실패하고 quotaExceeded 오류가 발생합니다. 이 할당량은 사용자의 보호를 위해 적용됩니다. 따라서 사용 가능한 슬롯이 완전히 소비되지 않는 한 일반적으로 고객 관리 또는 영업에 문의하여 할당량을 늘릴 수 있습니다. 그러나 동시에 실행되는 쿼리 수가 많으면 각 쿼리의 컴퓨팅 리소스 전체 가용성이 감소하므로 리소스 경합이 발생하여 쿼리당 처리 처리량이 저하될 수 있습니다. 따라서 동시 쿼리 할당량을 슬롯 리소스 포화점 이상으로 늘려서는 안 됩니다. 동시 쿼리 오류가 발생하면 지수 백오프 로직으로 쿼리를 재시도하여 쿼리 작업 지연 시간에 부정적인 영향을 미치지 않도록 할 수 있습니다.

사용자 환경에서 동시 쿼리 수를 줄일 수 있는 옵션은 다음과 같습니다.

  • 읽은 바이트 수를 추정하지만 실제로 쿼리를 처리하지 않는 테스트 실행 모드에서 쿼리를 실행합니다.
  • 쿼리 자체를 실행하는 대신 데이터를 실험하거나 탐색할 때 BigQuery의 테이블 미리보기 기능을 사용하여 테이블 데이터를 미리 봅니다.
  • 캐시된 쿼리 결과를 사용합니다. 대화형 및 일괄 쿼리가 모두 포함된 모든 쿼리 결과가 일부 예외를 제외하고 약 24시간 동안 임시 테이블에 캐시 처리됩니다. 캐시된 쿼리를 실행하는 경우에도 동시 쿼리 한도에 포함되지만 BigQuery에서 결과 집합을 계산할 필요가 없으므로 캐시된 결과를 사용하는 쿼리가 훨씬 더 빠릅니다.
  • BI Engine: BigQuery의 빠른 인메모리 분석 서비스입니다. BI Engine에서는 Google 데이터 스튜디오SQL 인터페이스와 같은 도구를 사용하여 대화형 대시보드 및 보고서를 작성할 수 있으며 BigQuery에 저장된 데이터의 동시 실행을 개선합니다. 이는 다수의 소규모 쿼리에 특히 효과적입니다.

쿼리 동시 실행 및 작업 성능과 관련된 기타 고려사항은 작업 격리 및 시차를 둔 작업입니다. 프로젝트 또는 예약에서 애플리케이션 사용 사례별로 쿼리 작업을 격리하면 쿼리가 리소스를 다량으로 사용하여 다른 쿼리의 성능에 부정적인 영향을 줄 수 있는 시끄러운 이웃(noisy-neighbor) 문제를 줄일 수 있습니다. 이렇게 하면 프로젝트당 동시 쿼리 한도에 도달할 가능성이 줄어듭니다.

여러 작업을 동시에 제출하는 대신 시차를 두거나 여러 작업을 순차적으로 제출하면 전반적인 성능에 도움이 되고 오류율이 낮아질 수 있습니다. 예를 들어 5개의 복잡한 작업이 있다고 가정해 보겠습니다. 이 다섯 개의 쿼리를 동시에 실행하면 많은 수의 슬롯이 소비되고 한 시간 내에 실행이 완료된다고 가정해 보겠습니다. 동일한 5개의 작업을 순차적으로 제출하는 경우에도 한 시간 안에 실행될 수 있지만 다른 쿼리에서 사용할 수 있는 슬롯 리소스가 확보되어 동시 쿼리 한도에 도달할 가능성이 줄어듭니다.

BigQuery는 프로젝트 또는 예약 내에서 경쟁 쿼리 간에 리소스를 할당하기 위해 공정 예약을 사용합니다. 즉, 모든 쿼리는 언제든지 사용 가능한 모든 슬롯에 동등하게 액세스할 수 있으며, 각 쿼리에 필요한 용량의 증감에 따라 활성 쿼리 간에 용량을 동적으로 자동 재할당됩니다. 따라서 동일한 프로젝트 또는 예약 내에서 비즈니스 크리티컬 프로덕션과 개발/테스트 쿼리를 실행하는 것은 각 쿼리가 슬롯에 동등하게 액세스할 수 있으므로 중요하지 않은 쿼리로 인해 실행 중인 중요한 쿼리에 성능 영향을 미칠 수 있기에 적합하지 않을 수 있습니다. 쿼리를 실행하기 전에 쿼리의 우선순위를 지정하는 것이 좋습니다.

안정성 최적화를 위한 DML 고려사항

BigQuery 데이터 조작 언어(DML) 문을 사용하면 BigQuery 테이블에서 데이터를 업데이트, 삽입, 삭제할 수 있으며 안정성에 대한 자체 가이드라인을 가집니다.

  • BigQuery는 완전히 원자적이므로 각 DML 문은 암시적 트랜잭션을 시작합니다. 즉, 각 DML 문이 성공적으로 종료될 때마다 문에서 발생한 변경사항이 자동으로 커밋됩니다.
  • 활성 스트리밍 버퍼가 있는 테이블에는 DML UPDATE, DELETE 또는 MERGE 문을 사용할 수 없습니다. 이를 시도하면 쿼리가 실패합니다.
  • DML INSERT, UPDATE, DELETE, MERGE 문에는 동시 할당량 한도가 없습니다. 하지만 동시 작업의 특정 임곗값에 도달하면 새 작업이 대기 상태로 큐에 추가됩니다.
  • 동일한 테이블에서 변형 DML 문을 동시에 실행하는 경우 BigQuery는 DML이 동일한 백엔드 파일을 변형할 수 있는지 확인하고 다른 DML을 최대 3번 재시도하는 동안 하나의 DML만 진행할 수 있도록 합니다. 3회의 후속 DML 재시도가 실패하면 DML 문이 시도된 변경사항의 충돌로 인해 실패합니다.
  • BigQuery는 DML UPDATE, DELETE, MERGE 작업을 완벽하게 지원하지만 트랜잭션 OLTP 스타일 데이터베이스는 아닙니다.

개별 DML 행 업데이트 또는 삽입을 다수로 제출하지 않는 것이 좋습니다. 대신 가능한 경우 DML 작업을 함께 그룹화합니다.

안정성 최적화를 위한 UDF 고려사항

BigQuery 사용자 정의 함수(UDF)는 제공된 코드의 실행을 기반으로 결과를 반환하는 SQL 표현식 또는 자바스크립트 코드에서 생성된 영구 또는 임시 함수입니다. UDF에는 안정성에 대한 자체 가이드라인이 있습니다.

  • UDF는 일반적으로 표준 SQL 쿼리에 비해 더 많은 슬롯 리소스를 사용하며 작업 성능에 영향을 줄 수 있습니다. 함수를 SQL로 표현할 수 있는 경우 코드를 표준 SQL 쿼리 작업으로 실행하는 것이 더 최적화된 경우가 많습니다.
  • 자바스크립트 UDF가 시간 초과되어 쿼리를 완료하지 못할 수 있습니다. 시간 제한은 5분 정도로 짧을 수 있지만 함수가 소비하는 사용자 CPU 시간과 자바스크립트 함수에 대한 입력 및 출력 크기를 포함한 여러 요소에 따라 달라질 수 있습니다.
  • UDF에는 자체 할당량과 동시 쿼리 한도가 적용됩니다. 자세한 내용은 UDF 제한사항을 참조하세요.

할당량 및 한도 관리

앞에서 설명한 것처럼 쿼리 작업에는 여러 가지 한도 및 할당량이 적용됩니다. 이러한 한도는 쿼리 유형 및 기타 요소에 따라 다르지만 최대 쿼리 또는 스크립트 실행 시간 제한은 6시간입니다. 이 한도는 변경할 수 없습니다. 경우에 따라 쿼리를 재시도해야 할 수 있습니다. 이 경우 재시도된 쿼리는 6시간 동안 추가로 실행할 수 있으며 최대 3회까지 재시도할 수 있습니다.

쿼리 작업 모니터링

BigQuery 작업 모니터링은 안정적인 애플리케이션을 실행하는 데 중요합니다. 모니터링은 BigQuery 관리자 리소스 차트 ,Cloud Monitoring 대시보드 또는 BigQuery의 Information_Schema 테이블을 통해 수행할 수 있습니다.
BigQuery 관리자 리소스 차트 및 Cloud Monitoring 대시보드를 사용하면 쿼리된 바이트 수, 실행된 동시 쿼리 수, 슬롯 소비, 쿼리 지연 시간 등을 기본적으로 모니터링할 수 있습니다. INFORMATION_SCHEMA 테이블은 작업 유형, 특정 오류 메시지, 캐시 속도, 작업 복잡성 등에 대한 추가 메타데이터를 제공합니다. INFORMATION_SCHEMA 테이블은 생성된 이후의 시간순으로 정렬된 대기 중이거나 현재 실행 중인 현재 쿼리 목록을 제공하는 아래 쿼리와 같은 추가 맞춤설정 레이어를 제공합니다.

SELECT
    creation_time,
    project_id,
    user_email,
    job_id,
    job_type,
    priority,
    state,
    TIMESTAMP_DIFF(CURRENT_TIMESTAMP(), start_time,second) as running_time_sec
 FROM
   region-us.INFORMATION_SCHEMA.JOBS_BY_PROJECT
 WHERE
    creation_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY) AND CURRENT_TIMESTAMP()
    AND state != "DONE"
ORDER BY
    running_time_sec DESC

데이터 쿼리 사용 사례

실시간 분석

이 사용 사례에서는 스트리밍 데이터를 사용하여 실시간 대화형 쿼리를 실행하는 많은 사용자가 사용하는 실시간 BI 대시보드를 제공합니다.

이 사용 사례에서는 BI 대시보드가 시끄러운 이웃(noisy neighbor)이 되고 기타 범용 쿼리 작업의 성능에 영향을 주지 않도록 하기 위해 별도의 프로젝트 또는 예약을 사용하여 BI 대시보드 쿼리를 다른 범용 쿼리와 분리해야 합니다. 또한 BigQuery 안티패턴을 보이는 실행 중 쿼리, 고비용 쿼리, SQL 쿼리는 INFORMATION_SCHEMA 테이블을 검토하여 모니터링되어야 하며 불필요한 지출 또는 쿼리 지연 시간 문제가 발생하지 않도록 수정되어야 합니다.

BI 대시보드에 대해 많은 동시 실행 쿼리 작업이 제출되거나 쿼리 지연 시간이 중요한 경우 BI Engine을 활용하는 것이 좋습니다.

커스텀 비용 관리 한도를 만들어 사용자별 또는 테이블별로 매일 처리할 수 있는 데이터 양을 제한합니다.

일괄 데이터 처리

이 사용 사례에서는 복잡한 야간 일괄 작업이 하루 전체 데이터에 대해 분석을 철저하게 수행하도록 처리되며 데이터 보강을 위해 다른 데이터 소스와 결합됩니다.

실시간 사용 사례의 안내와 마찬가지로, 별도의 프로젝트 또는 예약을 사용하여 이러한 복잡한 일괄 쿼리를 다른 범용 쿼리와 격리된 상태로 유지하여 이러한 작업이 시끄러운 이웃(noisy neighbor)이 되어 다른 쿼리 작업의 성능에 영향을 미치지 않도록 하는 것이 좋습니다. 또한 BigQuery 안티패턴을 보이는 장시간 실행 중인 쿼리, 고비용 쿼리, SQL 쿼리는 INFORMATION_SCHEMA 테이블을 통해 모니터링되어야 하며 불필요한 지출 및 쿼리 지연 시간 문제가 발생하지 않도록 수정되어야 합니다.

성능이 낮은 작업에 대한 알림을 받으려면 낮은 슬롯 가용성, 높은 쿼리 시간, 높은 스캔된 바이트 수와 같은 사항에 대해 Cloud Monitoring에서 알림을 생성합니다.

다음 단계