솔직히 클라우드 스파너의 예열 지표는 우리가 진지하게 검증했다.그것에 관해서는 아무런 거짓말도 없다.나는 조금도 숨기지 않고 전부 말할 것이다.

Gren Advent Calendar 2019 그렇죠
사실대로 말하면, 나는 매우 괴롭다.그리고 정말 진지하게, 진지하게 반복해서 검증한 후에야 비로소 발견하였다.
Cloud Spanner감동받았어요.그것에 관해서는 아무런 거짓말도 없다.
그 강함은 어디서 났을까..
나는 조금도 숨기지 않고 전부 말할 것이다.

Cloud Spanner 예열의 중요성

노트

Cloud Spanner 전체 CPU 사용률을 65% 이하로 제어하려면 충분한 수의 Cloud Spanner 노드를 제공해야 합니다.
콜드 상태의 Cloud Spanner는 사전 예열을 하지 않으면 게시에 필요한 노드를 제공하지 않습니다.

데이터베이스 구분자

분리는 Cloud Spanner의 데이터 단위입니다.
Cloud Spanner는 여러 노드를 최대한 활용하기 위해 테이블을 자동으로 스플릿으로 분할합니다.
구분자는 다음과 같은 조건에 따라 분할된다.

Size-dased splits

데이터 크기 기반 분할

테이블을 GB 단위로 분리

load-dased splits

로드 기반 분할

분산된 부하로 분기

Cloud Spanner의 모든 노드는 충분한 구분자를 생성하여 활용됩니다.
Cloud Spanner의 최대 성능을 제공합니다.
부하 시험은 발매 전 클라우드 스파너를 예열해 충분한 분열을 만들어야 한다.

Cloud Spanner 예열 지표

분리 조건으로는 Size-dased splits와 load-dased splits가 있습니다.
실제로 표가 언제 분리될지 보장할 수 없다.
그러나 부하 시험의 방법으로
Cloud Spanner 설계 워크숍 slide 20

클라우드 스파너의 부하 테스트를 진행할 때는 5분이 아닌 20~30분의 부하 테스트를 추천합니다.데이터 용량이 늘어나면서 스플릿이 더 많이 발생하고 모든 노드 사이에 데이터가 정상적으로 분포된다는 이유에서다.

따라서 우리는 계속 검증을 진행할 것이다.
또한Cloud Spanner 설계 워크숍 slide 20
Google Cloud metrics #spanner의 appi/appirequest_관심 count.

Cloud Spanner 사전 핫 인증

부하 테스트 도구 사용locust.
부하 테스트의 조건은 다음과 같다.

부하 테스트의 1회 실시 시간은 30분

초 동안 2000~30000 Requests

Cloud Spanner 노드 수 동일

참조로 사용할 Cloud Spanner의 메트릭은 다음과 같습니다.

API request rate

api/api_request_count

Request latencies

api/request_latencies

부하 테스트 방안 구성

로드 테스트 시나리오의 전반부에서 실행되는 고부하 API

부하 테스트 방안은 무작위로 실행

부하 시험 제1차

새 데이터베이스

표 작성

부하시험 실시

부하 시험 후
Stackdriver Monitoring에서 Cloud Spanner의 메트릭을 확인합니다.

왼쪽 그림은 API request rate이고, 오른쪽 그림은 Request latenciesp99입니다.
API request rate 차트를 봤는데 5:27 정도까지도 불안정했고 5:30 이상부터 안정적이었어요.
5:27 정도까지 Cloud Spanner 설계 워크숍 slide 20보듯이 단거리 경주를 제작했는데 5:30이 넘으면 단거리 경주 제작이 끝나 안정적으로 보인다.
Request latencies p99 차트에서도 5:27 정도 지연이 불안정하며 5:30 초과부터 안정적입니다.
5:27 정도의 Execute Streaming Sql, Commiit는 몇 초 소요
5시 30분이 넘으면 Execute StreamingSql은 30ms, Commiit는 10~13ms로 안정됩니다.

부하시험 제2차

Stackdriver Monitoring에서 Cloud Spanner의 메트릭을 확인합니다.

API request rate의 차트와 처음 비교를 해보면 앞부분(6:15 정도)의 차트와 처음 비교한 차트가 비교적 느리다는 것을 알 수 있습니다.
Request latencies p99 차트
Request latencies p99 차트에서도 6:15 정도 지연이 불안정하지만 처음 수 초가 걸렸을 때 수 밀리초로 확인할 수 있습니다.
이후 Execute StreamingSql은 30ms, Commiit는 10~15ms로 안정됐다.

부하시험 3차

Stackdriver Monitoring에서 Cloud Spanner의 메트릭을 확인합니다.

API request rate의 차트가 두 번째 차트와 크게 다르지 않은지 확인합니다.
Request latencies p99의 차트에서 Execute Streaming Sql은 30ms, Commiit는 10~13ms로 안정적입니다.

부하 시험의 결과에 근거하여

로드 테스트의 첫 번째 API request rate 차트에 초점을 맞출 때
Request latencies p99는 첫 번째, 두 번째, 세 번째에 거의 차이가 없는 지연입니다.
첫 번째 API request rate 차트가 안정됐을 때부터 클라우드 스파너의 예열이 완료돼도 문제없었다.
부하 시험의 두 번째와 세 번째 Request latencies p99의 도표는 차이가 있다
응용 프로그램 p99의 시간 지연을 비교한 결과 큰 차이가 발견되지 않았기 때문에 부하 테스트 스크립트의 임의적인 편차로 인한 것이라고 생각합니다.

Cloud Spanner 예열 지표

Cloud Spanner 몸 푸는 방법은 회사마다 다양해요.
Stackdriver Monitoring을 통해 확인할 수 있는 클라우드 스파너의 메트릭API request rate을 예열의 한 지표로 참고할 수 있다면 좋겠다.

참고 자료

Cloud Spanner

데이터베이스 구분자

Cloud Spanner를 게임 데이터베이스로 사용할 때의 모범 사례

Practice Cloud Spanner 설계 워크숍

'드래곤볼 전설'비하인드 Google Cloud 지원

주식회사 콜로라는 "GKE와 Cloud Spanner가 점프하는 용자 두악용 보행" 제9회 구글 클라우드 인스IDE Game&Apps

Google Cloud metrics #spanner