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