자동 확장

이 페이지에서는 자동 확장의 작동 방식을 설명하며 자동 확장이 사용 사례에 적합한지 확인하는 데 도움이 됩니다. 이 페이지를 읽기 전에 Bigtable 개요와 인스턴스, 클러스터, 노드를 숙지해야 합니다.

Bigtable에서 인스턴스는 요청을 처리하는 위치별 리소스인 클러스터의 컨테이너입니다. 각 클러스터에는 데이터를 관리하는 데 사용되는 컴퓨팅 리소스인 노드가 하나 이상 있습니다. 인스턴스에 클러스터를 만들 때 수동 노드 할당 또는 자동 확장을 선택합니다.

수동 노드 할당을 사용하면 클러스터의 노드 수가 변경될 때까지 일정하게 유지됩니다. 자동 확장을 사용 설정하면 Bigtable은 클러스터를 지속적으로 모니터링하고 필요한 경우 클러스터의 노드 수를 자동으로 조정합니다. 자동 확장은 모든 Bigtable 리전의 HDD와 SSD 클러스터 모두에서 작동합니다.

gcloud를 사용하거나 자바용 Cloud Bigtable 클라이언트 라이브러리를 사용하여 Google Cloud Console에서 자동 확장을 구성할 수 있습니다.

자동 확장을 사용해야 하는 경우

자동 확장의 이점은 다음과 같습니다.

비용 - 자동 확장을 사용하면 Bigtable은 가능하면 클러스터의 노드 수를 줄이기 때문에 비용을 최적화하는 데 도움이 될 수 있습니다. 이렇게 하면 초과 프로비저닝을 방지하는 데 도움이 됩니다.
성능 - 자동 확장을 사용하면 워크로드가 변경되거나 데이터 스토리지 요구사항이 증가할 때 Bigtable이 클러스터에 노드를 자동으로 추가할 수 있습니다. 이렇게 하면 클러스터에 대상 CPU 사용률 및 스토리지 요구사항을 충족할 만큼 충분한 노드가 있는지 확인하여 워크로드 성능 목표를 유지할 수 있습니다.
자동화 - 자동 확장을 통해 관리 복잡성이 줄어듭니다. Bigtable 서비스가 자동으로 클러스터 크기를 처리하므로 클러스터 크기를 수동으로 모니터링하고 확장하거나 이러한 작업을 하기 위해 수동으로 애플리케이션을 작성할 필요가 없습니다.

다음과 같은 상황에서 자동 확장을 선택하는 것이 좋습니다.

온라인 쇼핑 서비스에서 생성된 패턴과 같은 안정적인 일일 트래픽 패턴
유기적인 성장을 예상하는 새로운 애플리케이션
Bigtable을 처음 사용하는 워크로드

다음 워크로드 유형에는 자동 확장이 작동하지 않을 수 있습니다. 트래픽 증가 시 Bigtable이 노드를 빠르게 추가하더라도 추가 노드의 균형을 맞추는 데 시간이 걸릴 수 있기 때문입니다.

급증하는 트래픽
갑작스러운 일괄 워크로드

사용량 급증이 예측되거나 정기적으로 예정된 경우 계획된 버스트 전에 자동 확장을 사용하고 설정을 조정할 수 있습니다. 자세한 내용은 노드 재분산 중 지연을 참조하세요.

자동 확장 방식

자동 확장은 노드를 추가하거나 삭제하여 클러스터를 자동으로 확장하거나 크기를 변경하는 프로세스입니다. 자동 확장을 사용 설정하면 Bigtable이 자동으로 클러스터 크기를 조정합니다. 클러스터의 워크로드 또는 스토리지가 변동해야 하는 경우 Bigtable은 클러스터에 노드를 추가하여 확장하거나 클러스터에서 노드를 삭제하여 축소합니다.

Bigtable 자동 확장은 다음 측정기준을 기반으로 필요한 노드 수를 결정합니다.

CPU 사용률 목표
스토리지 사용률 목표
최소 노드 수
최대 노드 수

각 확장 측정기준은 권장 노드 수를 생성하며, Bigtable은 자동으로 가장 높은 노드 수를 사용합니다. 예를 들어 클러스터에 스토리지 사용률 목표를 충족하려면 10개 노드가 필요하지만 CPU 사용률 목표를 달성하려면 12개가 필요한 경우 Bigtable은 클러스터를 12개의 노드로 확장합니다.

노드 수가 변경되면 Bigtable은 노드 간에 데이터를 재균등화하여 지속적으로 스토리지를 최적화하여 트래픽이 고르게 분산되고 노드가 과부하되지 않도록 합니다.

클러스터가 확장된 후 Bigtable은 최적의 성능을 위해 클러스터의 노드를 자동으로 재균등화합니다. 확장과 재분산화가 진행되는 동안 모든 요청은 클러스터에 계속 도달합니다. 자세한 내용은 확장 제한사항을 참조하세요.

클러스터가 최대 노드 수로 확장되고 CPU 사용률 목표를 초과하면 요청이 지연되거나 실패할 수 있습니다. 클러스터가 최대 노드 수로 확장되었고 스토리지 사용률 한도를 초과하면 쓰기 요청이 실패합니다. 스토리지 한도에 대한 자세한 내용은 노드당 스토리지를 참조하세요.

클러스터를 축소할 때는 노드가 확장에 미치는 영향을 방지하기 위해 확장보다 느린 속도로 삭제됩니다. 자세한 내용은 확장 제한사항을 참조하세요.

자동 확장 매개변수

클러스터를 만들거나 수정하고 자동 확장을 선택할 때 CPU 사용률 목표, 최소 노드, 최대 노드 값을 정의합니다. 스토리지 사용률 목표를 구성하거나 기본값인 50%(SSD의 경우 2.5TB, HDD의 경우 8TB)로 유지할 수 있습니다.

매개변수	설명
CPU 사용률 목표	클러스터 CPU 용량의 백분율입니다. 범위는 10~80%입니다. 클러스터의 CPU 사용률이 사용자가 설정한 목표를 초과하면 Bigtable이 즉시 클러스터에 노드를 추가합니다. CPU 사용률이 대상보다 현저히 낮으면 Bigtable에서 노드를 삭제합니다. 자세한 내용은 CPU 사용률 목표 확인을 참조하세요.
최소 노드 수	Bigtable이 클러스터를 축소할 최소 노드 수입니다. 이 값은 0보다 커야 하고 최대 노드 수에 설정한 값의 10% 미만일 수 없습니다. 예를 들어 최대 노드 수가 40개이면 최소 노드 수는 최소 4 이상이어야 합니다. 10% 요구사항은 엄격한 한도입니다. 자세한 내용은 최소 노드 수 결정을 참조하세요.
최대 노드 수	확장할 클러스터의 최대 노드 수입니다. 이 값은 0보다 크고 최소 노드 수보다 크거나 같아야 합니다. 최대 노드 수는 최소 노드 수의 10배 이하여야 합니다. 이러한 10배의 요구사항은 엄격한 한도입니다. 자세한 내용은 최대 노드 수 결정을 참조하세요.
스토리지 사용률 목표	Bigtable이 확장되기 전에 저장할 수 있는 노드당 최대 테라바이트 수입니다. 이 목표를 사용하면 저장하는 데이터 양의 변동을 항상 처리할 수 있는 충분한 노드가 확보됩니다. 자세한 내용은 스토리지 사용률 목표 결정을 참조하세요.

자동 확장 구성

이 섹션에서는 자동 확장 매개변수를 선택하는 방법을 설명합니다. 초기 값을 설정한 후 클러스터를 모니터링하고 필요한 경우 숫자를 조정합니다.

CPU 사용률 목표 결정

고유한 워크로드의 CPU 사용률 목표를 기준으로 합니다. 클러스터에 가장 적합한 목표는 워크로드의 지연 시간과 처리량 요구사항에 따라 다릅니다. 권장사항은 CPU 사용량을 참조하고 높은 처리량과 짧은 지연 시간의 균형을 참조하여 권장 이유를 이해하세요.

일반적으로 허용치 이상의 지연 시간이 관찰되면 CPU 사용률 목표를 낮춰야 합니다.

스토리지 사용률 목표 결정

애플리케이션이 지연 시간에 민감한 경우 스토리지 사용률을 60% 미만으로 유지하세요. 애플리케이션이 지연 시간에 민감하지 않은 경우 스토리지 사용률 목표를 70% 이상으로 선택할 수 있습니다. 자세한 내용은 Bigtable 용량 계획을 참조하세요.

자동 확장의 경우 스토리지 사용률이 백분율이 아닌 노드당 스토리지의 바이트 수로 표시됩니다. 스토리지 사용률 목표는 노드별로 지정되지만 전체 클러스터에 적용됩니다. 노드 용량 한도는 SSD 스토리지의 경우 노드당 5TB, HDD 스토리지의 경우 노드당 16TB입니다.

다음 표는 일반적인 스토리지 사용률 목표 비율의 목표 금액을 보여줍니다. Google Cloud 콘솔은 노드당 TB의 값을 허용하고 gcloud CLI, API, Cloud Bigtable 클라이언트 라이브러리는 노드당 GiB의 정수 값을 허용합니다.

비율	SSD	HDD
80%	4TB 또는 4,096GiB	12.8TB 또는 13,107GiB
70%	3.5TB 또는 3,584GiB	11.2TB 또는 11,468GiB
60%	3TB 또는 3,072GiB	9.6TB 또는 9,830GiB
50%	2.5TB 또는 2,560GiB	8TB 또는 8,192GiB

최대 노드 수 결정

최대 노드 수로 선택하는 값은 대부분의 경우 최대 볼륨에 도달할 것으로 예상되지 않더라도 클러스터가 워크로드의 최대 트래픽을 처리하는 데 필요한 노드 수여야 합니다. Bigtable은 필요한 수보다 많은 노드로 확장하지 않습니다. 이 개수는 비용을 지불할 최대 노드 수로 간주할 수도 있습니다. 허용되는 값에 대한 자세한 내용은 자동 확장 매개변수를 참조하세요.

최대 개수는 사용자가 설정한 CPU 사용률 목표 및 Bigtable이 설정한 스토리지 사용률 목표를 모두 허용해야 합니다.

클러스터를 수동 할당에서 자동 확장으로 변경하는 경우 지난 한 달 동안 클러스터의 최대 노드 수를 찾습니다. 자동 확장 최댓값은 그 이상이어야 합니다.

기존 인스턴스의 새 클러스터에 자동 확장을 사용 설정하는 경우 인스턴스에 있는 다른 클러스터의 측정항목을 지침으로 삼습니다.

새 워크로드가 있으며 어떻게 증가할 지 잘 모르는 경우 기본 제공 스토리지 사용률 목표를 충족해야 하는 노드 수를 추정한 뒤 나중에 값을 조정할 수 있습니다.

이 값을 찾으려면 클러스터에 저장할 데이터 양을 추정한 다음, 사용하는 스토리지 유형의 스토리지 사용률 목표로 이 값을 나눕니다.

예를 들어 SSD 클러스터에 10TB를 저장하면 이 10TB를 자동 확장을 사용하는 SSD 클러스터에 기본적으로 설정된 스토리지 사용률 목표인 2.5TB로 나눕니다. 결과는 4입니다. 즉, 4는 해당 데이터 양을 처리할 수 있는 노드 수이며 최댓값은 이보다 커야 합니다.

동일한 수식을 사용하여 다음 예시는 몇 가지 샘플 스토리지 용량에 필요할 수 있는 노드 수를 보여줍니다.

클러스터당 SSD 스토리지	최소 노드 수
25TB	10
35TB	14
50TB	20

클러스터를 실행 중이고 자동 확장을 사용 설정된 후에는 클러스터를 모니터링하고 최대 노드 수로 선택한 값이 최소한 recommended number of nodes for CPU target 및 recommended number of nodes for storage target 만큼인지 확인합니다.

최소 노드 수 결정

가능한 경우 Bigtable이 가장 작고 비용 효율적인 최소 크기로 축소되도록 최소 값을 1로 설정할 수 있습니다. Bigtable은 CPU 및 스토리지 사용률 목표를 유지하는 데 필요한 최솟값 아래로 노드 수가 떨어지지 않도록 자동으로 조정하므로 클러스터는 너무 작아지지 않습니다. 허용되는 값에 대한 자세한 내용은 자동 확장 매개변수를 참조하세요.

그러나 대부분의 경우 이 값을 2 이상으로 설정해야 합니다. 다음과 같은 경우 더 높은 수를 선택하거나 최소 노드 수를 늘리세요.

사이버 먼데이와 같이 예정된 트래픽 양이 일시적으로 증가할 것으로 예상되며 용량이 충분한지 확인하려 합니다.
애플리케이션이 급증하는 트래픽을 전송합니다. 새 노드가 추가되면 Bigtable이 새 노드로 자동 재균등화합니다. 이 프로세스는 몇 분 정도 걸릴 수 있으므로 클러스터가 급증을 원활하게 수용할 수 있도록 보수적인 접근 방식을 취하고 더 높은 최솟값을 선택하는 것이 더 좋을 수 있습니다.
최대 노드 수를 늘립니다. 최솟값은 항상 최대 노드 수의 10% 이하여야 합니다. 예를 들어 최댓값을 30으로 설정하면 최솟값을 3 이상으로 설정해야 합니다.

클러스터의 최소 노드 수를 늘리면 Bigtable은 즉시 클러스터를 새 최솟값으로 확장하려고 시도합니다. 표준 제약조건이 적용되나, 영역에 노드가 없는 경우 구성된 최소 기준을 충족하도록 추가 노드가 프로비저닝되지 않습니다. Bigtable은 클러스터가 새 최소 노드 수로 성공적으로 확장될 때까지 계속해서 노드 추가를 시도하고 실패한 새 시도마다 감사 로그 항목을 새로 만듭니다. Bigtable은 이러한 상황에서 구성된 값을 변경하지 않습니다. 따라서 확장이 완료될 때까지 클러스터의 노드 수가 최솟값보다 작아질 수 있습니다.

설정 미세 조정

노드 사용량을 주시하고 필요한 경우 설정을 조정하세요(특히 자동 확장을 처음 사용 설정한 후).

복제 계정

복제를 사용하는 인스턴스에서 각 클러스터의 자동 확장 설정 및 활동은 인스턴스의 다른 클러스터에 대한 설정과 완전히 독립적입니다. 인스턴스의 각 클러스터에 확장 모드를 구성해야 합니다.

일반적으로 복제된 인스턴스의 경우 인스턴스의 모든 클러스터에 자동 확장을 사용 설정해야 합니다. 자동 확장 구성은 인스턴스의 모든 클러스터에서 동일한 경우가 많지만 각 클러스터의 사용 사례, 워크로드, 성능 요구사항에 따라 다를 수 있습니다.

복제된 인스턴스의 클러스터는 복제를 관리하기 위한 추가 작업을 수행하므로 단일 클러스터 인스턴스보다 더 높은 최대 노드 수를 선택해야 합니다. 자세한 내용은 복제 및 성능을 참조하세요.

액세스 제어

자동 확장을 구성하려면 구성 중인 클러스터 및 인스턴스에 대해 create 및 update 권한이 있는 역할의 주 구성원이어야 합니다.

모니터링

Bigtable은 Bigtable 자동 확장이 워크로드 요구사항에 맞게 확장 및 축소하면서 작동하는 방식을 이해하는 데 도움이 되는 몇 가지 측정항목을 제공합니다. 또한 측정항목은 설정이 비즈니스 워크로드 및 비용 요구사항을 충족하는 데 최적인지 여부를 판단하는 데 도움이 될 수 있습니다. 예를 들어 클러스터의 노드 수가 최대 노드 수에 가까워지는 경우가 많은 경우 최댓값을 높이는 것이 좋습니다. Bigtable 리소스 모니터링에 대한 자세한 내용은 인스턴스 모니터링을 참조하세요.

다음 측정항목이 Google Cloud 콘솔의 클러스터 개요 페이지에 있는 그래프에 표시됩니다. Cloud Monitoring을 사용하여 이러한 측정항목을 볼 수도 있습니다.

bigtable.googleapis.com/cluster/autoscaling/min_node_count
bigtable.googleapis.com/cluster/autoscaling/max_node_count
bigtable.googleapis.com/cluster/autoscaling/recommended_node_count_for_cpu
bigtable.googleapis.com/cluster/autoscaling/recommended_node_count_for_storage

로깅

Bigtable은 클러스터를 확장할 때마다 시스템 이벤트 감사 로그도 내보냅니다. 로그 항목은 다음과 비슷합니다.

Grew from 9 to 10 nodes to maintain CPU utilization at 60%.

Google Cloud 콘솔의 Bigtable 클러스터 개요 페이지에서 자동 확장 시스템 이벤트 로그를 볼 수 있습니다. 로그 탐색기를 사용하여 로그를 볼 수도 있습니다.

로그 탐색기로 이동합니다.

로그 탐색기로 이동

적합한 Google Cloud 프로젝트를 선택합니다.

쿼리 필드에 다음을 입력합니다.

resource.type="audited_resource" resource.labels.service="bigtableadmin.googleapis.com"
resource.labels.method="AutoscaleCluster"

쿼리 실행을 클릭합니다.

쿼리 결과 창에 지난 1시간 동안의 로그가 표시됩니다.

로그 보기에 대한 자세한 내용은 Cloud Logging을 참조하세요.