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

---

이 튜토리얼에서는 Spanner용 자동 확장 처리 도구의 인프라를 설정하는 방법을 보여줍니다. 이 튜토리얼에서는 요구사항에 따라 인프라를 설정할 수 있는 두 가지 방법을 보여줍니다.

• 프로젝트별 배포 토폴로지입니다. 자체적으로 자동 확장 처리 구성과 인프라를 관리하려는 개별 팀이 이 토폴로지를 사용하는 것이 좋습니다. 프로젝트별 배포 토폴로지는 자동 확장 처리의 기능을 테스트하기에 좋은 출발점이기도 합니다.
• 중앙 집중식 배포 토폴로지입니다. 자동 확장 처리의 구성요소와 구성을 중앙 위치에서 유지하는 동시에 하나 이상의 Spanner 인스턴스의 구성 및 인프라를 관리하는 팀이 이 토폴로지를 사용하는 것이 좋습니다. 중앙 집중식 토폴로지에서 자동 확장 처리 프로젝트 외에 추가적으로 두 번째 프로젝트를 설정합니다. 이 튜토리얼에서는 이를 애플리케이션 프로젝트라고 합니다. 애플리케이션 프로젝트는 Spanner를 포함한 애플리케이션 리소스를 보관합니다. 이 튜토리얼에서는 이러한 두 프로젝트에 대해 결제 및 API를 별도로 설정하고 사용 설정합니다.

이 문서는 다음 시리즈의 일부입니다.

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

이 시리즈는 운영 오버헤드를 줄이고 Spanner 배포 비용을 최적화하려는 IT, 운영, 사이트 안정성 엔지니어링(SRE) 팀을 대상으로 합니다.

목표

• 프로젝트별 또는 중앙 집중식 배포 토폴로지를 사용하여 자동 확장 처리를 배포합니다.
• 기존 Spanner 인스턴스를 Terraform 상태로 가져옵니다.
• 자동 확장 처리 구성하기

비용

이 문서에서는 비용이 청구될 수 있는 다음과 같은 Google Cloud 구성요소를 사용합니다.

• Cloud Scheduler
• Cloud Functions
• Pub/Sub
• Firestore
• Spanner

프로젝트 사용량을 기준으로 예상 비용을 산출하려면 가격 계산기를 사용하세요. Google Cloud를 처음 사용하는 사용자는 무료 체험판을 사용할 수 있습니다.

이 튜토리얼을 구현할 때 자동 확장 처리 구성요소 작업과 관련된 비용은 0이거나 0에 가깝습니다. 그러나 이 예상 비용에는 Spanner 인스턴스 비용은 포함되지 않습니다. Spanner 인스턴스 비용을 계산하는 방법의 예시는 Spanner 자동 확장을 참조하세요.

이 문서에 설명된 태스크를 완료했으면 만든 리소스를 삭제하여 청구가 계속되는 것을 방지할 수 있습니다. 자세한 내용은 삭제를 참조하세요.

시작하기 전에

1. Google Cloud 콘솔에서 Cloud Shell을 활성화합니다.

   Cloud Shell 활성화

2. Cloud Shell에서 다음 GitHub 저장소를 클론합니다.

   git clone https://github.com/cloudspannerecosystem/autoscaler
   

3. 각 토폴로지의 Terraform 구성 파일이 있는 작업 디렉터리의 변수를 내보냅니다.

   export AUTOSCALER_DIR="$(pwd)/autoscaler/terraform/cloud-functions/per-project"
   

자동 확장 처리 프로젝트 준비

이 섹션에서는 자동 확장 처리 프로젝트 배포를 준비합니다.

1. Google Cloud Console의 프로젝트 선택기 페이지에서 Google Cloud 프로젝트를 선택하거나 만듭니다.

   참고: 이 절차에서 생성한 리소스를 유지하지 않으려면 기존 프로젝트를 선택하지 말고 프로젝트를 새로 만드세요. 작업이 끝나면 프로젝트를 삭제하여 프로젝트와 관련된 모든 리소스를 삭제할 수 있습니다.

   프로젝트 선택기로 이동

2. Google Cloud 프로젝트에 결제가 사용 설정되어 있는지 확인합니다.

3. API Identity and Access Management (IAM), Resource Manager, App Engine Admin, Firestore, Spanner, Pub/Sub, Cloud Functions, Cloud Build, and Cloud Scheduler 사용 설정

   API 사용 설정

4. Cloud Shell에서 자동 확장 처리 프로젝트의 ID로 환경 변수를 설정합니다.

   export PROJECT_ID=INSERT_YOUR_PROJECT_ID
   gcloud config set project "${PROJECT_ID}"
   

5. 자동 확장 처리 인프라의 리전과 영역 및 App Engine 위치(Cloud Scheduler 및 Firestore의 경우)를 설정합니다.

   export REGION=us-central1
   export ZONE=us-central1-c
   export APP_ENGINE_LOCATION=us-central
   

6. 인프라에서 모든 리소스를 만드는 데 사용할 Terraform의 서비스 계정을 만듭니다.

   gcloud iam service-accounts create terraformer --display-name "Terraform service account"
   

7. 서비스 계정에 프로젝트 소유자 역할(roles/owner)을 제공합니다.

   gcloud projects add-iam-policy-binding "${PROJECT_ID}" \
       --member "serviceAccount:terraformer@${PROJECT_ID}.iam.gserviceaccount.com" \
       --role roles/owner
   

8. 서비스 계정 키 파일을 만듭니다.

   gcloud iam service-accounts keys create \
       --iam-account "terraformer@${PROJECT_ID}.iam.gserviceaccount.com" "${AUTOSCALER_DIR}/key.json"
   

9. 프로젝트에 아직 Firestore 인스턴스가 없으면 인스턴스를 하나 만듭니다.

   gcloud app create --region="${APP_ENGINE_LOCATION}"
   gcloud alpha firestore databases create --region="${APP_ENGINE_LOCATION}"
   

애플리케이션 프로젝트 준비

프로젝트별 모드에서 자동 확장 처리를 배포하는 경우 자동 확장 처리 배포로 건너뛸 수 있습니다.

중앙 집중식 배포 토폴로지에서는 자동 확장 처리의 모든 구성요소가 동일한 프로젝트에 있습니다. Spanner 인스턴스는 서로 다른 프로젝트에 있을 수 있습니다.

이 섹션에서는 Spanner 인스턴스가 있는 애플리케이션 프로젝트를 구성합니다. Spanner 인스턴스는 하나 이상의 특정 애플리케이션을 제공합니다. 이 튜토리얼에서 이러한 애플리케이션을 담당하는 팀은 자동 확장 처리 인프라 및 구성을 담당하는 팀과 별개의 팀으로 간주됩니다.

1. Google Cloud Console의 프로젝트 선택기 페이지에서 Google Cloud 프로젝트를 선택하거나 만듭니다.

   참고: 이 절차에서 생성한 리소스를 유지하지 않으려면 기존 프로젝트를 선택하지 말고 프로젝트를 새로 만드세요. 작업이 끝나면 프로젝트를 삭제하여 프로젝트와 관련된 모든 리소스를 삭제할 수 있습니다.

   프로젝트 선택기로 이동

2. Google Cloud 프로젝트에 결제가 사용 설정되어 있는지 확인합니다.

3. Spanner API 사용 설정

   API 사용 설정

4. Cloud Shell에서 환경 변수를 설정합니다.

   export APP_PROJECT_ID=INSERT_YOUR_APP_PROJECT_ID
   

   INSERT_YOUR_APP_PROJECT_ID를 애플리케이션 프로젝트의 ID로 바꿉니다.

5. 생성한 terraformer 서비스 계정에 소유자 역할(roles/owner)을 부여합니다.

   gcloud projects add-iam-policy-binding "${APP_PROJECT_ID}" \
       --member "serviceAccount:terraformer@${PROJECT_ID}.iam.gserviceaccount.com" \
       --role roles/owner
   

   서비스 계정에 이 역할을 부여하면 서비스 계정에서 리소스를 만들 수 있습니다.

6. 해당 Terraform 환경 변수에 애플리케이션 프로젝트 ID를 설정합니다.

   export TF_VAR_app_project_id="${APP_PROJECT_ID}"
   

자동 확장 처리 배포

이 섹션에서는 사전 구성된 Terraform 모듈을 사용하여 자동 확장 처리를 구성하는 구성요소를 배포합니다. 이러한 모듈을 정의하는 Terraform 파일은 다음 디렉터리에 있습니다.

디렉터리	디렉터리 콘텐츠
terraform/	각 배포 옵션과 재사용 가능한 모듈이 포함된 최상위 구성
terraform/cloud-functions/per-project/	프로젝트별 배포 옵션 안내
terraform/modules/autoscaler-functions/	Poller 및 Scaler Cloud Functions 및 Pub/Sub 주제 구성
terraform/modules/scheduler/	폴링을 트리거하는 Cloud Scheduler 구성
terraform/modules/spanner/	Spanner 데이터베이스 구성
terraform/cloud-functions/centralized/	중앙 집중식 배포 옵션 안내

1. Cloud Shell에서 해당 Terraform 환경 변수에 프로젝트 ID, 리전, 영역을 설정합니다.

   export TF_VAR_project_id="${PROJECT_ID}"
   export TF_VAR_region="${REGION}"
   export TF_VAR_zone="${ZONE}"
   

2. 이 단계에서는 자동 확장 처리가 모니터링할 기존 인스턴스를 설정하거나, 새 인스턴스를 만들어 설정합니다.

   기존 Spanner 인스턴스가 있는 경우 다음 변수에서 인스턴스 이름을 설정합니다.

   export TF_VAR_spanner_name=INSERT_YOUR_SPANNER_INSTANCE_NAME
   

   자동 확장 처리를 테스트하기 위해 새 Spanner 인스턴스를 만들려면 다음 변수를 설정합니다.

   export TF_VAR_terraform_spanner=true
   

   Terraform이 만드는 Spanner 인스턴스의 이름은 autoscale-test입니다.

   Terraform을 설정하여 Spanner 인스턴스를 관리하는 방법에 대한 자세한 내용은 Spanner 인스턴스 가져오기를 참조하세요.

3. 작업 디렉터리를 Terraform 프로젝트별 디렉터리로 변경합니다.

   cd "${AUTOSCALER_DIR}"
   terraform init
   

   이 명령어는 Terraform 프로젝트별 디렉터리도 초기화합니다.

4. 기존 App Engine 애플리케이션을 Terraform 상태로 가져옵니다.

   terraform import module.scheduler.google_app_engine_application.app "${PROJECT_ID}"
   

5. 자동 확장 처리 인프라를 만듭니다.

   terraform apply -parallelism=2
   

   Terraform에 만들 리소스 목록이 올바른지 확인하라는 다음 메시지가 표시됩니다.

      Do you want to perform these actions?
      Terraform will perform the actions described above.
      Only 'yes' will be accepted to approve.
      Enter a value:
      

   리소스를 확인한 후 메시지가 표시되면 yes를 입력합니다.

   Cloud Shell에서 이 명령어를 실행하면 다음과 같은 오류 메시지가 표시될 수 있습니다.

   "Error: cannot assign requested address"

   이 오류는 Terraform Google 제공업체의 알려진 문제입니다. 이 경우 terraform apply -parallelism=1. 명령어를 사용하여 다시 시도하세요.

Spanner 인스턴스 가져오기

Terraform에서 관리하기 위해 가져올 기존 Spanner 인스턴스가 있는 경우 이 섹션의 안내를 따르세요. 그렇지 않으면 자동 확장 처리 구성으로 건너뜁니다.

1. Cloud Shell에서 Spanner 인스턴스를 나열합니다.

   gcloud spanner instances list
   

2. 자동 확장할 인스턴스 이름으로 다음 변수를 설정합니다.

   SPANNER_INSTANCE_NAME=YOUR_SPANNER_INSTANCE_NAME
   

3. 빈 google_spanner_instance 리소스가 있는 Terraform 구성 파일을 만듭니다.

   echo "resource \"google_spanner_instance\" \"${SPANNER_INSTANCE_NAME}\" {}" > "${SPANNER_INSTANCE_NAME}.tf"
   

4. Spanner 인스턴스를 Terraform 상태로 가져옵니다.

   terraform import "google_spanner_instance.${SPANNER_INSTANCE_NAME}" "${SPANNER_INSTANCE_NAME}"
   

5. 가져오기가 완료되면 인스턴스의 Terraform 구성 파일을 실제 인스턴스 속성으로 업데이트합니다.

   terraform state show -no-color "google_spanner_instance.${SPANNER_INSTANCE_NAME}" \
       | grep -vE "(id|num_nodes|state|timeouts).*(=|\{)" \
       > "${SPANNER_INSTANCE_NAME}.tf"
   

   가져올 추가 Spanner 인스턴스가 있으면 가져오기 프로세스를 반복합니다.

자동 확장 처리 구성

자동 확장 처리를 배포한 후에는 매개변수를 구성합니다.

1. Google Cloud Console에서 Cloud Scheduler 페이지로 이동합니다.

   Cloud Scheduler로 이동

2. 자동 확장 처리 배포로 만든 poll-main-instance-metrics 작업 옆의 체크박스를 선택합니다.

3. 수정을 클릭합니다.

4. 페이로드 필드에 표시된 자동 확장 처리의 매개변수를 수정합니다.

   다음은 페이로드 예시입니다.

       [
           {
               "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"
           }
       ]
      

   페이로드는 JSON 배열을 사용하여 정의됩니다. 배열의 각 요소는 동일한 자동 확장 처리 작업 일정을 공유하는 Spanner 인스턴스를 나타냅니다.

   매개변수와 해당 기본값에 대한 자세한 내용은 Poller 구성요소 README를 참조하세요.

5. 변경사항을 저장하려면 업데이트를 클릭합니다.

   이제 자동 확장 처리가 구성되어 다음에 예약된 작업 실행에서 인스턴스를 모니터링하고 확장할 수 있습니다.

   JSON 페이로드에 구문 오류가 있으면 Google Cloud Console의 로그 탐색기 페이지에서 tf-poller-function 함수의 로그 항목으로 검사할 수 있습니다.

   로그 탐색기로 이동

   다음은 표시될 수 있는 오류의 예시입니다.

   SyntaxError: Unexpected token errortext in JSON at position 15 JSON.parse

   구문 오류를 방지하려면 JSON의 형식을 다시 지정하고 유효성을 검사할 수 있는 편집기를 사용하세요.

자동 확장 처리 모니터링

이 단계에서는 Poller 및 Scaler Cloud Functions에 대한 모니터링을 설정합니다.

1. Google Cloud 콘솔에서 로그 탐색기 페이지를 엽니다.

   로그 탐색기로 이동

2. 쿼리 미리보기를 클릭하고 다음 필터를 쿼리 빌더에 입력합니다.

   resource.type="cloud_function"
   resource.labels.function_name=~"tf-.*-function"
   

3. 쿼리 실행을 클릭합니다.

   쿼리 결과에서 자동 확장 처리 함수의 모든 메시지를 볼 수 있습니다. 폴러는 2분 단위로만 실행되므로 로그 메시지를 수신하려면 쿼리를 다시 실행해야 할 수 있습니다.

4. Scaler Cloud Functions의 메시지만 보려면 쿼리 미리보기 상자를 클릭하고 쿼리 빌더 텍스트 상자의 이전 필터를 다음과 같이 바꿉니다.

   resource.type="cloud_function"
   resource.labels.function_name="tf-scaler-function"
   

5. 쿼리 실행을 클릭합니다.

   텍스트 페이로드에 적용된 필터로 인해 쿼리 결과에는 확장 제안 및 결정과 관련된 Scaler 함수의 메시지만 표시됩니다.

   필터 쿼리 또는 유사한 필터를 사용하여 로그 기반 측정항목을 만들 수 있습니다. 이러한 측정항목은 자동 확장 이벤트의 빈도 기록과 같은 함수 또는 Cloud Monitoring 차트 및 알림 정책에 유용합니다.

자동 확장 처리 테스트

이 섹션에서는 최소 인스턴스 크기를 변경하고 로그를 모니터링하여 자동 확장 처리 작업을 확인합니다.

테스트 데이터베이스를 사용하여 자동 확장 처리를 배포하면 자동 확장 처리에서 NODES를 컴퓨팅 용량 단위로 사용하도록 구성됩니다. 최소 크기(minSize) 설정을 2로 변경하면 도구 작동 여부를 확인할 수 있습니다. 도구가 예상대로 실행되면 Spanner 인스턴스는 2개의 노드로 확장됩니다. 이 튜토리얼에서 기존 데이터베이스를 사용한 경우 다른 값이 표시될 수 있습니다.

1. Google Cloud Console에서 Cloud Scheduler 페이지로 이동합니다.

   Cloud Scheduler로 이동

2. 자동 확장 처리 배포로 만든 poll-main-instance-metrics 작업 옆의 체크박스를 선택합니다.

3. 수정을 클릭합니다.

4. 작업 페이로드 필드에서 minSize 값을 1에서 2로 변경합니다.

   "minSize": 2
   

5. 변경사항을 저장하려면 업데이트를 클릭합니다.

6. 로그 탐색기 페이지로 이동합니다.

   로그 탐색기 열기

7. 쿼리 미리보기를 클릭하고 다음 필터를 쿼리 빌더에 입력합니다.

   resource.type="cloud_function"
   resource.labels.function_name="tf-scaler-function"
   

8. 쿼리 실행을 클릭합니다.

9. 다음과 같은 로그 메시지가 표시될 때까지 현재 시점으로 이동을 클릭합니다.

   Scaling spanner instance to 2 NODES

10. Spanner가 노드 2개로 수평 확장되었는지 확인하려면 Google Cloud 콘솔에서 Spanner 콘솔 페이지로 이동합니다.

    Spanner로 이동

11. autoscale-test 인스턴스를 클릭합니다.

    개요에서 이제 노드 수가 2인지 확인합니다. 이 빠른 테스트에서는 자동 확장 처리 매개변수를 수정하여 수평 확장 이벤트를 보여줍니다. YCSB와 같은 도구를 사용하여 부하 테스트를 수행하면 사용률을 기준으로 확장 이벤트를 트리거하는 자동 확장 처리를 시뮬레이션할 수 있습니다.

삭제

이 튜토리얼에서 사용된 리소스 비용이 Google Cloud 계정에 청구되지 않도록 하려면 리소스가 포함된 프로젝트를 삭제하거나 프로젝트를 유지하고 개별 리소스를 삭제하세요.

프로젝트 삭제

주의: 프로젝트를 삭제하면 다음과 같은 효과가 발생합니다.

• 프로젝트의 모든 항목이 삭제됩니다. 이 문서의 태스크에 기존 프로젝트를 사용한 경우 프로젝트를 삭제하면 프로젝트에서 수행한 다른 작업도 삭제됩니다.
• 커스텀 프로젝트 ID가 손실됩니다. 이 프로젝트를 만들 때 앞으로 사용할 커스텀 프로젝트 ID를 만들었을 수 있습니다. appspot.com URL과 같이 프로젝트 ID를 사용하는 URL을 보존하려면 전체 프로젝트를 삭제하는 대신 프로젝트 내에서 선택한 리소스만 삭제합니다.

여러 아키텍처, 튜토리얼, 빠른 시작을 살펴보려는 경우 프로젝트를 재사용하면 프로젝트 할당량 한도 초과를 방지할 수 있습니다.

1. Google Cloud 콘솔에서 리소스 관리 페이지로 이동합니다.

   리소스 관리로 이동

2. 프로젝트 목록에서 삭제할 프로젝트를 선택하고 삭제를 클릭합니다.
3. 대화상자에서 프로젝트 ID를 입력한 후 종료를 클릭하여 프로젝트를 삭제합니다.

다음 단계

• 자동 확장 처리 아키텍처 읽어보기
• 배포 모드로 자동 확장 처리 배포 방법에 대해 알아보기
• Spanner 권장 기준에 대해 자세히 알아보기
• Spanner CPU 사용률 측정항목 및 지연 시간 측정항목에 대해 자세히 알아보기
• Spanner 스키마 설계 권장사항에 대해 자세히 알아보기
• Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항을 살펴봅니다. Cloud 아키텍처 센터 살펴보기