복제 구성 예시

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

이 페이지에서는 다른 사용 사례에 사용할 설정을 결정하는 방법도 설명합니다.

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

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

대부분의 경우 인스턴스 클러스터에 자동 확장을 사용 설정합니다. 자동 확장을 사용하면 Bigtable이 워크로드를 기준으로 자동으로 노드를 클러스터에 추가하고 삭제할 수 있습니다.

대신 수동 노드 할당을 선택하면 각 클러스터가 애플리케이션에서 수신하는 부하 외에도 복제를 처리할 수 있도록 인스턴스의 모든 클러스터에 충분한 노드를 프로비저닝합니다. 클러스터에 노드가 부족하면 복제 지연이 증가할 수 있고 메모리 축적으로 인해 클러스터에서 성능 문제가 발생할 수 있으며 인스턴스의 다른 클러스터에 대한 쓰기가 거부될 수 있습니다.

이 문서의 예시에서는 인스턴스 만들기를 설명하지만 클러스터를 기존 인스턴스에 추가할 수도 있습니다.

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

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

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

  1. 클러스터가 2개 있는 인스턴스를 만듭니다.

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

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

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

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

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

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

  1. 클러스터가 3개 있는 인스턴스를 만듭니다.

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

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

    • live-traffic-app-a: 애플리케이션에서 cluster-a로 단일 클러스터 라우팅
    • live-traffic-app-b: 애플리케이션에서 cluster-b로 단일 클러스터 라우팅
    • batch-analytics: 일괄 분석 작업에서 cluster-c로 단일 클러스터 라우팅

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

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

고가용성(HA) 만들기

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

고가용성(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와 작성한 항목을 읽을 수 있는 일관성을 모두 제공합니다. 필요한 경우 앱 프로필에서 단일 행 트랜잭션을 사용 설정할 수 있습니다.

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

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

  2. Google Cloud 콘솔을 사용하여 인스턴스의 클러스터를 모니터링하고 클러스터 하나에서만 들어오는 요청을 처리하는지 확인합니다.

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

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

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

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

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

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

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

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

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

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

  1. 클러스터 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 영역에 위치함

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

비즈니스 요구사항에 따라 이 사용 사례에 멀티 클러스터 라우팅 또는 단일 클러스터 라우팅 중 하나를 사용할 수 있습니다. 멀티 클러스터 라우팅을 사용하면 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 리전에 클러스터가 있는 인스턴스를 만들 수 있으며, 데이터는 자동으로 각 리전에 복제됩니다.

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

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

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

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

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

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

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

기타 사용 사례

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

다음 단계