복제 설정 예시

이 페이지에서는 일반적인 Cloud Bigtable 복제 사용 사례와 이러한 사례에 활용할 수 있는 설정을 설명합니다.

이 페이지에서는 여기에 나열되지 않은 사용 사례에 사용할 설정을 결정하는 방법도 설명합니다.

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

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

일괄 분석 워크로드를 다른 애플리케이션과 격리

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

워크로드 두 개를 격리하려면 다음 안내를 따르세요.

  1. 클러스터 2개가 있는 새 인스턴스를 만들거나 기존 인스턴스에 두 번째 클러스터를 추가합니다.

    이 구성에 표준 CPU 사용률 권장사항을 따릅니다.

  2. live-trafficbatch-analytics라는 앱 프로필 2개를 만듭니다.

    클러스터 ID가 cluster-acluster-b이면 live-traffic 앱 프로필은 요청을 cluster-a로 라우팅하고 batch-analytics 앱 프로필은 요청을 cluster-b로 라우팅해야 합니다. 이 구성은 동일한 앱 프로필을 사용하는 애플리케이션에 작성한 항목을 읽을 수 있는 일관성을 제공하지만 다른 앱 프로필을 사용하는 애플리케이션에는 제공하지 않습니다.

    필요한 경우 live-traffic 앱 프로필에서 단일 행 트랜잭션을 사용 설정할 수 있습니다. batch-analytics 앱 프로필은 읽기에만 사용한다고 가정하므로 이 앱 프로필에서는 단일 행 트랜잭션을 사용 설정할 필요가 없습니다.

  3. live-traffic 앱 프로필을 사용하여 실시간 트래픽 워크로드를 실행합니다.

  4. 실시간 트래픽 워크로드가 실행되는 동안 batch-analytics 앱 프로필을 사용하여 읽기 전용 일괄 워크로드를 실행합니다.

  5. 인스턴스 클러스터의 CPU 사용률을 모니터링하고, 필요한 경우 클러스터에 노드를 추가합니다.

  6. 원하는 도구로 클라이언트 측 지연 시간을 모니터링합니다. 자바용 HBase 클라이언트를 사용하는 경우 클라이언트 측 측정항목을 사용하여 지연 시간을 모니터링할 수 있습니다.

큰 워크로드 한 개에서 작은 워크로드 두 개를 격리하려면 다음 안내를 따르세요.

  1. 클러스터 3개가 있는 새 인스턴스를 만들거나 클러스터가 3개가 될 때까지 기존 인스턴스에 클러스터를 추가합니다.

    이 구성에 표준 CPU 사용률 권장사항을 따릅니다.

    이 단계에서는 클러스터 ID가 cluster-a, cluster-b, cluster-c라고 가정합니다.

    같은 애플리케이션을 제공하는 경우 cluster-acluster-b에 같은 수의 노드를 사용합니다. 큰 워크로드를 지원하도록 cluster-c에 더 많은 수의 노드를 사용합니다.

  2. 다음과 같은 앱 프로필을 만듭니다.

    • live-traffic-app-a: 애플리케이션에서 cluster-a로 단일 클러스터 라우팅
    • live-traffic-app-b: 애플리케이션에서 cluster-b로 단일 클러스터 라우팅
    • batch-analytics: 일괄 분석 작업에서 cluster-c로 단일 클러스터 라우팅
  3. 실시간 트래픽 앱 프로필을 사용하여 실시간 트래픽 워크로드를 실행합니다.

  4. 실시간 트래픽 워크로드를 실행하는 동안 batch-analytics 앱 프로필을 사용하여 읽기 전용 일괄 워크로드를 실행합니다.

  5. 인스턴스 클러스터의 CPU 사용률을 모니터링하고, 필요한 경우 클러스터에 노드를 추가합니다.

  6. 원하는 도구로 클라이언트 측 지연 시간을 모니터링합니다. 자바용 HBase 클라이언트를 사용하는 경우 클라이언트 측 측정항목을 사용하여 지연 시간을 모니터링할 수 있습니다.

고가용성 만들기

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

이 사용 사례에 맞게 인스턴스를 구성하려면 멀티 클러스터 라우팅을 사용하는 새 앱 프로필을 만들거나 멀티 클러스터 라우팅을 사용할 수 있도록 기본 앱 프로필을 업데이트합니다. 이 구성은 eventual consistency를 제공합니다. 멀티 클러스터 라우팅을 사용하면 단일 행 트랜잭션에서 데이터 충돌이 발생할 수 있으므로 단일 행 트랜잭션을 사용 설정할 수 없습니다.

가용성을 향상시키는 구성은 다음과 같습니다.

  • 클러스터 두 개가 동일한 리전의 다른 영역에 위치함. 이 옵션은 리전 간 복제 비용을 발생시키지 않고 고가용성 및 장애 조치 기능을 제공합니다. 복제된 영역을 사용할 수 있는 한 복제된 Cloud 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%로 설정하여 시작합니다. 인스턴스의 클러스터를 모니터링하고 필요에 맞게 노드 수를 조정하여 각 클러스터에서 장애 조치를 처리하기에 충분한 리소스가 확보되도록 합니다.

이 사용 사례에 장애 조치를 시뮬레이션하여 애플리케이션을 테스트할 수 있습니다.

  1. 멀티 클러스터 라우팅이 설정된 앱 프로필을 사용하여 테스트 워크로드를 실행합니다.

  2. Google Cloud Console을 사용하여 인스턴스의 클러스터를 모니터링하고 클러스터가 수신한 요청을 처리하는지 확인합니다.

  3. 클러스터 중 하나를 삭제하여 중단을 시뮬레이션합니다.

    이렇게 변경하면 클러스터에 저장된 데이터 복사본도 삭제됩니다.

  4. 계속해서 지연 시간과 오류 발생률을 모니터링합니다. 나머지 클러스터에 CPU 리소스가 충분하다면 수신한 요청을 처리할 수 있어야 합니다.

  5. 인스턴스에 클러스터를 추가하고 계속해서 인스턴스를 모니터링합니다. 새 클러스터에 데이터가 복제되기 시작됩니다.

실시간에 가까운 백업 제공

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

이 사용 사례에 맞게 인스턴스를 구성하려면 단일 클러스터 라우팅을 사용하는 앱 프로필을 만들거나 단일 클러스터 라우팅을 사용할 수 있도록 기본 앱 프로필을 업데이트합니다. 앱 프로필에 지정한 클러스터가 수신한 요청을 처리합니다. 다른 클러스터는 장애 조치가 필요한 경우를 대비한 백업으로 작동합니다. 이러한 구성을 활성/비활성 구성이라 하며 strong consistency와 작성한 항목을 읽을 수 있는 일관성을 모두 제공합니다. 필요한 경우 앱 프로필에서 단일 행 트랜잭션을 사용 설정할 수 있습니다.

이 구성에 표준 CPU 사용률 권장사항을 따릅니다.

이 구성을 구현하려면 다음 단계를 따르세요.

  1. 단일 클러스터 라우팅이 설정된 앱 프로필을 사용하여 워크로드를 실행합니다.

  2. Google Cloud Console을 사용하여 인스턴스의 클러스터를 모니터링하고 클러스터 1개만 수신한 요청을 처리하는지 확인합니다.

    다른 클러스터는 CPU 리소스를 사용하여 복제 및 기타 유지보수 작업을 수행합니다.

  3. 인스턴스의 두 번째 클러스터를 가리키도록 앱 프로필을 업데이트합니다.

    작성한 항목을 읽을 수 있는 일관성 손실 경고가 표시됩니다. 이는 strong consistency도 손실된다는 것을 의미합니다.

    단일 행 트랜잭션을 사용 설정한 경우 데이터 손실 가능성에 대한 경고도 표시됩니다. 장애 조치가 수행되는 동안 충돌하는 쓰기 작업을 보내면 데이터가 손실됩니다.

  4. 계속해서 인스턴스를 모니터링합니다. 두 번째 클러스터가 수신한 요청을 처리하는 것을 확인할 수 있습니다.

고가용성 및 리전 복원력 유지

한 대륙 내 다른 리전 두 곳에 고객이 집중되어 있다고 가정해 보겠습니다. 각각의 집중된 고객에게 Cloud Bigtable 클러스터를 사용하여 고객에게 최대한 가까운 곳에서 서비스를 제공하려 합니다. 각 리전에서 데이터 가용성을 극대화하려 하며 클러스터를 사용할 수 없는 경우에 대비해 장애 조치 옵션을 설정할 수도 있습니다.

이 사용 사례에서는 리전 A와 B에 클러스터가 각각 2개씩 있는 인스턴스를 만들 수 있습니다. 이 구성은 한 Google Cloud 리전에 연결할 수 없더라도 고가용성을 보장합니다. 또한 영역을 사용할 수 없게 되더라도 리전 복원력이 있으므로 영역의 리전에 있는 다른 클러스터를 계속 사용할 수 있습니다.

비즈니스 요구사항에 따라 이 사용 사례에 멀티 클러스터 라우팅 또는 단일 클러스터 라우팅 중 하나를 사용할 수 있습니다.

이 사용 사례에 맞게 인스턴스를 구성하려면 다음 안내를 따르세요.

  1. 클러스터 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 영역에 위치함
  2. 각 리전 근처에 애플리케이션 서버를 배치합니다.

비즈니스 요구사항에 따라 이 사용 사례에 멀티 클러스터 라우팅 또는 단일 클러스터 라우팅 중 하나를 사용할 수 있습니다. 멀티 클러스터 라우팅을 사용하면 Cloud Bigtable이 자동으로 장애 조치를 처리합니다. 단일 클러스터 라우팅을 사용하는 경우 개발자 판단에 따라 다른 클러스터로 장애 조치할 시기를 결정합니다.

멀티 클러스터 라우팅 옵션

이 사용 사례를 구현하고 애플리케이션이 한 리전에 연결할 수 없을 때 자동으로 Cloud Bigtable이 다른 리전으로 장애 조치하도록 하려면 멀티 클러스터 라우팅을 사용합니다.

이 구성을 구현하려면 멀티 클러스터 라우팅을 사용하는 새 앱 프로필을 만들거나 멀티 클러스터 라우팅을 사용할 수 있도록 기본 앱 프로필을 업데이트합니다.

이 구성은 eventual consistency를 제공합니다. 리전을 사용할 수 없게 되면 Cloud Bigtable 요청은 자동으로 다른 리전으로 전송됩니다. 이 경우, 다른 리전으로 전송되는 네트워크 트래픽에 요금이 부과되고 거리가 멀어져 애플리케이션의 지연 시간이 늘어날 수 있습니다.

멀티 클러스터 라우팅이 설정된 앱 프로필을 인스턴스당 한 개만 사용할 수 있으며, 멀티 클러스터 라우팅 프로필과 단일 클러스터 라우팅 프로필을 조합해서 사용할 수 없습니다. 둘 중 하나만 인스턴스에 사용해야 합니다.

처음 인스턴스를 설정할 때는 각 클러스터의 CPU 사용률이 35%를 초과하지 않도록 해야 합니다. 이러한 사용률 목표는 장애 조치가 수행될 때 각 클러스터가 일반적으로 같은 리전의 다른 클러스터에서 처리되는 트래픽을 처리할 수 있게 해줍니다. 트래픽 및 사용량 패턴에 따라 이 사용률 목표를 조정해야 할 수도 있습니다.

이 사용 사례에 장애 조치를 시뮬레이션하여 애플리케이션을 테스트할 수 있습니다.

  1. 테스트 워크로드를 실행합니다.

  2. Cloud Console을 사용하여 인스턴스의 클러스터를 모니터링하고 클러스터 4개 모두가 수신한 요청을 처리하는지 확인합니다.

  3. 리전 A에 있는 클러스터 중 하나를 삭제하여 영역 연결 문제를 시뮬레이션합니다.

    이렇게 변경하면 클러스터에 저장된 데이터 복사본도 삭제됩니다.

  4. 계속해서 남은 클러스터의 지연 시간과 오류 발생률을 모니터링합니다.

    클러스터에 CPU 리소스가 충분하다면 수신하는 요청을 처리할 수 있어야 합니다.

  5. 리전 A에 있는 인스턴스에 클러스터를 추가하고 계속해서 인스턴스를 모니터링합니다.

    새 클러스터에 데이터가 복제되기 시작됩니다.

  6. 리전 A에 있는 두 클러스터를 모두 삭제하여 리전 연결 문제를 시뮬레이션합니다.

    이렇게 변경하면 클러스터에 저장된 데이터 복사본이 삭제됩니다.

  7. 계속해서 남은 클러스터의 지연 시간과 오류 발생률을 모니터링합니다.

    클러스터에 CPU 리소스가 충분하다면 이전에 다른 리전에서 처리한 수신 요청을 처리할 수 있어야 합니다. 클러스터에 리소스가 부족하면 노드 수를 조정해야 할 수도 있습니다.

단일 클러스터 라우팅 옵션

이 사용 사례에서 영역이나 리전을 사용할 수 없게 될 때 Cloud Bigtable 클러스터가 자동으로 장애 조치하는 것을 원하지 않으면 단일 클러스터 라우팅을 사용하면 됩니다. 이 옵션은 Cloud Bigtable이 멀리 있는 리전과 트래픽 라우팅을 시작할 때 발생할 수 있는 비용과 지연 시간을 관리하려는 경우나 자신의 판단이나 비즈니스 규칙에 따라 장애 조치 결정을 내리려는 경우에 적합합니다.

이 구성을 구현하려면 단일 클러스터 라우팅을 사용하는 앱 프로필 4개를 만듭니다. 각 앱 프로필은 Cloud Bigtable 인스턴스의 다른 클러스터로 라우팅합니다.

이 구성에 표준 CPU 사용률 권장사항을 따릅니다.

이렇게 구성하면 클러스터를 사용할 수 없게 될 때 수동 장애 조치를 수행하거나 영역을 다시 사용할 수 있을 때까지 영역에서 데이터를 일시적으로 사용하지 못하도록 할 수 있습니다.

사용자와 가까운 곳에 데이터 저장

전 세계 사용자를 대상으로 하는 경우 애플리케이션을 사용자 근처에서 실행하고 데이터를 최대한 애플리케이션에 가깝게 배치하면 지연 시간을 단축시킬 수 있습니다. Cloud Bigtable을 사용하면 여러 Google Cloud 리전에 클러스터가 있는 인스턴스를 만들 수 있으며, 데이터는 자동으로 각 리전에 복제됩니다.

이 사용 사례에서는 단일 클러스터 라우팅이 설정된 앱 프로필을 사용합니다. 멀티 클러스터 라우팅은 클러스터 간의 거리로 인해 이 사용 사례에 적합하지 않습니다. 클러스터를 사용할 수 없게 되고 멀티 클러스터 앱 프로필이 먼 거리로 트래픽을 자동으로 다시 라우팅하면 애플리케이션의 지연 시간이 지나치게 길어지고 예상치 못한 추가 네트워크 비용이 발생할 수 있습니다.

이 사용 사례에 맞게 인스턴스를 구성하려면 다음 단계를 따르세요.

  1. 미국, 유럽, 아시아와 같은 지리적으로 고유한 리전 세 곳에 클러스터가 있는 인스턴스를 만듭니다.

    이 구성에 표준 CPU 사용률 권장사항을 따릅니다.

  2. 각 리전 근처에 애플리케이션 서버를 배치합니다.

  3. 다음과 유사한 앱 프로필을 만듭니다.

    • clickstream-us: 미국에 있는 클러스터로 단일 클러스터 라우팅
    • clickstream-eu: 유럽에 있는 클러스터로 단일 클러스터 라우팅
    • clickstream-asia: 아시아에 있는 클러스터로 단일 클러스터 라우팅

이 설정에서 애플리케이션은 가장 가까운 클러스터의 앱 프로필을 사용합니다. 각 클러스터에서 처리하는 쓰기 작업은 자동으로 다른 두 클러스터에 복제됩니다.

기타 사용 사례

이 페이지에 설명되지 않은 사용 사례의 경우 다음 질문을 통해 앱 프로필 구성 방법을 결정할 수 있습니다.

다음 단계