이 페이지에서는 Spanner 인스턴스의 중단을 유발하여 'Google의 합리적인 통제 범위를 벗어난 요인으로 인해 발생하는' 중단을 제외하는 Spanner 서비스수준계약 (SLA)에서 제외될 수 있는 사용자 제어 구성에 대해 설명합니다. 또한 이러한 구성을 피하는 방법에 관한 가이드라인도 제공합니다.
Spanner는 데이터 분할 및 재분배, 복제, 장애 조치, 모든 하드웨어 및 소프트웨어 업데이트와 같은 데이터베이스 작업의 여러 측면을 관리합니다. 기본 제공 설정과 관리 API를 사용하여 이러한 동작을 많이 구성할 수 있습니다. 워크로드는 애플리케이션, 네트워크 등 Spanner 외의 다른 구성요소에도 종속됩니다.
이러한 고객 제어 구성은 데이터베이스 부하 및 기타 구성 매개변수에 따라 인스턴스 다운타임의 위험을 증가시킬 수 있습니다.
인스턴스가 비정상 상태가 되고 Google에서 인스턴스가 이 페이지에 설명된 작업 제한을 준수하지 않는다고 판단하는 경우, 결과적으로 발생하는 다운타임에 Spanner SLA가 적용되지 않을 수 있습니다 (또는 계산에 포함되지 않음).
Spanner SLA에서 제외되는 구성
다음 구성은 Spanner SLA에서 제외됩니다.
인스턴스가 구성되고 워크로드가 인스턴스에 과부하를 초래하는 방식으로 사용되는 경우 SLA가 적용되지 않습니다.
자발적인 조치 또는 부작위로 인해 발생하는 인스턴스의 다운타임에는 SLA가 적용되지 않습니다.
Spanner API 또는 Spanner를 만들고 연결하는 데 필요한 기타 Google Cloud API를 사용 중지하면 SLA가 적용되지 않습니다.
프록시 및 방화벽 규칙과 같은 네트워크 구성으로 인해 Spanner API를 사용할 수 없는 것은 SLA에 포함되지 않습니다.
오래되었거나 잘못 구성된 클라이언트로 인한 애플리케이션 사용 불가는 SLA에 포함되지 않습니다. 특히 지원되는 종속 항목이 있는 최신 클라이언트 버전을 사용하고 있는지 확인합니다. 예를 들어 Java 애플리케이션은 Gradle 또는 Maven과 같은 패키지 관리자와 함께 Google의 BOM(자재 명세서)을 사용해야 합니다.
CPU 과부하: CPU 사용률이 지속적으로 높으면 인스턴스의 크기가 워크로드에 맞게 조정되지 않으며 SLA가 적용되지 않을 수 있습니다. Spanner CPU 사용률 권장사항은 장애 조치 이벤트의 오버헤드를 제공하며, 여기서 나머지 컴퓨팅 리소스는 인스턴스의 사용할 수 없는 부분에서 발생하는 트래픽을 수용하는 데 도움이 됩니다. Spanner CPU 사용률 측정항목을 사용하여 CPU 사용률을 모니터링할 수 있습니다.
스토리지가 가득 참: Spanner는 사용한 스토리지에 대해서만 요금을 청구합니다. 하지만 각 노드 또는 컴퓨팅 단위에는 관리할 수 있는 스토리지 양에 한도가 있습니다. 인스턴스의 크기가 노드당 주소 지정 가능 스토리지에 맞게 조정되지 않으면 인스턴스에 SLA가 적용되지 않을 수 있습니다. Spanner 스토리지 사용률 측정항목을 사용하여 스토리지 사용률을 모니터링할 수 있습니다.
할당량 한도: 노드 리소스는 사용자별 할당량에 따라 제한됩니다.
할당량 증가를 미리 요청하지 않으면 컴퓨팅 리소스가 오버로드되어 SLA가 적용되지 않을 수 있습니다. Google의 승인이 필요한 할당량 상향 요청은 일반적으로 하루 이내에 처리됩니다.
프로비저닝되지 않은 세션: Spanner 클라이언트는 gRPC 채널을 사용하여 쿼리 및 관리를 위해 Google Cloud 엔드포인트와 통신합니다. 클라이언트 환경에서 워크로드의 요청 볼륨을 지원할 만큼 충분한 채널을 제공하지 않으면 애플리케이션에서 높은 지연 시간과 낮은 요청 처리량이 발생할 수 있으며 이는 SLA에 포함되지 않을 수 있습니다.
연결 과부하: 쿼리의 트랜잭션 교착 상태, 네트워크 문제, 관리 API의 비율 제한과 같은 일시적인 오류가 발생할 경우 많은 Spanner API를 안전하게 재시도할 수 있습니다. 지나치게 공격적인 재시도는 기존 연결을 압도하여 리소스 소진이나 추가 제한을 유발할 수 있습니다. 지연 시간 증가 또는 처리량 감소는 SLA에 포함되지 않을 수 있습니다. 자세한 내용은 클라이언트 제한 시간 및 재시도 관리를 참고하세요.
하드 디스크 드라이브 (HDD) 오버로드:계층형 스토리지를 사용하면 솔리드 스테이트 드라이브(SSD)와 하드 디스크 드라이브 (HDD)를 혼합하여 Spanner 데이터를 저장할 수 있습니다. HDD 스토리지의 디스크 부하가 100%에 도달하면 Spanner 인스턴스의 지연 시간이 크게 늘어나 SLA가 적용되지 않을 수 있습니다. Spanner 계층화된 스토리지 측정항목을 사용하여 디스크 부하를 모니터링할 수 있습니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-05(UTC)"],[],[],null,["# Spanner operational guidelines\n\nThis page describes some of the user-controlled configurations that can cause an\noutage for a Spanner instance to be excluded from the\nSpanner Service Level Agreement (SLA), which excludes outages\n\"caused by factors outside of Google's reasonable control\". It also provides\nguidelines on how to avoid these configurations.\n\nSpanner manages many aspects of database operations, such as\nsplitting and rebalancing data, replication, failover, and all hardware and\nsoftware updates. You can configure many of these behaviors with built-in\nsettings and administrative APIs. Your workloads also depend on other components\nin addition to Spanner, such as your applications and network.\nThese customer-controlled configurations may increase the risk of instance\ndowntime, depending on your database load and other configuration parameters.\n\nIf your instance becomes unhealthy, and if Google determines that the instance\nis out of compliance with the operational limits described on this page, then\nany resulting downtime may not be covered by (or does not count against) the\nSpanner SLA.\n| **Note:** You're responsible for monitoring your Spanner instances and verifying that they are correctly sized and configured for the type of workloads that you're running.\n\nConfigurations excluded from the Spanner SLA\n--------------------------------------------\n\nThe following configurations are excluded from the Spanner SLA:\n\n- If your instance is configured and used in a way that causes the workload to overload the instance, then it isn't covered by the SLA.\n- Downtime of instances that results from your voluntary actions or inactions isn't covered by the SLA\n- If you disable the [Spanner API](/spanner/docs/getting-started/set-up#set_up_a_project) or other Google Cloud APIs that are required to create and connect to Spanner, then it isn't covered by the SLA.\n- Unavailability of the Spanner API that is the result of your network configuration, such as proxy and firewall rules, isn't covered by the SLA.\n- Application unavailability due to out-of-date or misconfigured [clients](/spanner/docs/reference/libraries) isn't covered by the SLA. In particular, verify that you are using recent client versions with supported dependencies. For example, Java applications should use [Google's BOM](/java/docs/bom) (bill of materials) with a package manager, such as Gradle or Maven.\n\nWe recommend that you set up alerts and monitoring using\n[Cloud Monitoring](/spanner/docs/monitoring-cloud).\n\n### Configurations to avoid\n\nTo maintain Spanner SLA coverage, you must avoid the following\nconfigurations:\n\n- **CPU overload** : If your CPU utilization is consistently high, then your instance isn't properly sized for your workload, and the instance might not be covered by the SLA. Spanner [CPU utilization recommendations](/spanner/docs/compute-capacity#change-compute-capacity) provide overhead for a failover event, where the remaining compute resources help to accommodate traffic from unavailable parts of the instance. You can use Spanner [CPU utilization metrics](/spanner/docs/cpu-utilization) to monitor CPU utilization.\n- **Full storage** : Spanner bills you only for the storage that you use. However, each node, or unit of compute, has a [limit](/spanner/quotas#database-limits) for the amount of storage it can manage. If your instance isn't properly sized for the addressable storage per node, then the instance might not be covered by the SLA. You can use Spanner [storage utilization metrics](/spanner/docs/storage-utilization) to monitor storage utilization.\n- **Quota limit:** Node resources are limited by per-user [quotas](/spanner/quotas). Failure to request quota increases in advance might result in compute resource overload, which might not be covered by the SLA. Quota increase requests that require approval from Google are typically fulfilled within one day.\n- **Under provisioned sessions** : Spanner clients use [gRPC channels](/spanner/docs/sessions#configure_the_number_of_sessions_and_grpc_channels_in_the_pools) to communicate with Google Cloud endpoints for queries and administration. If your client environments don't provide enough channels to support the request volume of a workload, your applications might experience high latency and low request throughput that might not be covered by the SLA.\n- **Connection overload:** Many Spanner APIs can be safely retried in the event of a transient failure, such as a transaction deadlock in a query, a network issue, or rate limits for administrative APIs. Overly aggressive retries might overwhelm existing connections, causing resource exhaustion or additional throttling. The increased latency or reduced throughput might not be covered by the SLA. For more information, see [managing client timeouts and retries](/spanner/docs/custom-timeout-and-retry).\n- **Hard disk drive (HDD) overload:** [Tiered storage](/spanner/docs/tiered-storage) lets you store your Spanner data on a mix of solid-state drives (SSD) and hard disk drives (HDD). If your disk load on HDD storage reaches 100%, your Spanner instance experiences significantly increased latency and might not be covered by the SLA. You can use Spanner [tiered storage metrics](/spanner/docs/monitoring-console#tiered_storage_charts_and_metrics) to monitor disk load.\n\nWhat's next\n-----------\n\n- Learn [best practices for improving Spanner performance and availability using the launch checklist](/spanner/docs/launch-checklist)."]]
