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