Google은 AI 기술을 사용하여 콘텐츠를 사용자의 기본 언어로 번역합니다. AI 번역에는 오류가 있을 수 있습니다.

안정성 이해

BigQuery를 사용하면 리전 내에서 머신 및 영역 장애를 자동으로 처리하여 중단을 최소화하면서 분석 워크로드를 실행할 수 있습니다. 더 광범위한 복원력을 위해 리전 간 재해 복구를 구성하고, 삭제되거나 손상된 데이터를 복원하고, 클라이언트 측 오류 재시도를 구현하여 안정성 요구사항을 충족할 수 있습니다.

이러한 기능은 이상 감지, 스트리밍 수집을 통한 실시간 분석, BigQuery ML을 통한 예측 분석을 포함하여 일관된 성능으로 대량의 데이터를 수집하고 분석하는 워크로드를 지원합니다. 이러한 솔루션의 자세한 예시는 BigQuery 참조 패턴을 참조하세요.

BigQuery의 신뢰성 측정기준

BigQuery가 워크로드의 요구사항을 충족하는지 확인하려면 가용성, 내구성, 데이터 일관성, 성능 일관성, 데이터 복구라는 5가지 주요 측정기준에서 안정성을 평가하면 됩니다.

가용성

가용성은 BigQuery에서 데이터를 읽거나 BigQuery에 데이터를 쓰는 기능을 정의합니다. BigQuery는 99.99% 업타임 SLA를 통해 읽기 및 쓰기 작업 모두 가용성이 높도록 설계되었습니다. 이 두 작업에는 2가지 구성요소가 모두 포함됩니다.

BigQuery 서비스
특정 쿼리를 실행하는 데 필요한 컴퓨팅 리소스

서비스의 신뢰성은 데이터를 검색하는 데 사용하는 특정 BigQuery API의 함수입니다. 컴퓨팅 리소스의 가용성은 쿼리를 실행할 때 사용할 수 있는 용량에 따라 달라집니다. BigQuery의 기본 컴퓨팅 단위와 슬롯 리소스 절약 모드에 대한 자세한 내용은 슬롯 이해를 참조하세요.

내구성

내구성은 사이트 안정성 통합문서의 SLO 구현 챕터에 정의된 대로 성공적으로 읽을 수 있는 데이터 비율을 측정합니다. 높은 내구성을 제공하기 위해 BigQuery는 선택한 위치 내의 두 영역에 데이터의 중복 사본을 자동으로 저장합니다.

데이터 일관성

데이터 일관성은 데이터가 작성되거나 수정된 후 데이터를 쿼리하는 방법과 시기를 정의합니다. 데이터 일관성의 한 가지 측면은 데이터 수집을 위해 '딱 한 번' 시맨틱스를 보장하는 것입니다. 자세한 내용은 실패한 작업 삽입 재시도를 참조하세요.

성능 일관성

일반적으로 성능은 두 가지 측정기준으로 표현할 수 있습니다. 지연 시간은 쿼리와 같은 긴 데이터 검색 작업의 실행 시간을 측정합니다. 처리량은 BigQuery가 특정 기간 동안 처리할 수 있는 데이터의 양을 측정합니다. BigQuery의 멀티 테넌트 및 수평 확장 설계 덕분에 처리량을 임의의 데이터 크기로 확장할 수 있습니다. 특정 사용 사례에 따라 지연 시간 및 처리량의 상대적 중요도가 결정됩니다.

데이터 복구

다음 측정항목을 사용하여 서비스 중단 후 데이터를 복구하는 기능을 측정할 수 있습니다.

복구 시간 목표 (RTO): 사고 후 데이터를 사용할 수 없는 최대 시간입니다.
목표 복구 시간 (RPO): 사고 발생 전에 수집된 데이터 중 조직에서 손실을 감당할 수 있는 최대 데이터 양입니다.

이러한 고려사항은 영역 또는 리전에 여러 날에 걸친 중단 또는 파괴적인 중단이 발생하는 드문 경우와 관련이 있습니다.

재해 복구 계획하기

이 섹션에서 재해 계획은 단일 머신의 손실부터 전체 리전의 치명적인 손실에 이르는 장애를 다룹니다. BigQuery는 단일 머신 및 영역 장애를 자동으로 처리하지만, 워크로드에 필요한 경우 리전 장애에 대비해 복구를 위한 아키텍처를 설계해야 합니다. 자동 복구가 종료되고 사용자의 책임이 시작되는 지점을 이해하는 것은 재해 복구 계획에 필수적입니다.

BigQuery는 99.99% 업타임 SLA를 제공합니다. 이 가용성은 서로 다른 두 영역에 데이터를 쓰고 중복 컴퓨팅 용량을 프로비저닝하는 BigQuery의 리전 아키텍처를 통해 지원됩니다. BigQuery SLA는 리전 (예: us-central1)과 멀티 리전 (예: US)에서 동일합니다.

장애 자동 처리

BigQuery는 리전 서비스이므로 개별 머신 또는 전체 영역의 손실을 자동으로 처리합니다. BigQuery는 기본 영역 인프라를 추상화합니다.

머신 손실

머신 장애는 Google이 운영하는 범위에서 매일 발생하는 현상입니다. BigQuery는 포함 영역에 영향을 미치지 않고 머신 장애를 자동으로 처리하도록 설계되어 있습니다.

BigQuery는 각 쿼리를 작은 태스크로 나누고 여러 머신에 동시에 전달합니다. 머신에 장애가 발생하거나 성능이 저하되면 BigQuery는 영향을 받는 태스크를 다른 머신에 자동으로 다시 전달합니다. 이러한 접근 방식은 꼬리 지연 시간을 줄이는 데 매우 중요합니다.

BigQuery는 Reed-Solomon 인코딩을 사용하여 데이터의 영역 복사본을 영구적으로 저장하고 다른 영역에 추가 영역 복사본을 하나 이상 저장합니다. 여러 머신 장애로 인해 영역 복사본이 손실되면 BigQuery가 손실을 감지하고 중복 데이터를 복원하기 위해 새 영역 복사본을 만듭니다.

영역 손실

99.99% 업타임 SLA를 충족하기 위해 BigQuery는 데이터와 컴퓨팅 슬롯 모두에 대한 자동 영역 중복을 제공합니다. 단일 영역 컴퓨팅 가용성만으로는 이 SLA를 충족할 수 없으므로 BigQuery는 심각한 영역 중단이 발생한 후 1분 이내에 새 쿼리를 다른 영역으로 자동으로 라우팅합니다. 진행 중인 쿼리는 완료하는 데 시간이 더 오래 걸릴 수 있지만 새로 실행된 쿼리는 다른 영역에서 정상적으로 완료됩니다.

영역을 장기간 사용할 수 없게 되더라도 BigQuery에서 데이터를 두 영역에 동기식으로 쓰므로 데이터가 손실되지 않습니다. 따라서 영역 서비스가 중단되어도 서비스에 지장을 주지 않습니다.

장애 유형

실패에는 소프트 실패와 하드 실패의 두 가지 유형이 있습니다.

소프트 장애는 하드웨어가 파괴되지 않는 작업 결함입니다. 예시로 전원 오류, 네트워크 파티션 또는 머신 비정상 종료를 들 수 있습니다. BigQuery는 소프트 장애 중에 데이터 손실을 방지하도록 설계되었습니다.

하드 장애는 홍수, 지진, 허리케인으로 인한 피해와 같이 하드웨어가 파괴되는 운영 장애입니다. BigQuery가 하드 장애 중에 데이터 손실을 방지할 수 있는지 여부는 장애가 단일 영역에 영향을 미치는지 아니면 전체 리전에 영향을 미치는지에 따라 달라집니다.

위치 중복 및 장애 동작

BigQuery 데이터 세트를 만들 때 데이터를 저장할 위치를 선택합니다. 이 위치는 다음 중 하나입니다.

리전: 아이오와 (us-central1) 또는 몬트리올 (northamerica-northeast1)과 같은 특정 지리적 위치
멀티 리전: 미국(US) 또는 유럽(EU)과 같이 두 개 이상의 지리적 장소를 포함하는 큰 지리적 영역

두 경우 모두에서 BigQuery는 선택된 위치의 단일 리전 내에 있는 두 개의 서로 다른 Google Cloud 영역에 데이터 복사본을 자동으로 저장합니다.

스토리지 중복성 외에도 BigQuery는 여러 영역에 걸쳐 중복 컴퓨팅 용량을 유지합니다. BigQuery는 여러 가용성 영역에 걸쳐 중복 스토리지와 컴퓨팅을 결합하여 고가용성과 내구성을 제공합니다.

머신 수준 장애가 발생하는 경우 BigQuery가 약간의 밀리초 지연만 있을 뿐 계속 실행되며 현재 실행 중인 모든 쿼리가 계속 처리됩니다. 소프트 또는 하드 영역 장애 중에는 데이터 손실이 발생하지 않지만 현재 실행 중인 쿼리를 다시 제출해야 할 수 있습니다. BigQuery는 정전, 변압기 장애, 네트워크 파티션과 같은 소프트 영역 장애를 몇 분 내에 자동으로 완화합니다.

리전 전체의 네트워크 연결 손실과 같은 소프트 리전 장애로 인해 리전이 다시 온라인 상태가 될 때까지 가용성이 손실될 수 있지만 데이터는 손실되지 않습니다. 전체 리전을 파괴하는 재해와 같은 하드 리전 장애로 인해 해당 리전에 저장된 데이터가 손실될 수 있습니다. BigQuery는 다른 리전의 데이터 백업 또는 복제본을 자동으로 제공하지 않습니다. 리전 간 데이터 세트 복제 또는 관리형 재해 복구를 사용하여 심각한 리전 장애에 대한 복원력을 향상할 수 있습니다.

BigQuery 데이터 세트 위치에 대한 자세한 내용은 위치 고려사항을 참조하세요.

시나리오: 리전 손실

BigQuery는 물리적 리전이 손상된 경우 내구성이나 가용성을 제공하지 않습니다. 이 제한사항은 리전과 멀티 리전 모두에 적용되므로 리전 중단 중에 내구성과 가용성을 유지하려면 미리 계획해야 합니다. 일시적인 리전 중단 중에 BigQuery의 99.99% SLA가 가용성 요구사항을 충족하지 않는 경우 리전 간에 중복 가용성을 구성하는 것이 좋습니다.

리전이 손상될 경우 데이터 손실을 방지하려면 데이터를 다른 지리적 위치에 백업하세요. 예를 들어 리전 간 데이터 세트 복제를 사용하여 데이터를 지리적으로 다른 리전에 지속적으로 복제할 수 있습니다.

BigQuery 멀티 리전을 사용하는 경우 해당 멀티 리전의 지리적 범위 내에 있는 단일 리전에 데이터를 백업하지 마세요. 예를 들어 US 멀티 리전에서 데이터를 백업하는 경우 재해 발생 시 상관관계가 있는 장애가 발생할 위험이 있으므로 us-central1과 같이 겹치는 리전을 선택하지 마세요. 멀티 리전의 지리적 범위에 대한 자세한 내용은 멀티 리전을 참조하세요.

비가용성 확장을 방지하려면 지리적으로 별도의 BigQuery 위치 두 개에 데이터를 복제하고 슬롯을 프로비저닝합니다. 관리형 재해 복구를 사용하여 보조 리전에서 슬롯을 자동으로 프로비저닝하고 한 리전에서 다른 리전으로 워크로드의 장애 조치를 제어할 수 있습니다.

시나리오: 실수로 인한 삭제 또는 데이터 손상

BigQuery에서는 BigQuery의 멀티 버전 동시 실행 제어 아키텍처를 통해 시간 여행을 지원합니다. 시간 이동을 사용하면 지난 7일 이내의 특정 시점에서 데이터를 쿼리할 수 있습니다. 이 기능을 사용하면 7일 이내에 실수로 삭제, 수정 또는 손상된 데이터를 복원할 수 있습니다. 시간 이동은 삭제된 테이블에서도 작동합니다.

또한 BigQuery를 사용하면 테이블 스냅샷을 만들어 동일한 리전 내에서 7일 이상의 시간 이동 기간 동안 데이터를 백업할 수 있습니다. 스냅샷 생성은 메타데이터 전용 작업이므로 추가 스토리지 요금이 발생하지 않습니다. 테이블 스냅샷은 실수로 인한 삭제를 방지하는 데 도움이 되지만 데이터 내구성을 높이지는 않습니다.

실시간 분석을 위한 재해 복구

스트리밍 엔드포인트 로그를 BigQuery에 지속적으로 수집하는 실시간 분석 파이프라인의 경우 확장된 리전 비가용성을 방지하려면 지속적으로 데이터를 복제하고 보조 리전에 슬롯을 프로비저닝해야 합니다. 하지만 수집 아키텍처는 Pub/Sub 및 Dataflow를 데이터 로드 방법 중 하나로 사용할 때 일시적인 BigQuery 비가용성에 대해 이미 복원력이 우수하므로 이렇게 높은 수준의 중복성에 비용을 투자할 가치는 없을 것입니다.

예를 들어 us-east4에서 us-central1의 Cloud Storage Archive Storage로 BigQuery 데이터를 내보내도록 야간 추출 작업을 구성한다고 가정해 보겠습니다. 이 내보내기는 us-east4에서 치명적인 데이터 손실이 발생하는 경우 내구성 있는 백업을 제공합니다. 이 구성에서 복구 지점 목표(RPO)는 24시간입니다. 가장 최근 백업이 최대 24시간 전일 수 있기 때문입니다. us-central1의 Cloud Storage 백업에서 BigQuery로 데이터를 복원해야 하므로 복구 시간 목표 (RTO)는 며칠이 걸릴 수 있습니다. 백업과 다른 리전에서 BigQuery를 프로비저닝하는 경우 먼저 데이터를 해당 리전으로 전송해야 합니다. 복구 리전에서 사전에 중복 슬롯을 구매하지 않은 경우 요청하는 수량에 따라 필요한 BigQuery 용량을 프로비저닝하는 데 추가 시간이 걸릴 수 있습니다.

일괄 데이터 처리를 위한 재해 복구

정해진 기한까지 비즈니스에 중요한 일일 보고서를 규제 기관에 전송해야 하는 일괄 데이터 처리 워크로드의 경우 전체 처리 파이프라인의 개별 인스턴스 2개를 실행하여 중복성을 구현하는 것은 비용을 투자할 가치가 있는 일입니다. us-west1 및 us-east4과 같은 두 개의 개별 리전을 사용하면 리전의 비가용성이 확장되거나 영구적인 리전 손실이 발생하는 경우를 대비한 지리적 분리와 두 개의 독립적인 장애 도메인이 제공됩니다.

보고서를 한 번만 전달해야 하는 경우 두 파이프라인이 모두 성공적으로 완료되면 출력을 조정해야 합니다. 한 가지 방법은 완료 시 Pub/Sub 주제에 알림을 게시하는 등의 방법으로 먼저 완료되는 파이프라인의 결과를 선택하는 것입니다. 또는 두 번째 파이프라인이 결과를 덮어쓰고 Cloud Storage에서 객체 버전 관리를 사용하도록 할 수 있습니다. 나중에 완료된 파이프라인에서 손상된 데이터를 작성하는 경우 Cloud Storage에서 첫 번째 파이프라인이 쓴 버전을 복원하면 됩니다.

오류 처리

다음 섹션에서는 안정성에 영향을 미치는 오류를 처리하기 위한 권장사항을 설명합니다.

실패한 API 요청 재시도

클라이언트 애플리케이션, 클라이언트 라이브러리 또는 파트너 도구가 BigQuery에 API 요청을 실행할 때 잘린 지수 백오프를 사용합니다. 이 재시도 전략을 사용하면 클라이언트가 시스템 오류 또는 할당량 오류를 수신하는 경우 무작위로 증가하는 대기 간격을 사용하여 최대 횟수까지 요청을 재시도합니다.

잘린 지수 백오프를 사용하면 일시적인 오류에 대한 애플리케이션의 복원력이 향상됩니다. 정상적인 작동 상황에서도 BigQuery의 99.99% 가용성 SLA에 설명된 대로 요청 10,000개 중 1개 정도는 실패할 것으로 예상할 수 있습니다. 비정상적인 상황에서는 이 오류율이 증가할 수 있지만 오류가 무작위로 분산되면 지수 백오프를 통해 대부분의 실패를 완화할 수 있습니다.

요청이 5xx 오류로 인해 지속적으로 실패하는 경우 Cloud Customer Care에 문의하고 지원 케이스 우선순위를 설정할 때 비즈니스 영향을 명확하게 전달하여 지원팀에서 문제를 정확하게 분류할 수 있도록 하세요. 반대로 4xx 오류로 요청이 지속적으로 실패하는 경우 애플리케이션을 수정하여 문제를 해결할 수 있습니다. 자세한 내용은 오류 메시지를 확인하세요.

지수 백오프 로직 예시

지수 백오프 로직은 재시도 간 대기 시간을 최대 백오프 시간까지 늘려서 쿼리 또는 요청을 재시도합니다. 다음 단계는 클라이언트가 잘린 지수 백오프를 구현하는 방법을 보여줍니다.

BigQuery에 요청을 보냅니다.
요청이 실패하면 1 + random_number_milliseconds초 동안 기다린 후 요청을 다시 시도합니다.
요청이 실패하면 2 + random_number_milliseconds초 동안 기다린 후 요청을 다시 시도합니다.
요청이 실패하면 4 + random_number_milliseconds초 동안 기다린 후 요청을 다시 시도합니다.
이 패턴을 반복하여 재시도할 때마다 기본 대기 시간을 maximum_backoff시간까지 두 배로 늘립니다.
대기 시간을 maximum_backoff 이상으로 늘리지 않고 최대 재시도 횟수까지 계속 대기하고 재시도합니다.

이 백오프 계산에 대해 다음 세부정보를 고려하세요.

대기 시간은 min(((2^n)+random_number_milliseconds), maximum_backoff)이고, n은 반복(요청)할 때마다 1씩 증가합니다.
random_number_milliseconds는 1,000밀리초 이하의 랜덤 숫자입니다. 이러한 무작위 순서 지정은 많은 클라이언트가 우연히 동기화되고 동시에 재시도되어 일련의 동기화된 작업으로 요청을 보내는 상황을 피하는 데 도움이 됩니다. 각 재시도 요청 후 random_number_milliseconds를 다시 계산합니다.
최대 백오프 간격(maximum_backoff)은 일반적으로 32 또는 64초입니다. maximum_backoff의 적절한 값은 사용 사례에 따라 다릅니다.

클라이언트가 최대 백오프 시간에 도달한 후에도 계속 재시도할 수 있습니다. 이후 재시도는 백오프 시간을 계속 늘릴 필요가 없습니다. 예를 들어 클라이언트가 최대 백오프 시간으로 64초를 사용하는 경우 이 값에 도달한 후 클라이언트가 64초마다 계속 재시도할 수 있습니다. 무한 재시도 루프를 방지하려면 클라이언트가 설정된 한도 후에 재시도를 중지하도록 최대 재시도 횟수를 구성합니다.

재시도 간 대기 시간과 재시도 횟수는 사용 사례 및 네트워크 조건에 따라 달라집니다.

실패한 작업 삽입 재시도

애플리케이션에 정확히 한 번의 삽입 시맨틱스가 필요한 경우 작업의 WriteDisposition가 테이블의 기존 데이터를 처리하는 방법 (실패, 덮어쓰기 또는 추가)을 고려하세요.

WRITE_EMPTY 또는 WRITE_TRUNCATE 처리를 사용하면 실패한 작업 삽입 또는 실행을 재시도하여 최대 한 번 시맨틱스를 구현할 수 있습니다. BigQuery는 작업이 수집하는 모든 행을 테이블에 원자적으로 기록하기 때문입니다.

WRITE_APPEND 처리를 사용하는 경우 재시도 시 중복 데이터가 추가되지 않도록 커스텀 작업 ID를 지정합니다. BigQuery는 이전 작업 ID를 재사용하는 작업 생성 요청을 거부하므로 작업 ID를 지정하면 해당 ID에 대해 최대 한 번의 시맨틱스가 제공됩니다. 그런 다음 예측 가능한 새 작업 ID로 재시도하기 전에 이전의 모든 시도가 실패했음을 확인하여 1회만 실행되는 시맨틱스를 달성할 수 있습니다.

일시적인 네트워크 문제로 인해 클라이언트가 작업 삽입 확인을 수신하지 못하면 동일한 작업 ID로 재시도해도 status=ALREADY_EXISTS (code=409 및 reason="duplicate")와 함께 실패합니다. jobs.get을 호출하여 기존 작업의 상태를 검색하고 새 작업 ID로 새 작업을 만들지 여부를 결정합니다.

사용 사례 및 안정성 요구사항

BigQuery는 다양한 아키텍처에서 핵심 구성요소로 사용될 수 있습니다. 배포하는 사용 사례 및 아키텍처에 따라 다양한 가용성, 성능, 안정성 요구사항을 충족해야 할 수 있습니다. 다음 섹션에서는 두 가지 일반적인 아키텍처와 안정성 요구사항을 살펴봅니다.

실시간 분석

첫 번째 예시는 이벤트 데이터 처리 파이프라인입니다. 이 아키텍처에서 Pub/Sub는 엔드포인트에서 로그 이벤트를 수집하고 스트리밍 Dataflow 파이프라인은 BigQuery Storage Write API를 사용하여 데이터를 처리하고 BigQuery에 씁니다. 그런 다음 분석가는 데이터에 대한 임시 쿼리를 실행하여 이벤트 시퀀스를 다시 만들고 거의 실시간 대시보드는 데이터를 시각화하여 트렌드와 패턴을 감지합니다.

이 워크로드에는 높은 엔드 투 엔드 데이터 기록 빈도가 필요하므로 낮은 수집 지연 시간이 중요합니다. 데이터가 BigQuery에 작성된 후 신뢰성은 사용자가 일관되고 예측 가능한 지연 시간으로 임시 쿼리를 실행할 수 있는지 여부와 데이터를 사용하는 대시보드가 최신 정보를 반영하는지 여부라는 두 가지 요소에 따라 달라집니다.

일괄 데이터 처리

두 번째 예시는 금융 서비스 업계의 규정 준수를 위한 일괄 처리 아키텍처입니다. 핵심 요구사항은 고정된 야간 기한까지 규제 기관에 일일 보고서를 제공하는 것입니다. 보고서를 생성하는 야간 일괄 프로세스가 이 기한까지 완료되면 성능 요구사항을 충족하는 것으로 간주됩니다.

파이프라인은 데이터를 BigQuery에 로드하고 대시보드, 분석, PDF 보고서 생성을 위해 데이터를 다른 데이터 소스와 조인합니다. 이러한 보고서를 오류 없이 적시에 제공하는 것이 중요한 비즈니스 요구사항입니다. 따라서 데이터 수집 중에 신뢰성을 보장하고 규제 기한을 충족하는 일관된 기간 내에 정확한 보고서를 생성해야 합니다.