복제 구성 예시
이 페이지에서는 일반적인 Bigtable 복제 사용 사례와 이러한 사례에 활용할 수 있는 설정을 설명합니다.
이 페이지에서는 다른 사용 사례에 사용할 설정을 결정하는 방법도 설명합니다.
이 페이지를 읽기 전에 Bigtable 복제 개요를 숙지해야 합니다.
인스턴스에 클러스터를 추가하기 전에 복제된 테이블의 가비지 컬렉션 정책 변경 시 적용되는 제한사항을 숙지해야 합니다.
대부분의 경우 인스턴스 클러스터에 자동 확장을 사용 설정합니다. 자동 확장을 사용하면 Bigtable이 워크로드를 기준으로 자동으로 노드를 클러스터에 추가하고 삭제할 수 있습니다.
대신 수동 노드 할당을 선택하면 각 클러스터가 애플리케이션에서 수신하는 부하 외에도 복제를 처리할 수 있도록 인스턴스의 모든 클러스터에 충분한 노드를 프로비저닝합니다. 클러스터에 노드가 부족하면 복제 지연이 증가할 수 있고 메모리 축적으로 인해 클러스터에서 성능 문제가 발생할 수 있으며 인스턴스의 다른 클러스터에 대한 쓰기가 거부될 수 있습니다.
이 문서의 예시에서는 인스턴스 만들기를 설명하지만 클러스터를 기존 인스턴스에 추가할 수도 있습니다.
일괄 분석 워크로드를 다른 애플리케이션과 격리
대량으로 읽기 작업을 다수 처리하는 일괄 분석 작업과 읽기 및 쓰기를 모두 처리하는 애플리케이션을 하나의 클러스터로 실행하면 대량 일괄 작업으로 인해 애플리케이션 사용자의 작업 속도가 느려질 수 있습니다. 하지만 복제 기능과 함께 단일 클러스터 라우팅이 설정된 앱 프로필을 사용하여 일괄 분석 작업과 애플리케이션 트래픽을 다른 클러스터로 라우팅하면 일괄 처리 작업이 애플리케이션 사용자에게 영향을 주지 않습니다.
클러스터가 2개 있는 인스턴스를 만듭니다.
live-traffic
및batch-analytics
라는 앱 프로필 2개를 만듭니다.클러스터 ID가
cluster-a
및cluster-b
이면live-traffic
앱 프로필은 요청을cluster-a
로 라우팅하고batch-analytics
앱 프로필은 요청을cluster-b
로 라우팅해야 합니다. 이 구성은 동일한 앱 프로필을 사용하는 애플리케이션에 작성한 항목을 읽을 수 있는 일관성을 제공하지만 다른 앱 프로필을 사용하는 애플리케이션에는 제공하지 않습니다.필요한 경우
live-traffic
앱 프로필에서 단일 행 트랜잭션을 사용 설정할 수 있습니다.batch-analytics
앱 프로필은 읽기에만 사용한다고 가정하므로 이 앱 프로필에서는 단일 행 트랜잭션을 사용 설정할 필요가 없습니다.live-traffic
앱 프로필을 사용하여 실시간 트래픽 워크로드를 실행합니다.실시간 트래픽 워크로드가 실행되는 동안
batch-analytics
앱 프로필을 사용하여 읽기 전용 일괄 워크로드를 실행합니다.
큰 워크로드 한 개에서 작은 워크로드 두 개를 격리하려면 다음 안내를 따르세요.
클러스터가 3개 있는 인스턴스를 만듭니다.
이 단계에서는 클러스터 ID가
cluster-a
,cluster-b
,cluster-c
라고 가정합니다.다음과 같은 앱 프로필을 만듭니다.
live-traffic-app-a
: 애플리케이션에서cluster-a
로 단일 클러스터 라우팅live-traffic-app-b
: 애플리케이션에서cluster-b
로 단일 클러스터 라우팅batch-analytics
: 일괄 분석 작업에서cluster-c
로 단일 클러스터 라우팅
실시간 트래픽 앱 프로필을 사용하여 실시간 트래픽 워크로드를 실행합니다.
실시간 트래픽 워크로드를 실행하는 동안
batch-analytics
앱 프로필을 사용하여 읽기 전용 일괄 워크로드를 실행합니다.
고가용성(HA) 만들기
인스턴스에 클러스터가 하나밖에 없으면 데이터 내구성과 가용성은 클러스터가 위치한 영역으로 제한됩니다. 복제는 개별 데이터 복사본을 여러 영역 또는 리전에 저장하고 필요 시 자동으로 클러스터를 변경해 장애 조치를 취하므로 내구성과 가용성이 모두 향상될 수 있습니다.
고가용성(HA) 사용 사례에 맞게 인스턴스를 구성하려면 다중 클러스터 라우팅을 사용하는 새 앱 프로필을 만들거나 다중 클러스터 라우팅을 사용할 수 있도록 기본 앱 프로필을 업데이트합니다. 이 구성은 eventual consistency를 제공합니다. 다중티 클러스터 라우팅을 사용하면 단일 행 트랜잭션에서 데이터 충돌이 발생할 수 있으므로 단일 행 트랜잭션을 사용 설정할 수 없습니다.
가용성을 향상시키는 구성은 다음과 같습니다.
서로 다른 리전 3개 이상에 있는 클러스터(권장 구성). HA에 권장되는 구성은 서로 다른 리전마다 클러스터 N+2개가 있는 인스턴스입니다. 예를 들어 데이터를 처리하는 데 필요한 최소 클러스터 수가 2개인 경우 HA를 유지하려면 클러스터 4개가 있는 인스턴스가 필요합니다. 이 구성은 드물지만 리전 2개를 사용할 수 없게 되더라도 업타임을 제공합니다. 여러 대륙에 클러스터를 분산하는 것이 좋습니다.
구성 예:
cluster-a
가 아이오와의us-central1-a
영역에 위치함cluster-b
가 벨기에의europe-west1-d
영역에 위치함cluster-c
가 타이완의asia-east1-b
영역에 위치함
클러스터 두 개가 동일한 리전의 다른 영역에 위치함. 이 옵션은 리전 가용성 내의 고가용성과 리전 간 복제 비용이 발생하지 않는 장애 조치 기능을 제공하며 장애 조치 지연 시간이 증가하지 않습니다. 복제된 영역을 사용할 수 있는 한 복제된 Bigtable 인스턴스의 데이터를 사용할 수 있습니다.
구성 예시:
cluster-a
가 시드니의australia-southeast1-a
영역에 위치함cluster-b
가 시드니의australia-southeast1-b
영역에 위치함
클러스터 두 개가 서로 다른 리전에 위치함. 이 멀티 리전 구성은 이전의 멀티 영역 구성과 같은 고가용성을 제공하지만 리전 중 하나에 연결할 수 없더라도 데이터를 사용할 수 있습니다.
리전 간 쓰기 복제에 요금이 부과됩니다.
구성 예시:
cluster-a
가 도쿄의asia-northeast1-c
영역에 위치함cluster-b
가 홍콩의asia-east2-b
영역에 위치함
클러스터 두 개가 리전 A에 위치하고 세 번째 클러스터가 리전 B에 위치함. 이 옵션을 사용하면 리전 중 하나에 연결할 수 없더라도 데이터를 사용할 수 있으며, 리전 A에 용량이 추가로 확보됩니다.
리전 간 쓰기 복제에 요금이 부과됩니다. 리전 B에 클러스터가 하나밖에 없으므로 리전 A에 쓰면 요금이 1번 청구됩니다. 리전 A에는 클러스터 2개가 있으므로 리전 B에 쓰면 요금이 2번 청구됩니다.
구성 예:
cluster-a
가 벨기에의europe-west1-b
영역에 위치함cluster-b
가 벨기에의europe-west1-d
영역에 위치함cluster-c
가 핀란드의europe-north1-c
영역에 위치함
실시간에 가까운 백업 제공
비활성 데이터를 읽을 수 없는 경우처럼 요청을 항상 단일 클러스터에 라우팅해야 하는 경우도 있습니다. 하지만 이때도 한 클러스터로 요청을 처리하고 다른 클러스터는 실시간에 가까운 백업으로 유지해 복제를 사용할 수 있습니다. 서빙 클러스터를 사용할 수 없는 경우 직접 백업 클러스터로 장애 조치하여 다운타임을 최소화할 수 있습니다.
이 사용 사례에 맞게 인스턴스를 구성하려면 단일 클러스터 라우팅을 사용하는 앱 프로필을 만들거나 단일 클러스터 라우팅을 사용할 수 있도록 기본 앱 프로필을 업데이트합니다. 앱 프로필에 지정한 클러스터가 수신한 요청을 처리합니다. 다른 클러스터는 장애 조치가 필요한 경우를 대비한 백업으로 작동합니다. 이러한 구성을 활성/비활성 구성이라 하며 strong consistency와 작성한 항목을 읽을 수 있는 일관성을 모두 제공합니다. 필요한 경우 앱 프로필에서 단일 행 트랜잭션을 사용 설정할 수 있습니다.
이 구성을 구현하려면 다음 단계를 따르세요.
단일 클러스터 라우팅을 사용하는 앱 프로필을 사용해 워크로드를 실행합니다.
Google Cloud 콘솔을 사용하여 인스턴스의 클러스터를 모니터링하고 클러스터 하나에서만 들어오는 요청을 처리하는지 확인합니다.
다른 클러스터는 CPU 리소스를 사용하여 복제 및 기타 유지보수 작업을 수행합니다.
인스턴스의 두 번째 클러스터를 가리키도록 앱 프로필을 업데이트합니다.
작성한 항목을 읽을 수 있는 일관성 손실 경고가 표시됩니다. 이는 strong consistency도 손실된다는 의미입니다.
단일 행 트랜잭션을 사용 설정하면 데이터 손실 가능성에 대한 경고도 표시됩니다. 장애 조치가 수행되는 동안 충돌하는 쓰기 작업을 보내면 데이터가 손실됩니다.
계속해서 인스턴스를 모니터링합니다. 두 번째 클러스터가 수신한 요청을 처리하는 것을 확인할 수 있습니다.
고가용성 및 리전 복원력 유지
한 대륙 내 다른 리전 두 곳에 고객이 집중되어 있다고 가정해 보겠습니다. 각각의 집중된 고객에게 Cloud Bigtable 클러스터를 사용하여 고객에게 최대한 가까운 곳에서 서비스를 제공하려 합니다. 각 리전에서 데이터 가용성을 극대화하려 하며 클러스터를 사용할 수 없는 경우에 대비해 장애 조치 옵션을 설정할 수도 있습니다.
이 사용 사례에서는 리전 A와 B 각각에 클러스터가 2개 있는 인스턴스를 만들 수 있습니다. 이 구성은 한 Google Cloud 리전에 연결할 수 없더라도 고가용성을 보장합니다. 또한 영역을 사용할 수 없게 되더라도 리전 복원력이 있으므로 영역의 리전에 있는 다른 클러스터를 계속 사용할 수 있습니다.
비즈니스 요구사항에 따라 이 사용 사례에 멀티 클러스터 라우팅 또는 단일 클러스터 라우팅 중 하나를 사용할 수 있습니다.
이 사용 사례에 맞게 인스턴스를 구성하려면 다음 단계를 따르세요.
클러스터 4개(즉, 리전 A와 B 각각에 2개)가 있는 Bigtable 인스턴스를 만듭니다. 클러스터는 같은 리전에서 서로 다른 영역에 있어야 합니다.
구성 예시:
cluster-a
가 뭄바이의asia-south1-a
영역에 위치함cluster-b
가 뭄바이의asia-south1-c
영역에 위치함cluster-c
가 도쿄의asia-northeast1-a
영역에 위치함cluster-d
가 도쿄의asia-northeast1-b
영역에 위치함
각 리전 근처에 애플리케이션 서버를 배치합니다.
비즈니스 요구사항에 따라 이 사용 사례에 멀티 클러스터 라우팅 또는 단일 클러스터 라우팅 중 하나를 사용할 수 있습니다. 멀티 클러스터 라우팅을 사용하면 Bigtable이 자동으로 장애 조치를 처리합니다. 단일 클러스터 라우팅을 사용하는 경우 개발자가 본인 판단에 따라 다른 클러스터로 장애 조치할 시기를 결정합니다.
단일 클러스터 라우팅 옵션
이 사용 사례에서 영역이나 리전을 사용할 수 없게 될 때 Bigtable 클러스터가 자동으로 장애 조치하는 것을 원하지 않으면 단일 클러스터 라우팅을 사용하면 됩니다. 이 옵션은 Bigtable이 멀리 있는 리전과 트래픽 라우팅을 시작할 때 발생할 수 있는 비용과 지연 시간을 관리하려는 경우나 자신의 판단이나 비즈니스 규칙에 따라 장애 조치 결정을 내리려는 경우에 적합합니다.
이 구성을 구현하려면 인스턴스에 요청을 보내는 각 애플리케이션에 단일 클러스터 라우팅을 사용하는 앱 프로필을 최소 하나 이상 만듭니다. 앱 프로필을 Bigtable 인스턴스의 모든 클러스터로 라우팅할 수 있습니다. 예를 들어 뭄바이에서 애플리케이션 3개를 실행하고 도쿄에서 6개를 실행하는 경우 뭄바이 애플리케이션의 앱 프로필 하나를 asia-south1-a
로 라우팅하고 2개를 asia-south1-c
로 라우팅하도록 구성할 수 있습니다. 도쿄 애플리케이션의 경우 asia-northeast1-a
로 라우팅되는 앱 프로필 3개와 asia-northeast1-b
로 라우팅되는 앱 프로필 3개를 구성합니다.
이렇게 구성하면 클러스터를 사용할 수 없게 될 때 수동 장애 조치를 수행하거나 영역을 다시 사용할 수 있을 때까지 영역에서 데이터를 일시적으로 사용하지 못하도록 할 수 있습니다.
멀티 클러스터 라우팅 옵션
이 사용 사례를 구현하고 애플리케이션이 한 리전에 연결할 수 없을 때 자동으로 Bigtable이 다른 리전으로 장애 조치하도록 하려면 멀티 클러스터 라우팅을 사용합니다.
이 구성을 구현하려면 각 애플리케이션의 멀티 클러스터 라우팅을 사용하는 새 앱 프로필을 만들거나 멀티 클러스터 라우팅을 사용할 수 있도록 기본 앱 프로필을 업데이트합니다.
이 구성은 eventual consistency를 제공합니다. 리전을 사용할 수 없게 되면 Bigtable 요청은 자동으로 다른 리전으로 전송됩니다. 이 경우, 다른 리전으로 전송되는 네트워크 트래픽에 요금이 부과되고 거리가 멀어져 애플리케이션의 지연 시간이 늘어날 수 있습니다.
사용자와 가까운 곳에 데이터 저장
전 세계 사용자를 대상으로 하는 경우 애플리케이션을 사용자 근처에서 실행하고 데이터를 최대한 애플리케이션에 가깝게 배치하면 지연 시간을 단축시킬 수 있습니다. Bigtable을 사용하면 여러 Google Cloud 리전에 클러스터가 있는 인스턴스를 만들 수 있으며, 데이터는 자동으로 각 리전에 복제됩니다.
이 사용 사례에서는 단일 클러스터 라우팅이 설정된 앱 프로필을 사용합니다. 멀티 클러스터 라우팅은 클러스터 간의 거리로 인해 이 사용 사례에 적합하지 않습니다. 클러스터를 사용할 수 없게 되고 멀티 클러스터 앱 프로필이 먼 거리로 트래픽을 자동으로 다시 라우팅하면 애플리케이션의 지연 시간이 지나치게 길어지고 예상치 못한 추가 네트워크 비용이 발생할 수 있습니다.
이 사용 사례에 맞게 인스턴스를 구성하려면 다음 단계를 따르세요.
미국, 유럽, 아시아와 같은 지리적으로 고유한 리전 세 곳에 클러스터가 있는 인스턴스를 만듭니다.
각 리전 근처에 애플리케이션 서버를 배치합니다.
다음과 유사한 앱 프로필을 만듭니다.
clickstream-us
: 미국에 있는 클러스터로 단일 클러스터 라우팅clickstream-eu
: 유럽에 있는 클러스터로 단일 클러스터 라우팅clickstream-asia
: 아시아에 있는 클러스터로 단일 클러스터 라우팅
이 설정에서 애플리케이션은 가장 가까운 클러스터의 앱 프로필을 사용합니다. 각 클러스터에서 처리하는 쓰기 작업은 자동으로 다른 두 클러스터에 복제됩니다.
기타 사용 사례
이 페이지에 설명되지 않은 사용 사례의 경우 다음 질문을 통해 앱 프로필 구성 방법을 결정할 수 있습니다.
읽기-수정-쓰기 작업(증분 및 추가 포함)과 검사 및 변형 작업(조건부 변형 또는 조건부 쓰기라고도 함)과 같은 단일 행 트랜잭션을 수행해야 하나요?
이 경우에는 데이터 손실을 방지하기 위해 앱 프로필에서 단일 클러스터 라우팅을 사용하고 개발자는 장애 조치를 수동으로 처리해야 합니다.
Bigtable에서 장애 조치를 자동으로 처리하기를 원하나요?
그렇다면 앱 프로필에서 다중 클러스터 라우팅을 사용해야 합니다. 클러스터가 수신하는 요청을 처리할 수 없으면 자동으로 Cloud Bigtable이 다른 클러스터로 장애 조치를 수행합니다. 자동 장애 조치에 대해 자세히 알아보기
데이터 손실 방지를 위해 다중 클러스터 라우팅을 사용할 때 단일 행 트랜잭션을 사용할 수 없습니다. 자세히 알아보기
기본 클러스터를 사용할 수 없는 경우를 대비해서 백업 또는 예비 클러스터를 보유하고 싶으신가요?
그렇다면 앱 프로필에서 단일 클러스터 라우팅을 사용하고 필요한 경우 수동으로 백업 클러스터로 장애 조치합니다.
이 구성에서는 필요에 따라 단일 행 트랜잭션을 사용할 수 있습니다.
트래픽 종류에 따라 다른 클러스터로 보내길 원하세요?
그렇다면 앱 프로필에서 단일 클러스터 라우팅을 사용하고 각 유형의 트래픽을 별도의 클러스터에 전달합니다. 필요한 경우 클러스터를 수동으로 변경해 장애 조치를 취합니다.
필요한 경우 앱 프로필에서 단일 행 트랜잭션을 사용할 수 있습니다.