[운영관점 Spanner 시리즈] 확장성 이해하기

Cloud Spanner를 사용하면 고객이 유지보수 기간 없이 필요에 따라 손쉽게 인스턴스를 확장하고 축소할 수 있습니다. 이번 블로그에서는 확장 및 축소 방법을 설명하고 권장사항을 제공합니다.

확장해야 하는 경우

트래픽 증가가 예상될 경우 이벤트가 발생하기 전에 인스턴스를 확장하는 것이 좋습니다. 확장이란 인스턴스의 노드 수를 늘리는 것입니다. (일반적으로 '확장(Scale up)'에는 한 노드에 더 많은 리소스를 추가한다는 의미가 있지만 이 블로그에서는 '확장'을 노드 수를 늘린다는 의미로, '축소'는 노드 수를 줄인다는 의미로 사용합니다). 인스턴스 크기는 단계별로 나누어 늘릴 필요 없이 한 번에 늘릴 수 있지만 인스턴스 크기가 두 배가 될 때마다 30분의 재조정 시간을 할애하는 것이 좋습니다. 예를 들어 노드 100개로 시작했다가 최대 1,000개로 확장해야 하는 경우 인스턴스 크기를 한 번에 변경할 수 있지만 이벤트가 발생하기 최소 2시간 전에 변경해야 합니다. 확장하는 동안 꼬리 응답 시간(Tail Latency)이 약간 증가할 수 있습니다. 따라서 트래픽이 적을 때 인스턴스를 확장 또는 축소하는 것이 좋습니다.

CPU 사용률이 권장되는 기준을 초과하면 인스턴스를 확장해야 할 때입니다. 사용률을 확인하려면 다음 안내를 따르세요.

1단계: Cloud Console -> Spanner로 이동합니다.

2단계: CPU 사용률을 확인할 인스턴스를 클릭합니다.

3단계: 모니터링을 클릭합니다.

인스턴스 확장 여부를 결정할 때는 데이터베이스가 아닌 인스턴스별 CPU 사용률을 살펴봐야 합니다. (예시에서는 gti 데이터베이스 대신 jerene-test-instance 인스턴스를 선택)

4단계: “24시간 CPU 사용률의 이동 평균”과 “CPU 사용률 — 높은 우선순위” 메트릭을 검토합니다. 두 항목 모두 빨간색 선 아래에 위치해 있어야 합니다. 다만, 이 값은 리전 인스턴스와 멀티 리전 인스턴스에서 서로 다릅니다.

확장해야 하는 정도

확장할 노드 수는 사용 사례에 따라 다릅니다. 먼저 일반적인 사용량 기준을 정하는 것이 중요합니다. Cloud Spanner는 선형 확장되므로 이를 사용해 필요한 노드 수를 예측할 수 있습니다. 예를 들어 노드 15개가 있는 인스턴스의 현재 CPU 사용률이 80%인데 이를 60%로 줄이려면 우선 노드 5개까지 인스턴스를 확장하는 것이 좋습니다.

확장이 도움이 되지 않는 경우

수많은 요청이 특정 키(기본 테이블 키 또는 색인 키일 수 있음)에 지나치게 자주 액세스함에 따라 이 키를 읽거나 쓸 때 응답 시간이 늘어나게 하는 핫스팟이 발생하고 있다면 인스턴스를 확장해도 도움이 되지 않습니다. 이때는 여기에 나온 대안을 고려해 보세요. 이러한 문제는 키가 한 노드(및 복제본)에 있는 단일 Split에만 상주하기 때문에 발생합니다. 노드를 더 추가해도 상황이 달라지지 않습니다. 따라서 CPU 사용률이 낮은데 지연 시간(특히 꼬리 지연 시간)이 증가한다면 부하 집중을 해결하는 방안을 살펴보세요.

축소해야 하는 경우

확장과 달리 인스턴스를 축소하면 데이터베이스 Split을 기존 서버에서 인스턴스 내의 다른 서버로 이동하게 됩니다. 이전에 이 서버로 전송되었던 트래픽들은 데이터베이스 Split을 호스팅하는 새 서버로 재전송 됩니다. 따라서 축소 이벤트가 발생하면 꼬리 지연 시간이 증가할수 있습니다.

축소 빈도

다시 축소하기 전까지 30분(최소 10분 이상) 기다리는 것이 좋습니다. 그래야 다음번 축소가 있기 전에 데이터베이스 Split을 새 서버로 이동할 수 있습니다. 몇 분마다 인스턴스의 확대와 축소를 반복하지 않는 것이 좋습니다. 또한 Cloud Spanner는 현재 시간 단위로 요금을 부과하므로 매 시간 인스턴스를 여러 차례 확장 및 축소해도 비용 절감 효과를 얻지 못할 수 있습니다.

자동 확장 처리로 어떤 작업이 가능한가요?

자동 확장 처리는 사용자 수요에 따라 노드 수를 조정하는 방식으로 운영 관련 요구사항을 쉽게 충족하고 클라우드 지출의 효율성을 극대화하도록 설계되었습니다.

자동 확장 처리는 선형식, 단계식, 직접식이라는 3가지 확장 방법을 지원합니다. 이러한 확장 방법을 사용하면 워크로드에 맞게 자동 확장 처리를 구성할 수 있으며 세 가지 방법을 자유롭게 조합하여 하루 동안의 로드 패턴에 맞게 조정하고, 일괄 프로세스가 있는 경우에는 일정에 따라 확장하고, 작업을 완료한 후 다시 축소할 수 있습니다. 

대부분의 로드 패턴은 기본 확장 방법을 사용하여 관리할 수 있지만 추가적인 맞춤설정이 필요한 경우 자동 확장 처리에 새 측정항목과 확장 방법을 손쉽게 추가하여 특정 워크로드를 지원하도록 확장할 수 있습니다.

자동 확장 처리를 내 환경에 배포하려면 어떻게 해야 하나요?

가장 간단한 설계를 원한다면 프로젝트별 토폴로지로 자동 확장 처리를 배포하면 됩니다. 이 경우 하나 이상의 Spanner 인스턴스를 소유한 각 팀에서 자동 확장 처리 인프라 및 구성을 책임지게 됩니다. 또는 자동 확장 처리 인프라 및 구성을 더 세부적으로 제어하려면 중앙화하도록 선택하여 단일 운영팀에 권한을 부여하면 됩니다. 이 토폴로지는 규제가 심한 산업에 적합할 수 있습니다. 이 토폴로지의 구조는 다음과 같습니다.

빠른 준비와 실행을 위해 GitHub 저장소에는 Terraform 구성 파일과 각 환경에 따른 단계별 안내가 포함되어 있습니다.

자동 확장 처리는 어떻게 작동되나요?

간단히 말해 자동 확장 처리는 Cloud Monitoring API에서 측정항목을 가져와 권장되는 기준과 비교한 후 Spanner에 노드를 추가 또는 삭제하도록 요청합니다. 다음 다이어그램은 분산형 배포의 내부 구성요소를 보여줍니다.

(1) Cloud Scheduler 작업을 하나 이상 구성하여 자동 확장 처리에서 측정항목을 가져오는 빈도를 정의합니다. (2) 이 작업이 트리거되면 Cloud Scheduler에서 Pub/Sub 큐에 정의한 인스턴스별 구성 매개변수를 사용해 메시지를 게시합니다. (3) Cloud 함수('Poller')에서 이 메시지를 읽고 (4) Cloud Monitoring API를 호출하여 Cloud Spanner 인스턴스 측정항목을 가져온 후 (5) 다른 Pub/Sub 큐에 이를 게시합니다.

(6) 별도의 Cloud 함수('Scaler')에서 새 메시지를 읽고 (7) 마지막 확장 이벤트 후 안전한 기간이 지났는지 확인하고 (8) 권장 노드 수를 계산하여 특정 인스턴스에 노드를 추가하거나 삭제하도록 Cloud Spanner에 요청합니다.

이 과정이 진행되는 동안 자동 확장 처리에서 추적 및 감사를 위해 Cloud Logging에 권장사항 및 작업의 단계별 요약을 작성합니다.

자세히 알아보기

• 자동 확장 처리에 대한 자세한 내용은 새로운 자동 확장 처리를 통한 Spanner 인스턴스의 자동 크기 조정을 참조하세요.
• 자세한 내용을 알아보거나 참여를 원한다면 GitHub 저장소를 확인하거나 Qwiklab에서 자동 확장 처리를 실험하거나 무료 체험판을 통해 시작해 보세요.