성능 이해

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

일반적인 워크로드의 성능

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

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

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

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

참고: 이러한 성능 수치는 추정치이며 읽기 전용 또는 쓰기 전용 워크로드를 반영합니다. Bigtable 성능은 워크로드, 스키마 디자인, 데이터세트 특성에 따라 크게 달라집니다. 이러한 성능 수치는 컴퓨팅 요구사항을 추정할 때 시작점으로 도움이 될 수 있지만 정확한 클러스터 크기 조정이나 비용 추정에 사용해서는 안 됩니다.

Bigtable 용량 계획

Bigtable 클러스터를 계획할 때 지연 시간 또는 처리량 중 무엇을 최적화할지 결정합니다. 예를 들어 일괄 데이터 처리 작업의 경우 지연 시간보다 처리량을 더 중요하게 생각할 수도 있습니다. 반면 사용자 요청을 처리하는 온라인 서비스의 경우 처리량보다 낮은 지연시간을 우선시해야 할 수 있습니다. 처리량에 맞게 최적화하면 일반적인 워크로드에 대한 성능 섹션의 수치를 달성할 수 있습니다.

CPU 사용률

대부분의 경우 Bigtable이 사용량에 따라 노드를 추가하거나 삭제할 수 있는 자동 확장을 사용하는 것이 좋습니다. 자세한 내용은 자동 확장을 참조하세요.

자동 확장 타겟을 구성할 때 또는 수동 노드 할당을 선택하는 경우 다음 가이드라인을 따르세요. 이 가이드라인은 인스턴스의 클러스터 수에 관계없이 적용됩니다. 수동 노드 할당이 있는 클러스터의 경우 최적의 성능을 위해 CPU 사용률을 이러한 값 미만으로 유지하는 것을 목표로 클러스터의 CPU 사용률을 모니터링해야 합니다.

최적화 목표	최대 CPU 사용률
처리량	90%
지연 시간	60%

모니터링에 대한 자세한 내용은 Monitoring을 참고하세요.

스토리지 사용량

용량 계획 시 또 다른 고려사항은 스토리지입니다. 클러스터의 스토리지 용량은 스토리지 유형과 클러스터의 노드 수에 따라 결정됩니다. 클러스터에 저장된 데이터 양이 증가하면 Bigtable은 클러스터의 모든 노드에 데이터 양을 분산시켜 스토리지를 최적화합니다.

클러스터의 스토리지 사용량(바이트)을 클러스터의 노드 수로 나눠 노드당 스토리지 사용량을 결정할 수 있습니다. 예를 들어 HDD 노드가 3개이고 데이터가 9TB인 클러스터가 있다고 가정해 보세요. 각 노드는 약 3TB를 저장하며, 이는 노드당 HDD 스토리지 용량 한도인 16TB의 18.75%입니다.

스토리지 사용률이 증가하면 클러스터에 전체 CPU 요구사항을 충족할 수 있는 충분한 노드가 있더라도 워크로드에서 쿼리 처리 지연 시간이 증가할 수 있습니다. 노드당 스토리지가 높을수록 색인 생성과 같은 백그라운드 작업이 더 많이 필요하기 때문입니다. 더 많은 스토리지를 처리하기 위해 백그라운드 작업이 증가하면 지연 시간이 길어지고 처리량이 줄어들 수 있습니다.

자동 확장 설정을 구성할 때는 다음으로 시작합니다. 수동 노드 할당을 선택하는 경우 클러스터의 스토리지 사용률을 모니터링하고 노드를 추가하거나 삭제하여 다음을 유지합니다.

최적화 목표	최대 스토리지 사용률
처리량	70%
지연 시간	60%

자세한 내용은 노드당 스토리지를 참고하세요.

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

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

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

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

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

느린 성능의 원인

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

• 단일 읽기 요청으로 연속되지 않은 다수의 row key 또는 행 범위를 읽습니다. Bigtable은 테이블을 스캔하고 요청된 행을 순차적으로 읽습니다. 이러한 동시 로드 부족은 전체 지연 시간에 영향을 미치며 핫 노드에 발생하는 읽기는 꼬l리 지연 시간을 늘릴 수 있습니다. 자세한 내용은 읽기 및 성능을 참조하세요.
• 테이블 스키마가 정확하게 설계되지 않았습니다. Bigtable에서 좋은 성능을 얻기 위해서는 각 테이블 간에 읽기 및 쓰기를 고르게 분배할 수 있도록 스키마를 설계하는 것이 필수적입니다. 또한 한 테이블의 핫스팟은 동일한 인스턴스 내 다른 테이블의 성능에 영향을 줄 수 있습니다. 자세한 내용은 스키마 설계 권장사항을 참조하세요.
• Bigtable 테이블의 행에는 많은 양의 데이터가 포함되어 있습니다. 위에 표시된 성능 예상치는 각 행에 1KB의 데이터가 포함되어 있다고 가정합니다. 행당 더 많은 양의 데이터를 읽고 쓸 수 있지만 행당 데이터 양이 증가하면 초당 행 수는 감소합니다.
• Bigtable 테이블의 행에는 매우 많은 수의 셀이 포함되어 있습니다. Bigtable이 행에서 각 셀을 처리하려면 시간이 걸립니다. 또한 각 셀은 테이블에 저장되고 네트워크를 통해 전송되는 데이터 양에 더 많은 오버헤드를 줍니다. 예를 들어 1KB(1,024바이트)의 데이터를 저장하는 경우, 각각 1바이트를 포함하는 1,024개의 셀에 데이터를 분산시키는 것보다 데이터를 한 셀에 저장하는 것이 훨씬 더 공간 효율적입니다. 필요한 것보다 많은 셀에서 데이터를 분리하면 최상의 성능을 얻지 못할 수도 있습니다. 열에 여러 타임스탬프 버전이 포함되어 있으므로 행에 셀이 많은 경우 최근 값만 유지하는 것이 좋습니다. 이미 존재하는 테이블에 대한 또 다른 옵션은 각 재작성을 통해 이전 버전을 모두 삭제하는 것입니다.

• 클러스터에 노드가 없습니다. 클러스터의 노드는 컴퓨팅을 제공하여 클러스터가 수신한 읽기 및 쓰기를 처리하고 스토리지를 추적하며 압축과 같은 유지 관리 작업을 수행합니다. 클러스터에 컴퓨팅 및 스토리지에 권장되는 한도를 충족할 만큼 충분한 노드가 있는지 확인해야 합니다. 클러스터가 과부하 상태인지 여부는 모니터링 도구를 사용하여 확인할 수 있습니다.

  • 컴퓨팅 - Bigtable 클러스터의 CPU가 과부하 상태인 경우 노드를 추가하면 워크로드를 더 많은 노드에 분산하여 성능을 향상시킬 수 있습니다.
  • 스토리지 - 노드당 스토리지 사용량이 권장 사용량을 초과하는 경우 클러스터에 요청을 처리하는 데 충분한 CPU가 있더라도 최적의 지연 시간과 처리량을 유지하려면 노드를 추가해야 합니다. 노드당 스토리지를 늘리면 노드당 백그라운드 유지보수 작업량이 증가하기 때문입니다. 자세한 내용은 스토리지 사용량과 성능의 장단점을 참조하세요.

• Bigtable 클러스터가 최근에 확장 또는 축소된 경우. 클러스터의 노드 수가 증가한 후 클러스터 성능이 눈에 띄게 향상될 때까지 부하 상태에서 최대 20분이 걸릴 수 있습니다. Bigtable은 클러스터에서 발생하는 부하를 기준으로 클러스터의 노드를 확장합니다.

  축소하기 위해 클러스터의 노드 수를 줄일 때는 지연 시간 급증을 최소화하기 위해 10분 동안 클러스터 크기를 10% 넘게 줄이지 마세요.

• Bigtable 클러스터에 HDD 디스크가 사용되는 경우. 대부분의 경우 클러스터에서는 HDD 디스크보다 성능이 상당히 뛰어난 SSD 디스크를 사용해야 합니다. 자세한 내용은 SSD와 HDD 스토리지 중에서 선택을 참조하세요.

• 네트워크 연결에 문제가 있는 경우. 네트워크 문제로 인해 처리량이 줄어들고 읽기 및 쓰기 작업이 평소보다 오래 걸릴 수 있습니다. 특히 클라이언트가 Bigtable 클러스터와 동일한 영역에서 실행되지 않거나 클라이언트가 Google Cloud 외부에서 실행되는 경우 문제가 발생할 수 있습니다.

• 복제를 사용 중이지만 애플리케이션이 오래된 클라이언트 라이브러리를 사용하고 있습니다. 복제를 사용 설정한 후 지연 시간이 증가하면 애플리케이션이 사용 중인 Cloud Bigtable 클라이언트 라이브러리가 최신 상태인지 확인합니다. 이전 버전의 클라이언트 라이브러리는 복제를 지원하도록 최적화되지 않을 수 있습니다. 클라이언트 라이브러리의 GitHub 저장소를 찾으려면 Cloud Bigtable 클라이언트 라이브러리를 참조하세요. 여기에서 버전을 확인하고 필요한 경우 업그레이드할 수 있습니다.

• 복제를 사용 설정했지만 클러스터에 노드를 추가하지 않았습니다. 복제를 사용하는 인스턴스에서는 각 클러스터가 애플리케이션에서 수신하는 부하 외에도 복제 작업을 처리해야 합니다. 클러스터를 과도하게 프로비저닝하면 지연 시간이 늘어날 수 있습니다. Google Cloud 콘솔에서 인스턴스의 CPU 사용량 차트를 확인하여 이를 확인할 수 있습니다.

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

콜드 스타트 및 낮은 QPS

콜드 스타트와 낮은 QPS는 지연 시간을 증가시킬 수 있습니다. Bigtable은 자주 액세스되는 큰 테이블에서 가장 효과적입니다. 이런 이유로 일정 기간 사용하지 않은 후 (콜드 스타트) 요청을 보내기 시작하면 Bigtable이 연결을 다시 설정하는 동안 지연 시간이 길어질 수 있습니다. QPS가 낮을 때도 지연 시간이 더 깁니다.

QPS가 낮거나 일정 기간 동안 사용하지 않을 경우 Bigtable 테이블에 요청을 보낸다는 것을 알고 있는 경우 다음 전략을 사용하여 연결을 예열 상태로 유지하면 이러한 긴 지연 시간을 방지할 수 있습니다.

• 항상 낮은 비율의 인위적인 트래픽을 테이블에 전송합니다.
• 안정적인 QPS가 풀을 활성 상태로 유지하도록 연결 풀을 구성합니다.

2.18.0 버전 이전의 Java용 Cloud Bigtable 클라이언트 버전을 사용하는 경우 채널 새로고침을 사용 설정할 수 있습니다. 이후 버전에서는 채널 가격 책정이 기본적으로 사용 설정됩니다.

콜드 스타트 또는 낮은 QPS 기간 중에는 Bigtable에서 반환하는 오류 수가 오류를 반환하는 작업의 비율보다 관련성이 높습니다.

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

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

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

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

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

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

노드 간 데이터 양 분배

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

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

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

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

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

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

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

Bigtable로 성능 테스트

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

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

성능 문제 해결

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

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

• 가능한 적은 수의 클라이언트를 만들어야 합니다. Bigtable용 클라이언트를 만드는 것은 상대적으로 비용이 많이 드는 작업입니다. 따라서 가능한 적은 수의 클라이언트를 만들어야 합니다.

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

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

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

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

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

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

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

• 단일 행의 지연 시간을 확인합니다. ReadRows 요청을 보낼 때 예기치 않은 지연 시간을 발견하면 요청에서 첫 번째 행의 지연 시간을 확인하여 원인을 정밀하게 파악할 수 있습니다. 기본적으로 ReadRows 요청의 전체 지연 시간에는 요청의 모든 행에 대한 지연 시간과 행 간의 처리 시간이 포함됩니다. 전체 지연 시간이 길지만 첫 번째 행 지연 시간이 짧다면 지연 시간이 Bigtable 문제가 아닌 요청 수 또는 처리 시간으로 인해 발생한다는 의미입니다.

  Java용 Bigtable 클라이언트 라이브러리를 사용하면 클라이언트 측 측정항목을 사용 설정한 후 Google Cloud 콘솔 측정항목 탐색기에서 read_rows_first_row_latency 측정항목을 볼 수 있습니다.

• 워크로드마다 별도의 앱 프로필 사용. 새 워크로드를 추가한 후 성능 문제가 발생하면 새 워크로드에 대해 새 앱 프로필을 만듭니다. 그런 후 앱 프로필에 대해 개별적으로 측정항목을 모니터링하여 추가적으로 문제 해결을 수행할 수 있습니다. 여러 앱 프로필을 사용하는 것이 권장되는 이유에 관한 자세한 내용은 앱 프로필 작동 방식을 참고하세요.

• 클라이언트 측 측정항목 사용 설정하기. 클라이언트 측 측정항목을 설정하여 성능 문제를 최적화하고 해결하는 데 도움을 받을 수 있습니다. 예를 들어 Bigtable은 균일하게 분산된 높은 QPS에서 가장 잘 작동하므로 소량의 일부 요청에 대해 P100(최대) 지연 시간이 증가해도 Bigtable에서 더 큰 성능 문제가 발생한다는 의미는 아닙니다. 클라이언트 측 측정항목은 요청 수명 주기에서 지연 시간을 일으킬 수 있는 부분에 대한 유용한 정보를 제공할 수 있습니다.

다음 단계

• Bigtable 스키마 설계 방법에 대해 알아봅니다.
• Bigtable 성능 모니터링 방법을 확인합니다.
• Key Visualizer로 문제를 해결하는 방법을 알아봅니다.
• 노드를 프로그래매틱 방식으로 Bigtable 클러스터에 추가하는 샘플 코드를 확인합니다.