자동 확장 처리 도구 개요

이 페이지에서는 Spanner의 동반 도구로 사용할 수 있는 오픈소스 도구인 Spanner(자동 확장 처리)용 자동 확장 처리 도구를 소개합니다. 이 도구를 사용하면 사용 중인 용량을 기준으로 Spanner 인스턴스 하나 이상에서 컴퓨팅 용량을 자동으로 늘리거나 줄일 수 있습니다.

Spanner 확장에 대한 자세한 내용은 Spanner 자동 확장을 참조하세요. 자동 확장 처리 도구 배포에 대한 자세한 내용은 다음을 참조하세요.

• Spanner용 프로젝트별 또는 중앙 집중식 자동 확장 처리 도구 배포
• Spanner용 분산 자동 확장 처리 도구 배포

이 페이지에서는 자동 확장 처리의 기능, 아키텍처, 구성, 배포 토폴로지를 보여줍니다. 이 시리즈로 이어지는 주제는 서로 다른 토폴로지에 자동 확장 처리를 배포하는 과정을 안내합니다.

자동 확장 처리

자동 확장 처리 도구는 Spanner 배포의 사용량과 성능을 관리하는 데 유용합니다. 성능 요구 사항에 맞춰 비용 관리를 돕기 위해 자동 확장 처리 도구는 인스턴스를 모니터링하고 다음 매개변수가 유지되도록 노드 또는 처리 단위를 자동으로 추가하거나 삭제합니다.

• CPU 사용량의 권장 최댓값

• 노드당 스토리지에 대한 권장 한도

  구성 가능한 마진을 더하거나 뺀 값

Spanner 배포를 자동 확장하면 인프라가 간섭에 거의 또는 전혀 없이 부하 요구사항을 충족하도록 자동으로 조정하거나 확장할 수 있습니다. 자동 확장 기능은 프로비저닝된 인프라 크기를 올바르게 조정하므로 비용을 줄일 수 있습니다.

아키텍처

이 섹션에서는 자동 확장 처리의 구성요소와 각 용도에 대해 자세히 설명합니다.

자동 확장 처리 도구 아키텍처는 Cloud Scheduler, Pub/Sub 주제 2개, Cloud Run Functions 2개, Firestore로 구성됩니다. Cloud Monitoring API는 Spanner 인스턴스의 CPU 사용량과 스토리지 측정항목을 가져오는 데 사용됩니다.

Cloud Scheduler

Cloud Scheduler를 사용하여 자동 확장 처리 도구에서 Spanner 인스턴스 확장 측정항목 기준점을 확인하는 빈도를 정의합니다. Cloud Scheduler 작업은 인스턴스 한 개 또는 여러 개를 동시에 확인할 수 있습니다. 작업 일정은 필요한 만큼 정의할 수 있습니다.

Poller Cloud Run 함수

Poller Cloud Run 함수는 Spanner 인스턴스 하나 이상에 대한 시계열 측정항목을 수집하고 처리합니다. Poller는 각 Spanner 인스턴스의 측정항목 데이터를 사전 처리하여 가장 관련성이 높은 데이터 포인트만 평가하고 Scaler Cloud Run 함수로 전송합니다. Poller Cloud Run 함수에서 수행되는 사전 처리도 리전, 이중 리전, 멀티 리전 Spanner 인스턴스의 기준점 평가 프로세스를 간소화합니다.

Scaler Cloud Run 함수

Scaler Cloud Run 함수는 Poller Cloud 함수에서 수신한 데이터 포인트를 평가하고, 노드 또는 처리 단위 수를 조정할지 여부와 조정해야 하는 경우 그 양을 결정합니다. Cloud Run 함수는 측정항목 값과 기준점을 비교하고 허용되는 margin을 더하거나 빼고 구성된 확장 방법에 따라 노드 또는 처리 단위 수를 조정합니다. 확장 방법에 대한 자세한 내용은 자동 확장 처리 기능을 참조하세요.

운영 흐름

이 섹션에서는 다음 아키텍처 다이어그램과 같이 자동 확장 처리 도구의 운영 모델을 자세히 설명합니다.

1. Cloud Scheduler에서 자동 확장 작업의 일정, 시간, 빈도를 정의합니다.
2. Cloud Scheduler는 개발자가 정의한 일정에 Spanner 인스턴스 하나 이상에 대한 자동 확장 처리 도구 구성 매개변수가 있는 JSON 페이로드를 포함하는 메시지를 Polling Pub/Sub 주제로 푸시합니다.
3. 메시지가 Polling 주제에 게시되면 메시지를 처리하기 위해 Poller Cloud Run 함수의 인스턴스가 생성됩니다.
4. Poller Cloud Run 함수는 메시지 페이로드를 읽고 Cloud Monitoring API를 쿼리하여 각 Spanner 인스턴스의 사용량 측정항목을 검색합니다.
5. Poller 함수는 메시지에 열거된 Spanner 인스턴스마다 특정 Spanner 인스턴스를 평가하기 위한 측정항목과 구성 매개변수가 포함된 메시지 하나를 Scaling Pub/Sub 주제로 푸시합니다.

6. Scaler Cloud Run 함수는 Scaler 주제로 푸시된 메시지마다 다음을 수행합니다.

   1. Spanner 인스턴스 측정항목을 구성된 임곗값, 구성 가능한 마진을 더하거나 뺀 값과 비교합니다.

   마진을 직접 구성하거나 기본값을 사용할 수 있습니다. 1. 인스턴스 확장 여부를 결정합니다. 1. 선택한 확장 방법에 따라 인스턴스를 확장해야 하는 노드나 처리 단위 수를 계산합니다.

7. Scaler Cloud Run 함수는 인스턴스가 Firestore에서 마지막으로 확장된 시간을 검색하고 현재 시간과 비교하여 대기 기간에 따라 확장 또는 축소가 허용되는지 확인합니다.

8. 구성된 대기 기간이 경과하면 Scaler Cloud Run 함수는 확장 또는 축소 요청을 Spanner 인스턴스로 보냅니다.

이 과정에서 자동 확장 처리 도구는 추적 및 감사할 수 있도록 해당 권장사항과 작업에 대한 요약을 Cloud Logging에 작성합니다.

선택한 배포 토폴로지에 관계없이 자동 확장 처리 도구의 전체 작업은 동일하게 유지됩니다.

자동 확장 처리 기능

이 섹션에서는 자동 확장 처리 도구의 주요 기능을 설명합니다.

여러 인스턴스 관리

자동 확장 처리 도구는 여러 프로젝트에서 Spanner 인스턴스 여러 개를 관리할 수 있습니다. 멀티 리전, 이중 리전, 리전 인스턴스는 모두 확장 시 사용되는 여러 다른 사용률 기준점이 포함됩니다. 예를 들어 멀티 리전 및 이중 리전 배포는 우선순위가 높은 CPU 사용량 45%로 확장되는 반면 리전 배포는 우선순위가 높은 CPU 사용량 65%로 확장되며 둘 다 허용 margin을 더하거나 뺍니다. 확장을 위한 다양한 기준점에 대한 자세한 내용은 높은 CPU 사용량 알림을 참조하세요.

독립 구성 매개변수

자동 확장된 각 Spanner 인스턴스에는 하나 이상의 폴링 일정이 있을 수 있습니다. 각 폴링 일정에는 고유한 구성 매개변수 집합이 있습니다.

이러한 매개변수는 다음 요소를 결정합니다.

• 최대 및 최소 노드나 처리 단위 수로 인스턴스 확장 또는 축소 규모를 제어하여 비용을 관리할 수 있습니다.
• 확장 방법은 워크로드와 관련된 Spanner 인스턴스를 조정하는 데 사용됩니다.
• 대기 기간을 통해 Spanner가 데이터 분할을 관리하도록 허용합니다.

다양한 워크로드의 다양한 확장 방법

자동 확장 처리 도구는 Spanner 인스턴스 확장 및 축소를 위한 3가지 확장 방법(단계식, 선형, 직접식)을 제공합니다. 각 방법은 다양한 유형의 워크로드를 지원하도록 설계되었습니다. 독립적인 폴링 일정을 만들 때 자동 확장되는 Spanner 인스턴스마다 방법을 한 가지 이상 적용할 수 있습니다.

단계식

단계식 확장은 피크가 작거나 여러 개인 워크로드에 유용합니다. 단일 자동 확장 이벤트로 모든 작업을 원활하게 처리하도록 용량을 프로비저닝합니다.

다음 차트는 여러 개의 부하 정체 또는 단계가 있는 패턴을 보여줍니다. 각 단계에는 여러 개의 작은 피크가 있습니다. 이 패턴은 단계식 방법에 적합합니다.

부하 임곗값을 초과하는 경우 이 방법에서는 고정되지만 구성 가능한 수를 사용하여 노드나 처리 단위를 프로비저닝하고 삭제합니다. 예를 들어 확장 작업마다 노드 3개가 추가되거나 삭제됩니다. 구성을 변경하여 언제든지 더 큰 용량 증분을 추가하거나 삭제할 수 있습니다.

선형

선형 확장은 더 점진적으로 변경되거나 몇 개의 큰 피크가 있는 부하 패턴에 가장 적합합니다. 이 방법은 사용량을 확장 임곗값 미만으로 유지하는 데 필요한 최소 노드 또는 처리 단위 수를 계산합니다. 각 확장 이벤트에서 추가되거나 삭제된 노드 또는 처리 단위 수는 고정 단계 금액으로 제한되지 않습니다.

다음 차트의 샘플 부하 패턴은 부하의 갑작스런 증가와 감소를 보여줍니다. 이러한 변동은 이전 차트에서와 같이 식별 가능한 단계로 그룹화되지 않습니다. 이 패턴은 선형 확장을 사용하면 더 쉽게 처리됩니다.

자동 확장 처리 도구는 사용률 임곗값에 대한 관찰된 사용량의 비율을 사용하여 현재 총 개수에서 노드나 처리 단위를 추가할 것인지 뺄 것인지 여부를 계산합니다.

새 노드 또는 처리 단위 수를 계산하는 수식은 다음과 같습니다.

newSize = currentSize * currentUtilization / utilizationThreshold

직접

직접식 확장을 사용하면 용량이 즉각적으로 늘어납니다. 이 방법은 시작 시간이 알려진 일정에서 미리 결정된 더 높은 노드 수가 주기적으로 필요한 일괄 워크로드를 지원하기 위한 것입니다. 이 방법은 인스턴스를 일정에 지정된 최대 노드 또는 처리 단위 수까지 확장하며 선형 또는 단계식 방법에 추가로 사용됩니다.

다음 차트에서는 자동 확장 처리가 직접식 방법을 사용하기 위해 용량을 사전 프로비저닝한 대규모 계획된 부하 증가를 보여줍니다.

일괄 워크로드가 완료되고 사용량이 정상 수준으로 돌아가면 구성에 따라 선형 또는 단계식 확장이 적용되어 인스턴스가 자동으로 축소됩니다.

배포 방법

자동 확장 처리 도구는 개별 프로젝트에서 또는 관리하는 Spanner 인스턴스와 함께 배포될 수 있습니다. 자동 확장 처리 도구는 유연하도록 설계되었으며 운영팀과 애플리케이션팀 간 기존의 책임 분리를 수용할 수 있습니다. Spanner 인스턴스의 자동 확장을 구성하는 책임을 단일 운영팀으로 중앙 집중화하거나 해당 Spanner 인스턴스에서 제공하는 애플리케이션에 더 가까운 팀으로 분산할 수 있습니다.

다른 배포 모델에 대한 자세한 내용은 배포 토폴로지를 참조하세요.

쉬운 배포 및 관리를 위한 서버리스

자동 확장 처리 도구는 Cloud Run Functions, Pub/Sub, Cloud Scheduler, Firestore와 같은 서버리스 및 관리가 적은 Google Cloud 도구만을 통해 빌드됩니다. 이 방식은 자동 확장 처리 도구 실행 비용과 운영 오버헤드를 최소화합니다.

자동 확장 처리 도구는 기본 제공되는 Google Cloud 도구를 사용하여 인증과 승인에 IAM(IAM)을 최대한 활용할 수 있습니다.

구성

자동 확장 처리 도구에는 Spanner 배포 확장을 관리하는 데 사용할 수 있는 다양한 구성 옵션이 있습니다. 다음 섹션에서는 기본 구성 옵션과 고급 구성 옵션을 설명합니다.

기본 구성

자동 확장 처리 도구는 Cloud Scheduler에 정의된 구성을 통해 Spanner 인스턴스를 관리합니다. Spanner 인스턴스 여러 개를 동일한 간격으로 폴링해야 하는 경우 같은 Cloud Scheduler 작업에서 이러한 인스턴스를 구성하는 것이 좋습니다. 각 인스턴스 구성은 JSON 객체로 표시됩니다. 다음 예시는 Cloud Scheduler 작업 하나로 Spanner 인스턴스 2개를 관리하는 구성입니다.

   [
    {
        "projectId": "my-spanner-project", "instanceId": "spanner1",
        "scalerPubSubTopic": "projects/my-spanner-project/topics/spanner-scaling",
        "units": "NODES", "minSize": 1, "maxSize": 3
     },
     {
        "projectId":
        "different-project", "instanceId": "another-spanner1", "scalerPubSubTopic":
        "projects/my-spanner-project/topics/spanner-scaling", "units":
        "PROCESSING_UNITS", "minSize": 500, "maxSize": 3000, "scalingMethod": "DIRECT"
    }
   ]

Spanner 인스턴스는 다양한 Cloud Scheduler 작업에 대해 여러 구성을 가질 수 있습니다. 예를 들어 인스턴스에 일반 작업을 위한 선형 방법이 포함된 하나의 자동 확장 처리 구성이 있을 수 있지만 계획된 일괄 워크로드에 대한 직접식 방법이 있는 또 다른 자동 확장 처리 구성이 있을 수도 있습니다.

Cloud Scheduler 작업이 실행되면 Pub/Sub 메시지가 Polling Pub/Sub 주제로 전송됩니다. 이 메시지의 페이로드는 동일한 작업에서 구성된 모든 인스턴스에 대한 구성 객체의 JSON 배열입니다. Poller README 파일에서 전체 구성 옵션 목록을 참조하세요.

고급 구성

자동 확장 처리 도구에는 Spanner 인스턴스 관리 시기와 방법을 더욱 세밀하게 관리할 수 있게 해주는 고급 구성 옵션이 있습니다. 다음 섹션에서는 이러한 제어 선택을 소개합니다.

커스텀 임곗값

자동 확장 처리 도구는 다음 부하 측정항목에 권장되는 Spanner 기준점을 사용하여 인스턴스에 추가하거나 뺄 노드 또는 처리 단위 수를 결정합니다.

• 우선순위가 높은 CPU
• 24시간 이동 평균 CPU
• 스토리지 사용량

Spanner 측정항목에 대한 알림 만들기의 설명대로 기본 기준점을 사용하는 것이 좋습니다. 하지만 자동 확장 처리 도구에서 사용하는 기준점을 수정하려는 경우도 있습니다. 예를 들어 낮은 임곗값을 사용하여 자동 확장 처리 도구가 높은 임곗값일 때보다 더 빠르게 반응하도록 할 수 있습니다. 이러한 수정은 더 높은 임곗값에서 알림이 트리거되는 것을 방지하는 데 도움이 됩니다.

커스텀 측정항목

자동 확장 처리 도구의 기본 측정항목은 대부분의 성능과 확장 시나리오를 처리하지만 수평 축소 및 확장 시기를 결정하는 데 사용되는 자체 측정항목을 지정해야 하는 경우도 있습니다. 이러한 시나리오의 경우 metrics 속성을 사용하여 구성에서 커스텀 측정항목을 정의합니다.

마진

마진은 임곗값 주변의 상한 및 하한을 정의합니다. 자동 확장 처리 도구는 측정항목 값이 상한값을 초과하거나 하한값 미만인 경우에만 자동 확장 이벤트를 트리거합니다.

이 매개변수의 목적은 임곗값 주변의 작은 워크로드 변동으로 인해 자동 확장 이벤트가 트리거되지 않도록 하여 자동 확장 처리 작업의 변동량을 줄이는 것입니다. 임곗값과 마진은 측정항목 값이 원하는 바에 따라 다음 범위를 함께 정의합니다.

[threshold - margin, threshold + margin]

. 마진이 작을수록 범위가 좁아져 자동 확장 이벤트가 트리거될 가능성이 높아집니다.

측정항목의 마진 매개변수를 지정하는 것은 선택사항이며, 기본값은 매개변수 앞뒤에 모두 5% 포인트입니다.

배포 토폴로지

자동 확장 처리 도구를 배포하려면 다음 토폴로지 중에서 기술 및 운영 요구사항을 가장 잘 충족하는 토폴로지를 결정합니다.

• 프로젝트별 토폴로지: 자동 확장 처리 인프라가 자동 확장되어야 하는 Spanner와 동일한 프로젝트에 배포됩니다.
• 중앙 집중식 토폴로지: 자동 확장 처리 도구가 한 프로젝트에 배포되며 여러 프로젝트에서 Spanner 인스턴스 하나 이상을 관리합니다.
• 분산 토폴로지: 대부분의 자동 확장 처리 인프라가 한 프로젝트에 배포되지만 일부 인프라 구성요소는 다른 프로젝트에서 자동 확장되는 Spanner 인스턴스와 함께 배포됩니다.

프로젝트별 토폴로지

프로젝트별 토폴로지 배포에서 자동 확장되어야 하는 Spanner 인스턴스가 있는 각 프로젝트에는 자동 확장 처리 구성요소의 자체적인 독립 배포도 있습니다. 자체적으로 자동 확장 처리 구성과 인프라를 관리하려는 개별 팀이 이 토폴로지를 사용하는 것이 좋습니다. 또한 자동 확장 처리 도구 기능을 테스트할 수 있는 좋은 출발점입니다.

다음 다이어그램은 프로젝트별 배포의 대략적인 개념을 보여줍니다.

앞선 다이어그램에 표시된 프로젝트별 배포에는 다음과 같은 특성이 있습니다.

• 애플리케이션 1과 애플리케이션 2의 두 애플리케이션은 각각 자체 Spanner 인스턴스를 사용합니다.
• Spanner 인스턴스(A)는 애플리케이션 1과 애플리케이션 2 프로젝트 각각에 있습니다.
• 독립된 자동 확장 처리(B)는 프로젝트 내 인스턴스 자동 확장이 제어되도록 각 프로젝트에 배포됩니다.

프로젝트별 배포에 대한 자세한 다이어그램은 아키텍처 섹션을 참조하세요.

프로젝트별 배포에는 다음과 같은 장단점이 있습니다.

장점:

• 가장 간단한 설계: 프로젝트별 토폴로지는 모든 자동 확장 처리 구성요소가 자동 확장되는 Spanner 인스턴스와 함께 배포되므로 3가지 토폴로지 중에서 가장 간단한 설계입니다.
• 구성: Spanner 인스턴스를 소유한 팀에서 스케줄러 매개변수를 제어하므로 팀이 중앙 집중식 또는 분산 토폴로지 보다 필요에 따라 자동 확장 처리를 더 자유롭게 조정할 수 있습니다.
• 인프라 책임의 경계 명확: Cloud Spanner 인스턴스의 팀 소유자는 자동 확장 처리 인프라의 소유자이기도 하므로 프로젝트별 토폴로지 설계는 자동 확장 처리 인프라에 대한 책임과 보안의 명확한 경계를 설정합니다.

단점:

• 더 많은 전체 유지보수: 각 팀이 자동 확장 처리 구성과 인프라를 담당하므로 회사 전체의 모든 자동 확장 처리 도구가 같은 업데이트 가이드라인을 따르게 하기가 어려워질 수 있습니다.
• 보다 복잡한 감사: 각 팀에 높은 수준의 제어가 있기 때문에 중앙 집중식 감사가 더 복잡해질 수 있습니다.

프로젝트별 토폴로지를 사용하여 자동 확장 처리를 설정하는 방법을 알아보려면 Spanner용 프로젝트별 또는 중앙 집중식 자동 확장 처리 도구 배포를 참조하세요.

중앙 집중식 토폴로지

프로젝트별 토폴로지와 마찬가지로 중앙 집중식 토폴로지에서는 모든 자동 확장 처리 도구 구성요소가 같은 프로젝트에 있습니다. 하지만 Spanner 인스턴스는 다른 프로젝트에 있습니다. 이 배포는 중앙에서 자동 확장 처리 도구 단일 배포를 통해 여러 Spanner 인스턴스의 구성과 인프라를 관리하는 팀에 적합합니다.

다음 다이어그램은 중앙 집중식 프로젝트 배포에 대한 대략적인 개념을 보여줍니다.

앞의 다이어그램에 표시된 중앙 집중식 배포의 특징은 다음과 같습니다.

• 애플리케이션 1과 애플리케이션 2의 두 애플리케이션은 각각 자체 Spanner 인스턴스를 사용합니다.
• Spanner 인스턴스(A)는 애플리케이션 1과 애플리케이션 2 프로젝트 각각에 있습니다.
• 자동 확장 처리(B)가 애플리케이션 1 및 애플리케이션 2 프로젝트 모두에서 Spanner 인스턴스 자동 확장을 제어하기 위해 별도의 프로젝트에 배포됩니다.

중앙 집중식 프로젝트 배포에 대한 자세한 다이어그램은 Spanner용 프로젝트별 또는 중앙 집중식 자동 확장 처리 도구 배포를 참조하세요.

중앙 집중식 배포에는 다음과 같은 장단점이 있습니다.

장점:

• 중앙 집중식 구성 및 인프라: 단일 팀이 스케줄러 매개변수와 자동 확장 처리 인프라를 제어합니다. 이 방식은 규제가 심한 업계에서 유용할 수 있습니다.
• 전체 유지보수 감소: 일반적으로 유지보수 및 설정은 프로젝트별 배포에 비해 더 쉽게 유지됩니다.
• 중앙 집중식 정책 및 감사: 팀 간 권장사항을 지정하고 수행하기가 더 쉬울 수 있습니다. 감사는 실행하기 더 간편할 수 있습니다.

단점:

• 중앙 집중식 구성: 자동 확장 처리 매개변수에 대한 모든 변경사항은 변경을 요청하는 팀에서 Spanner 인스턴스를 소유하고 있더라도 중앙 집중식 팀을 거쳐야 합니다.
• 추가 위험 가능성: 자동 확장 처리 인프라가 고가용성을 염두에 두고 설계된 경우에도 중앙 집중식 팀 자체가 단일 장애점이 될 수 있습니다.

이 옵션을 사용하여 자동 확장 처리 도구를 설정하는 단계별 튜토리얼은 Spanner용 프로젝트별 또는 중앙 집중식 자동 확장 처리 도구 배포를 참조하세요.

분산 토폴로지

분산 토폴로지 배포에서는 자동 확장되어야 하는 Cloud Scheduler 및 Spanner 인스턴스가 같은 프로젝트에 있습니다. 자동 확장 처리 도구의 나머지 구성요소는 중앙에서 관리되는 프로젝트에 있습니다. 이 배포는 하이브리드 배포입니다. Spanner 인스턴스를 소유한 팀은 인스턴스의 자동 확장 처리 구성 매개변수만 관리하며 중앙 팀은 나머지 자동 확장 처리 인프라를 관리합니다.

다음 다이어그램에서는 분산 프로젝트 배포에 대한 대략적인 개념을 보여줍니다.

앞의 다이어그램에 표시된 하이브리드 배포에는 다음과 같은 특성이 있습니다.

• 애플리케이션 1과 애플리케이션 2의 두 애플리케이션은 자체 Spanner 인스턴스를 사용합니다.
• Spanner 인스턴스(A)는 애플리케이션 1과 애플리케이션 2 프로젝트 모두에 있습니다.
• 독립된 Cloud Scheduler 구성요소(C)가 각 프로젝트, 즉 애플리케이션 1과 애플리케이션 2에 배포됩니다.
• 나머지 자동 확장 처리 구성요소(B)가 별도의 프로젝트에 배포됩니다.
• 자동 확장 처리 도구는 각 프로젝트의 독립된 Cloud Scheduler 구성요소에서 전송한 구성을 사용하여 애플리케이션 1 및 애플리케이션 2 프로젝트 모두에서 Spanner 인스턴스를 자동 확장합니다.

중앙 집중식 프로젝트 배포에 대한 자세한 다이어그램은 Spanner용 분산 자동 확장 처리 도구 배포를 참조하세요.

분산형 배포에는 다음과 같은 장단점이 있습니다.

장점:

• 애플리케이션팀이 구성 및 일정 제어: Cloud Scheduler는 자동 확장되는 Spanner 인스턴스와 함께 배포되므로 애플리케이션팀이 구성 및 예약을 더 세밀하게 제어할 수 있습니다.
• 운영팀에서 인프라 제어: 자동 확장 처리 도구의 핵심 구성요소가 중앙에서 배포되어 운영팀에서 자동 확장 처리 인프라를 제어할 수 있습니다.
• 중앙 집중식 유지보수: Scaler 인프라가 중앙 집중화되어 오버헤드가 줄어듭니다.

단점:

• 더욱 복잡한 구성: 애플리케이션팀이 폴링 주제에 쓸 수 있는 서비스 계정을 제공해야 합니다.
• 추가 위험 가능성: 인프라가 고가용성을 염두에 두고 설계된 경우에도 공유 인프라가 단일 장애점이 될 수 있습니다.

분산 배포에서 자동 확장 처리 도구를 설정하는 방법은 Cloud Spanner용 분산 자동 확장 도구 배포를 참조하세요.

데이터 분할

Spanner는 분할이라는 데이터 범위를 노드 또는 처리 단위라고 부르는 노드의 하위 영역에 할당합니다. 노드나 처리 단위는 할당된 분할의 데이터를 독립적으로 관리하고 제공합니다. 데이터 분할은 데이터 볼륨과 액세스 패턴을 포함한 여러 가지 요소를 기반으로 생성됩니다. 자세한 내용은 Spanner - 스키마 및 데이터 모델을 참조하세요.

참고: Spanner는 해당 시간 동안 존재하는 최대 노드 또는 처리 단위 수에 시간당 요금을 시간별 요금과 곱하여 요금을 청구합니다. 따라서 프로비저닝하는 모든 노드 또는 처리 단위의 요금은 1시간 단위로 청구됩니다. 시간 내 확장을 위해 자동 확장 처리 구성을 최적화하지 않는 것이 좋습니다. 자세한 내용은 Spanner 가격 책정 개요를 참조하세요.

데이터는 분할되어 구성되며 Spanner는 분할을 자동으로 관리합니다. 따라서 자동 확장 처리 도구에서 노드 또는 처리 단위를 추가하거나 삭제할 때 새 용량이 추가되거나 인스턴스에서 삭제되므로 Spanner 백엔드가 분할을 다시 할당하고 재구성할 수 있도록 충분한 시간을 허용해야 합니다.

자동 확장 처리 도구는 확장 및 축소 이벤트 모두에서 대기 기간을 사용하여 인스턴스에서 노드 또는 처리 단위를 추가하거나 삭제할 수 있는 속도를 제어합니다. 이 방법을 사용하면 인스턴스에서 컴퓨팅 메모 또는 처리 단위와 데이터 분할 사이의 관계를 재구성하는 데 필요한 시간을 확보할 수 있습니다. 기본적으로 확장 및 축소 대기 기간은 다음과 같은 최솟값으로 설정됩니다.

• 수직 확장 값: 5분
• 축소 값: 30분

확장 권장사항과 대기 기간에 대한 자세한 내용은 Spanner 인스턴스 확장을 참조하세요.

비용

자동 확장 처리 도구 리소스는 최소한으로 소비되므로 대부분의 사용 사례에서 비용을 무시할 수 있습니다. Google Cloud에서 자동 확장 처리를 사용할 때는 비용이 발생하지 않습니다. 예를 들어 자동 확장 처리 도구를 실행하면 각 인스턴스의 폴링 간격이 5분인 Spanner 인스턴스 3개를 무료로 관리할 수 있습니다. 이러한 예측에는 다음이 포함됩니다.

• Cloud Scheduler 작업 3개
• Pub/Sub 메시지 0.15GB
• 51840 Cloud Run 함수 500ms 호출
• Firestore의 10MB 미만 데이터

Spanner 데이터베이스 작업 비용은 추정값에 포함되지 않습니다. 가격 계산기를 사용하여 예상 사용량을 토대로 예상 비용을 산출합니다.

다음 단계

• 프로젝트별 또는 중앙 집중식 토폴로지에 자동 확장 처리 도구 배포 방법 알아보기
• 분산 토폴로지에서 자동 확장 처리 도구 배포 방법 알아보기
• Spanner 권장 기준 자세히 알아보기
• Spanner CPU 사용률 측정항목 및 지연 시간 측정항목 자세히 알아보기
• 핫스팟을 방지하고 Spanner에 데이터를 로드하기 위한 Spanner 스키마 설계 권장사항 알아보기
• Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항 살펴보기 Cloud 아키텍처 센터를 살펴보세요.