Cloud Spanner 점검 기능을 통한 문제 해결 개선
Shambhu Hegde
Product Manager, Google Cloud
* 본 아티클의 원문은 2021년 2월 9일 Google Cloud 블로그(영문)에 게재되었습니다.
우수한 개발자 환경은 수평 확장이 가능한 Google의 완전 관리형 관계형 데이터베이스 서비스인 Cloud Spanner에서 가장 중점을 두고 있는 부분 중 하나입니다. 데이터베이스 전문가 또는 개발자 입장에서는 데이터베이스 성능을 파악하고 발생한 문제를 감지하여 해결하도록 도와주는 도구를 확보하는 것이 중요합니다. 이 때문에 Google은 데이터베이스 성능을 쉽게 모니터링하고 잠재적 문제를 진단 및 해결하며 애플리케이션의 전체적인 효율성을 최적화할 수 있는 새로운 점검 기능을 Spanner에 계속 추가해 왔습니다.
최근에는 기본 제공되는 테이블 형태의 여러 점검 도구를 출시했는데 이러한 도구에서는 쿼리를 통해 쿼리, 읽기, 트랜잭션 등 Spanner 작업에 대한 유용한 통계를 얻을 수 있습니다. 이 새로운 점검 테이블을 기존 알림 및 모니터링 기능과 결합해 사용한다면 문제를 진단 및 해결하는 데 도움이 될 강력한 도구 조합이 완성됩니다. 그러면 새로운 점검 도구를 자세히 살펴보겠습니다. 먼저 Spanner에서 점검 및 모니터링 기능을 활용하여 데이터 기반 애플리케이션을 최대한 활용하는 기본적인 방법부터 알아봅니다.
리소스 사용률 모니터링 방법
CPU와 스토리지는 예상 성능을 제공하기에 충분한 노드가 인스턴스에 프로비저닝되는지 확인하기 위해 Spanner에서 모니터링해야 할 주요 리소스입니다. 이미 Spanner가 통합되어 있는 Google Cloud Monitoring 제품군을 사용하면 권장 기준을 토대로 CPU 및 스토리지 사용률 측정항목에 대한 알림을 설정할 수 있습니다. 측정항목 값이 기준을 초과하면 알림이 자동으로 전송되며 Spanner 콘솔의 모니터링 탭에서 측정항목을 자세히 살펴보고 시간에 따른 변화를 분석할 수 있습니다.
예를 들어 CPU 사용률에 대한 알림을 받고 아래와 같은 모니터링 그래프에서 급증을 확인했다고 가정하겠습니다.
Cloud Monitoring 콘솔로 이동하여 기간을 선택하면 이 데이터를 더욱 상세하게 분석할 수 있습니다. 또한 인스턴스, 데이터베이스, 상세 분석을 위한 작업 우선순위 등의 옵션을 기준으로 필터링하여 집중적으로 추가 조사해야 할 부분을 결정할 수 있습니다. 측정항목 목록에 있는 여러 측정항목의 상관관계를 파악하여 급증한 이유를 파악하고 가능한 해결책을 결정할 수도 있습니다. 예를 들어 API 요청 증가와 CPU 사용률 증가에 상관관계가 있다면 Spanner의 워크로드로 인해 CPU 사용률이 증가했다고 추론할 수 있으며 노드를 더 프로비저닝하여 CPU 사용률을 권장 한도 내로 되돌려야 합니다.
요청이 증가하지 않았음에도 CPU 사용률이 급증했다면 비효율적인 SQL 쿼리 또는 읽기로 인해 CPU가 많이 사용된 것일 수 있습니다. 이와 같은 경우 어떤 SQL 쿼리나 읽기를 조사해야 할지 쉽게 파악할 수 있는 점검 테이블을 개발했습니다. 아래에 있는 이 블로그의 '새로운 점검 도구' 섹션이나 관련 문서에서 자세한 내용을 알아보세요.
성능 모니터링 방법
상황에 따라서는 처리량 목표나 지연 시간 목표와 같이 애플리케이션에 특정한 성능 요구사항이 있을 수 있습니다. 예를 들어 쓰기 작업에 대한 99번째 백분위수 지연 시간이 60ms 미만이어야 하고 지연 시간 측정항목이 이 기준을 초과하면 전송되는 알림을 구성했다고 가정하겠습니다.
쓰기 지연 시간이 기준을 초과했다는 알림을 받으면 Spanner 콘솔에서 지연 시간 그래프를 검토하여 이 이슈를 조사할 수 있습니다. 예를 들어 위의 이미지에서 쓰기 작업에 대한 99번째 백분위수 지연 시간이 오전 6시 10분에 급증하는 것을 확인할 수 있습니다. Cloud Monitoring 콘솔을 사용하면 지연 시간 급증에 영향을 미친 API 메서드를 파악할 수 있습니다. Commit API가 지연 시간 급증의 원인으로 밝혀졌다고 가정해 보겠습니다. 다음 단계로는 비용이 많이 드는 커밋과 관련된 트랜잭션을 파악해야 합니다. 커밋 지연 시간이 증가한 이유는 무엇이었나요?
Google은 이 문제를 해결하기 위해 상위 쿼리, 읽기, 트랜잭션, 트랜잭션 잠금과 관련된 세부정보와 통계를 제공하는 새로운 점검 도구를 개발했습니다. 이 도구는 기본 제공되는 여러 테이블로 구성되며 쿼리하여 자세한 통계를 얻을 수 있습니다. 이 표를 참조하여 각 도구를 사용하기에 적합한 경우를 알아보세요. 이번에는 각 도구의 기능을 자세히 살펴보겠습니다.
새로운 Spanner 점검 도구 소개
SQL 쿼리 심층 점검
쿼리 통계: 비용이 많이 드는 쿼리와 이 쿼리가 성능에 미치는 영향을 파악하고 조사하려면 쿼리 통계 테이블을 사용하세요. 이 테이블은 다음과 같은 질문의 답을 얻는 데 도움이 됩니다.
- CPU를 가장 많이 사용하는 쿼리는 무엇인가요?
- 쿼리당 평균 지연 시간은 얼마나 되나요?
- 스캔한 행 수와 쿼리에서 반환한 데이터 바이트 수는 얼마나 되나요?
다음은 테이블로부터 얻은 결과의 예시입니다. CPU를 가장 많이 사용하고 지연 시간이 가장 긴 상위 쿼리 2개의 디지털 지문을 쉽게 확인할 수 있습니다.
이 디지털 지문을 사용해 테이블에서 실제 쿼리 텍스트를 검색하세요. 다음 단계로, Spanner 콘솔에서 쿼리 설명 기능을 사용해 쿼리 실행 계획을 분석하고 쿼리를 최적화할 수 있습니다. 최근에는 완료된 쿼리는 물론 취소/실패한 쿼리에 통계를 더 추가함으로써 고객이 다양한 쿼리 유형의 문제를 해결할 수 있도록 Spanner의 쿼리 통계를 한층 더 개선하였습니다.
가장 오래된 활성 쿼리: 쿼리 통계 테이블은 지난 쿼리를 분석하는 데 도움이 되는 반면, 가장 오래된 활성 쿼리 테이블은 지연 시간과 높은 CPU 사용량 문제를 초래한 쿼리를 식별하는 데 도움이 됩니다. 이 테이블은 다음과 같은 질문의 답을 얻는 데 도움이 됩니다.
- 현재 실행 중인 쿼리 수는 몇 개인가요?
- 가장 오랫동안 실행 중인 쿼리는 무엇인가요?
- 쿼리를 실행 중인 세션은 무엇인가요?
이러한 답을 구하면 문제가 발생한 쿼리를 식별하고 그 어떤 복잡한 해결책보다도 빠르게 문제를 해결하는 데 도움이 됩니다. 예를 들어 속도가 가장 느린 쿼리가 애플리케이션 성능에 영향을 미치고 있는 것을 파악하고 즉각적인 해결을 위해 해당 세션을 삭제하는 등의 조치를 취할 수 있습니다.
읽기 작업 심층 점검
읽기 통계: 읽기 트래픽으로 인해 발생한 문제를 해결하려면 읽기 통계 테이블을 사용하세요. 이 테이블은 다음과 같은 질문의 답을 얻는 데 도움이 됩니다.
- CPU를 가장 많이 사용하는 읽기 작업은 무엇인가요?
- 읽기당 평균 CPU 사용량이 얼마나 되나요?
- 이 읽기와 관련된 총 대기 시간이 얼마나 되나요?
다음 단계로, 이러한 읽기 작업을 최적화하거나 사용 사례에 적합한 읽기 작업(강력 읽기 및 비활성 읽기)을 결정할 수 있습니다.
읽기-쓰기 트랜잭션 심층 점검
트랜잭션 통계: 트랜잭션으로 인해 발생한 문제를 해결하려면 트랜잭션 통계 테이블을 사용하세요. 읽기-쓰기 트랜잭션의 성능에 영향을 미치는 요인을 효과적으로 파악할 수 있습니다. 이 테이블은 다음과 같은 질문의 답을 얻는 데 도움이 됩니다.
- 가장 느린 속도로 실행되는 트랜잭션은 무엇인가요?
- 트랜잭션의 커밋 지연 시간과 전체적인 지연 시간은 얼마나 되나요?
- 트랜잭션의 커밋 시도 횟수는 몇 번인가요?
- 트랜잭션에서 쓰거나 읽은 열은 무엇인가요?
이 정보를 분석하면 특정 열의 대량 업데이트와 같이 트랜잭션 속도를 낮출 수 있는 잠재적 병목 현상을 발견할 수 있습니다. 트랜잭션 성능 문제의 빈번한 원인 중 하나는 잠금 충돌입니다. 트랜잭션의 커밋 지연 시간 또는 전체 지연 시간이 증가한다면 잠금 통계 테이블을 사용해 트랜잭션 잠금으로 인해 문제가 발생하는지 확인하세요.
잠금 통계: 성능에 영향을 미치는 트랜잭션을 식별한 후 잠금 통계 테이블을 사용해 트랜잭션 성능 특성과 잠금 충돌의 상관관계를 파악합니다. 이 테이블은 다음과 같은 질문의 답을 얻는 데 도움이 됩니다.
- 잠금 충돌을 높이는 원인이 되는 행과 열은 무엇인가요?
- 어떤 유형의 잠금 충돌이 발생하나요?
- 잠금 충돌로 인한 대기 시간은 얼마나 되나요?
데이터베이스의 잠금 충돌 원인과 관련된 중요 통계를 트랜잭션 통계 테이블과 함께 참고하면 문제가 있는 트랜잭션을 파악할 수 있습니다. 다음 단계로, 추천받은 권장사항을 적용하여 트랜잭션을 최적화하고 성능을 개선하세요.
클라이언트 측 측정항목 및 Google 프런트엔드 측정항목 모니터링
지금까지 Spanner 레이어에서 점검 측정항목과 도구를 사용하는 방법에 대해 알아봤습니다. 하지만 애플리케이션 레이어(클라이언트 측)와 네트워크 레이어(Google 프런트엔드)에 문제가 있을 수도 있으므로 엔드 투 엔드 모니터링을 위해서는 이러한 레이어도 모니터링해야 합니다. 이미 OpenCensus와 통합된 Spanner를 사용하면 클라이언트 측 측정항목과 gRPC 측정항목을 모니터링하는 데 도움이 됩니다. Spanner에서는 네트워크 레이어로 인해 지연 시간 문제가 발생했는지 파악할 수 있도록 Google 프론트엔드 관련 측정항목도 제공합니다. 클라이언트 측 측정항목 및 Google 프런트엔드 측정항목을 Spanner 레이어 측정항목과 결합하면 엔드 투 엔드 모니터링을 수행하여 문제의 원인을 찾아 해결할 수 있습니다.
Spanner 점검 기능 업데이트로 Spanner에서 개발 작업이 더욱 생산적으로 이루어지길 바랍니다. Spanner에 대한 자세한 내용은 Spanner YouTube 재생목록을 확인하세요.
자세히 알아보기
Spanner를 시작하려면 인스턴스를 만들거나 Spanner Qwiklabs를 사용해 보세요.
다음 블로그에서 문제 해결을 위해 점검 도구를 사용하는 방법을 자세히 알아보세요.
