Cloud Bigtable 성능 이해

이 페이지에서는 최적 조건에서 Cloud Bigtable이 제공할 수 있는 대략적인 성능, 성능에 영향을 줄 수 있는 요소, Cloud Bigtable 성능 문제 테스트 및 문제해결을 위한 팁에 대해 설명합니다.

일반적인 워크로드의 성능

Cloud Bigtable은 예측 가능하며 선형적으로 확장되는 성능을 제공합니다. 아래 설명한 느린 성능의 원인을 방지하면 각 Cloud Bigtable 노드는 클러스터에 사용되는 스토리지 유형에 따라 다음과 같은 대략적인 처리량을 제공할 수 있습니다.

스토리지 유형 읽기   쓰기   스캔
SSD 초당 최대 10,000 행 또는 초당 최대 10,000 행 또는 초당 최대 220MB
HDD 초당 최대 500 행 또는 초당 최대 10,000 행 또는 초당 최대 180MB

이 예상은 각 행에 1KB의 데이터가 포함되어 있다고 가정합니다.

일반적으로 클러스터 성능은 클러스터에 추가되는 노드에 비례하여 확장됩니다. 예를 들어 10개 노드가 포함된 SSD 클러스터를 만들 경우 클러스터가 일반적인 읽기 전용 또는 쓰기 전용 워크로드에 최대 초당 100,000행을 지원할 수 있습니다.

Cloud Bigtable 용량 계획

높은 처리량과 짧은 지연 시간의 절충안

Cloud Bigtable 클러스터를 계획할 때 처리량과 지연 시간 간의 절충안을 이해하는 것이 중요합니다. Cloud Bigtable은 광범위한 애플리케이션에서 사용되며 사용 사례마다 최적화 목표가 다를 수 있습니다. 예를 들어 일괄 데이터 처리 작업의 경우, 지연 시간보다 처리량을 더 중요하게 생각할 수도 있습니다. 반면 사용자 요청을 처리하는 온라인 서비스는 처리량보다 적은 지연 시간을 우선시할 수 있습니다. 따라서 용량을 적절하게 계획하는 것이 중요합니다.

해당 일반적인 워크로드의 성능 섹션은 처리량 우선순위를 설정할 때 달성할 수 있지만, 지연 시간에 민감한 애플리케이션의 경우 이러한 부하의 Cloud Bigtable에 대한 꼬리 지연 시간이 너무 길 수 있습니다. 일반적으로 Cloud Bigtable은 클러스터의 CPU 부하가 70% 미만이면 최적의 지연 시간을 제공합니다. 그러나 지연 시간에 민감한 애플리케이션의 경우 애플리케이션의 최대 Cloud Bigtable QPS에 최소 2배의 용량을 계획하는 것이 좋습니다. 이 용량을 사용하면 Cloud Bigtable 클러스터가 CPU 부하의 50% 미만에서 실행되므로 프런트엔드 서비스에 짧은 지연 시간을 제공할 수 있습니다. 또한 이 용량은 트래픽 급증 또는 키 액세스 핫스팟에 대한 버퍼를 제공하여 클러스터 노드 간에 트래픽이 불균형하게 발생할 수 있습니다.

Cloud Bigtable에 대해 일반적인 워크로드 실행

용량 계획 시 항상 Cloud Bigtable 클러스터에 대해 자체 일반적인 워크로드를 실행하여 애플리케이션에 최적의 리소스 할당을 파악할 수 있습니다.

Google의 PerfKit BenchmarkerYCSB를 사용하여 클라우드 서비스를 벤치마킹합니다. Cloud Bigtable용 PerfKitBenchmarker 가이드에 따라 자신의 워크로드에 대한 테스트를 만들 수 있습니다. 그렇게 할 때 생성된 벤치마크가 프로덕션의 다음 특성을 반영하도록 벤치마킹 구성 yaml 파일의 매개변수를 조정해야 합니다.

  • 표의 총 크기입니다. 비례 배분할 수 있지만 최소 100GB를 사용합니다.
  • 행 데이터 형태(행 키 크기, 열 수, 행 데이터 크기 등)
  • 데이터 액세스 패턴(행 키 배포)
  • 읽기와 쓰기의 혼합

추가 권장사항은 Cloud Bigtable로 성능 테스트를 참조하세요.

느린 성능의 원인

위에 표시된 예상치보다 Cloud Bigtable의 실행 속도가 느려질 수 있는 몇 가지 요인이 있습니다.

  • 테이블 스키마가 올바르게 설계되지 않은 경우. Cloud Bigtable에서 좋은 성능을 얻기 위해서는 각 테이블 간에 읽기 및 쓰기를 고르게 분배할 수 있도록 스키마를 설계하는 것이 필수적입니다. 자세한 내용은 스키마 설계를 참조하세요.
  • Cloud Bigtable 테이블의 행에는 많은 양의 데이터가 포함되어 있습니다. 위에 표시된 성능 예상치는 각 행에 1KB의 데이터가 포함되어 있다고 가정합니다. 행당 더 많은 양의 데이터를 읽고 쓸 수 있지만 행당 데이터 양이 증가하면 초당 행 수는 감소합니다.
  • Cloud Bigtable 테이블의 행에는 매우 많은 수의 셀이 포함되어 있습니다. Cloud Bigtable이 행에서 각 셀을 처리하려면 시간이 걸립니다. 또한 각 셀은 테이블에 저장되고 네트워크를 통해 전송되는 데이터 양에 더 많은 부담을 줍니다. 예를 들어 1KB(1,024바이트)의 데이터를 저장하는 경우, 각각 1바이트를 포함하는 1,024개의 셀에 데이터를 분산시키는 것보다 데이터를 한 셀에 저장하는 것이 훨씬 더 공간 효율적입니다. 필요한 것보다 많은 셀에서 데이터를 분리하면 최상의 성능을 얻지 못할 수도 있습니다. 열에 여러 타임스탬프 버전이 포함되어 있으므로 행에 셀이 많은 경우 최근 값만 유지하는 것이 좋습니다. 이미 존재하는 테이블에 대한 또 다른 옵션은 각 재작성을 통해 이전 버전을 모두 삭제하는 것입니다.
  • Cloud Bigtable 클러스터에 노드가 충분하지 않은 경우. Cloud Bigtable 클러스터가 과부하 상태일 경우, 노드를 추가하면 성능이 향상될 수 있습니다. 클러스터가 과부하 상태인지 여부는 모니터링 도구를 사용하여 확인할 수 있습니다.
  • Cloud Bigtable 클러스터가 최근에 확장 또는 축소된 경우. 확장하기 위해 클러스터의 노드 수를 늘린 후 클러스터 성능이 대폭 향상된 것을 보려면 부하 상태에서 최대 20분이 걸릴 수 있습니다. 축소하기 위해 클러스터의 노드 수를 줄일 때는 지연 시간 급증을 최소화하기 위해 10분 동안 클러스터 크기를 10% 넘게 줄이지 마세요.
  • Cloud Bigtable 클러스터에 HDD 디스크가 사용되는 경우. 대부분의 경우 클러스터에서는 HDD 디스크보다 성능이 상당히 뛰어난 SSD 디스크를 사용해야 합니다. 자세한 내용은 SSD와 HDD 스토리지 중에서 선택을 참조하세요.
  • 네트워크 연결에 문제가 있는 경우. 네트워크 문제로 인해 처리량이 줄어들고 읽기 및 쓰기 작업이 평소보다 오래 걸릴 수 있습니다. 특히 클라이언트가 Cloud Bigtable 클러스터와 동일한 영역에서 실행되지 않거나 클라이언트가 Google Cloud 외부에서 실행되는 경우 문제가 발생할 수 있습니다.

각 워크로드마다 성능이 달라질 수 있으므로 가장 정확한 벤치마크를 얻기 위해서는 자신의 고유 워크로드를 사용하여 테스트를 수행해야 합니다.

복제 및 성능

복제를 사용 설정하면 Cloud Bigtable 인스턴스 성능이 영향을 받습니다. 이러한 영향은 일부 측정항목에는 긍정적이지만 일부 측정항목에는 부정적입니다. 복제를 사용 설정하기 전에 성능에 미치는 잠재적 영향을 이해해야 합니다.

읽기 처리량

특히 멀티 클러스터 라우팅을 사용할 때 복제를 사용하면 읽기 처리량을 향상시킬 수 있습니다. 또한 Cloud Bigtable 데이터가 지리적으로 애플리케이션 사용자와 더 가깝게 배치되므로 읽기 지연 시간을 단축시킬 수 있습니다.

쓰기 처리량

복제를 사용하면 가용성과 읽기 성능을 향상시킬 수 있지만 쓰기 처리량은 늘어나지 않습니다. 하나의 클러스터에 대한 쓰기는 인스턴스의 모든 다른 클러스터에 복제되어야 합니다. 따라서 각 클러스터는 다른 클러스터의 변경사항을 가져오기 위해 CPU 리소스를 소모합니다. 복제하려면 각 클러스터에서 추가 작업을 수행해야 하므로 쓰기 처리량이 실제로 줄어들 수 있습니다.

예를 들어 단일 클러스터 인스턴스가 있고 클러스터에 노드가 3개 있다고 가정합니다.

노드가 3개인 단일 클러스터 인스턴스

클러스터에 노드를 추가하는 경우 쓰기 처리량에 미치는 영향은 두 번째 3노드 클러스터를 인스턴스에 추가하여 복제를 사용 설정하는 경우와 다릅니다.

원본 클러스터에 노드 추가: 클러스터에 노드 3개를 추가하여 총 6개의 노드를 만들 수 있습니다. 인스턴스의 쓰기 처리량은 두 배가 되지만, 한 영역에서만 인스턴스 데이터를 사용할 수 있습니다.

노드가 6개인 단일 클러스터 인스턴스

복제를 사용하는 경우: 노드가 3개 있는 두 번째 클러스터를 추가하여 총 6개의 노드를 만들 수도 있습니다. 이제 인스턴스는 쓰기를 처음 받을 때와 다른 클러스터로 복제할 때 각각 1번씩 각 데이터 조각을 2번 씁니다. 이때 쓰기 처리량은 증가하지 않고 오히려 줄어들 수 있지만, 데이터를 서로 다른 두 영역에서 사용할 수 있는 이점이 있습니다.

노드가 6개인 두 클러스터 인스턴스

이 예에서 각 인스턴스의 클러스터에 노드가 총 6개 있더라도 단일 클러스터 인스턴스는 복제된 인스턴스가 처리할 수 있는 쓰기 처리량의 두 배를 처리할 수 있습니다.

복제 지연 시간

멀티 클러스터 라우팅을 사용하면 Cloud Bigtable의 복제가 eventual consistency를 갖게 됩니다. 일반적으로 거리가 멀어지면 데이터를 복제하는 데 시간이 오래 걸립니다. 복제된 클러스터가 다른 리전에 있으면 일반적으로 동일한 리전에 있는 경우보다 복제 지연 시간이 더 길어집니다.

앱 프로필 및 트래픽 라우팅

사용 사례에 따라 앱 프로필을 한 개 이상 사용하여 Cloud Bigtable 트래픽을 라우팅합니다. 각 앱 프로필에서는 멀티 클러스터 또는 단일 클러스터 라우팅을 사용합니다. 선택한 라우팅에 따라 성능이 영향을 받을 수 있습니다.

멀티 클러스터 라우팅은 지연 시간을 최소화할 수 있습니다. 멀티 클러스터 라우팅을 사용하는 앱 프로필은 애플리케이션 관점에서 인스턴스 내 가장 가까운 클러스터로 요청을 자동으로 라우팅한 후 쓰기를 인스턴스 내 다른 클러스터에 복제합니다. 이렇게 최단 거리를 자동으로 선택하므로 지연 시간이 최소화됩니다.

단일 클러스터 라우팅을 사용하는 앱 프로필은 단일 클러스터에서 쓰기 후 읽기 시맨틱스를 갖추거나 워크로드 분리와 같은 특정 사용 사례에 적합할 수 있지만 멀티 클러스터 라우팅 사용과 같은 방식으로 지연 시간을 줄이지 못합니다.

사용 사례에 맞게 앱 프로필을 구성하는 방법은 복제 설정 예를 참조하세요.

Cloud Bigtable의 시간별 데이터 최적화 방법

Cloud Bigtable은 각 테이블의 기본 데이터를 저장하기 위해 Cloud Bigtable 클러스터의 노드 간에 이동할 수 있는 여러 태블릿으로 데이터를 분할합니다. Cloud Bigtable은 이러한 저장 방법을 통해 다음과 같은 두 가지 시간별 데이터 최적화 전략을 사용할 수 있습니다.

  1. Cloud Bigtable은 각 Cloud Bigtable 노드에 대략적으로 동일한 양의 데이터를 저장하려고 합니다.
  2. Cloud Bigtable은 모든 Cloud Bigtable 노드 간에 읽기 및 쓰기를 동일하게 분배하려고 합니다.

일부 경우에는 이러한 전략이 서로 충돌할 수 있습니다. 예를 들어 한 태블릿의 행이 매우 자주 읽힐 경우, Cloud Bigtable은 일부 노드가 다른 노드보다 더 많은 데이터를 저장하게 되더라도, 이 태블릿을 고유 노드에 저장할 수 있습니다.

이러한 과정 중에 Cloud Bigtable은 태블릿 크기를 줄이거나 기존 태블릿 내에서 사용량이 많은 행을 격리하기 위해 태블릿을 더 작은 태블릿 여러 개로 분할할 수도 있습니다.

다음 섹션에서는 이러한 각 전략에 대해 자세히 설명합니다.

노드 간 데이터 양 분배

Cloud Bigtable은 사용자가 Cloud Bigtable 테이블에 데이터를 기록할 때 해당 테이블의 데이터를 태블릿으로 분할합니다. 각 태블릿에는 테이블 내의 연속된 행 범위가 포함됩니다.

소량의 데이터만 테이블에 기록한 경우 Cloud Bigtable은 클러스터 내의 단일 노드에 모든 태블릿을 저장합니다.

단일 노드에 태블릿이 4개 있는 클러스터.

더 많은 태블릿이 누적되면, Cloud Bigtable이 이러한 태블릿 중 일부를 클러스터의 다른 노드로 이동하여 클러스터 간에 데이터 양이 고르게 분배되도록 합니다.

추가 태블릿은 여러 노드 간에 분배됩니다.

읽기 및 쓰기를 노드 간에 고르게 분배

스키마 설계가 올바르게 수행된 경우 전체 테이블에 읽기 및 쓰기가 고르게 분배될 것입니다. 하지만 일부 경우에는 특정 행이 다른 행보다 자주 액세스되는 상황을 피할 수 없습니다. Cloud Bigtable은 읽기 및 쓰기를 고려하여 노드 간에 태블릿을 고르게 분배함으로써 이러한 상황에 대처할 수 있게 해줍니다.

예를 들어 클러스터 내의 일부 태블릿에 읽기 작업의 25%가 집중되고, 다른 모든 태블릿에는 읽기가 고르게 분포되었다고 가정해보겠습니다.

48개의 태블릿 중 3개의 태블릿에 25%의 읽기가 집중됩니다.

Cloud Bigtable은 전체 클러스터에서 읽기가 가능한 한 고르게 분포될 수 있도록 기존 태블릿을 다시 분배합니다.

사용량이 많은 3개의 태블릿이 고유 노드에 격리됩니다.

Cloud Bigtable로 성능 테스트

Cloud Bigtable에 의존하는 애플리케이션의 성능 테스트를 실행하는 경우 테스트를 계획하고 실행할 때 다음 가이드라인을 따르세요.

  • 충분한 데이터로 테스트합니다.
    • 프로덕션 인스턴스의 테이블에 노드당 총 100GB 이하의 데이터가 포함된 경우 동일한 양의 데이터로 테이블을 테스트합니다.
    • 테이블에 노드당 100GB가 넘는 데이터가 포함된 경우 노드당 100GB 이상의 데이터가 포함된 테이블로 테스트합니다. 예를 들어 프로덕션 인스턴스에 4개의 노드 클러스터 1개가 있고 인스턴스의 테이블에 총 1TB의 데이터가 포함된 경우 400GB 이상의 테이블을 사용하여 테스트를 실행합니다.
  • 단일 테이블로 테스트
  • 노드당 스토리지 사용량을 권장 수준 아래로 유지합니다. 자세한 내용은 노드당 스토리지 사용량을 참조하세요.
  • 테스트를 진행하기 전에 몇 분 동안 강도 높은 사전 테스트를 실행합니다. 이 단계를 통해 Cloud Bigtable은 관측된 액세스 패턴에 따라 노드 간에 데이터를 균등화할 수 있습니다.
  • 최소 10분 이상 테스트를 실행합니다. 이 단계를 통해 Cloud Bigtable은 데이터를 더욱 최적화할 수 있고, 개발자는 디스크에서 읽기뿐만 아니라 메모리에서 캐시된 읽기도 테스트할 수 있습니다.

성능 문제 해결

Cloud Bigtable이 사용자의 애플리케이션에서 성능 병목 현상을 일으키는 것 같다고 생각될 경우 다음 사항을 모두 확인하세요.

  • 테이블에 대한 Key Visualizer 검사를 확인합니다. Cloud Bigtable용 Key Visualizer 도구는 클러스터의 각 테이블에 대한 사용 패턴을 표시하는 일일 검사를 제공합니다. Key Visualizer는 사용 패턴이 특정 행의 핫스팟 또는 과도한 CPU 사용과 같은 바람직하지 않은 결과를 초래하는지 여부를 확인할 수 있도록 지원합니다. Key Visualizer를 시작하는 방법 알아보기
  • Cloud Bigtable 읽기 및 쓰기를 수행하는 코드를 주석 처리합니다. 이렇게 해서 성능 문제가 사라진다면 현재 Cloud Bigtable을 성능에 최적화된 방식으로 사용하고 있지 않는 것일 수 있습니다. 성능 문제가 계속된다면 Cloud Bigtable와 관련된 문제가 아닐 수 있습니다.
  • 가능한 적은 수의 클라이언트를 만들어야 합니다. Cloud Bigtable용 클라이언트를 만드는 것은 상대적으로 비용이 많이 드는 작업입니다. 따라서 가능한 적은 수의 클라이언트를 만들어야 합니다.

    • 복제 또는 앱 프로필을 사용하여 인스턴스로 보내는 서로 다른 유형의 트래픽을 식별하는 경우 앱 프로필마다 하나의 클라이언트를 만들어 애플리케이션 전체에서 공유합니다.
    • 복제 또는 앱 프로필을 사용하지 않는 경우 단일 클라이언트를 만들어 애플리케이션 전체에서 공유합니다.

    자바용 HBase 클라이언트를 사용하는 경우 클라이언트가 아닌 Connection 객체를 생성하므로 최대한 적은 수의 연결을 만들어야 합니다.

  • 테이블의 여러 행에 대한 읽기 및 쓰기를 수행 중인지 확인합니다. Cloud Bigtable은 테이블 전체에 읽기 및 쓰기가 고르게 분배되어 클러스터의 모든 노드에 워크로드를 분배할 수 있는 경우에 최적의 성능을 발휘합니다. 읽기 및 쓰기를 모든 Cloud Bigtable 노드에 분배할 수 없으면 성능이 저하됩니다.

    소량의 행만 읽고 쓰고 있다면 읽기 및 쓰기가 더욱 고르게 분배되도록 스키마를 다시 설계해야 합니다.

  • 읽기 및 쓰기 성능이 거의 동일한지 확인합니다. 읽기가 쓰기보다 상당히 빠른 경우에는 존재하지 않는 행을 읽으려고 시도하고 있거나, 소량의 행만 포함된 대량의 row key를 읽으려고 시도하고 있는 것일 수 있습니다.

    읽기와 쓰기를 올바르게 비교하기 위해서는 최소 90% 이상의 읽기에서 올바른 결과를 반환하도록 목표를 설정해야 합니다. 또한 대량의 행 키를 읽는 경우에는 존재할 가능성이 낮은 최대 행 수 대신 해당 범위에 있는 실제 행 수를 기준으로 성능을 측정합니다.

  • 데이터에 적합한 유형의 쓰기 요청을 사용합니다. 데이터를 쓰는 최적의 방법을 선택하면 높은 성능을 유지할 수 있습니다.

다음 단계