복제 구성 예시

이 페이지에서는 일반적인 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) 만들기

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

고가용성(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: 아시아에 있는 클러스터로 단일 클러스터 라우팅

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

기타 사용 사례

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

다음 단계