Cloud Bigtable Hotspot 제거

Cloud Bigtable(이하 Bigtable)의 성능이 저하될 수 있는 요인은 여러 가지가 있습니다. 다양한 성능 문제를 해결하기 위해 bigtable은 클러스터에서 hot tablet을 식별하고 관찰할 수 있는 기능을 제공합니다. 본 글에서는 bigtable의 hot tablet을 식별하는 방법과 제거하는 방법에 대해서 사용 사례를 통해 설명드리겠습니다.Cloud Bigtable(이하 Bigtable)의 성능이 저하될 수 있는 요인은 여러 가지가 있습니다. 다양한 성능 문제를 해결하기 위해 bigtable은 클러스터에서 hot tablet을 식별하고 관찰할 수 있는 기능을 제공합니다. 본 글에서는 bigtable의 hot tablet을 식별하는 방법과 제거하는 방법에 대해서 사용 사례를 통해 설명드리겠습니다.

Bigtable의 테이블은 쿼리 워크로드의 균형을 맞추기 위해 tablet이라는 연속 행 블록으로 샤딩됩니다. 각 tablet은 bigtable의 각 노드와 연결되며, tablet 행 작업은 노드에서 수행됩니다. 성능, 확장성을 최적화하기 위해 액세스 패턴을 기반으로 tablet이 분할되거나 다른 노드로 이동하며, 사용자 액세스 패턴에 따라 tablet이 노드 간에 분할 및 재조정됩니다.

Hot tablet은 노드와 연결된 다른 tablet보다, 지나치게 많은 CPU를 사용하는 tablet입니다. Hot tablet은 특정 데이터 포인트에 대한 예상치 못한 많은 양의 요청 또는 초기 스키마 설계 중 고르지 않은 테이블 모델링으로 인해 발생할 수 있습니다. 이 불균형한 노드 사용은 더 높은 대기 시간 및 복제 지연을 유발할 수 있으며, 이는 hot spot이라고 표현합니다. 이 경우에 사용할 수 있는 완화 기술에 대해 알아보겠습니다.

[그림 1]

[그림 1]과 같이 몇 시간 동안 P99 지연 시간이 증가한 경우가 있다고 가정해 봅시다. 이는 CPU 초과 사용으로 인해 발생할 수 있으며, 워크로드가 클러스터의 권장 사용 제한을 초과함을 의미합니다. CPU 초과 사용률은 일반적으로 클러스터가 과소 프로비저닝되었음을 의미하며, 클러스터에 수동으로 더 많은 노드를 추가하거나 자동 확장을 사용하여 노드를 자동으로 추가하여 해결할 수 있습니다.
CPU 초과 사용이 근본적인 문제인지 확인하기 위해 이 클러스터의 CPU 사용률을 살펴볼 필요가 있습니다.

[그림 2]

만약 [그림 2]와 같이 클러스터의 평균 CPU 사용률이 권장 한도인 70% 보다 낮고, hottest node의 CPU 사용률은 거의 100%와 같이 실행될 경우에는, hot tablet을 확인해 볼 필요가 있습니다. 이와 같이 평균 node와 hottest node 사이의 CPU 사용률의 큰 차이는 hot spot의 강력한 표시라고 볼 수 있습니다.

1) Hot Tablet 확인

다음을 사용하여 hot tablet 목록을 확인할 수 있습니다.

• Google Cloud CLI
• Cloud Bigtable Admin API
• Cloud Bigtable 클라이언트 라이브러리

Google Cloud CLI를 사용하기 위해서는 gcloud CLI를 설치해야 합니다.

특정 클러스터의 hot tablet 목록을 보려면, Cloud Shell 또는 로컬 터미널 창에서 hot-tablets list 명령어를 실행합니다.

Unsetgcloud bigtable hot-tablets list CLUSTER_ID –instance INSTANCE_ID

다음을 바꿉니다.

• CLUSTER_ID: 클러스터의 영구 식별자
• INSTANCE_ID: 인스턴스의 영구 식별자

Hot tablet은 CPU 사용량을 기준으로 내림차순으로 출력되며, 출력 예시는 아래와 같습니다.

• TABLE : Hot tablet과 연결된 테이블의 ID입니다.
• CPU_USAGE : 1분 간격으로 Hot tablet과 연결된 노드의 평균 CPU 사용률을 백분율로 표시합니다. 이 비율은 시작 시간부터 종료 시간까지 쓰기 CPU와 읽기 CPU의 합계의 평균입니다.
• START_TIME : Hot tablet 기간의 시작 시간입니다.
• END_TIME  :Hot tablet 기간의 종료 시간입니다.
• START_KEY : Hot tablet의 첫 번째 row key입니다.
• END_KEY : Hot tablet의 마지막 row key입니다.

2) Hot Spot 해결

위의 예시에서 확인되는 hot spot을 해결하기 위해서는 두 가지 방법을 고려할 수 있습니다.

1. 격리/조절할 다운스트림 유저/워크로드 식별
2. Row key 재설계

위의 두 가지 방법에 대한 자세한 설명은 아래와 같습니다.

1. 격리/조절할 다운스트림 유저/워크로드 식별 : user432958에서 user433124까지(출력 첫 번째 항목) row key에 해당하는 사용자와 연결된 트래픽을 격리하거나 조절할 수 있습니다. 또한, 출력 두 번째 항목은 user312932에서 user312932\000까지 단일 행만 표시됩니다. 이는 가능한 가장 작은 tablet 크기입니다. 단일 row key에서 과도하게 쓰기/읽기는 단일 행 tablet으로 이어집니다. 이 문제를 해결하기 위해 user312932와 관련된 트래픽을 격리하거나 조절하여 hot tablet을 완화할 수 있습니다.
2.  Row key를 재설계하여 테이블 쿼리가 row key 공간 전체에, 보다 고르게 분산되도록 하여 로드 밸런싱 및 tablet 분할을 개선할 수 있습니다. <user-id>를 row key로 사용하면 모든 사용자 관련 정보가 단일 행에 저장됩니다. 이는 관련 없는 데이터를 함께 그룹화하고 잠재적으로 여러 워크플로가 동일한 행에 액세스하도록 하는 안티 패턴입니다. 고려해야 할 대체 row key 디자인은 <workload-type>:<user-id> 또는 <workload-type>:<user-id>:<timestamp>입니다.

1) Key Visualizer

Hot tablet 목록을 key visualizer의 히트맵과 함께 사용할 수 있습니다. Key visualizer는 키 공간 액세스 패턴을 전체적으로 관찰하는 데 적합한 도구입니다.

Key visualizer에서 히트맵을 검사한 후 특정 hot spot을 추가로 살펴볼 수 있습니다. Key visualizer는 몇 주 동안 실행되며, hot spot의 데이터가 15분 간격으로 집계됩니다. 또한 여러 태블릿이 같은 key visualizer 키 공간에 결합될 수 있습니다.

2) 수명이 짧은 단기 Hot Spot

그러나 좁은 key 범위에서 burst CPU 사용하는 경우에는 key visualier로 진단이 어려울 수 있습니다. 이 경우는 수명이 짧은 hot spot을 발생시키고 P99 대기시간을 높아지게 할 수 있으며, 이러한 유형의 hot spot은 key visualizer로 진단하기 어려울 수 있습니다. Key visualizer의 최소 세분성이 15분이며 일시적인 hot spot을 표시하지 않을 수 있기 때문입니다. Key visualizer는 지속적이고 수명이 긴 hot spot을 식별하는 데 탁월한 도구이지만, 보다 세분화된 burst 사용을 식별하지 못할 수 있습니다.

[그림 3]

[그림 4]

[그림 3]과 같이 지연 시간이 급증하여 hottest node의 CPU 사용률을 확인했으나, [그림 4]와 같이 CPU 사용률이 권장량보다 낮은 경우가 있을 수 있습니다. 이는 수명이 긴 hot spot은 없음을 나타내지만 키 범위 내에서 일시적인 hot spot을 나타낼 수 있습니다. 이러한 경우에는 key visualizer에서 진단이 어려울 수 있습니다.

[그림 5]

[그림 5]와 같이 단기 hot spot이 발생한 경우에는 key visualizer에서 확인되지 않을 수 있습니다. 만약 단기 hot spot이 발생한 경우에는 3-a에서의 gcloud 명령어를 통해 단기 hot spot을 식별할 수 있습니다.

만약 하나의 클러스터에 여러 개의 테이블을 가지고 있는 경우에는 key visualizer를 통해 hot spot을 식별하기 어려울 수 있습니다. Key visualizer는 테이블 수준에서 작동하기 때문입니다. 따라서 테이블이 여러 개 있는 클러스터의 경우에는, 클러스터 수준에서 작동하는 3-a에서의 gcloud 명령어를 통해 CPU 사용량이 많은 테이블을 식별할 수 있습니다.