복제 및 성능
복제를 사용 설정하면 Bigtable 인스턴스 성능이 영향을 받습니다. 이러한 영향은 일부 측정항목에는 긍정적이지만 일부 측정항목에는 부정적입니다. 복제를 사용 설정하기 전에 성능에 미치는 잠재적 영향을 이해해야 합니다.
읽기 처리량
특히 멀티 클러스터 라우팅을 사용할 때 복제를 사용하면 읽기 처리량을 향상시킬 수 있습니다. 또한 복제 덕분에 Bigtable 데이터가 지리적으로 애플리케이션 사용자와 더 가깝게 배치되므로 읽기 지연 시간을 단축시킬 수 있습니다.
쓰기 처리량
복제를 사용하면 가용성과 읽기 성능을 향상시킬 수 있지만 쓰기 처리량은 늘어나지 않습니다. 하나의 클러스터에 대한 쓰기는 인스턴스의 모든 다른 클러스터에 복제되어야 합니다. 따라서 각 클러스터는 다른 클러스터의 변경사항을 가져오기 위해 CPU 리소스를 소모합니다. 복제하려면 각 클러스터에서 추가 작업을 수행해야 하므로 쓰기 처리량이 실제로 줄어들 수 있습니다.
예를 들어 단일 클러스터 인스턴스가 있고 클러스터에 노드가 3개 있다고 가정합니다.
클러스터에 노드를 추가하는 경우 쓰기 처리량에 미치는 영향은 두 번째 3노드 클러스터를 인스턴스에 추가하여 복제를 사용 설정하는 경우와 다릅니다.
원본 클러스터에 노드 추가: 클러스터에 노드 3개를 추가하여 총 6개의 노드를 만들 수 있습니다. 인스턴스의 쓰기 처리량은 두 배가 되지만, 한 영역에서만 인스턴스 데이터를 사용할 수 있습니다.
복제를 사용하는 경우: 노드가 3개 있는 두 번째 클러스터를 추가하여 총 6개의 노드를 만들 수도 있습니다. 이제 인스턴스는 쓰기를 처음 받을 때와 다른 클러스터로 복제할 때 각각 1번씩 각 데이터 조각을 2번 씁니다. 이때 쓰기 처리량은 증가하지 않고 오히려 줄어들 수 있지만, 데이터를 서로 다른 두 영역에서 사용할 수 있는 이점이 있습니다.
이 예에서 각 인스턴스의 클러스터에 노드가 총 6개 있더라도 단일 클러스터 인스턴스는 복제된 인스턴스가 처리할 수 있는 쓰기 처리량의 두 배를 처리할 수 있습니다.
복제 지연 시간
멀티 클러스터 라우팅을 사용하면 Bigtable의 복제가 eventual consistency를 갖게 됩니다. 일반적으로 거리가 멀어지면 데이터를 복제하는 데 시간이 오래 걸립니다. 복제된 클러스터가 다른 리전에 있으면 일반적으로 동일한 리전에 있는 경우보다 복제 지연 시간이 더 길어집니다.
노드 사용량
쓰기 처리량에 설명된 대로 인스턴스가 복제를 사용할 때 인스턴스의 각 클러스터는 애플리케이션에서 수신하는 부하 외에도 복제 작업을 처리해야 합니다. 따라서 멀티 클러스터 인스턴스의 클러스터에는 트래픽이 유사한 단일 클러스터 인스턴스의 클러스터보다 더 많은 노드가 필요한 경우가 많습니다.
앱 프로필 및 트래픽 라우팅
사용 사례에 따라 앱 프로필을 한 개 이상 사용하여 Bigtable 트래픽을 라우팅합니다. 각 앱 프로필에서는 멀티 클러스터 또는 단일 클러스터 라우팅을 사용합니다. 선택한 라우팅에 따라 성능이 영향을 받을 수 있습니다.
멀티 클러스터 라우팅은 지연 시간을 최소화할 수 있습니다. 멀티 클러스터 라우팅을 사용하는 앱 프로필은 애플리케이션 관점에서 인스턴스 내 가장 가까운 클러스터로 요청을 자동으로 라우팅한 후 쓰기를 인스턴스 내 다른 클러스터에 복제합니다. 이렇게 최단 거리를 자동으로 선택하므로 지연 시간이 최소화됩니다.
단일 클러스터 라우팅을 사용하는 앱 프로필은 단일 클러스터에서 쓰기 후 읽기 시맨틱스를 갖추거나 워크로드 분리와 같은 특정 사용 사례에 적합할 수 있지만 멀티 클러스터 라우팅 사용과 같은 방식으로 지연 시간을 줄이지 못합니다.
사용 사례에 맞게 앱 프로필을 구성하는 방법은 복제 설정 예를 참조하세요.
행 범위 삭제
작업이 느리고 작업 중 CPU 사용량이 증가하기 때문에 복제를 사용하는 인스턴스에서는 가능한 행 범위를 삭제하지 않는 것이 좋습니다.