라우팅 옵션
요청을 애플리케이션에서 Bigtable로 전송할 때 Bigtable에 요청을 처리하는 방법을 알려주는 앱 프로필을 사용합니다. 앱 프로필에서 요청에 대한 라우팅 정책을 지정합니다. 복제를 사용하는 인스턴스의 경우 라우팅 정책에서 요청을 수신하는 클러스터와 장애 조치 처리 방법을 제어합니다.
이 문서에서는 표준 앱 프로필에 사용할 수 있는 라우팅 정책을 설명합니다.
라우팅 정책은 Data Boost(프리뷰)를 사용할 수 없는 경우 특히 워크로드 격리 사용 사례에 중요합니다. 요청 우선순위와 함께 구성할 수 있습니다.
라우팅 정책은 복제에 영향을 미치지 않지만 이 페이지를 읽기 전에 Bigtable 복제 작동 방식을 숙지해야 합니다. 장애 조치도 읽어야 합니다.
단일 클러스터 라우팅
단일 클러스터 라우팅 정책은 모든 요청을 인스턴스의 클러스터 하나로 라우팅합니다. 해당 클러스터를 사용할 수 없게 되면 직접 다른 클러스터로 장애 조치해야 합니다.
이는 단일 행 트랜잭션을 사용 설정할 수 있는 유일한 라우팅 정책입니다.
복제된 인스턴스는 일반적으로 eventual consistency를 제공합니다. 하지만 단일 클러스터 라우팅을 사용하도록 해당 워크로드의 앱 프로필을 구성하면 복제된 인스턴스의 워크로드에 작성한 항목을 읽을 수 있는 일관성을 달성할 수 있으므로 읽기 및 쓰기 요청이 같은 클러스터에 전송됩니다. 복제된 인스턴스에 있는 추가 워크로드의 트래픽을 워크로드 요구사항에 따라 인스턴스의 다른 클러스터로 라우팅할 수 있습니다.
멀티 클러스터 라우팅
멀티 클러스터 라우팅 정책은 인스턴스에 전송한 요청을 인스턴스에 클러스터가 있는 가장 가까운 리전으로 라우팅합니다. 클러스터를 사용할 수 없게 되면 트래픽이 자동으로 사용 가능한 가장 가까운 클러스터로 장애 조치됩니다.
이 구성은 eventual consistency를 제공합니다. 멀티 클러스터 라우팅을 사용하면 단일 행 트랜잭션에서 데이터 충돌이 발생할 수 있으므로 멀티 클러스터 라우팅으로 단일 행 트랜잭션을 사용 설정할 수 없습니다. 자세한 내용은 단일 행 트랜잭션을 참조하세요.
고가용성(HA)을 원하는 경우 멀티 클러스터 라우팅을 사용합니다. 권장 인스턴스 구성과 자세한 내용은 고가용성(HA) 만들기를 참조하세요.
멀티 클러스터 라우팅에는 모든 클러스터 및 클러스터 그룹 등 2가지 유형이 있습니다.
모든 클러스터 라우팅
모든 클러스터 라우팅을 통해 인스턴스의 모든 클러스터에서 요청을 수신하고 장애 조치를 수행할 수 있습니다.
클러스터 그룹 라우팅
가능한 장애 조치에서 인스턴스 클러스터를 하나 이상 제외하려면 클러스터 그룹 라우팅을 사용하면 됩니다. 이 형식의 멀티 클러스터 라우팅을 사용하면 앱 프로필에서 트래픽을 보낼 수 있는 클러스터의 하위 집합을 지정할 수 있습니다. 이는 별도의 워크로드에 클러스터를 예약하려는 경우에 유용할 수 있습니다.
단일 행 트랜잭션
Bigtable에서 읽기, 쓰기, 삭제 요청과 같은 변형은 행 수준에서 항상 원자적으로 이루어집니다. 여기에는 동일한 변형 작업에 포함되어 있는 경우에 한해 단일 행의 여러 열에 대한 변형이 포함됩니다. Bigtable에서는 행 2개 이상을 원자적으로 업데이트하는 트랜잭션을 지원하지 않습니다.
그러나 Bigtable은 다른 데이터베이스에서 트랜잭션이 필요한 일부 쓰기 작업을 지원합니다. 사실상 Bigtable은 단일 행 트랜잭션을 사용하여 이러한 작업을 완료하게 됩니다. 이러한 작업에는 읽기 및 쓰기가 포함되며, 모든 읽기 및 쓰기는 원자적으로 실행되지만 행 수준에서만 원자적입니다.
- 읽기-수정-쓰기 작업(증분 및 추가 포함): 읽기-수정-쓰기 작업은 기존 값을 읽고 기존 값을 증분 또는 추가하고 업데이트된 값을 테이블에 기록합니다.
- Check-and-mutate 작업(조건부 변이 또는 조건부 쓰기라고도 함): Check-and-mutate 작업에서 Bigtable은 행을 검사하여 지정된 조건을 충족하는지 확인합니다. 조건을 충족한 경우 Bigtable은 새로운 값을 행에 기록합니다.
단일 행 트랜잭션 간의 충돌
Bigtable 인스턴스의 모든 클러스터는 읽기 및 쓰기를 모두 허용하는 기본 클러스터입니다. 따라서 단일 행 트랜잭션이 필요한 작업은 복제된 인스턴스에서 문제를 일으킬 수 있습니다.
예를 들어 티켓 판매 시스템의 데이터를 저장하는 데 사용하는 테이블이 있다고 가정해 보겠습니다. 정수 카운터를 사용하여 판매된 티켓 수를 저장합니다. 티켓을 판매할 때마다 앱에서 카운터를 1씩 늘리도록 읽기-수정-쓰기 작업을 전송합니다.
인스턴스에 클러스터가 한 개 있으면 단일 클러스터에서 수신한 순서대로 요청을 원자적으로 처리하므로 클라이언트 앱이 동시에 티켓을 판매하고 데이터 손실 없이 카운터를 늘릴 수 있습니다.
반면에 인스턴스에 클러스터가 여러 개 있고 앱 프로필이 멀티 클러스터 라우팅을 허용하는 경우 카운터 증가를 위한 동시 요청이 각각 서로 다른 클러스터로 전송된 후 인스턴스의 다른 클러스터에 복제될 수 있습니다. 서로 다른 클러스터로 라우팅되는 2개의 증가 요청을 동시에 전송하면 서로에 대해 "인식"하지 못한 채 트랜잭션이 완료됩니다. 각 클러스터의 카운터가 1씩 증가합니다. 데이터가 다른 클러스터에 복제되면 Bigtable에서 2씩 증가시키려는 사용자의 의도를 알 수 없습니다.
Bigtable에서는 의도하지 않은 결과를 방지하기 위해 다음을 수행합니다.
- 각 앱 프로필에서 단일 행 트랜잭션을 허용할지 여부를 지정해야 합니다.
- 두 기능을 동시에 사용할 수 있는 안전한 방법이 없기 때문에 다중 클러스터 라우팅을 사용하는 앱 프로필에서 단일 행 트랜잭션을 사용하도록 설정할 수 없습니다.
- 단일 클러스터 라우팅을 사용하고 다른 클러스터를 가리키는 두 개 이상의 다른 앱 프로필에서 단일 행 트랜잭션을 사용하도록 설정하는 경우 경고를 보냅니다. 이러한 유형의 구성을 만들려면 충돌하는 읽기-수정-쓰기 요청이나 검사 및 변형 요청을 다른 클러스터로 보내지 않아야 합니다.