콘텐츠로 이동하기
데이터베이스

[개발자를 위한 Spanner 시리즈] 성능 분석 및 측정 방법 알아보기

2022년 2월 4일
https://storage.googleapis.com/gweb-cloudblog-publish/images/cloud_spanner.max-2600x2600.jpg
Google Cloud Korea Team

Cloud Spanner는 일관성과 대규모 가용성을 위해 설계된 분산 관계형 데이터베이스입니다. Google의 가장 잘 알려진 제품과 마찬가지로 금융 서비스, 소매, 게임 및 기타 여러 산업 분야의 조직에서도 가장 까다로운 "비즈니스 운영" 워크로드에 Spanner를 사용합니다. 이러한 애플리케이션을 실행하는 개발 및 운영(DevOps) 팀은 Spanner가 컴퓨팅 및 스토리지 리소스를 사용하여 사용량을 조정하고 스키마 및 쿼리를 최적화하는 방법을 이해해야 합니다. 

Spanner의 사용 패턴을 분석하는 새로운 대화형 모니터링 도구인 Key Visualizer는 모든 규모의 데이터베이스에 대한 중요한 성능 및 리소스 메트릭의 추세와 이상값을 보여줍니다. 성능 튜닝 및 인스턴스 크기 조정을 위해 설계된 현재 웹 기반 Cloud Console에서 모든 Spanner 데이터베이스에 대해 추가 비용 없이 Key Visualizer를 사용할 수 있습니다. 

또한 추가적으로 성능 테스트를 위해 JMeter 활용할 수 있습니다. 애플리케이션 코드 변경과 데이터 마이그레이션을 실행하기 전에 Cloud Spanner에서 커스텀 워크로드에 대한 성능 테스트에 활용할 수 있습니다. JMeter를 활용하는 방법에 대해 뒤에서 간략히 소개 하겠습니다.


확장성과 가용성을 위한 데이터 분할

대부분의 분산 시스템과 마찬가지로 Spanner는 단일 리전 또는 멀티 리전에 있는 여러 머신에 걸쳐 데이터와 처리를 분할합니다. 일반적인 수직 확장 데이터베이스와 달리 Spanner는 파티션을 자동으로 관리하여 불편한 수동 샤딩 없이 수평 확장합니다. 테이블을 더 작은 범위의 행 또는 Split으로 동적으로 분할하고 이러한 Split을 격리된 인프라 전체에 복제함으로써 Spanner는 최대 99.999%의 가용성을 제공하며 이는 모든 확장형 관계형 데이터베이스 중 가장 높습니다.

행의 분할은 행의 기본 키에 따라 결정됩니다. 올바른 키를 선택하면 Spanner가 데이터를 고르게 분배하고 처리하여 데이터 액세스를 위한 I/O 경합 또는 쿼리 실행을 위한 CPU와 같은 리소스에 대해 경합하는 핫스팟을 방지할 수 있습니다. 데이터베이스의 키 영역에서 리소스가 사용되는 방식을 이해하면 데이터와 이에 접근하는 워크로드에 대한 패턴를 알수 있게 되고, 사이징 및 프로비저닝에 대한 통찰력을 얻을 수 있습니다.


사용 패턴 이해하기

아래 스크린샷은 작동 중인 Key Visualizer를 보여줍니다.

https://storage.googleapis.com/gweb-cloudblog-publish/images/Screen_Shot_2022-02-04_at_2.18.16_PM.max-700x700.png

Key Visualizer는 세 가지 차원으로 리소스 및 성능 메트릭을 표시합니다.

  1. 타임은 X축을 따라 표시됩니다. 상기 그래픽에서 시간 단위로 표시 되어 있습니다
  2. 키 영역은 Y축에 있습니다. 현재 데이터베이스의 모든 테이블과 인덱스에 있는 모든 행은 최대 1,000개의 정렬된 행 범위로 나뉩니다. 범위는 테이블 또는 인덱스별로 계층적으로 표시됩니다.
  3. Key Visualizer는 Write가 수행된 바이트와 같은 메트릭의 집계 값을 시간과 행의 범위가 교차하는 지점에 표시합니다. Key Visualizer는 단순히 숫자를 표시하는 대신 색상 스펙트럼에 따라 낮은 값에서 높은 값까지 해당 메트릭에 대한 값의 범위를 나타냅니다. 값이 낮아 "Cold"인 경우 진한 파란색과 자주색으로 표시되고 "Hot"인 값은 노란색과 흰색으로 표시됩니다. 값의 범위와 이에 따른 색상은 히트맵 위에 표시됩니다.

이 간편한 디스플레이를 통해 수만 개의 개별 측정값에 대한 추세와 이상값을 빠르게 파악할 수 있습니다. 예를 들어, 위의 히트맵에는 SingerByDescSingerID 인덱스의 높은 읽기 트래픽이 대각선 패턴으로 나타나  있습니다. 쿼리 통계에 표시되는 대기 시간이 긴 쿼리에 대한 실행 계획과 이를 상호 참조하면 병목을 찾는데 도움이 될 수 있습니다.

더 자세한 분석을 위해 자르기 도구를 사용하여 이동 및 확대/축소를 하며 히트맵의 특정 영역에 집중할 수 있습니다. 측정값 위로 마우스를 가져가면 해당 값과 기타 세부 정보가 표시됩니다.


이용 가능 메트릭

Key Visualizer는 각 행의 범위 및 시간 윈도우를 6가지 다른 메트릭으로 자동으로 집계합니다. 이러한 집계는 시간 및 키 공간에 대한 상대 값을 비교하기 위해 각 행 범위에 있는 행의 수로 정규화됩니다. 왼쪽 상단의 드롭다운에서 표시할 측정항목을 선택할 수 있습니다.

  • CPU seconds: 특정 범위의 행을 읽거나 쓰는 데 소요된 대략적인 총 시간
  • Logical bytes stored: 아직 정리되지 않은 여러 버전의 업데이트된 데이터를 포함하는 총 사용된 유효 스토리지 용량
  • Number of rows read: SQL 쿼리 또는 Spanner의 읽기 API에서 액세스한 행의 수
  • Number of bytes read: 읽은 행의 총 크기
  • Number of rows written: SQL DML 또는 Spanner의 변형 API를 사용하여 업데이트된 행의 수
  • Number of bytes written: Write된 행의 총 크기


핫스팟 디버깅 하기

Key Visualizer의 핵심 이점은 바로 핫스팟을 정확히 찾아내는 기능입니다. 핫스팟은 소수 범위의 행들이 과도한 양의 리소스를 사용하여 다른 활동을 고갈시키는 병목 현상을 말합니다. 핫스팟은 히트맵에서 밝은 수평선 또는 대각선 영역으로 표시됩니다. 히트맵의 밝은 영역은 핫스팟을 나타낼 수 있지만 안정적인 운영 데이터베이스의 경우 일반적으로 가끔 밝은 줄무늬를 포함하는 밝은 부분과 어두운 부분이 잘 분산되어 있습니다. 제품 문서에서 핫스팟을 더 자세히 다루며, 여기서는 Key Visualizer에서 발생할 수 있는 패턴 유형에 대해 간략히 보여 줍니다. 예를 들어, 다음은 다른 범위보다 지속적으로 액세스가 많은 두 개의 개별 행 범위를 보여줍니다.

https://storage.googleapis.com/gweb-cloudblog-publish/images/Screen_Shot_2022-02-04_at_2.21.05_PM.max-300x300.png

또한 핫스팟은 종종 간헐적으로 나타나기도 합니다. 다음 예를 보세요:

https://storage.googleapis.com/gweb-cloudblog-publish/images/Screen_Shot_2022-02-04_at_2.22.02_PM.max-300x300.png

상기 패턴의 경우 두 개의 행 범위에 집중된 활동의 갑작스러운 발생을 나타냅니다. 이는 악성 쿼리를 일으키는 애플리케이션 버그나, 키가 배포되는 방식에 영향을 미치는 스키마 변경 또는 새로운 트래픽 패턴의 표시일 수 있습니다.

그러나 가장 일반적인 것은 시간이 지남에 따라 행 범위가 대각선 또는 삼각형인 패턴입니다.

https://storage.googleapis.com/gweb-cloudblog-publish/images/Screen_Shot_2022-02-04_at_2.23.04_PM.max-300x300.png

대각선은 데이터가 키에 의해 순차적으로 액세스됨을 나타냅니다. 이는 전체 테이블 스캔과 같은 작업을 수행하는 대량 Export 또는 숫자 시퀀스를 사용하여 다음 키를 결정하는 Insert의 결과일 수 있습니다. 분산 인프라에 대한 일관성과 씨름할 필요가 없는 일반적인 단일 인스턴스 데이터베이스의 경우 흔하지만 순서가 지정된 키를 사용하는 것은 보통 Spanner에서는 안티패턴 입니다. Spanner는 키를 사용하여 데이터를 분할하기 때문에 키가 연속적으로 포함된 행을 삽입하거나 업데이트하면 종종 리소스 경합이 발생합니다. 가장 좋은 방법은 UUID와 같이 잘 분산된 합성 기본 키를 사용하고 필요한 경우 주문 번호나 사용자 이름과 같은 일반 키를 별도의 열에 유지하는 것입니다. 애플리케이션에서 자주 필터링하거나 조인하는 경우 일반 키를 인덱싱할 수 있습니다.

참고로 다음은 히트맵이 어둡고 밝은 색상의 세밀한 혼합을 표시되며 읽기 및 쓰기가 데이터베이스 전체에 고르게 분포 되어 있는 것을 나타냅니다. 이 히트맵은 Cloud Spanner의 효과적인 사용 패턴을 나타내며, 아무런 조치를 취할 필요가 없습니다.

https://storage.googleapis.com/gweb-cloudblog-publish/images/Screen_Shot_2022-02-04_at_2.24.11_PM.max-300x300.png

Key Visualizer는 관리자와 개발자가 애플리케이션이 Spanner와 상호 작용하는 방식을 더 잘 이해하기 위해 사용할 수 있는 도구입니다. Spanner의 기존 검사모니터링 기능을 보완하며 성능 최적화 및 리소스 관리를 단순화합니다.


JMeter로 성능 테스트 하기

Writing Tests

JMeter는 애플리케이션과 마찬가지로 Cloud Spanner와 상호 작용하며, 동일한 방식으로 DML 작업을 수행합니다. 따라서 테스트는 트랜잭션과 같은 운영의 패턴을 시뮬레이션을 해야 합니다. 예를 들어 트랜잭션이 여러 테이블에 대한 입력 또는 업데이트 문으로 구성된 경우 JMeter는 이와 같은 것들을 재현 해야 합니다.

JMeter에는 다음과 같은 계층 구조가 있습니다.

Test Plan > Thread Group(s) > Sampler(s) (aka test)

Test Plan은 최상위 구성 요소입니다. 여기에는 전역 속성과 라이브러리(예: jdbc 드라이버 등)가 포함될 수 있습니다.

Thread Group은 데이터베이스 트랜잭션을 나타냅니다. 여기에는 하나 이상의 Sampler가 포함되며,Thread Group 내의 모든 Sampler는 직렬로 실행됩니다.

Sampler는 단일 DML 호출을 나타내야 합니다. 만약 트랜잭션에 여러 DML 호출이 필요한 경우 여러 Sampler를 만들어야 합니다. 일반적으로 데이터베이스 호출에 JDBC Sampler를 사용합니다. Mutation 또는 병렬 읽기 등을 사용해야 하는 경우 여기에 설명된 대로 JSR 223 Sampler를 사용할 수도 있습니다. 또한 실제 애플리케이션에서와 같이 한 Sampler의 결과를 다음 Sampler로 전달할 수 있습니다.


테스트 수행 및 결과 수집하기

JMeter 테스트는 네트워크 지연 시간을 최소화하기 위해 가능한 한 Cloud Spanner 인스턴스와 물리적으로 가까운 곳에서 실행해야 합니다. 따라서 Cloud Spanner 인스턴스와 동일한 지역의 Compute Engine에서 Private Service Connect를 통해 실행하는 것이 가장 좋습니다. 멀티 리전 Cloud Spanner의 경우 네트워크 지연을 최소화하기 위해 Cloud Spanner 인스턴스의 리더 지역에 GCE 인스턴스를 생성해야 합니다.

JMeter는 커맨드라인으로 수행이 필요하며, CPU를 많이 사용하는 애플리케이션이므로 사전에 충분한 VM 리소스를 할당하는 것이 필요합니다. 자세한 사항은 JMeter를 사용하여 Cloud Spanner 성능 테스트 측정하기의 세부 단계별 가이드를 따라 Cloud Spanner 성능을 직접 테스트 해보시기 바랍니다.


다음 게시물 예고

지금까지 개발자를 위한 Spanner 시리즈로 입문하기에서 부터 성능 분석 및 측정하기라는 주제로 이야기를 해보았습니다. 다음은 운영자를 위한 Spanner 시리즈를 포스팅 할 예정이니 많은 관심 부탁 드립니다.

게시 위치