리전 및 멀티 리전 구성

이 페이지에서는 인스턴스 구성과 Cloud Spanner가 제공하는 두 가지 유형의 인스턴스 구성(리전 구성 및 멀티 리전 구성)에 대해 설명합니다. 리전 구성과 멀티 리전 구성의 차이 및 장단점도 설명합니다.

인스턴스 구성

인스턴스 구성은 해당 인스턴스에서 데이터베이스의 지리적 위치와 복제를 정의합니다. 인스턴스를 만들 때 인스턴스를 리전(모든 리소스가 단일 Google Cloud 리전에 있음) 또는 멀티 리전(리소스가 리전 두 곳 이상에 있음)으로 구성해야 합니다. 인스턴스 구성을 선택하여 구성할 리전 유형을 선택합니다. 이 선택으로 해당 인스턴스의 데이터가 저장되는 위치가 결정됩니다.

인스턴스 이동 단계의 안내에 따라 인스턴스 구성을 변경할 수 있습니다. 인스턴스 이동에 대한 일반 정보는 인스턴스를 다른 구성으로 이동을 참조하세요.

리전 구성

Google Cloud 서비스는 북미, 남미, 유럽, 아시아, 오스트레일리아의 여러 위치에서 제공됩니다. 사용자와 서비스가 단일 리전 내에 있으면 읽기 및 쓰기 지연 시간이 가장 짧은 리전 인스턴스 구성을 선택합니다.

사용 가능한 구성

Cloud Spanner는 다음과 같은 지역 인스턴스 구성을 제공합니다.

지역명 리전 설명
미주
northamerica-northeast1 몬트리올 리프 아이콘 낮은 CO2
northamerica-northeast2 토론토 리프 아이콘 낮은 CO2
southamerica-east1 상파울루 리프 아이콘 낮은 CO2
southamerica-west1 산티아고
us-central1 아이오와 리프 아이콘 낮은 CO2
us-east1 사우스캐롤라이나
us-east4 북버지니아
us-south1 댈러스
us-west1 오리건 리프 아이콘 낮은 CO2
us-west2 로스앤젤레스
us-west3 솔트레이크시티
us-west4 라스베이거스
유럽
europe-central2 바르샤바
europe-north1 핀란드 리프 아이콘 낮은 CO2
europe-southwest1 마드리드 리프 아이콘 낮은 CO2
europe-west1 벨기에 리프 아이콘 낮은 CO2
europe-west2 런던
europe-west3 프랑크푸르트
europe-west4 네덜란드
europe-west6 취리히 리프 아이콘 낮은 CO2
europe-west8 밀라노
europe-west9 파리 리프 아이콘 낮은 CO2
아시아 태평양
asia-east1 타이완
asia-east2 홍콩
asia-northeast1 도쿄
asia-northeast2 오사카
asia-northeast3 서울
asia-south1 뭄바이
asia-south2 델리
asia-southeast1 싱가포르
asia-southeast2 자카르타
australia-southeast1 시드니
australia-southeast2 멜버른

리전 구성에 관계없이 Cloud Spanner는 해당 리전의 각기 다른 Google Cloud 영역 내에 하나씩 3개의 읽기-쓰기 복제본을 유지합니다. 각 읽기-쓰기 복제본에는 읽기-쓰기 및 읽기 전용 요청을 처리할 수 있는 운영 데이터베이스의 전체 복사본이 있습니다. Cloud Spanner는 여러 영역에서 복제본을 사용하므로 단일 영역에 장애가 발생해도 데이터베이스를 계속 사용할 수 있습니다.

복제

리전 구성에는 정확히 3개의 읽기-쓰기 복제본이 포함됩니다. 복제의 설명대로 모든 Cloud Spanner 변형에는 다수의 응답 복제본으로 구성된 쓰기 쿼럼이 있어야 합니다. 쓰기 쿼럼은 리전 구성의 복제본 3개 중 2개로 구성됩니다.

권장사항

최적의 성능을 위해 다음 권장사항을 따르세요.

  • 핫스팟 및 기타 성능 문제를 방지하는 스키마를 설계합니다.
  • 중요한 컴퓨팅 리소스를 Cloud Spanner 인스턴스와 같은 리전에 배치합니다.
  • 컴퓨팅 용량을 충분히 프로비저닝하여 우선순위가 높은 총 CPU 사용률을 65% 미만으로 유지합니다.

성능

위에 설명된 권장사항을 따르면 컴퓨팅 용량의 각 1,000개의 처리 단위(1노드)는 최대 10,000QPS 읽기(초당 쿼리 수) 읽기 또는 2,000QPS 쓰기(행당 1KB 데이터로 단일 행 쓰기)를 제공할 수 있습니다.

다중 지역 구성

위에 설명한 대로 Cloud Spanner 지역 구성은 단일 지역 내 여러 영역 사이에 데이터를 복제합니다. 하지만 애플리케이션에서 여러 지리적 위치의 데이터를 읽어야 하는 경우가 자주 있거나(예를 들어 북미 및 아시아의 사용자 모두에게 데이터를 제공) 쓰기와 읽기가 다른 위치에서 발생하는 경우(예를 들어 북미에는 대량의 쓰기 작업 부하가 있고 유럽에는 대량의 읽기 작업 부하가 있는 경우)에는 지역 구성이 적합하지 않을 수 있습니다.

다중 지역 구성을 사용하면 인스턴스 구성에서 정의한 대로 데이터베이스의 데이터를 단순히 여러 영역이 아니라 여러 지역의 여러 영역에도 복제할 수 있습니다. 이러한 추가 복제본을 사용하여 구성의 지역에서 가까운 여러 위치 또는 지역 내 여러 위치에서 짧은 지연 시간으로 데이터를 읽을 수 있습니다. 하지만 절충해야 하는 부분도 있습니다. 이는 다중 지역 구성에서는 쿼럼(읽기-쓰기) 복제본이 여러 지역에 분산되어 있기 때문입니다. 따라서 이러한 복제본이 서로 통신하여 쓰기에 응답할 때 추가로 네트워크 지연이 생길 수 있습니다. 즉, 다중 지역 구성을 사용하면 애플리케이션에서 쓰기가 약간 지연되지만 더 많은 위치에서 읽기를 빠르게 수행할 수 있습니다.

사용 가능한 구성

대륙 1개

이름 위치 읽기-쓰기 리전 읽기 전용 리전 감시 리전
asia1 아시아 도쿄: asia-northeast1 L,2R
오사카: asia-northeast2 2R
없음 서울: asia-northeast3
eur3 유럽 벨기에: europe-west1 L,2R
네덜란드: europe-west4 2R
없음 핀란드: europe-north1
eur5 유럽 런던: europe-west2 L,2R
벨기에: europe-west1 2R
없음 네덜란드: europe-west4
eur6 유럽 네덜란드: europe-west4 L,2R
프랑크푸르트: europe-west3 2R
없음 취리히: europe-west6
nam3 북미 북 버지니아: us-east4 L,2R
사우스캐롤라이나: us-east1 2R
없음 아이오와: us-central1
nam6 북미 아이오아: us-central1 L,2R
사우스캐롤라이나: us-east1 2R
오리건: us-west1 1R
로스앤젤레스: us-west2 1R
오클라호마: us-central2
nam7 북미 아이오와: us-central1 L,2R
북 버지니아: us-east4 2R
없음 오클라호마: us-central2
nam8 북미 로스앤젤레스: us-west2 L,2R
오리곤: us-west1 2R
없음 솔트레이크시티: us-west3
nam9 북미 북 버지니아: us-east4 L,2R
아이오와: us-central1 2R
오리건: us-west1 2R 사우스캐롤라이나: us-east1
nam10 북미 아이오와: us-central1 L,2R
솔트레이크시티: us-west3 2R
없음 오클라호마: us-central2
nam11 북미 아이오아: us-central1 L,2R
사우스캐롤라이나: us-east1 2R
없음 오클라호마: us-central2
nam12 북미 아이오와: us-central1 L,2R
북 버지니아: us-east4 2R
오리건: us-west1 2R 오클라호마: us-central2
nam13 북미 오클라호마: us-central2 L,2R
아이오와: us-central1 2R
없음 솔트레이크시티: us-west3

대륙 3개

이름 위치 읽기-쓰기 리전 읽기 전용 리전 감시 리전
nam-eur-asia1 북미
유럽
아시아
아이오와: us-central1 L,2R
오클라호마: us-central2 2R
벨기에: europe-west1 2R
타이완: asia-east1 2R
사우스 캐롤라이나: us-east1
nam-eur-asia3 북미
유럽
아시아
아이오와: us-central1 L,2R
사우스 캐롤라이나: us-east1 2R
벨기에: europe-west1 1R
네덜란드: europe-west4 1R
타이완: asia-east1 2R
오클라호마: us-central2
  • L: 기본 최적 리전

  • 1R: 리전의 1개 복제본

  • 2R: 리전의 2개 복제본

이점

다중 지역 인스턴스는 다음과 같은 주요 이점을 제공합니다.

  • 99.999% 가용성: Cloud Spanner 지역 구성이 제공하는 99.99% 가용성보다 높습니다.

  • 데이터 분산: Cloud Spanner는 강력한 일관성을 보장하며 리전 사이에 데이터를 자동으로 복제합니다. 따라서 데이터를 사용 위치에 저장하여 지연 시간을 줄이고 사용자 환경을 개선할 수 있습니다.

  • 외부 일관성: 지리적으로 먼 위치에서 복제하더라도 Cloud Spanner를 단일 머신에서 실행되는 데이터베이스처럼 사용할 수 있습니다. 트랜잭션은 직렬화가 보장되며, 데이터베이스에서 트랜잭션 순서는 클라이언트가 커밋된 트랜잭션을 관찰하는 순서와 동일합니다. 외부 일관성은 일부 다른 제품에서 제공하는 'strong consistency'보다 더욱 강력한 보증입니다. TrueTime 및 외부 일관성에서 이 속성에 대해 자세히 알아보세요.

복제

각 다중 지역 구성에는 읽기-쓰기 지역으로 지정된 지역이 2개 있으며 각 지역에는 읽기-쓰기 복제본이 2개 있습니다. 이러한 읽기-쓰기 리전 중 하나는 기본 최적 리전으로 지정됩니다. 즉, 이 리전에 데이터베이스의 최적 복제본이 포함됩니다. Cloud Spanner는 감시 리전이라는 세 번째 리전에 감시 복제본도 배치합니다.

클라이언트에서 데이터베이스에 변형을 실행할 때마다 쓰기 쿼럼이 형성됩니다. 이 쿼럼은 기본 최적 지역의 복제본 중 1개와 추가 응답 복제본 4개 중 2개로 구성됩니다. (쿼럼은 응답에 참여하는 다른 복제본에 따라 구성에 포함된 2개 또는 3개 지역의 복제본으로 형성될 수도 있습니다.) 이러한 응답 복제본 5개 외에도 구성에는 짧은 지연 시간 읽기를 제공하기 위한 읽기 전용 복제본이 있습니다. 읽기 전용 복제본이 있는 리전을 읽기 전용 리전이라 합니다.

일반적으로 멀티 리전 구성의 응답 리전은 지리적으로 가까운(1,000마일 미만) 곳에 배치되어 빠르게 쓸 수 있고 지연 시간이 짧은 쿼럼을 형성합니다(자세히 알아보기). 그러나 리전들은 조정 오류를 방지하기 위해 충분히 멀리(일반적으로 최소 수백 마일) 떨어져 있습니다.

다음 섹션에서는 각 리전 유형을 보다 자세하게 설명하고 쓰기 및 읽기 워크로드를 적절하게 배치하는 방법에 대한 안내를 제공합니다.

리전 유형

읽기-쓰기 리전

위에 설명한 대로 각 멀티 리전 구성에는 읽기-쓰기 리전이 2개 있으며, 각 리전에는 읽기-쓰기 복제본이 2개 있습니다. 이러한 읽기-쓰기 리전 중 하나는 기본 최적 리전으로 지정됩니다. 최적 복제본은 각 분할에 대해 기본 최적 리전에 있는 복제본 중에서 선택됩니다. 최적 복제본이 실패할 경우 기본 최적 리전에 있는 다른 복제본이 자동으로 다음 최적 복제본 역할을 수행합니다. 실제로 최적 복제본은 자체적으로 상태 확인을 실행하며, 비정상 상태를 감지하면 최적 복제본 역할을 사전에 포기할 수 있습니다. 기본 최적 리전의 복제본을 사용할 수 있는 정상적인 환경에서 기본 최적 리전에는 최적 복제본이 포함되며, 따라서 쓰기가 먼저 처리됩니다.

두 번째 읽기-쓰기 리전에는 최적 복제본이 될 수 있는 추가 복제본이 있습니다. 드물긴 하지만 기본 최적 리전의 모든 복제본이 손실되는 경우 두 번째 읽기-쓰기 리전에서 새 최적 복제본이 선택됩니다.

DB의 리더 리전 변경의 안내에 따라 데이터베이스의 최적 리전을 구성할 수 있습니다. 최적 리전 구성에 대한 일반적인 내용은 기본 최적 리전 구성을 참조하세요.

읽기 전용 리전

읽기 전용 지역에는 읽기 전용 복제본이 있습니다. 이 복제본은 읽기-쓰기 지역의 외부에 있는 클라이언트에 짧은 지연 시간 읽기를 제공할 수 있습니다.

감시 지역

감시 지역에는 쓰기에 응답하기 위해 사용되는 감시 복제본이 있습니다. 읽기-쓰기 지역을 사용할 수 없게 되는 드문 경우에 감시가 중요해집니다.

권장사항

최적의 성능을 위해 다음 권장사항을 따르세요.

  • 핫스팟 및 기타 성능 문제를 방지하는 스키마를 설계합니다.
  • 최적의 쓰기 지연 시간을 위해서는 쓰기가 많은 워크로드의 컴퓨팅 리소스를 기본 최적 리전 내 또는 가까이 배치합니다.
  • 기본 최적 리전 외부에서 최적의 읽기 성능을 얻으려면 최소 15초의 비활성을 사용합니다.
  • 워크로드가 한 리전에만 의존하지 않도록 하려면 중요 컴퓨팅 리소스를 둘 이상의 리전에 배치합니다. 올바른 옵션은 모든 단일 리전 중단이 애플리케이션 모두에 영향을 주지 않도록 2개의 서로 다른 읽기-쓰기 리전 옆에 배치하는 것입니다.
  • 컴퓨팅 용량을 충분히 프로비저닝하여 각 리전에서 우선순위가 높은 총 CPU 사용률을 45% 미만으로 유지합니다.

성능

각 Cloud Spanner 구성은 복제 토폴로지에 따라 성능 특성이 약간씩 다릅니다.

위에 설명된 권장사항을 따르면 컴퓨팅 용량의 각 1,000개의 처리 단위(1노드)는 다음과 같은 대략적인 성능 근사치를 제공할 수 있습니다.

멀티 리전 구성 최대 읽기 근사치(리전별 QPS) 최대 쓰기 근사치(QPS 합계)
asia1 7,000 1,800
eur3 7,000 1,800
eur5 7,000 1,800
eur6 7,000 1,800
nam3 7,000 1,800
nam6 us-central1us-east1에서 7,000,
us-west1us-west2[1]에서 3,500
1,800
nam7 7,000 1,800
nam8 7,000 1,800
nam9 7,000 1,800
nam10 7,000 1,800
nam11 7,000 1,800
nam12 7,000 1,800
nam13 7,000 1,800
nam-eur-asia1 7,000 1,000
nam-eur-asia3 7,000 1,000
  • [1]: us-west1us-west2는 리전당 2개의 복제본이 아닌 1개의 복제본을 포함하기 때문에 QPS 성능의 절반만 제공됩니다.

읽기는 어디서나 제공될 수 있기 때문에 읽기 안내는 리전별로 제공되지만 쓰기 안내는 전체 구성에 해당합니다. 쓰기 안내에서는 행당 1KB 데이터로 단일 행을 쓴다고 가정합니다.

인스턴스를 다른 구성으로 이동

인스턴스를 모든 인스턴스 구성에서 리전 구성과 멀티 리전 구성을 포함한 다른 인스턴스 구성으로 이동할 수 있습니다.

인스턴스를 이동해도 다운타임이 발생하지 않으며 Cloud Spanner는 이동 중에 strong consistency를 포함하여 일반적인 트랜잭션 보장을 계속 제공합니다.

인스턴스 이동 단계

  1. Cloud Console에서 Spanner 인스턴스 페이지로 이동합니다.

    인스턴스 페이지로 이동

  2. 이동하려는 인스턴스의 이름을 클릭합니다.

    Cloud Console에 인스턴스의 개요 페이지가 표시됩니다.

  3. 인스턴스 수정을 클릭합니다.

  4. 새 인스턴스 구성으로 이동하려면 Google에 문의를 클릭하고 Cloud Spanner 라이브 인스턴스 마이그레이션 요청(미리보기) 양식을 작성하세요.

    • 새 인스턴스 구성으로 이동할 것을 요청하려면 spanner.instances.update 권한이 있어야 합니다.
    • 양식이 제출되면 Google이 인스턴스 구성 변경 예약을 위해 사용자에게 연락합니다.

인스턴스 이동 제한사항

  • 한 번에 한 인스턴스에서 하나의 프로젝트만 이동할 수 있습니다.
  • 인스턴스를 이동해도 인스턴스의 이름, ID 또는 프로젝트 ID는 변경되지 않습니다.
  • 마이그레이션 중에는 인스턴스를 변경해서는 안 됩니다. 여기에는 인스턴스 노드 수 변경, 데이터베이스 스키마 변경, 데이터베이스 만들기 또는 삭제, 백업 만들기 또는 삭제가 포함됩니다.
  • Cloud Spanner 백업은 인스턴스 구성에 따라 다르며 인스턴스를 이동할 때 포함되지 않습니다. 인스턴스를 새 인스턴스 구성으로 이동하면 이전 인스턴스 구성의 모든 백업이 삭제됩니다.
  • 현재 CMEK가 사용 설정된 데이터베이스가 있는 인스턴스의 인스턴스 구성은 변경할 수 없습니다.

인스턴스 이동 시 성능 고려 사항

인스턴스가 이동 중일 때에는 인스턴스의 읽기/쓰기 지연 시간이 길어지고 트랜잭션 취소율이 높아집니다.

시작 시 대부분의 마이그레이션은 12시간 이내에 완료해야 합니다. 일부 마이그레이션은 인스턴스의 크기 및 기타 특성에 따라 시간이 더 오래 걸릴 수 있습니다. Google에서 마이그레이션할 인스턴스와 관련된 예상 마이그레이션 시간을 알려드립니다.

인스턴스의 모든 데이터베이스가 동시에 마이그레이션됩니다. 클라이언트 애플리케이션에서 Cloud Spanner를 여러 번 순차적으로 호출할 수 있으므로 Cloud Spanner 지연 시간이 증가하는 것보다 애플리케이션 꼬리 지연 시간이 더 길어질 수 있습니다.

인스턴스 마이그레이션 후 인스턴스 구성의 세부 사항에 따라 인스턴스의 성능이 달라집니다. 예를 들어 멀티 리전 구성은 일반적으로 리전 구성보다 쓰기 지연 시간이 더 길고 읽기 지연 시간이 더 짧습니다.

기본 리더 리전 구성

애플리케이션 대기 시간을 줄이기 위해 연결 클라이언트에 더 가깝게 데이터베이스의 기본 최적 리전 위치를 변경할 수 있습니다.

멀티 리전 구성을 사용하는 모든 Cloud Spanner 인스턴스에 대해 리더 리전을 변경할 수 있습니다. 리더 리전의 위치를 변경하는 방법은 DB의 리더 리전 변경을 참조하세요. 데이터베이스의 기본 리더 리전이 될 수 있는 리전은 멀티 리전 구성의 읽기-쓰기 리전뿐입니다.

리더 리전은 모든 데이터 베이스 쓰기를 처리하는 역할을 합니다. 따라서 대부분의 트래픽이 하나의 지리적 리전에서 유입되는 경우 리더 리전을 그 지리적 리전으로 이동하여 지연 시간을 줄이는 것이 좋습니다. 기본 리더 리전 업데이트는 비용은 저렴하고 데이터 이동이 수반되지 않습니다. 새 값이 적용되는 데 몇 분 정도 걸립니다.

기본 리더 리전 변경은 장기 실행 작업을 사용하는 스키마 변경입니다. 필요한 경우 장기 실행 작업의 상태를 가져올 수 있습니다.

장단점: 리전 구성과 멀티 리전 구성 비교

구성 가용성 지연 시간 비용 데이터 위치
지역 99.99% 지역 내에서 쓰기 지연 시간을 줄입니다. 낮은 비용. 가격을 참조하세요. 지리적 데이터 거버넌스를 활성화합니다.
다중 지역 99.999% 여러 지리적 지역에서 읽기 지연 시간을 줄입니다. 높은 비용. 가격을 참조하세요. 구성 내 여러 리전에 데이터를 분산합니다.

다음 단계