Spanner Omni 라이선스 설치 및 관리

Spanner Omni를 다운로드하여 무료로 사용해 보세요. 프로덕션에 Spanner Omni를 사용하려면 Google에 문의하여 상업용 버전 라이선스 획득에 대해 알아보세요.

이 문서에서는 라이선스 키를 저장하고 처리하는 방법, 배포에 설치하는 방법, 만료되는 키를 업데이트하는 방법, 모든 노드에서 설치를 확인하는 방법을 설명합니다.

프로덕션 환경을 실행하려면 상업용 Spanner Omni 라이선스 키를 설치해야 합니다. 비프로덕션 환경에서는 라이선스 키 없이 vCPU가 4개 이하인 단일 서버 구성으로 Spanner Omni를 배포하여 백업 및 복원 기능을 사용할 수 있습니다. 사용되는 서버 또는 vCPU 수와 관계없이 기본 또는 개발자 라이선스에서는 작업자 기능이 지원되지 않습니다. 작업자를 사용하기 위한 상업용 라이선스를 구매하려면 Google에 문의하세요.

사용 가능한 라이선스 유형, 버전, 기능에 대해 알아보려면 Spanner Omni 버전 개요를 참고하세요.

라이선스 키 저장

Spanner Omni 라이선스 키는 매우 민감한 사용자 인증 정보로 취급하세요. 누군가 라이선스 키를 유출하면 Google은 향후 Spanner Omni 출시에서 이를 무효화합니다. 키 노출을 방지하려면 다음 수명 주기 가이드라인을 구현하세요. 일반 텍스트로 영구 스토리지에 키를 쓰는 대신 자동화 시스템을 사용하여 키를 삽입하는 것이 좋습니다. 다음 섹션에서는 라이선스 키를 저장하고, 자동 배포 파일을 보호하고, 런타임 전송을 구성하는 방법을 설명합니다.

중앙 보안 비밀 관리자에 저장

라이선스 키를 소스 제어에 커밋하거나 구성 파일에 하드코딩하지 마세요. 항상 다음과 같은 중앙 집중식 사용자 인증 정보 저장소에 키를 저장하세요.

• 클라우드: Google Cloud Secret Manager, Amazon Web Services (AWS) Secrets Manager 또는 Microsoft의 Azure Key Vault
• 플랫폼에 구애받지 않음: HashiCorp Vault

배포 자동화

Terraform 또는 Ansible과 같은 자동화 도구를 통해 배포할 때는 라이선스 키를 일반 텍스트 구성 변수로 전달하지 마세요.

• Terraform: 데이터 소스를 사용하여 배포 런타임에 라이선스 키를 동적으로 가져옵니다. sensitive = true 속성을 사용하여 변수를 표시하면 실행 콘솔 로그에 키가 표시되지 않습니다.
• Ansible: 비밀 관리자 플러그인 (예: google.cloud.gcp_secret_manager 또는 community.hashicorp.vault)을 통해 구성 실행 중에 메모리에 키를 유지하거나 저장소에 저장된 경우 Ansible Vault로 키를 암호화합니다.

런타임에 라이선스 키 전송

승인되지 않은 사용자에게 노출하지 않고 라이선스 키를 데이터베이스 프로세스에 전달하려면 다음 기법을 사용하세요.

VM 기반 배포 (클라우드 또는 온프레미스)

• Identity and Access Management (IAM) 기반 삽입: 데이터베이스 VM을 관리형 서비스 계정 또는 IAM 역할과 연결합니다. 시작 또는 프로비저닝 (예: Ansible 사용) 중에 이 ID를 사용하여 제한된 액세스 권한이 있는 메모리 또는 디렉터리에서 라이선스 키를 보안 비밀 관리자로부터 가져옵니다.
• 운영체제 권한: 디스크에 키를 쓰는 경우 Spanner Omni 프로세스를 실행하는 사용자만 파일을 볼 수 있도록 파일 액세스를 제한합니다 (예: chmod 400 /path/to/license). 호스트 머신에 대한 SSH 액세스를 심각하게 제한합니다.

Kubernetes 배포

• Secrets Store CSI 드라이버 사용: 표준 Secrets Store CSI 드라이버를 사용하여 외부 보안 비밀 관리자에서 Spanner Omni 포드로 라이선스 키를 임시 메모리 볼륨 (tmpfs)으로 직접 마운트합니다. 사용자 인증 정보는 메모리에만 존재하며 포드가 종료되면 사라집니다.
• 기본 제공 Kubernetes 보안 비밀 방지: base64 인코딩만 사용하고 etcd에 유지되는 기본 제공 Kubernetes 보안 비밀을 사용하지 마세요.

라이선스 키 설치

라이선스 키를 설치하거나 업데이트하려면 Spanner Omni 서버가 로컬 경로 (예: /path/to/your/license)로 키에 액세스할 수 있도록 합니다.

라이선스 키의 경로를 서버에 전달하려면 spanner start 또는 spanner start-single-server 명령어를 실행할 때 --license-file-path 플래그 또는 SPANNER_LICENSE_FILE_PATH 환경 변수를 사용합니다.

예를 들면 다음과 같습니다.

spanner start --root \
  --license-file-path=LICENSE_KEY_FILE_PATH \
  --server-address=RESOLVABLE_HOSTNAME \
  --zone=ZONE_NAME \
  --base-dir=SPANNER_BASE_DIR

또는 환경 변수를 사용하여 라이선스 경로를 제공합니다.

SPANNER_LICENSE_FILE_PATH=LICENSE_KEY_FILE_PATH \
  spanner start --root \
    --server-address=RESOLVABLE_HOSTNAME \
    --zone=ZONE_NAME \
    --base-dir=SPANNER_BASE_DIR

다음을 바꿉니다.

• LICENSE_KEY_FILE_PATH: 라이선스 키 파일의 로컬 경로입니다.
• RESOLVABLE_HOSTNAME: 확인 가능한 노드 서버의 호스트 이름 또는 IP 주소입니다.
• ZONE_NAME: 배포의 영역 이름입니다.
• SPANNER_BASE_DIR: 서버 파일이 저장된 기본 디렉터리입니다.

또는 서버에서 예상하는 경로(BASE_DIR/license/license)에 라이선스 키를 배치할 수 있습니다. Kubernetes 배포의 경우 BASE_DIR은 기본적으로 /spanner로 설정됩니다.

만료가 임박한 라이선스 업데이트

활성 배포에서 만료되는 개발자 버전 라이선스를 업데이트, 연장 또는 갱신하려면 영구 라이선스를 요청하세요. 만료되는 개념 증명 라이선스를 연장하거나 상업용 라이선스를 구매하려면 Google에 문의하세요. 새 라이선스를 받은 후 경로를 제공하고 Spanner Omni 서버의 순차적 다시 시작을 시작합니다.

1. 각 노드에서 새 라이선스 파일에 액세스할 수 있도록 합니다.
2. 한 번에 하나의 서버 노드를 다시 시작하여 순차적 재시작을 실행합니다.
3. 출시 중에 배포 상태를 모니터링합니다. 노드가 다시 시작되지 않거나 오류가 발생하면 이전에 작동했던 구성으로 롤백하고 서버 로그를 검사하여 새 라이선스가 올바르게 제공되었는지 확인합니다.

Helm (Kubernetes)을 사용하여 라이선스 키 설치

Google 제공 Helm 차트를 사용하여 배포하는 경우 업그레이드 중에 라이선스 파일의 경로를 동적으로 전달할 수 있습니다.

Helm의 --set-file 플래그에는 디스크의 실제 경로가 필요하므로 라이선스 키를 영구 파일에 저장하지 마세요. 대신 보안 비밀 관리자에서 키를 가져와 임시 파일이나 인메모리 경로 (예: Linux의 /dev/shm)에 저장합니다. 이 경로를 Helm에 전달하고 나중에 파일을 즉시 삭제하거나 파기합니다. 이렇게 하면 시스템이 일반 텍스트 사용자 인증 정보를 디스크에 남기지 않으므로 로컬에 유지되거나 실수로 버전 제어에 커밋되는 것을 방지할 수 있습니다.

helm upgrade --install spanner-omni \
  --set-file licenseKey=LICENSE_KEY_FILE_PATH

다음을 바꿉니다.

• LICENSE_KEY_FILE_PATH: 라이선스 키 파일의 로컬 경로입니다.

라이선스 설치 확인

클러스터의 모든 활성 서버 노드에 라이선스 키를 설치하므로 요청을 처리하는 서버 노드 중 하나의 상태를 검사하여 설치를 확인할 수 있습니다. 엔드포인트에 describe 명령어를 사용합니다.

spanner deployment describe --deployment-endpoint=SERVER_ADDRESS

다음을 바꿉니다.

• SERVER_ADDRESS: 서버 노드의 주소입니다.

클러스터 전체 감사 실행

VM 클러스터 또는 Kubernetes StatefulSet의 모든 노드에 올바른 라이선스 키가 설치되어 있는지 확인하려면 클러스터 전체 감사 명령어를 실행하세요.

spanner admin license check

클러스터 전체 감사는 데이터베이스 토폴로지의 모든 서버를 검사합니다. 따라서 이 명령어를 실행하기 전에 모든 노드 서버가 온라인 상태이고 네트워크에서 액세스할 수 있는지 확인하세요.

감사 결과 해석

다음 표를 사용하여 클러스터 전체 감사의 결과를 파악하세요.

클러스터 상태	출력 유형	설명 및 필요한 조치
균일 (예상)	단일 라이선스 식별자	모든 노드가 동일한 라이선스 키와 유형을 사용하고 있습니다. 추가 조치는 필요하지 않습니다.
혼합 (조치 필요)	라이선스 식별자 및 서버 목록	노드 간에 다른 라이선스 키가 감지됩니다 (예: 중단된 순차 업데이트 중). 나열된 노드를 조사하여 새 라이선스 파일이 올바르게 적용되었는지 확인합니다.

상업용 라이선스 규정 준수 유지

Spanner Omni 상업용 라이선스를 사용하는 경우 라이선스 계약을 준수해야 합니다. 규정 준수를 유지하면 결제 분쟁을 방지하고 클러스터 리소스 사용량을 추적하여 Google에 보고할 수 있습니다. Spanner Omni 상업용 라이선스 계약을 준수하려면 다음 단계를 완료하세요.

1. 각 결제 주기 말에 Spanner Omni Usage Tool을 실행하여 클러스터 vCPU 사용량 측정항목을 수집합니다.

   spanner admin license report --row-format=CSV
   

2. 기술계정 관리자 (TAM) 또는 Google 계정팀과 협력하여 조직의 기본 제출 채널을 확인합니다.

3. 결과 페이로드를 다음 달 5일까지 Google에 제출합니다.

다음 단계

• VM에 배포 만들기
• Kubernetes에 배포 만들기
• CLI 빠른 시작