이 페이지에서는 Spanner를 사용하여 개념 증명(POC)을 계획하고 실행하기 위한 전략을 제공합니다. 인스턴스 구성, 스키마 설계, 데이터 로드, 성능 평가와 같은 POC의 중요한 측면에 관한 심층적인 참조와 통계를 제공합니다. Spanner의 기능을 평가하는 데 필요한 단계를 강조하고 Spanner 채택과 관련된 잠재적 위험과 이점을 파악하는 데 도움이 됩니다.
POC는 Spanner의 기술적 기능을 검증하는 것 외에도 두 가지 목적을 제공합니다.
- 사용 사례에 Spanner가 제공하는 이점을 이해하는 데 도움이 됩니다.
- Spanner 채택과 관련된 위험을 식별하는 데 도움이 됩니다.
Spanner POC는 다음 다이어그램에 표시된 것처럼 특정 비즈니스 및 기술 목표를 해결하기 위해 맞춤설정된 다양한 평가 측면을 포함합니다.
이 문서의 가이드라인은 이러한 각 영역을 평가하는 데 도움이 됩니다.
성능 및 확장성을 사용하면 Spanner가 특정 워크로드, 지연 시간 요구사항, 다양한 인스턴스 구성의 영향을 처리하는 방식을 이해할 수 있습니다. 이러한 테스트는 Spanner의 원활한 확장 기능을 보여줄 수 있습니다.
모니터링 기능을 사용하면 Spanner가 효과적인 데이터베이스 작업에 필요한 통계를 제공하는지 평가할 수 있습니다. 이 평가에는 다음이 포함됩니다.
- 쿼리 실행 계획 분석 옵션
- 시스템 리소스 사용률
- 알림 구성 옵션
POC를 통해 운영 효율성을 완전히 최적화하기 위해 해결해야 하는 격차를 파악할 수 있습니다.
보안 및 규정 준수는 조직에 Spanner가 적합한지 판단하는 데 중요한 요소입니다. 여기에는 Spanner가 다음과 같은 강력한 규정 준수 이점을 제공하면서 보안 위험을 완화할 수 있는지 확인하는 평가가 포함됩니다.
- 전송 중 및 저장 데이터에 대한 CMEK 또는 EKM과 같은 암호화 옵션
- 최소 권한 액세스 제어 상황
- 감사 로깅
- 규제 요구사항 준수
백업 및 재해 복구(DR) 기능은 운영 및 데이터 복원력을 보장하는 데 필수적입니다. POC를 통해 PITR(point-in-time recovery) 및 가용성과 같은 Spanner의 DR 기능을 검증할 수 있습니다.
마이그레이션 가능성에는 현재 데이터베이스 솔루션에서 Spanner로 전환하는 복잡성을 이해하는 것이 포함됩니다. 스키마 호환성, 마이그레이션 도구, 애플리케이션 변경사항을 평가하면 필요한 투자를 정량화하고 Spanner 도입의 위험과 이점을 파악할 수 있습니다.
평가 중에 Spanner의 기능 집합을 살펴보고 애플리케이션의 기능 요구사항을 충족하는지 확인하는 것이 좋습니다. 여기에는 전역 일관성, SQL 쿼리 기능 또는 다른 Google Cloud 서비스와의 통합 테스트가 포함될 수 있습니다.
평가를 통해 리전 간 일관성과 같은 Spanner의 고유한 강점을 강조할 수 있지만 기존 애플리케이션 아키텍처와의 통합 노력과 같은 잠재적 위험도 드러낼 수 있습니다.
POC 활동 수명 주기
이 POC에서는 다음 단계를 안내합니다. 이 문서의 권장사항에 따라 특정 사용 사례에 맞게 Spanner를 설정하고 평가하세요.
POC 계획하기
성공적인 POC의 기반은 기술적 우선순위와 비즈니스 우선순위 모두에 부합하는 명확하고 측정 가능한 목표를 정의하는 데 있습니다. Spanner의 잠재력 살펴보기와 같은 모호한 목표는 집중되지 않은 노력과 모호한 결과를 초래하는 경우가 많으므로 피하세요. 대신 99.999% 가용성 달성, 다운타임 감소, 트랜잭션 지연 시간을 20ms 미만으로 유지하면서 처리량을 200% 늘리기와 같은 구체적인 목표에 POC 목표를 연결하세요.
Spanner의 고유한 아키텍처는 대규모 확장성이 필요한 워크로드에 적합하므로 사용 사례의 확장성을 평가하는 것이 좋습니다. 테스트 시나리오에는 다음이 포함되어야 합니다.
- 일반적인 운영 부하 처리
- 트래픽 급증 관리
- 효율적으로 축소
이러한 테스트를 통해 다양한 조건에서 Spanner의 성능을 파악하고 확장성 관련 기술 요구사항을 충족하는지 확인할 수 있습니다. 구체적이고 실행 가능한 목표는 POC를 구조화하는 데 도움이 될 뿐만 아니라 성공을 평가하기 위한 확실한 기반을 만듭니다.
정량화된 평가 기준표 정의
명확하고 측정 가능한 측정항목과 개별 성공 기준으로 구성된 평가 기준은 POC가 목표를 달성했는지 결론을 내리는 데 필수적입니다. 예를 들어 실적만 테스트하는 대신 다음과 같은 목표도 지정해야 합니다.
- 특정 프로덕션 수준 QPS(초당 쿼리 수) 제공
- 사전 정의된 최대 부하에서 20ms 미만의 지연 시간 유지
- 성능 저하 없이 명확하게 정의된 트래픽 버스트 처리
잘 정의된 기준을 사용하면 워크로드에 대해 Spanner를 객관적으로 평가하고 다음 단계에 대한 실행 가능한 통계를 얻을 수 있습니다. 읽기 및 쓰기 작업 지연 시간의 백분위수 타겟(예: p50 및 p95)을 구체적으로 정의합니다. 허용 가능한 지연 시간 임계값을 명확하게 정의하면 비즈니스 요구사항에 맞는 Spanner 성능 테스트를 설계하는 데 도움이 됩니다.
평가 기준의 예는 다음과 같습니다.
| 평가 패싯 | 성공 기준 |
| 가용성 | 99.999% |
| 보안 | EKM이 있는 CMEK 필요 |
| 지역 서비스 중단 시 목표 복구 시간(RPO) 보장 | 0 |
| 가장 중요한 트랜잭션의 지연 시간 한도 | p50이 20ms 미만 |
| 가장 중요한 사용자 대상 쿼리의 지연 시간 | p50이 100ms 미만 |
| 확장성 | 1시간 동안 p50 지연 시간 20ms 미만으로 초당 10,000건의 트랜잭션에서 초당 100,000건의 트랜잭션으로 수직 확장이 가능함을 보여줍니다. |
평가 케이스 범위 지정
POC에는 전체 규모의 이전이 필요하지 않습니다. 대신 대표적인 워크로드나 시스템의 중요한 구성요소를 테스트하는 데 집중하세요. 예를 들어 운영에 중요한 주요 쿼리, 중요한 트랜잭션 모양 또는 특정 데이터 기반 워크플로를 식별합니다. 결과가 관련성이 있고 의미가 있도록 하면서 복잡성을 줄이기 위해 범위를 좁힙니다. 이 접근 방식을 사용하면 전체 시스템 이전의 복잡성에 압도되지 않고 Spanner의 기능을 평가할 수 있습니다.
Spanner 인스턴스 구성 선택
평가 목적으로 Spanner 인스턴스를 만들 때는 지리적 위치및 서비스 가용성 SLA에 대한 비즈니스 요구사항을 충족하는 인스턴스 구성을 선택합니다. Spanner는 단일 리전, 멀티 리전, 이중 리전 등 다양한 구성을 제공합니다. 각 구성은 서로 다른 지연 시간, 가용성, 중복 요구사항을 충족하도록 설계되었습니다.
- 단일 리전 구성은 하나의 Google Cloud 리전에 데이터를 저장하여 해당 리전 내에서 짧은 지연 시간과 비용 효율성을 제공합니다. 이러한 토폴로지는 99.99%의 가용성을 제공하는 리전 내 영역 중복이 필요한 워크로드에 적합합니다.
- 이중 리전 구성은 장애 조치를 위해 각 리전에 감시 복제본이 있는 단일 국가의 두 리전에 데이터를 복제합니다. 이 구성은 단일 리전 설정보다 높은 가용성(99.999%)과 내결함성을 제공합니다. 이러한 토폴로지는 엄격한 규정 준수(예: 데이터 상주) 또는 지리적 근접성 요구사항이 있는 워크로드에 적합합니다.
- 멀티 리전 구성은 여러 리전에 데이터를 복제하여 매우 높은 가용성과 리전 서비스 중단에 대한 복원력을 보장합니다. 이러한 토폴로지는 최대 99.999%의 가용성으로 지리적 중복성이 필요한 애플리케이션에 적합합니다.
리전 간 인스턴스의 지연 시간 고려사항
이중 리전 및 멀티 리전 구성에서 Spanner 복제본의 지리적 분포는 지연 시간에 영향을 줄 수 있습니다. 쓰기 지연 시간은 읽기-쓰기 트랜잭션을 조정하는 리더 리전과 각 쓰기 작업을 확인하는 다른 리전의 근접성에 따라 달라집니다. 애플리케이션의 컴퓨팅 리소스를 리더 리전에 가까이 배치하면 왕복 지연이 줄어들고 지연 시간이 최소화됩니다.
애플리케이션의 요구사항에 맞게 데이터베이스의 리더 리전을 수정할 수 있습니다. 읽기 전용 작업의 경우 Spanner는 가장 가까운 복제본에서 비활성 읽기를 제공하여 지연 시간을 줄일 수 있지만, 강력한 읽기에는 리더 리전이 포함되어 작업 지연 시간이 증가할 수 있습니다. 멀티 리전 설정에서 지연 시간을 최적화하려면 리더 리전을 전략적으로 선택하고, 서비스의 컴퓨팅 리소스를 리더 리전과 동일한 위치에 배치하고, 읽기 중심 워크로드에 대해 오래된 읽기를 활용하세요.
애플리케이션의 요구사항을 충족하는 구성
애플리케이션의 인스턴스 구성을 선택할 때는 가용성, 지연 시간, 데이터 상주 요구사항과 같은 요소를 고려하세요. 예를 들어 애플리케이션에서 특정 지리적 영역의 사용자에 대해 지연 시간이 짧은 응답이 필요한 경우 리전 인스턴스로 충분할 수 있습니다. 하지만 더 높은 가용성이 필요하거나 전 세계에 분산된 사용자를 지원하는 애플리케이션의 경우 멀티 리전 구성이 더 적합합니다.
애플리케이션의 프로덕션 요구사항과 거의 일치하는 구성으로 시작하여 성능을 평가합니다. 지연 시간과 비용은 구성에 따라 다르므로 사용 사례의 요구사항을 반영하도록 POC 환경을 조정하세요. 멀티 리전 배포의 경우 지리적 서비스 배포를 시뮬레이션하고 지연 시간을 테스트하여 구성이 프로덕션 요구사항과 일치하는지 확인합니다. 자세한 내용은 Spanner 멀티 리전 리더 배치 가이드를 참고하세요.
Spanner 크기 조정
POC 중에 평가 워크로드를 효과적으로 처리할 수 있도록 Spanner 인스턴스의 초기 컴퓨팅 용량을 프로비저닝합니다. 초기 인스턴스 크기는 예상 워크로드와 일치해야 하며, 읽기 및 쓰기 초당 쿼리 수(QPS), 쿼리 복잡성, 동시 실행 수준을 고려해야 합니다.
합리적인 가정으로 시작하면 기준을 설정하고 관찰된 성능에 따라 점진적으로 확장할 수 있습니다. Spanner의 참조 벤치마크에 나온 크기 조정 안내를 사용하여 기준 인스턴스 구성을 설정할 수 있습니다.
POC 중의 크기 조정은 반복적이어야 합니다. 초기 설정으로 시작한 다음 지연 시간, CPU 사용률과 같은 주요 측정항목을 모니터링하고 필요에 따라 할당된 컴퓨팅 용량을 조정합니다. 이렇게 하면 프로덕션 환경과 유사한 조건을 복제하면서 Spanner의 확장성과 성능 기능을 검증할 수 있습니다.
일관된 트래픽과 변동하는 수요와 같은 일반적인 워크로드 패턴은 크기 조정 접근 방식에 영향을 미쳐야 합니다. 자동 확장을 사용 설정하면 Spanner에서 워크로드 강도에 맞게 컴퓨팅 리소스 용량을 동적으로 프로비저닝합니다.
스키마 설계
스키마 설계는 데이터 구성 방식이 성능과 확장성에 직접적인 영향을 미칠 수 있으므로 Spanner POC의 중요한 측면입니다.
잘 설계된 스키마는 POC에서 Spanner의 기능을 보여주는 데 기초가 됩니다. 부하 테스트는 잠재적인 병목 현상이나 비효율성을 파악하는 데 도움이 되며, 이를 통해 최적의 스키마를 만드는 반복적인 개선을 할 수 있습니다.
확장성을 고려하여 설계하기
Spanner용 데이터베이스 스키마를 만들 때는 분산 아키텍처를 고려해야 합니다. 몇 가지 주요 고려사항과 최적화는 다음과 같습니다.
- 기본 키: 키 공간에 데이터를 균등하게 분산하는 기본 키를 선택합니다. 분할에서 부하 집중을 일으킬 수 있는 타임스탬프와 같이 단조롭게 증가하는 키는 피하세요.
- 색인: 쓰기 성능과 스토리지 비용에 미치는 영향을 고려하면서 쿼리 성능을 최적화하도록 색인을 설계합니다. 색인이 너무 많거나 계획이 잘못되면 불필요한 오버헤드가 발생할 수 있습니다.
- 테이블 인터리브 처리: 테이블 인터리브 처리를 사용하여 관련 데이터의 액세스 패턴을 최적화합니다. 이렇게 하면 교차 프로세스 통신이 줄어들고 쿼리 효율성이 개선될 수 있습니다.
Spanner 스키마 설계 권장사항을 참고하여 일반적인 문제를 방지하고 고성능과 확장성을 지원하는 스키마를 설계하세요.
다음 이미지와 같이 Google Cloud 콘솔에서 초안 스키마를 만들 수 있습니다.
Spanner 마이그레이션 도구를 사용한 스키마 마이그레이션
Spanner 마이그레이션 도구(SMT)를 사용하면 MySQL 또는 PostgreSQL을 비롯한 관계형 데이터베이스에서 마이그레이션할 때 스키마 생성을 간소화할 수 있습니다. SMT는 스키마 생성을 자동화하고 색인 및 스키마 조정 제안과 같은 기본 최적화를 포함합니다. SMT는 강력한 시작점을 제공하지만 스키마를 특정 사용 사례 또는 워크로드 패턴에 맞추려면 수동으로 조정해야 하는 경우가 많습니다.
반복적인 스키마 설계 프로세스 사용
초기 스키마는 시작점을 제공하지만 완벽하지는 않을 수 있습니다. POC의 스키마 생성은 일회성 작업이 아니라 테스트를 통해 통찰력을 얻으면서 발전하는 반복적인 프로세스입니다. 강력한 스키마는 애플리케이션 성능에 필수적입니다. 이를 위해서는 신중하게 고려된 초기 설계를 통해 SMT와 같은 도구를 활용하고 부하 테스트 결과를 기반으로 반복적으로 개선해야 합니다. 이 프로세스를 따르면 스키마가 애플리케이션의 요구사항을 효과적으로 충족할 수 있습니다. 또한 Spanner 기능을 최대한 활용하는 방법도 알아봅니다.
데이터 로드 중
성공적인 Spanner POC는 대표 데이터를 데이터베이스에 로드하여 스키마 설계를 검증하고 애플리케이션 워크플로를 시뮬레이션하는 데 달려 있습니다. 이 프로세스를 간소화할 수 있는 권장 도구가 몇 가지 있습니다. 자체 데이터를 로드하기 위해 Spanner는 다음 옵션을 제공합니다.
- BigQuery의 역방향 추출, 변환, 로드(ETL)를 Spanner에 사용하면 SQL 기반 변환을 사용하여 데이터를 Spanner에 로드할 수 있는 사용하기 쉬운 통합 데이터 로드 메커니즘이 제공됩니다. 이 방법은 JSON과 같은 반구조화된 데이터를 비롯한 다양한 데이터 형식에 적합합니다.
- MySQL 및 PostgreSQL과 같은 관계형 데이터베이스의 경우 Spanner 마이그레이션 도구(SMT)가 스키마 생성, 데이터 유형 매핑, 대량 데이터 로드를 자동화합니다.
- 플랫 파일 형식의 경우 Google에서는 CSV에서 Spanner로, Avro에서 Spanner로의 Dataflow 템플릿을 제공하여 대량 데이터 로드를 위한 수동 스키마 정의를 만듭니다. JDBC 호환 데이터베이스의 경우 Google은 JDBC to Spanner Dataflow 템플릿을 제공합니다.
이러한 옵션에 대한 자세한 내용은 사용자 데이터 사용을 참고하세요.
샘플 데이터를 사용할 수 없는 경우 Machmeter의 JMeter 및 QuickPerf와 같은 합성 데이터 생성 도구를 사용하여 스키마와 사용 사례에 맞게 데이터 세트를 만들 수 있습니다. 자세한 내용은 샘플 데이터 생성을 참고하세요.
자체 데이터 사용
POC에 사용할 수 있는 샘플 데이터가 있는 경우 해당 데이터를 Spanner에 로드하는 방법은 여러 가지가 있습니다.
| 소스 | 도구 | 스키마 생성 | 변환 | 데이터 크기 |
| MySQL | SMT | 자동 | 데이터 유형 변환만 | small |
| PostgreSQL | SMT | 자동 | 데이터 유형 변환만 | small |
| 모든 JDBC | JDBC에서 Spanner로 | 수동 | 데이터 유형 변환만 | large |
| CSV | CSV to Spanner | 수동 | 데이터 유형 변환만 | large |
| BigQuery 역방향 ETL | 수동 | 복잡한 변환 지원 | large | |
| Avro | Avro to Spanner | 수동 | 데이터 유형 변환만 | large |
| BigQuery 역방향 ETL | 수동 | 복잡한 변환 지원 | large | |
| JSON | BigQuery 역방향 ETL | 수동 | 복잡한 변환 지원 | large |
BigQuery에서 Spanner로의 역방향 ETL
BigQuery에서 Spanner로의 역방향 ETL을 사용하면 다양한 데이터 소스를 빠르게 수집하고 SQL을 사용하여 BigQuery 테이블로 변환할 수 있습니다. 그런 다음 BigQuery 테이블에서 Spanner 테이블로 데이터를 내보낼 수 있습니다. 특히 NoSQL 데이터 소스에서 내보내기로 생성되는 경우가 많은 JSON과 같은 반구조화된 데이터에 유용합니다. BigQuery에는 자동 스키마 감지가 있지만 Spanner 스키마 생성은 수동이므로 데이터를 로드하기 전에 스키마를 정의해야 합니다.
Spanner 마이그레이션 도구
POC를 시작하려면 Spanner 마이그레이션 도구(SMT)를 사용하여 MySQL 및 PostgreSQL 소스의 데이터를 Spanner로 마이그레이션하면 됩니다. SMT는 스키마 생성 프로세스를 자동화하여 소스 데이터베이스의 데이터 유형을 Spanner의 해당 유형에 매핑합니다. 또한 Spanner 관련 스키마 최적화 추천도 제공합니다. 따라서 자동 스키마 변환으로 충분한 간단한 이전 작업에 특히 유용합니다.
SMT는 이전 프로세스를 안내하는 사용자 인터페이스를 제공합니다. 이 과정에서 소스 데이터베이스를 선택하고 스키마 설계에 관한 추천 및 옵션을 검토합니다.
Dataflow 템플릿
Dataflow는 확장 가능한 데이터 처리를 위해 설계된 완전 관리형 서비스로, 대량의 데이터를 로드하는 데 적합합니다.
Google은 일반적인 로드 패턴에 대해 다음과 같은 오픈소스 템플릿을 제공합니다.
- CSV to Spanner는 Cloud Storage에 저장된 CSV 파일에서 Spanner로 데이터를 로드합니다.
- Avro to Spanner는 Cloud Storage에서 기존 Avro 데이터 파일을 로드합니다.
- JDBC to Spanner는 JDBC를 지원하는 데이터베이스에서 데이터를 로드합니다.
이러한 각 템플릿에서는 데이터 로드를 시작하기 전에 Spanner 스키마를 수동으로 만들어야 합니다.
Dataflow는 모든 크기의 데이터 세트를 수용하도록 자동으로 확장되므로 테라바이트 규모의 데이터 세트에서도 Spanner로의 고성능 데이터 수집이 보장됩니다. 이 확장성은 다음과 같은 몇 가지 절충을 통해 제공됩니다.
- Dataflow 파이프라인은 최적의 실행을 위해 스키마, 데이터 매핑, 실행 매개변수를 정의하도록 수동으로 구성해야 합니다.
- Dataflow는 대규모 데이터 마이그레이션에 필요한 유연성과 성능을 제공하지만 다른 도구보다 설정 및 관리에 더 많은 노력이 필요할 수 있습니다.
샘플 데이터 생성
샘플 데이터는 없지만 특정 사용 사례가 있는 경우 요구사항에 따라 스키마를 모델링하고 도구를 사용하여 대표 데이터 세트를 생성할 수 있습니다. 이러한 도구를 사용하면 스키마 설계와 애플리케이션 워크플로를 검증하기 위해 의미 있는 데이터로 Spanner를 채울 수 있습니다.
Machmeter의 JMeter
Machmeter의 JMeter는 JMeter를 사용하여 Spanner의 샘플 데이터를 생성하는 예를 제공합니다. 사용 사례 중심 예시에 중점을 두는 Machmeter는 예상되는 프로덕션 스키마와 구조적으로 유사한 데이터 패턴을 생성하기 위한 좋은 시작점입니다. 제공된 예에는 대량 삽입 및 기타 작업을 위한 스크립트가 포함되어 있습니다. 스크립트를 조정하여 대규모로 합성 데이터 세트를 생성할 수 있습니다. 자세한 내용은 Machmeter 저장소 또는 문서를 참고하세요.
QuickPerf
QuickPerf는 Spanner JDBC 드라이버와 함께 배포됩니다. QuickPerf는 스키마 무결성 및 데이터베이스 동작을 테스트하기 위한 대표 데이터 세트를 빠르게 만드는 SQL 기반 스크립트를 제공합니다. 이 방법은 복잡성이 낮은 중소 규모 데이터 세트를 빠르게 생성할 수 있는 간편한 선택입니다.
부하 테스트
부하 테스트를 통해 워크로드를 처리할 때 Spanner 성능을 관찰하여 데이터베이스가 프로덕션 요구사항에 맞게 최적의 구성을 갖추고 있는지 확인할 수 있습니다. 이전에 소개된 두 도구인 Machmeter의 JMeter와 QuickPerf는 워크로드를 시뮬레이션하고 처리량, 지연 시간, 리소스 사용률과 같은 성능 측정항목을 측정하는 데 특히 효과적입니다.
Machmeter 프로젝트를 통해 개선된 Apache JMeter는 Spanner를 사용한 분산 부하 테스트를 위한 강력한 프레임워크를 제공합니다. Machmeter에는 Spanner 워크로드를 시뮬레이션하도록 특별히 설계된 사전 빌드된 JMeter 구성이 포함되어 있습니다. 이러한 구성을 조정하여 대표적인 쿼리, 트랜잭션, 일괄 작업을 실행할 수 있으므로 다양한 시나리오에서 Spanner의 성능을 측정할 수 있습니다.
JMeter는 동시 사용자 및 트랜잭션을 시뮬레이션할 수 있으므로 Spanner 인스턴스의 확장성과 복원력을 테스트하는 데 적합합니다. Kubernetes 또는 관리형 서비스 GKE를 사용하여 분산 모드로 JMeter를 배포하여 테스트 환경을 확장할 수 있습니다. 결과를 통해 Spanner가 특정 워크로드를 관리하고, 수요가 증가할 때 확장하며, 최대 부하 중에 실행되는 방식을 파악할 수 있습니다.
자세한 내용과 구성 예시는 Machmeter 저장소를 참고하세요.
QuickPerf는 Spanner를 사용한 성능 테스트를 위해 설계된 경량 벤치마킹 도구입니다. 최소한의 설정으로 성능 측정항목을 생성하는 데 중점을 두어 최적화를 빠르게 반복할 수 있습니다. QuickPerf는 구성하기 쉽고, 특히 소규모 테스트와 특정 스키마 또는 쿼리 최적화의 성능 영향을 빠르게 측정하려는 시나리오에 적합합니다.
부하 테스트 권장사항
부하 테스트를 실행할 때는 정확하고 실행 가능한 결과를 얻기 위해 Spanner의 권장사항을 따르는 것이 중요합니다.
- 준비 기간: 노드를 확장하거나 새 워크로드를 도입한 후 Spanner가 안정적인 상태에 도달할 수 있도록 준비 기간(일반적으로 30분 이상)을 허용합니다.
- 관련 측정항목 측정: 처리량(초당 작업 수), 지연 시간 백분위수(예: p50, p95), CPU 사용률과 같은 측정항목에 집중하여 Spanner가 워크로드를 처리하는 방식을 파악합니다.
- 긴 벤치마크 실행: 더 대표적인 결과를 얻으려면 리밸런싱 및 백그라운드 유지관리 작업과 같은 시스템 동작을 고려하여 장시간(예: 1시간 이상) 부하 테스트를 실행하세요.
- 확장 테스트: 확장 및 축소 시나리오를 모두 테스트하여 다양한 노드 구성 및 최대 부하에서 Spanner 동작을 관찰합니다.
JMeter Machmeter 및 QuickPerf와 같은 도구와 부하 테스트 권장사항을 사용하여 Spanner의 성능을 효과적으로 평가하고, 병목 현상을 파악하고, 워크로드 요구사항을 충족하도록 데이터베이스를 최적화할 수 있습니다.
모니터링
POC 중에 특히 부하가 걸린 상태에서 Spanner의 성능과 확장성을 효과적으로 보여주려면 Spanner의 운영 특성을 깊이 이해해야 합니다. Spanner는 데이터베이스 성능의 모든 측면에 대한 세부적인 통계를 제공하도록 설계된 포괄적인 모니터링 및 진단 도구 모음을 제공합니다. 이 도구 모음은 측정항목 대시보드부터 세부적인 시스템 테이블까지 다양한 리소스를 제공하여 병목 현상을 식별하고, 설계 선택사항을 검증하고, 성능을 최적화하는 데 도움이 됩니다.
시스템 통계는 Spanner 인스턴스의 성능과 운영 상태에 대한 심층적인 관측 가능성을 제공합니다. 조정 가능한 세부사항 수준에서 CPU 사용률, 지연 시간, 처리량 등 여러 영역에 관한 측정항목과 통계를 제공합니다. POC 중에 테스트 중에 Spanner 동작을 관찰하는 시작점입니다. 시스템 통계를 사용하면 높은 CPU 사용률이나 읽기 또는 쓰기 지연 시간 증가와 같은 성능 병목 현상을 빠르게 식별할 수 있습니다. 이를 통해 후속 조사를 위한 기반이 마련됩니다.
쿼리 통계는 CPU 시간, 실행 횟수, 평균 지연 시간과 같은 측정항목을 기반으로 가장 빈번하고 비용이 많이 드는 쿼리를 식별하는 것부터 시작하여 쿼리 실행에 대한 하향식 보기를 제공합니다. 더 자세히 살펴보면 쿼리 통계를 통해 쿼리의 각 단계에 대한 통계를 비롯한 자세한 실행 계획을 검토하고 속도 저하를 유발하는 특정 작업을 정확히 파악할 수 있습니다. 또한 이전 성능 추세를 조사하고 서로 다른 기간의 쿼리 성능을 비교하는 기능도 제공합니다. 이를 통해 회귀 또는 스키마 및 코드 변경의 영향을 식별할 수 있습니다. 색인 자문과 같은 추가 도구는 쿼리를 분석하여 쿼리 성능을 향상시킬 수 있는 새 색인이나 변경된 색인을 추천합니다.
트랜잭션 통계는 트랜잭션 지연 시간, 커밋 대기 시간, 읽기 및 쓰기된 행 수와 바이트 수, 분산 트랜잭션의 참여자에 관한 자세한 측정항목을 통해 트랜잭션 실적을 파악할 수 있도록 지원합니다. 이러한 측정항목은 지연 시간이 길거나 중단된 트랜잭션을 보여주고 특성에 관한 세부정보를 제공합니다. POC 부하 테스트 중에 트랜잭션 통계는 스트레스를 받고 있는 시스템의 트랜잭션 효율성을 평가하는 데 필수적입니다. 부하가 증가함에 따라 성능 저하를 모니터링하고 식별할 수 있습니다. 개별 트랜잭션을 분석하면 다른 트랜잭션을 차단하는 장기 실행 트랜잭션이나 과도하게 큰 데이터 볼륨을 읽거나 쓰는 단일 트랜잭션과 같은 속도 저하의 원인을 파악할 수 있습니다. 트랜잭션 통계의 정보를 사용하면 트랜잭션 경계 최적화, 트랜잭션 내 쿼리 개선, 일반적인 트랜잭션에 포함된 데이터 양을 줄이기 위한 스키마 조정과 같은 타겟팅된 조정 작업을 실행할 수 있습니다. 이렇게 하면 POC에서 예상되는 부하 수준에서 트랜잭션 일관성과 성능을 유지하는 Spanner의 기능을 보여줄 수 있습니다.
잠금 통계는 트랜잭션 잠금 동작에 대한 가시성을 제공하여 잠금 경합 문제를 식별하고 해결하는 데 도움이 됩니다. 문제를 일으키는 특정 row key 범위를 비롯한 잠금 대기에 관한 정보를 표시합니다. POC 부하 테스트 중에 트랜잭션 잠금 충돌로 인해 확장성 제한이 발생하는지 식별하는 데 잠금 통계가 중요합니다. 동시 로드가 증가하면 트랜잭션이 동일한 데이터를 업데이트하기 위해 경쟁하기 시작하여 대기 시간이 늘어나고 처리량이 줄어들 수 있습니다. 이 정보는 스키마 최적화, 트랜잭션 경계 수정, 애플리케이션 로직 조정에 도움이 됩니다. 이러한 조치를 통해 경합을 완화하고 Spanner 데이터베이스가 예상 워크로드에서 성능을 유지하여 잠금 메커니즘으로 인한 성능 저하를 방지할 수 있습니다.
핫스팟 통계는 부하 집중 조건으로 인해 발생하는 성능 병목 현상(특히 지연 시간 증가)을 식별합니다. 핫스팟은 일반적으로 부하가 높고 불균형할 때 발생합니다. 핫스팟의 원인은 다음과 같은 경우가 많습니다.
- 스키마 설계가 최적이 아님
- 기본 키 선택
- 작업을 노드에 균등하게 분산하는 대신 데이터의 작은 하위 집합에 집중시키는 액세스 패턴
POC 부하 테스트 중에 핫스팟 통계를 사용하면 스키마를 최적화할 위치를 결정할 수 있습니다. 예를 들어 핫스팟을 방지하기 위해 기본 키를 조정하거나 보조 색인을 수정해야 할 수 있습니다.
Key Visualizer는 테이블과 색인의 전체 키 공간에 걸쳐 시간 경과에 따른 데이터베이스 사용 패턴을 시각적으로 나타냅니다. 읽기 및 쓰기 활동을 보여주는 히트맵을 생성하여 강도가 높은 영역과 잠재적으로 문제가 있는 패턴을 강조 표시합니다. POC 중에 이 도구는 스키마 설계를 검증하고 잠재적인 확장성 제한을 식별하는 데 도움이 됩니다. 부하가 증가하면 워크로드가 키 공간과 각 테이블 및 색인에 어떻게 분산되는지 확인할 수 있습니다.
점검 테이블(주로 Spanner_SYS 테이블 시스템)은 데이터베이스의 내부 상태와 성능에 관한 풍부한 정보를 제공합니다. 이러한 테이블은 쿼리 실행, 트랜잭션 동작, 잠금 경합, 스키마 세부정보에 관한 자세한 통계를 노출합니다. POC 부하 테스트 중에 이러한 점검 테이블은 이전에 언급한 통계 도구에서 제공하는 것 이상의 데이터 기반 성능 진단 접근 방식을 제공합니다. 예를 들어 이러한 도구를 사용하여 감지하기 어려운 데이터베이스의 잠금 충돌의 근본 원인을 해결하고 최적화를 위한 실행 가능한 통계를 도출할 수 있습니다.
최적화
부하 테스트는 Spanner 구현에서 성능 문제와 잠재적인 병목 현상을 식별하는 데 중요한 단계입니다. 이러한 테스트에서 얻은 통계를 바탕으로 스키마 설계, 트랜잭션 동작, 쿼리 성능 전반에서 최적화 노력을 기울여 Spanner가 워크로드 요구사항을 충족하도록 해야 합니다.
스키마 설계 최적화
초기 스키마 설계는 확장성과 성능에 관한 권장사항을 기반으로 하지만 실제 조건에서 워크로드를 실행하면 개선이 필요한 영역이 드러나는 경우가 많습니다. 부하 테스트는 특정 조건에서 스키마가 어떻게 작동하는지에 관한 유용한 정보를 제공하여 부하 집중, 불균형한 데이터 분포, 쿼리 성능의 비효율성과 같은 문제를 강조합니다.
최적화는 애플리케이션의 워크로드 특성에 맞게 다음 영역을 미세 조정하는 데 중점을 둡니다.
- 기본 키 조정: 로드 테스트에서 핫스팟이나 불균형한 데이터 분포가 발견되면 기본 키 설계를 검토합니다. 예를 들어 키 접두사에 무작위성을 추가하여 쿼리 효율성을 유지하면서 노드 간에 데이터를 더 균등하게 분산하는 것이 좋습니다.
- 색인 개선: 로드 테스트를 통해 중복 색인 또는 과도한 색인이 쓰기 처리량에 부정적인 영향을 미치는지 확인할 수 있습니다. 불필요한 색인을 삭제하거나 기존 색인을 재구성하여 쿼리 성능을 개선합니다. 색인 선택도를 평가하고 일반적인 쿼리 패턴과 일치하는지 확인합니다.
- 인터리브 처리된 테이블 및 계층 구조: 관련 테이블이 테이블 인터리브를 통해 쿼리 지연 시간을 줄일 수 있는지 분석합니다. 테스트 중에 관찰된 액세스 패턴에 따라 인터리브 처리 결정을 조정합니다. 반대로 계층 구조로 인해 예상치 못한 오버헤드가 발생하는 경우 이러한 테이블을 별도로 모델링하는 것이 좋습니다.
확장 가능한 스키마 빌드에 관한 자세한 내용은 Spanner 스키마 설계 권장사항을 참고하세요.
트랜잭션 시맨틱 및 쿼리 최적화
부하 테스트는 경합이 심하거나 잠금 문제와 같은 트랜잭션 및 쿼리 실행의 비효율성을 강조하는 경우가 많습니다. 트랜잭션 시맨틱스와 쿼리 구조를 최적화하여 처리량을 최대화하고 지연 시간을 최소화합니다.
- 트랜잭션 모드: 각 워크로드 작업에 적합한 트랜잭션 모드를 사용합니다. 예를 들어 데이터를 수정하지 않는 쿼리에는 읽기 전용 트랜잭션을 사용하고, 일괄 업데이트 및 삭제에는 Partitioned DML을 사용합니다.
- 일괄 처리: 가능한 경우 일괄 쓰기 작업을 사용하여 여러 왕복으로 발생하는 오버헤드를 줄입니다.
- 쿼리 최적화: 필요한 열과 행만 포함하도록 쿼리를 리팩터링하고, 색인을 활용하고, 애플리케이션에서 쿼리 매개변수를 사용하여 오버헤드를 줄입니다.
최적화 전략에 대한 자세한 내용은 트랜잭션 개요 및 SQL 권장사항을 참고하세요.
반복적인 부하 테스트
최적화는 반복적인 프로세스입니다. 중요한 스키마 또는 쿼리 변경이 있을 때마다 부하 테스트를 실행하여 개선사항을 검증하고 새로운 병목 현상이 발생하지 않는지 확인합니다.
다양한 수준의 동시 실행, 트랜잭션 유형, 데이터 볼륨으로 실제 애플리케이션 시나리오를 시뮬레이션하여 Spanner가 최대 부하 및 정상 상태 조건에서 예상대로 작동하는지 확인합니다.
모니터링할 주요 측정항목
최적화 중에 지연 시간(p50, p99), 처리량, CPU 사용률과 같은 주요 측정항목을 추적합니다.
다음 단계
- Spanner POC를 계획하고 실행하는 방법을 시청하여 Spanner의 기능을 효과적으로 평가하는 데 필요한 필수 단계, 권장사항, 도구를 알아보세요.