복제 개요

Bigtable의 복제를 사용하면 여러 리전 간에 또는 같은 리전의 여러 영역 간에 데이터를 복사하여 데이터 가용성과 내구성을 높일 수 있습니다. 또한 다양한 유형의 요청을 다른 클러스터에 라우팅하여 워크로드를 분리할 수 있습니다.

이 페이지에서는 Bigtable에서의 복제 작동 방식과 몇 가지 일반적인 복제 사용 사례를 설명합니다. 복제가 활성화되었을 때 Bigtable이 사용하는 일관성 모델 그리고 한 클러스터에서 다른 클러스터로 장애 조치를 수행할 때 발생하는 상황도 설명합니다.

  • 일반적인 사용 사례를 구현할 수 있는 설정에 대한 예시는 복제 구성 예시를 참조하세요.
  • 복제를 사용하는 인스턴스를 만드는 방법은 인스턴스 만들기를 참조하세요.
  • 기존 인스턴스에 대해 복제를 활성화하는 방법은 클러스터 추가를 참조하세요.
  • 복제와 관련된 비용을 알아보려면 가격 책정을 참조하세요.

이 페이지를 읽기 전에 Bigtable 개요를 숙지해야 합니다.

복제 작동 방식

Bigtable 인스턴스에서 복제를 사용하려면 클러스터가 2개 이상 있는 새 인스턴스를 생성하거나 기존 인스턴스에 클러스터를 추가합니다.

Bigtable 인스턴스는 최대 8개의 Bigtable 리전에 클러스터를 보유할 수 있으며, 이러한 8개의 각 리전에서 인스턴스는 영역당 하나의 클러스터만 포함할 수 있습니다. 예를 들어 영역이 각각 3개 있는 리전 8개에 인스턴스를 만들면 인스턴스에는 최대 24개의 클러스터가 있을 수 있습니다.

리전의 각 영역에는 클러스터가 하나만 포함될 수 있습니다. 클러스터가 서로 다른 영역이나 리전에 있으면 Google Cloud 영역이나 리전 하나를 사용할 수 없게 되더라도 인스턴스의 데이터에 액세스할 수 있습니다.

클러스터가 두 개 이상 있는 인스턴스를 만들면 Bigtable이 즉시 각 클러스터 사이에서 데이터 동기화를 시작하여 인스턴스에 클러스터가 있는 각 영역에 별도의 독립적인 데이터 복사본을 만듭니다. 마찬가지로 기존 인스턴스에 새 클러스터를 추가하면 Bigtable은 원래 클러스터 영역에서 새 클러스터 영역으로 기존 데이터를 복사한 후 데이터 변경사항을 각 영역 간에 동기화합니다.

Bigtable은 다음 유형의 모든 변경사항을 포함한 모든 데이터 변경사항을 복제합니다.

  • 기존 테이블에 있는 데이터의 업데이트
  • 새 테이블과 삭제된 테이블
  • 추가된 column family와 삭제된 column family
  • column family의 가비지 컬렉션 정책 변경사항

복제에는 지연 시간이 있으며 클러스터 간 일관성은 최종적으로 이루어집니다.

Bigtable은 인스턴스에 있는 각 클러스터를 기본 클러스터로 취급하기 때문에 각 클러스터에서 읽기 및 쓰기를 수행할 수 있습니다. 다양한 유형의 애플리케이션에서 발생한 요청이 여러 클러스터에 라우팅되도록 인스턴스를 설정할 수도 있습니다.

인스턴스에 클러스터를 추가하기 전에 복제된 테이블의 가비지 컬렉션 정책을 변경할 때 적용되는 제한사항을 숙지해야 합니다.

성능

복제를 사용하면 복제된 인스턴스를 만들거나 단일 클러스터 인스턴스에 클러스터를 추가하여 복제를 사용 설정할 때 계획해야 하는 성능 영향이 있습니다. 예를 들어 다른 리전에 있는 복제된 클러스터의 경우 일반적으로 같은 리전에 있는 복제된 클러스터보다 복제 지연 시간이 더 깁니다. 또한 두 개 이상의 클러스터가 있는 인스턴스의 클러스터에는 복제 처리의 추가 작업을 처리하기 위해 더 많은 노드가 필요한 경우가 많습니다. 자세한 내용은 성능 이해를 참조하세요.

사용 사례

이 섹션에서는 Bigtable 복제의 몇 가지 일반적인 사용 사례에 대해 설명합니다. 각 사용 사례에 대한 최상의 구성 설정과 다른 사용 사례에 대한 구현 팁을 찾으려면 복제 설정 예를 참조하세요.

서빙 애플리케이션을 일괄 읽기에서 분리

읽기 및 쓰기 조합을 수행하는 애플리케이션에서 대량 읽기를 다수 수행하는 일괄 분석 작업을 단일 클러스터로 실행하면 대량 일괄 작업으로 인해 애플리케이션 사용자의 작업 속도가 느려질 수 있습니다. 하지만 복제 기능과 함께 단일 클러스터 라우팅이 설정된 앱 프로필을 사용하여 일괄 분석 작업과 애플리케이션 트래픽을 다른 클러스터로 라우팅하면 일괄 처리 작업이 애플리케이션 사용자에게 영향을 주지 않습니다. 사용 사례 구현 자세히 알아보기

가용성 향상

인스턴스에 클러스터가 1개밖에 없는 경우에는 데이터의 내구성과 가용성이 클러스터가 위치한 영역으로 제한됩니다. 복제는 개별 데이터 사본을 여러 영역 또는 리전에 저장하고 필요한 경우 클러스터 간에 자동으로 장애 조치를 취하므로 내구성과 가용성이 모두 향상될 수 있습니다. 사용 사례 구현 자세히 알아보기

실시간에 가까운 백업 제공

비활성 데이터를 읽을 수 없는 경우처럼 요청을 항상 단일 클러스터에 라우팅해야 하는 경우도 있습니다. 하지만 이때도 한 클러스터로 요청을 처리하고 다른 클러스터는 실시간에 가까운 백업으로 유지해 복제를 사용할 수 있습니다. 서빙 클러스터를 사용할 수 없는 경우 직접 백업 클러스터로 장애 조치하여 다운타임을 최소화할 수 있습니다. 사용 사례 구현 자세히 알아보기

데이터를 전 세계에 배치

전 세계 위치에 복제를 설정하면 데이터를 고객 가까이에 배치할 수 있습니다. 예를 들어 미국, 유럽, 아시아에 복제 클러스터가 있는 인스턴스를 만들고 애플리케이션 트래픽을 가장 가까운 클러스터로 라우팅하도록 앱 프로필을 설정할 수 있습니다. 사용 사례 구현 자세히 알아보기

일관성 모델

이 섹션에서는 사용하는 라우팅 정책에 따라 Bigtable에서 복제에 제공할 수 있는 일관성 모델을 설명합니다.

eventual consistency

기본적으로 Bigtable의 복제는 eventual consistency를 갖게 됩니다. 즉, 클러스터 한 개에 변경사항을 기록하면 클러스터 간에 변경사항이 복제된 후에만 인스턴스의 다른 클러스터에서 변경사항을 읽을 수 있다는 의미입니다.

인스턴스가 응답하면 복제는 일반적으로 시간 단위가 아닌 초 또는 분 단위로 지연됩니다. 하지만 클러스터에 데이터를 대량으로 기록하는 경우 또는 클러스터가 과부하 상태이거나 일시적으로 사용 불가능한 경우에는 복제하는 데 시간이 오래 걸릴 수 있습니다. 또한 클러스터가 서로 멀리 떨어져 있는 경우에도 복제에 더 많은 시간이 소요될 수 있습니다. 따라서 읽고 있는 내용이 최신 기록 값이라고 가정하거나 기록 후 몇 초 만에 Bigtable에 변경사항이 복제되었을 것이라고 가정하는 것은 일반적으로 안전하지 않습니다.

작성한 항목을 읽을 수 있는 일관성

단일 클러스터 라우팅으로 읽기-쓰기 일관성을 얻을 수 있으며, 행 어피니티 라우팅과 함께 멀티 클러스터 라우팅을 사용하거나 인스턴스의 클러스터가 각각 다른 리전에 있는 경우 높은 읽기-쓰기 일관성 비율을 얻을 수 있습니다.

단일 클러스터 라우팅

단일 클러스터 라우팅을 사용하는 경우 복제가 사용 설정된 경우 Bigtable은 read-your-writes consistency를 제공할 수 있습니다. 이 일관성 모델을 사용하면 애플리케이션이 최근 기록 이전의 데이터를 절대 읽지 않습니다.

사용하는 각 앱 프로필은 단일 클러스터 라우팅용으로 구성되어야 하며 모든 앱 프로필은 요청을 동일한 클러스터로 라우팅해야 합니다. 인스턴스의 추가 클러스터를 동시에 다른 목적으로 사용할 수 있습니다.

리전당 클러스터 1개가 있는 멀티 클러스터 라우팅

멀티 클러스터 라우팅을 사용하면 Bigtable은 항상 요청을 가장 가까운 클러스터로 라우팅합니다. 인스턴스의 각 클러스터가 서로 다른 Bigtable 리전에 있고 멀티 클러스터 라우팅용으로 구성된 앱 프로필을 사용하는 경우 장애 조치가 발생하지 않는 한 데이터는 소스 리전 내에서 작성한 항목을 읽을 수 있는 일관성을 갖습니다.

행 어피니티 라우팅

리전에 클러스터가 두 개 이상 있는 인스턴스로의 멀티 클러스터 라우팅을 통해 작성한 항목을 읽을 수 있는 일관성의 비율을 높이려면 행 어피니티 라우팅 (고정 라우팅)용으로 구성된 앱 프로필을 사용하면 됩니다.

행 어피니티 라우팅을 사용하면 Bigtable은 요청의 행 키를 기반으로 단일 행 읽기 및 쓰기 요청을 특정 클러스터로 자동으로 라우팅합니다. 행 키와 클러스터 간의 매핑은 수동으로 설정할 수 없습니다. 클러스터가 비정상 상태이거나, 네트워크 문제가 있거나, 클러스터에 요청이 너무 많이 수신되는 등 다양한 이유로 요청이 여전히 실패할 수 있으므로 일관성이 보장되지는 않습니다.

강력한 일관성

일부 복제 사용 사례의 경우 Bigtable은 strong consistency를 제공하므로 모든 애플리케이션에 데이터가 동일한 상태로 표시됩니다. strong consistency를 달성하기 위해 앞서 설명된 작성한 항목을 읽을 수 있는 일관성을 제공하는 단일 클러스터 라우팅 앱 프로필 구성을 사용하지만, 인스턴스의 추가 클러스터를 사용하려면 먼저 다른 클러스터로 장애 조치해야 합니다. 복제 설정 예시를 검토하여 사용 사례에 사용할 수 있는지 확인하세요.

충돌 해결 방법

Bigtable 테이블의 각 셀 값은 4-튜플(row key, column family, column qualifier, timestamp)로 고유하게 식별됩니다. 이러한 식별자에 대한 자세한 내용은 Bigtable 스토리지 모델을 참조하세요. 드물지만 정확히 4-튜플이 포함된 쓰기 2회가 서로 다른 두 클러스터로 전송되는 경우 Bigtable은 서버측 시간에 기반한 내부 마지막 쓰기 성공 알고리즘을 사용하여 충돌을 자동으로 해결합니다. Bigtable '마지막 쓰기 성공' 구현은 확정적이며 복제가 따라잡으면 모든 클러스터가 4-튜플에 대해 동일한 값을 갖습니다.

애플리케이션 프로필

인스턴스에서 복제를 사용하는 경우 애플리케이션 프로필이나 앱 프로필을 사용하여 라우팅 정책을 지정합니다. 앱 프로필은 읽기-수정-쓰기 작업(증분 및 추가 포함) 및 검사 및 변형 작업(조건부 변이 또는 조건부 작성이라고도 함)을 포함하는 단일 행 트랜잭션을 수행할 수 있는지도 결정합니다.

자세한 내용은 애플리케이션 프로필을 참조하세요. 일반적인 사용 사례를 구현할 수 있는 설정에 대한 예시는 복제 구성 예시를 참조하세요.

라우팅 정책

모든 앱 프로필에는 애플리케이션으로부터 들어오는 요청을 처리하는 클러스터를 제어하는 라우팅 정책이 있습니다. 라우팅 정책 옵션에는 다음이 포함됩니다.

  • 단일 클러스터 라우팅: 모든 요청을 지정한 단일 클러스터로 보냅니다.
  • 멀티 클러스터 라우팅:
    • 모든 클러스터 라우팅: 인스턴스에서 가장 가까운 클러스터로 요청을 전송합니다.
    • 클러스터 그룹 라우팅: 모든 요청을 지정한 클러스터로 제한합니다.
    • 행 어피니티 라우팅: 요청의 행 키를 기반으로 단일 행 읽기 또는 쓰기 요청을 특정 클러스터로 전송합니다. 자세한 내용은 행 어피니티 라우팅을 참고하세요.

장애 조치

Bigtable 클러스터가 응답하지 않을 경우 복제본이 있으면 수신 트래픽을 같은 인스턴스의 다른 클러스터로 장애 조치할 수 있습니다. 장애 조치는 애플리케이션이 사용하는 앱 프로필과 앱 프로필 구성 방식에 따라 수동 또는 자동으로 수행될 수 있습니다. 자세한 내용은 장애 조치를 참고하세요.

복제가 사용 설정된 경우 행 범위 삭제

Cloud Bigtable Admin API를 사용하면 row key를 기반으로 테이블에서 연속된 행 범위를 삭제할 수 있습니다. 복제를 사용하지 않는 인스턴스에서는 Bigtable이 행을 빠르고 효율적으로 삭제할 수 있습니다. 하지만 복제가 활성화되었을 때는 행 범위를 삭제하면 훨씬 느리고 비효율적입니다.

다음 단계