인스턴스 이동

이 페이지에서는 Spanner의 인스턴스를 이동하는 방법을 설명합니다.

Spanner 인스턴스를 모든 인스턴스 구성에서 리전 구성, 이중 리전 구성, 멀티 리전 구성을 포함한 다른 인스턴스 구성으로 이동할 수 있습니다. 인스턴스를 이동해도 다운타임이 발생하지 않으며 Spanner는 이동 중에 strong consistency를 포함한 일반적인 트랜잭션 보장을 계속 제공합니다.

인스턴스를 소스 인스턴스 구성에서 커스텀 인스턴스 구성으로 이동할 수도 있습니다(예: us-west2 읽기 전용 복제본이 있는 nam3 기본 구성). 기존 인스턴스 구성의 토폴로지를 업데이트할 수 없으므로 먼저 원하는 토폴로지가 있는 새 커스텀 인스턴스 구성을 만들어야 합니다. 새 커스텀 인스턴스 구성을 만든 후에는 소스 인스턴스 구성에서 새 커스텀 인스턴스 구성으로 인스턴스를 이동할 수 있습니다.

Spanner 인스턴스를 이동해야 하는 이유

인스턴스를 이전하면 다음과 같은 이점이 있습니다.

가용성 향상: 리전에서 이중 리전 또는 멀티 리전으로 이동을 수행한 후 다운타임 없이 99.999%의 가용성을 확보합니다.
지연 시간 감소: 리전에서 이중 리전 또는 멀티 리전으로 또는 멀티 리전에서 멀티 리전으로 이동을 통해 추가 읽기 전용 복제본으로 지연 시간을 줄이고 지리적 범위를 확장합니다.
비용 절감: 이중 리전 또는 멀티 리전 구성에서 리전 구성으로 전환하여 시간당 비용을 줄입니다.
데이터베이스 같은 위치에 배치: 인스턴스를 보다 최적화된 위치로 이동하여 Spanner 애플리케이션을 클라이언트 애플리케이션과 같은 위치에 배치합니다.

가격 책정

인스턴스를 이동하면 소스 및 대상 인스턴스 구성에 시간당 컴퓨팅 및 스토리지 요금이 적용됩니다. 이동이 완료되면 대상 구성에서 인스턴스 스토리지에 대한 요금이 청구됩니다.

인스턴스를 새 리전, 이중 리전 또는 멀티 리전 인스턴스 구성으로 이동할 경우 아웃바운드 데이터 전송 요금이 청구될 수 있습니다. 자세한 내용은 Spanner 가격 책정을 참조하세요.

제한사항

인스턴스를 이동하려면 최소 1개의 노드(1,000개의 처리 단위)가 있어야 합니다.
프로젝트와 Google Cloud 계정 간에는 인스턴스를 이동할 수 없습니다.
Standard 버전을 사용하는 인스턴스를 리전 인스턴스 구성에서 이중 리전 또는 멀티 리전 인스턴스 구성으로 직접 이동할 수는 없습니다. 먼저 Enterprise Plus 버전으로 인스턴스 버전을 업그레이드한 후에 인스턴스를 이동해야 합니다.
인스턴스 리소스에서 리전 서비스 엔드포인트를 사용하는 활성 요청이 있는 경우 리전 시행에서 리전 간 인스턴스에 대한 액세스를 차단하므로 인스턴스를 이동하면 리전 엔드포인트를 사용하는 모든 요청에 영향을 미칩니다. 전역 엔드포인트를 사용하는 요청은 영향을 받지 않습니다.
Spanner 백업은 인스턴스 구성에 따라 다르며 인스턴스를 이동할 때 포함되지 않습니다. 자세한 내용은 백업을 참조하세요.
인스턴스 이동 중에 다음 API는 사용 중지됩니다.
- InstanceAdmin.DeleteInstance
- InstanceAdmin.UpdateInstance
- DatabaseAdmin.CreateDatabase
- DatabaseAdmin.UpdateDatabaseDdl(요청에 default_leader가 지정된 경우 사용 중지됨)
- DatabaseAdmin.RestoreDatabase
- DatabaseAdmin.CreateBackup
- DatabaseAdmin.CreateBackupSchedule
- DatabaseAdmin.CopyBackup
데이터베이스에 수정된 기본 리더가 있는 경우 대상 인스턴스 구성에서 읽기-쓰기 리전의 이름을 지정하고 해당 구성이 멀티 리전인 경우 선택이 유지됩니다. 대상 구성이 리전이거나 명명된 읽기-쓰기 리전이 없으면 기본 리더 선택이 삭제됩니다.
인스턴스를 이동하면 인스턴스의 인스턴스 구성 속성이 변경됩니다. 자동화를 통해 Spanner 리소스를 관리하는 경우 발생할 수 있는 모든 불일치에 대비하고 해결해야 합니다.
- 예를 들어 Terraform을 사용하여 Spanner 인스턴스와 데이터베이스를 관리하고 terraform apply --auto-approve를 사용 설정하여 리소스를 동기화 상태로 유지하면 인스턴스를 이동할 때 모든 인스턴스와 하위 리소스가 삭제됩니다. 구성을 업데이트하여 삭제 및 데이터 손실을 방지합니다. apply 명령어에 대한 자세한 내용은 Terraform 적용 옵션을 참조하세요.
인스턴스가 이동되는 동안 Spanner 모니터링 측정항목과 차트가 소스 및 대상 인스턴스 구성 모두에 데이터를 표시하거나 하나의 인스턴스 구성에 있는 성능만 반영할 수 있습니다.
오픈소스 자동 확장 처리 도구를 구성한 경우 사용 중지할 필요가 없습니다. InstanceAdmin.UpdateInstance(노드 및 처리 단위 변경에 사용됨)가 사용 중지되었기 때문에 실패합니다.
Spanner 관리형 자동 확장 처리 기능이 사용 설정된 경우 인스턴스를 이동할 수 없습니다. 인스턴스를 이동하려면 관리형 자동 확장 처리를 사용 중지하고 인스턴스를 이동한 다음 관리형 자동 확장 처리를 다시 사용 설정해야 합니다.
- 또한 자동 확장을 사용하는 경우 언급된 최대 권장사항에 따라 최대 CPU 사용량에 맞게 노드를 충분히 프로비저닝한 후 인스턴스를 이동하기 전에 자동 확장을 중지해야 합니다.
Spanner 무료 체험판 인스턴스를 이동할 수 없습니다. 유료 인스턴스로 업그레이드한 후에 인스턴스를 이동할 수 있습니다.

성능에 대한 고려사항

인스턴스가 이동 중일 때에는 읽기-쓰기 지연 시간이 길어지고 트랜잭션 취소율이 높아집니다. 인스턴스 이동은 사용자가 프로비저닝한 예비 CPU를 사용하여 수행되므로 이동 중에 CPU 사용률이 최대 100%까지 증가할 수 있습니다. 그러나 인스턴스를 이동해도 다운타임이 발생하지 않습니다. 인스턴스 이동에 걸리는 시간은 데이터베이스 크기, 노드 수, 이동 종류(예: 리전에서 멀티 리전으로 이동)를 비롯한 다양한 요소에 따라 달라집니다.

인스턴스를 이동한 후 인스턴스 구성의 세부 사항에 따라 인스턴스의 성능이 달라집니다. 예를 들어 이중 리전 및 멀티 리전 구성의 경우 일반적으로 리전 구성보다 쓰기 지연 시간이 더 길고 읽기 지연 시간이 더 짧습니다.

백업

인스턴스를 이동할 때 원래 구성에 있는 백업은 새로운 대상 구성으로 자동으로 이동되지 않습니다. 인스턴스 이동을 시작할 때 원래 구성에 백업이 남아 있으면 인스턴스 이동이 중단됩니다. 인스턴스를 이동하기 전에 백업을 복사하고 데이터 복구 계획을 세우는 것이 중요합니다.

인스턴스의 원래 구성에 유지해야 하는 백업이 있는 경우, 두 개의 소형(100 PU) 임시 인스턴스인 placeholder-source와 placeholder-dest로 백업을 복사하는 것이 좋습니다.

placeholder-source: 이동 중인 인스턴스의 원래 구성과 동일한 인스턴스 구성으로 만든 인스턴스입니다. 이동을 취소해야 하는 경우, 이 인스턴스를 사용해 백업을 원래 구성으로 복원할 수 있습니다.
placeholder-dest: 대상 인스턴스 구성과 동일한 인스턴스 구성으로 만든 인스턴스입니다. 이렇게 하면 인스턴스 이동이 완료된 직후 새 구성에서 즉시 사용할 수 있는 백업을 확보할 수 있습니다.

복원 기능은 구성 간 복원을 지원하지 않으므로, 이러한 자리표시자 인스턴스는 필요한 경우 새 구성에서 빠른 롤백 또는 복구를 수행하기 위해 필수적입니다. 이는 인스턴스 이동 중 문제가 발생할 경우를 대비한 안전망 역할을 합니다.

백업을 placeholder-source 및 placeholder-dest로 복사한 후에는 인스턴스를 이동하기 전에 원래 구성에 있는 기존 백업을 모두 삭제해야 합니다. 그런 다음 인스턴스 이동이 완료되면 이미 대상 구성에 백업 사본이 준비되어 있습니다. 또한 새 백업을 만들 수도 있습니다.

이 방법을 따르면 인스턴스 이동 과정에서 비즈니스 연속성을 보장하고 잠재적인 다운타임이나 데이터 손실을 최소화할 수 있습니다.

인스턴스 이동 방법

gcloud 명령어를 사용하여 Google Cloud 콘솔 Cloud Shell 및 gcloud CLI로 인스턴스를 이동할 수 있습니다.

기본 요건

인스턴스 구성을 이동하기 전에 제한사항 및 성능 고려사항 섹션을 읽었는지 확인합니다. 이어서 다음 단계를 수행합니다.

이동 중인 인스턴스에 대해 spanner.instances.update IAM 권한이 있는지 확인합니다.
해당하는 경우 프로덕션 인스턴스를 이동하기 전에 비프로덕션 인스턴스(예: 테스트 및 스테이징)를 이동하여 인스턴스 이동 중에 워크로드에 미치는 성능 영향을 평가하고 파악할 수 있게 도와줍니다.
Spanner 인스턴스를 이동하면 Data Catalog에서 만든 인스턴스 태그가 이동 프로세스에서 삭제됩니다. 태그를 보존하려면 이동 전에 태그를 내보내고 이동 후에 태그를 가져와야 합니다. 자세한 내용은 태그 내보내기 및 가져오기를 참조하세요.

권장사항의 경우 다음 가이드라인도 준수해야 합니다.

프로덕션 인스턴스를 이동하기 전에 대상 인스턴스 구성의 비프로덕션 인스턴스에서 성능 워크로드를 테스트합니다. 프로덕션 인스턴스를 이동하는 데 걸리는 시간을 확인하기 위해 프로덕션 인스턴스와 유사한 스테이징 인스턴스를 이동할 수 있습니다.
Key Visualizer를 사용하여 데이터베이스에 핫스팟이 없는지 확인합니다.
대상 노드 구성에 예상되는 최대 인스턴스 사용량을 지원하기에 충분한 노드 할당량이 있는지 확인합니다. 자세한 내용은 Spanner 할당량 및 한도를 참조하세요.
이동한 인스턴스 구성에서 인스턴스의 최대 CPU 사용률이 40% 미만이고 노드당 스토리지 양이 1테비바이트(TiB) 미만인지 확인합니다.
이전 중에는 인스턴스를 변경하지 마세요. 여기에는 인스턴스 노드 수 변경, 데이터베이스 스키마 변경, 데이터베이스 만들기 또는 삭제, 백업 만들기 또는 삭제가 포함됩니다.

이러한 권장사항에 따라 인스턴스를 이동하면 일반적으로 24시간 이내에 이동이 완료됩니다. 하지만 애플리케이션 워크로드에 따라 완료 시간이 더 길거나 짧아질 수 있습니다.

인스턴스 이동

Google Cloud 콘솔

Google Cloud 콘솔에서 인스턴스 페이지로 이동합니다.

인스턴스
이동하려는 인스턴스를 선택합니다.
인스턴스 개요 페이지의 구성 옆에 있는 edit 새 구성으로 인스턴스 이동을 클릭합니다.
새 구성으로 데이터베이스 이동 창에서 인스턴스의 새 인스턴스 구성을 선택합니다.
저장을 클릭합니다.

gcloud CLI

gcloud spanner instances move 명령어를 사용하여 인스턴스를 이동합니다.

gcloud spanner instances move INSTANCE_ID \
--target-config=TARGET_CONFIG

다음을 바꿉니다.

INSTANCE_ID: 이동할 인스턴스의 영구 식별자입니다.
TARGET_CONFIG: 인스턴스를 이동할 인스턴스 구성의 영구 식별자입니다. 인스턴스의 새로운 지리적 위치입니다. 리전, 이중 리전 또는 멀티 리전 인스턴스 구성일 수 있습니다(예: nam3, regional-us-central1 또는 custom-nam3-us-west2).

예를 들어 test-instance 인스턴스를 현재 인스턴스 구성에서 nam3으로 이동하려면 다음을 실행합니다.

  gcloud spanner instances move test-instance --target-config=nam3

선택사항: us-west2 리전의 읽기 전용 복제본을 nam3의 기본 인스턴스 구성에 추가하려면 다음을 실행합니다.

기본 구성을 클론하고 새 커스텀 인스턴스 구성 custom-nam3-us-west2에 읽기 전용 복제본을 추가합니다.

gcloud spanner instance-configs create custom-nam3-us-west2 \
--clone-config=nam3 --add-replicas=location=us-west2, type=READ_ONLY

test-instance 인스턴스를 현재 인스턴스 구성에서 이 새로운 custom-nam3-us-west2 인스턴스 구성으로 이동합니다.
```
gcloud spanner instances move test-instance --target-config=custom-nam3-us-west2
```

선택사항: CMEK가 사용 설정된 데이터베이스가 있는 인스턴스 이동

gcloud spanner instances move 명령어를 사용하여 CMEK가 사용 설정된 데이터베이스가 있는 인스턴스를 이동합니다. 명령어에 --target-database-move-configs 플래그와 KMS 키 값을 포함하거나 필요한 KMS 키로 JSON 또는 YAML 파일을 구성해야 합니다.

사용 참고사항:

이동하려는 인스턴스에 CMEK 지원 데이터베이스가 여러 개 있는 경우 각 데이터베이스에 대해 --target-database-move-configs를 지정해야 합니다. 모든 데이터베이스에 동일한 키를 사용할 수 있지만 CMEK 지원 데이터베이스마다 키를 지정해야 합니다.
키는 대상 인스턴스 구성의 모든 리전을 포함해야 합니다. 예를 들어 대상 인스턴스 구성이 nam3에 있는 경우 regional-us-east4, regional-us-east1, regional-us-central1에 키를 설정해야 합니다.
인스턴스를 이동하는 동안 CMEK가 사용 설정되지 않은 데이터베이스의 KMS 키는 설정할 수 없습니다.
인스턴스를 이동하는 동안 소스 또는 대상 인스턴스 구성에서 CMEK 키를 사용 중지하거나 폐기해서는 안 됩니다. 사용 중지하거나 폐기하려고 하면 마이그레이션이 진행되지 않습니다.

gcloud spanner instances move INSTANCE_ID \
  --target-config=TARGET_CONFIG \
  --target-database-move-configs=^:^database-id=DATABASE_ID_1:kms-key-names=KMS_KEY_1[, KMS_KEY_2 ... ] \
  [--target-database-move-configs=^:^database-id=DATABASE_ID_2:kms-key-names=KMS_KEY_1 ... ]

또는

gcloud spanner instances move INSTANCE_ID \
  --target-config=TARGET_CONFIG \
  --target-database-move-configs=CONFIG_FILE_PATH

데이터베이스 ID와 KMS 키로 CONFIG_FILE_PATH 파일을 구성합니다. 다음 구성 파일 예시에는 nam3의 모든 리전을 포함하도록 regional-us-east4, regional-us-east1, regional-us-central1에 동일한 키가 있는 두 데이터베이스 database-1 및 database-2의 KMS 키가 포함되어 있습니다.

[
  {
    database-id: database-1,
    kms-key-names:
      "projects/[your-project]/locations/us-east4/keyRings/[your-keyring]/cryptoKeys/[your-key],projects/[your-project]/locations/us-east1/keyRings/[your-keyring]/cryptoKeys/[your-key],projects/[your-project]/locations/us-central1/keyRings/[your-keyring]/cryptoKeys/[your-key]",
  },
  {
    database-id: database-2,
    kms-key-names:
      "projects/[your-project]/locations/us-east4/keyRings/[your-keyring]/cryptoKeys/[your-key],projects/[your-project]/locations/us-east1/keyRings/[your-keyring]/cryptoKeys/[your-key],projects/[your-project]/locations/us-central1/keyRings/[your-keyring]/cryptoKeys/[your-key]",
  },
]

인스턴스 이동 및 취소 진행 상황을 모니터링하는 방법

gcloud spanner operations describe를 사용하거나 커스텀 Cloud Monitoring 대시보드를 만들어 인스턴스 이동 진행 상황을 모니터링할 수 있습니다.

이동 및 취소 작업 진행 상황 보기

인스턴스 이동 또는 인스턴스 이동 취소 작업의 진행 상황을 추적하려면 gcloud spanner operations describe 명령어를 사용합니다. 이 명령어를 사용하려면 진행 중인 인스턴스 이동 작업의 작업 ID가 필요합니다.

다음을 실행하여 인스턴스 이동 작업의 작업 ID를 가져옵니다.
```
gcloud spanner operations list --instance="INSTANCE_ID"
```
다음을 바꿉니다.
- INSTANCE_ID: 이동할 인스턴스의 영구 식별자입니다.
인스턴스 이동 작업을 비롯한 장기 실행 작업 목록이 출력에 표시됩니다.
gcloud spanner operations describe 명령어를 실행하여 진행 상황 백분율과 상태를 확인합니다.
```
gcloud spanner operations describe OPERATION_ID --instance=INSTANCE_ID
```
다음을 바꿉니다.
- OPERATION_ID: 확인할 인스턴스 이동 작업의 작업 ID입니다.
- INSTANCE_ID: 확인할 인스턴스의 인스턴스 ID입니다.

인스턴스 이동 작업 모니터링

커스텀 Cloud Monitoring 대시보드를 만들어 잠재적인 서비스 영향이 있는 장기 실행 작업인 인스턴스 이동 중에 측정항목을 표시하고 모니터링할 수 있습니다.

대시보드의 총 스토리지 및 데이터베이스별 총 데이터베이스 스토리지 그래프는 이동 진행 상황을 모니터링하는 데 유용합니다. 대상 구성의 스토리지가 증가하는 동안 소스 구성의 스토리지가 점진적으로 감소하는 것을 볼 수 있습니다.

Google Cloud 콘솔

move-instance-dashboard.json 파일을 다운로드합니다. 이 파일에는 Monitoring에서 커스텀 대시보드를 채우는 데 필요한 정보가 있습니다.
Google Cloud 콘솔에서 대시보드 페이지로 이동합니다.
대시보드로 이동

검색창을 사용하여 이 페이지를 찾은 경우 부제목이 Monitoring인 결과를 선택합니다.
대시보드 개요 페이지에서 대시보드 만들기를 클릭합니다.
대시보드 툴바에서 대시보드 설정 드롭다운을 클릭합니다. JSON, JSON 편집기를 차례로 선택합니다.
JSON 편집기 창에서 다운로드한 move-instance-dashboard.json 파일의 콘텐츠를 복사하여 편집기에 붙여넣습니다.
대시보드에 변경사항을 적용하려면 변경사항 적용을 클릭합니다. 이 대시보드를 사용하지 않으려면 대시보드 개요 페이지로 돌아가세요.
대시보드가 생성된 후 필터 추가를 클릭합니다. 그런 다음 project_id 또는 instance_id를 선택하여 인스턴스 이동 진행 상황을 모니터링합니다.

gcloud CLI

move-instance-dashboard.json 파일을 다운로드합니다. 이 파일에는 Monitoring에서 커스텀 대시보드를 채우는 데 필요한 정보가 있습니다.
프로젝트에서 대시보드를 만들려면 gcloud monitoring dashboards create 명령어를 실행합니다.
```
gcloud monitoring dashboards create --config-from-file=move-instance-dashboard.json
```
자세한 내용은 gcloud monitoring dashboards create 참조를 확인하세요.

인스턴스 이동 취소 방법

진행 중인 인스턴스 이동만 취소할 수 있습니다. 이미 완료된 인스턴스 이동을 되돌리려면 새로 시작해야 합니다.

gcloud spanner operations cancel을 사용하면 인스턴스 이동 작업을 취소할 수 있습니다. 취소는 즉시 처리되지 않으며 이동 시작 이후 경과된 시간과 대략 동일한 시간이 걸립니다. 데이터를 소스 인스턴스 구성으로 다시 이동해야 하기 때문입니다.

이 명령어를 사용하려면 진행 중인 인스턴스 이동 작업의 작업 ID가 필요합니다.

다음을 실행하여 작업 ID를 가져옵니다.
```
gcloud spanner operations list --type=INSTANCE --instance="INSTANCE_ID"
--filter="done:False AND metadata.@type:MoveInstanceMetadata
```
다음을 바꿉니다.
- INSTANCE_ID: 이동할 인스턴스의 영구 식별자입니다.
출력에 진행 중인 인스턴스 이동 작업 목록이 표시됩니다.
gcloud spanner operations cancel 명령어를 실행하여 인스턴스 이동을 취소합니다.
```
gcloud spanner operations cancel OPERATION_ID
```
다음을 바꿉니다.
- OPERATION_ID: 취소할 인스턴스 이동 작업의 작업 ID입니다.

다음 단계

Spanner 리전, 이중 리전, 멀티 리전 구성 자세히 알아보기
Google Cloud 리전 및 영역 자세히 알아보기

인스턴스 이동 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

Spanner 인스턴스를 이동해야 하는 이유

가격 책정

제한사항

성능에 대한 고려사항

백업

인스턴스 이동 방법

기본 요건

인스턴스 이동

Google Cloud 콘솔

gcloud CLI

선택사항: CMEK가 사용 설정된 데이터베이스가 있는 인스턴스 이동

인스턴스 이동 및 취소 진행 상황을 모니터링하는 방법

이동 및 취소 작업 진행 상황 보기

인스턴스 이동 작업 모니터링

Google Cloud 콘솔

gcloud CLI

인스턴스 이동 취소 방법

다음 단계

인스턴스 이동