Cloud Bigtable 비용 최적화 입문서

  * 본 아티클의 원문은 2021년 2월 6일 Google Cloud 블로그(영문)에 게재되었습니다. 

고객의 다양한 워크로드를 처리하기 위해 Google Cloud에서는 여러 관리형 데이터베이스를 제공합니다. MongoDB, Datastax의 Cassandra, Redis Labs, Neo4j를 포함한 파트너 관리 서비스 외에도 Google Cloud는 관계형 사용 사례를 위한 CloudSQL 및 Cloud Spanner, 문서 데이터를 위한 Firestore 및 Firebase, 인메모리 데이터 관리를 위한 Memorystore, 짧은 지연 시간으로 초당 수백만 개의 요청을 지원하도록 수평 확장이 가능한 와이드 칼럼 키-값 데이터베이스인 Cloud Bigtable 등 일련의 관리형 데이터베이스를 제공하고 있습니다. 

Cloud Bigtable과 같은 완전 관리형 클라우드 컴퓨팅 데이터베이스를 사용하는 조직은 기존 자체 관리형 데이터베이스의 운영 오버헤드 없이 페타바이트 단위의 데이터를 저장하고, 분석하며, 관리할 수 있습니다. 클라우드 데이터베이스는 기본적으로 비용 효율성을 제공하지만 시스템이 계속 성장하고 애플리케이션을 지원하면서 비용을 최적화할 기회가 추가로 발생합니다. 

이 블로그 게시물에서는 Cloud Bigtable의 청구 가능한 구성요소를 검토하고, 다양한 리소스의 변화가 비용에 미칠 수 있는 영향에 대해 살펴보며, 가장 까다로운 워크로드의 리소스 소비를 관리하는 데 도움이 될 대략적인 권장사항 몇 가지를 소개합니다. (이후 게시물에서 모든 규모의 조직에 적용되는 방법과 권장사항을 사용해 비용을 최적화하면서도 성능 저하를 조정하는 방법에 대해 다룰 예정입니다.) 

Cloud Bigtable 비용에 영향을 미치는 리소스 이해하기

Bigtable 인스턴스 비용은 사용한 리소스의 양과 직접적인 관련이 있습니다. 컴퓨팅 리소스는 리소스를 프로비저닝한 시간을 기준으로 요금이 청구되지만 네트워크 트래픽 및 스토리지는 사용량에 따라 요금이 부과됩니다. 

구체적으로 살펴보자면 Cloud Bigtable을 사용할 때의 요금 청구 기준은 다음과 같습니다.

노드

Cloud Bigtable에서는 노드가 컴퓨팅 리소스 단위로 사용됩니다. 노드 수가 증가하면 인스턴스에서 점점 더 많은 양의 데이터를 제공할 수 있을 뿐만 아니라 점진적으로 더 많은 요청(쓰기 및 읽기)에 응답할 수 있습니다. 인스턴스의 노드 요금은 인스턴스의 클러스터에서 데이터를 솔리드 스테이트 드라이브(SSD)에 저장하든 하드 디스크 드라이브(HDD)에 저장하든 상관없이 동일합니다. Bigtable에서 한 시간마다 인스턴스 클러스터에 존재하는 노드 수를 추적합니다. 그 한 시간 동안 존재하는 최대 노드 수에 대한 요금이 각 클러스터의 리전별 요율에 따라 청구됩니다. 노드 가격은 노드당 시간 단위로 책정됩니다. 노드 단위 가격은 클러스터 리전에 따라 결정됩니다.

데이터 스토리지

Cloud Bigtable 인스턴스를 만들 때 스토리지 유형을 SSD와 HDD 중에서 선택합니다. 스토리지 유형을 선택한 후에는 변경할 수 없습니다. 한 달 동안 사용한 평균 저장용량을 이용해 월 단위 요금을 계산합니다. 데이터 스토리지 비용은 리전에 따라 달라지므로 청구서에 인스턴스 클러스터를 프로비저닝한 리전마다 별도의 항목으로 표기됩니다. 
Cloud Bigtable의 기본 스토리지 형식은 SSTable입니다. 이 내부 표현에서 사용한 압축된 디스크 스토리지에 대한 요금만 청구됩니다. 즉, Bigtable 서비스에서 압축된 데이터의 요금만 부과됩니다. 또한 내구성 개선을 위해 Google Cloud의 모든 데이터가 Colossus 파일 스토리지 시스템에 유지됩니다. 데이터 스토리지 가격은 바이너리 기가바이트(GiB)/월 단위로 책정됩니다. 스토리지 단위 가격은 배포 리전 및 스토리지 유형(SSD 또는 HDD)에 따라 결정됩니다.

네트워크 트래픽

Bigtable로 전송되는 인그레스 트래픽 또는 바이트 수는 무료입니다. Bigtable에서 전송되는 이그레스 트래픽 또는 바이트 수는 대상에 따라 가격이 책정됩니다. 동일 영역으로의 이그레스와 동일 리전의 영역 간 이그레스는 무료입니다. 반면 리전 간 이그레스와 대륙 내 이그레스는 결제 기간 중에 전송된 총 바이트 수에 따라 비용이 점진적으로 증가합니다. 이그레스 트래픽은 전송된 GiB 단위로 가격이 책정됩니다.

백업 스토리지 

Cloud Bigtable 사용자는 프로젝트 할당량의 범위 내에서 관리형 테이블 백업을 간단하게 시작하여 데이터를 손상이나 연산자 오류로부터 보호할 수 있습니다. 백업은 백업을 가져온 클러스터의 영역에 저장되며 보관처리된 테이블보다 클 수 없습니다. 백업을 만들어 수동 삭제나 할당된 TTL(수명)을 통해 삭제할 때까지의 백업 기간과 사용한 저장용량에 따라 요금이 청구됩니다. 백업 스토리지 가격은 GiB/월 단위로 책정됩니다. 스토리지 단위 가격은 배포 리전에 따라 달라지지만 인스턴스 스토리지 유형과는 상관없이 동일한 요금이 적용됩니다.

조정하여 Bigtable 비용에 영향을 미칠 수 있는 항목 이해하기 

앞서 언급했듯 Cloud Bigtable의 청구 가능 비용은 결제 기간 동안 사용된 스토리지 및 네트워크 리소스와 더불어 프로비저닝된 컴퓨팅 노드와 직접적인 관련이 있습니다. 따라서 리소스를 적게 사용하면 당연히 운영 비용이 줄어듭니다.  

동시에 리소스 소비율을 줄일 경우 성능과 기능에 미치는 영향도 고려해야 합니다. 실행 중인 데이터베이스 종속 프로덕션 시스템의 운영 비용 절감은 필요한 개발 또는 관리 작업에 대한 동시 평가와 잠재적 성능 저하 평가를 통해 이룰 수 있습니다. 

소비율을 쉽게 변경할 수 있는 리소스가 있는 반면 소비율을 변경하려면 애플리케이션 또는 정책 변경이 필요한 유형의 리소스도 있습니다. 그 밖의 리소스 유형은 데이터 마이그레이션을 수행해야만 소비율 변경이 가능합니다.

노드 수

애플리케이션 또는 워크로드에 따라 인스턴스에서 사용하는 리소스가 청구서의 상당 부분을 차지할 수 있지만 프로비저닝된 노드 수가 가장 큰 단일 항목으로 표기될 가능성이 매우 높습니다. 예를 들어 일반적으로 Cloud Bigtable 노드는 워크로드에 따라 비용의 50~80%를 차지합니다. 따라서 노드 수를 줄이면 빠르게 비용을 절감하며 가장 큰 효과를 얻을 가능성이 높습니다. 

짐작하다시피 클러스터 CPU 로드는 클러스터 노드에서 제공하는 데이터베이스 작업의 직접적인 결과물입니다. 대략적으로는 데이터베이스 작업의 복잡성, 초당 읽기 또는 쓰기 작업 속도, 워크로드에 필요한 데이터 처리 속도가 조합되어 이러한 로드가 생성됩니다.  

워크로드의 작업 구성은 시간이 지나면서 순환하며 변경될 수 있어 워크로드 요구에 맞춰 노드 수를 구성할 기회가 생깁니다. 

Cloud Bigtable 클러스터를 실행할 때 변경할 수 없는 최대 측정항목 상한 2가지가 있는데 바로 사용 가능한 최대 CPU(즉, 평균 CPU 사용률 100%)와 노드에서 관리 가능한 저장 데이터의 최대 평균 수량입니다. 이 블로그를 작성하는 시점에 SSD 및 HDD 클러스터의 노드는 각각 노드당 2.5TiB 및 8TiB 이하의 데이터를 관리하도록 제한됩니다.

워크로드에서 이 한도를 초과하려고 시도하면 클러스터 성능이 심각하게 저하될 수 있습니다. 사용 가능한 CPU 사용률이 소진되면 데이터베이스 작업에서 요청 지연 시간과 서비스 오류율이 증가하는 등 점차 바람직하지 않은 결과가 발생합니다. 인스턴스 클러스터에서 노드당 저장용량이 엄격한 한도를 초과하면 이 한도를 초과하는 각 클러스터에 노드를 추가할 때까지 해당 인스턴스에 있는 모든 클러스터에 대한 쓰기 작업이 실패합니다.

따라서 클러스터의 노드 수는 여유 공간이 개별 측정항목 상한 이하로 유지될 만큼 선택하는 것이 좋습니다. 데이터베이스 작업이 증가해도 데이터베이스가 최적의 지연 시간으로 계속 요청을 처리할 수 있으며 엄격한 제공 한도에 도달하기 전까지 로드 급증을 지원할 여유가 생깁니다.  

또는 워크로드가 컴퓨팅 집약적이기보다는 데이터 집약적이라면 필요한 최소 노드 수가 줄어들도록 클러스터에 저장되는 데이터양을 줄일 수 있습니다.

데이터 스토리지 볼륨

일부 애플리케이션이나 워크로드에서는 상당량의 데이터를 생성하고 저장합니다. 그로 인해 워크로드의 동작이 발생한다면 Cloud Bigtable에서 저장하거나 보관하는 데이터를 줄여 비용을 절감할 수 있습니다.  

앞서 논의한 대로 데이터 스토리지 비용은 시간이 지나면서 저장되는 데이터양과 연관됩니다. 인스턴스에 저장되는 데이터가 줄면 스토리지 비용도 적게 발생합니다. 스토리지 볼륨, 데이터 구조, 보존 정책에 따라 SSD 또는 HDD 스토리지 유형의 인스턴스에서 비용을 절감할 기회가 존재할 수 있습니다.

위에서 언급했듯 저장되는 총 데이터에 따른 최소 노드 요구사항이 존재하기 때문에 저장되는 데이터를 줄이면 노드 비용을 절감할 기회가 마련되며 데이터 스토리지 비용을 절감할 수 있습니다.

백업 스토리지 볼륨 

테이블 백업이 수행될 때마다 백업 스토리지 보관 기간에 대한 추가 비용이 발생합니다. 더 적은 수의 데이터 사본을 짧은 기간 동안 보관하는 실천 가능한 백업 전략을 세울 수 있다면 청구서에서 이 부분에 대한 요금을 줄일 수 있습니다. 

스토리지 유형

애플리케이션의 성능 요구 또는 워크로드에 따라 데이터베이스를 SSD에서 HDD로 마이그레이션할 경우 노드 및 데이터 스토리지 비용을 모두 줄일 수 있습니다.  

HDD 노드가 SSD 노드보다 관리할 수 있는 데이터가 더 많고 HDD의 스토리지 비용이 SSD 스토리지 비용보다 훨씬 적기 때문입니다. 

하지만 HDD는 성능 특성이 SSD와 다릅니다. 읽기 및 쓰기 지연 시간이 길고 지원되는 초당 읽기 수가 적으며 처리량도 적습니다. 그러므로 이 스토리지 유형을 선택하기 전에 특정 워크로드의 요구에 대한 HDD의 적합성을 평가해야 합니다.

인스턴스 토폴로지 

이 블로그를 작성하는 시점에 Cloud Bigtable 인스턴스는 사용자가 선택한 사용 가능한 Google Cloud 위치에 프로비저닝된 클러스터를 최대 4개까지 포함할 수 있습니다. 인스턴스 토폴로지에 클러스터가 2개 이상 포함된 경우 리소스 소비 비용을 줄일 수 있는 여러 가지 가능성이 존재합니다.  

잠시 시간을 내어 인스턴스의 클러스터 수와 위치를 평가해 보세요.  

각각의 추가 클러스터로 인해 추가 노드 및 데이터 스토리지 비용이 발생하는 것은 쉽게 납득할 수 있을 것입니다. 그런데 추가 클러스터는 네트워크 비용에도 영향을 미칩니다. 인스턴스에 클러스터가 여러 개 있으면 데이터가 인스턴스 토폴로지의 모든 클러스터 간에 자동으로 복제됩니다.

인스턴스 클러스터가 다른 리전에 위치할 경우 인스턴스에서 리전 간 데이터 복제를 위한 네트워크 이그레스 비용이 발생합니다. 애플리케이션 워크로드에서 다른 리전의 클러스터에 대한 데이터베이스 작업을 실행하면 애플리케이션에서 발생하는 호출과 Cloud Bigtable의 응답 모두에 대한 네트워크 이그레스 비용이 발생합니다.

인스턴스에 클러스터를 여러 개 만들어야 할 확실한 비즈니스 근거(시스템 가용성 요구사항 등)가 있습니다. 예를 들어 단일 클러스터는 99.9% 가용성을 제공하지만 멀티 클러스터 라우팅 정책을 사용할 경우 클러스터가 2개 이상인 복제된 인스턴스에서는 99.99% 가용성을 제공합니다. 인스턴스 토폴로지 요구사항을 평가할 때 이러한 옵션을 고려해야 합니다.

Cloud Bigtable 인스턴스의 추가 클러스터 위치를 선택할 때는 데이터 제공 및 지속성 용량이 분산된 애플리케이션 엔드포인트 가까이에 위치하도록 복제본을 지리적으로 서로 다른 위치에 배치하도록 선택하면 됩니다. 그러면 애플리케이션에 다양한 이점이 제공될 뿐만 아니라 추가 노드, 클러스터 위치, 전 세계에 분산된 인스턴스에서 발생할 수 있는 데이터 복제 비용이 비용에 미치는 영향을 파악하는 데 유용합니다. 

마지막으로 최소 노드 수를 관리되는 데이터양으로 제한하지만 클러스터의 노드 수가 대칭을 이룰 필요는 없습니다. 따라서 각 클러스터에서 예상되는 애플리케이션 트래픽의 예상 로드에 따라 클러스터의 크기를 비대칭적으로 조정할 수 있습니다.

비용 최적화에 대한 일반적인 권장사항

지금까지 비용이 Cloud Bigtable 인스턴스 리소스에 어떻게 배분되는지 검토하고 청구 비용에 영향을 미칠 수 있는 리소스 소비 조정에 대해 알아봤습니다. 성능 목표에 따라 절충점을 찾을 수 있는 비용 절감 실현 전략 몇 가지를 확인하세요. 

(이 권장사항에 이어 다음 게시물에서는 기법과 추천사항을 다룰 예정입니다.) 

노드 비용을 절감하는 옵션

데이터베이스가 과도하게 프로비저닝된 경우, 즉 워크로드의 데이터베이스 작업을 제공하는 데 필요한 것보다 많은 노드가 데이터베이스에 포함되어 있으면 노드 수를 줄여 비용을 절감할 수 있습니다.  

수동으로 노드 수 최적화 

워크로드에서 생성된 로드가 균일하고 노드 수가 관리되는 데이터양으로 제한되지 않는다면 필요한 최소 개수를 찾는 수동 프로세스를 사용해 노드 수를 점진적으로 줄일 수 있습니다.

자동 확장 처리 배포

애플리케이션 워크로드의 데이터베이스 수요가 순환하는 특성을 보이거나 단기간 로드 증가를 겪다가 상당량이 감소한다면 일정 또는 측정항목 기준에 따라 노드 수를 자동으로 늘리거나 줄이는 자동 확장 처리가 인프라에 도움이 될 수 있습니다.

데이터베이스 성능 최적화 

앞서 살펴본 것처럼 애플리케이션 워크로드에서 발생하는 데이터베이스 작업으로 생성된 로드가 포함되도록 Cloud Bigtable 클러스터의 크기를 조정해야 하며 로드 급증을 처리할 수 있을 정도로 충분한 여유 공간이 있어야 합니다. 필요한 최소 노드 수와 데이터베이스에서 수행하는 작업량 사이에는 직접적인 상관관계가 있으므로 클러스터 성능을 개선하여 필요한 최소 노드 수를 줄일 수 있습니다.

변경을 고려할 만한 데이터베이스 스키마 또는 애플리케이션 로직에는 rowkey 설계 수정, 필터링 로직 조정, 열 명명 표준, 열 값 설계가 포함됩니다. 어떤 경우든 애플리케이션 요청에 응답하는 데 필요한 계산량을 줄이는 것이 목표입니다.

직렬화된 데이터 구조에 다수의 열 저장 

Cloud Bigtable에서는 데이터를 와이드 칼럼 형식으로 정리합니다. 이 구조는 희소 데이터를 제공하는 데 필요한 계산 작업량을 크게 줄여줍니다. 반면 데이터가 상대적으로 밀집된 경우, 즉 대부분의 행에서 대다수 열이 채워져 있으며 애플리케이션에서 요청에 응답할 때마다 대부분의 열을 검색하는 경우 열 값을 단일 데이터 구조의 필드로 결합하면 도움이 될 수 있습니다. 프로토콜 버퍼가 이러한 직렬화 구조의 일종입니다.

아키텍처 대안 평가

Cloud Bigtable은 읽기를 rowkey 공간에 균일하게 분포할 때 최고 성능을 제공합니다. 제공 로드가 컴퓨팅 리소스에서 균일하게 공유된다는 점에서 이러한 액세스 패턴이 이상적이긴 하지만 일부 애플리케이션이 균일하게 분포되지 않은 데이터와 상호작용할 가능성이 있습니다.

예를 들어 특정 워크로드 패턴에서는 Cloud Memorystore를 활용해 연속 읽기 또는 용량 캐시를 제공할 수 있습니다. 추가 인프라로 인해 추가 비용이 더해질 수 있지만 특정 시스템 동작으로 Bigtable 노드 비용이 더 많이 절감되는 결과를 얻을 수 있습니다. 

이 옵션은 Zipf 분포와 같은 멱함수 분포에 따라 워크로드가 데이터를 쿼리하는 사용 사례에 도움이 될 가능성이 높습니다. 이 경우 소수의 키가 많은 요청을 처리하며 애플리케이션에서 극히 짧은 P99 지연 시간을 요구합니다. 대신 캐시가 eventual consistency를 보이기 때문에 애플리케이션에서 일정 수준의 데이터 지연 시간을 허용할 수 있어야 합니다.

이와 같이 아키텍처를 변경하면 요청을 더 효율적으로 처리할 수 있을 뿐만 아니라 클러스터의 노드 수도 줄일 수 있습니다. 

데이터 스토리지 비용 절감 옵션

워크로드의 데이터 볼륨에 따라 데이터 스토리지 비용이 Cloud Bigtable 비용의 상당 부분을 차지할 수 있습니다. Cloud Bigtable에 저장하는 데이터를 줄이거나 저렴한 스토리지 유형을 선택하면 데이터 스토리지 비용을 절감할 수 있습니다. 

장기 데이터를 Cloud Storage 또는 BigQuery로 오프로드하는 전략을 개발하면 포괄적인 분석 사용 사례에 활용할 기회를 잃지 않고도 Cloud Bigtable에 자주 액세스하지 않는 데이터를 보관하는 것에 대한 실용적인 대안을 얻을 수 있습니다. 

데이터 보존 정책 평가 

저장된 데이터 볼륨을 줄이는 간단한 방법 중 하나는 일정한 수명 기준이 지나면 오래된 데이터가 데이터베이스에서 삭제되도록 데이터 보존 정책을 수정하는 것입니다. 

이를 위해 보존 정책 한도를 초과한 데이터를 주기적으로 삭제하는 자동화된 프로세스를 작성해도 되지만 Cloud Bigtable에서는 column family에 할당된 정책에 따라 열에 가비지 컬렉션을 적용할 수 있는 기능을 기본적으로 제공합니다. 각 셀의 버전 타임스탬프를 기준으로 셀 버전 수를 제한하거나 최대 수명 또는 TTL(수명)을 정의하는 정책을 설정할 수 있습니다. 

가비지 컬렉션 정책을 마련하면 데이터 보관 요구사항을 설정한 애플리케이션에서 Cloud Bigtable 데이터 볼륨이 제한 없이 증가하는 것을 막을 수 있는 도구가 제공됩니다. 

대규모 데이터 구조 오프로드

Cloud Bigtable은 총 크기가 최대 100바이너리 메가바이트(MiB)인 행에서 원활하게 작동하며 최대 256MiB의 행을 지원하여 애플리케이션이 각 행에 저장할 수 있는 데이터양을 유연하게 결정할 수 있습니다. 그렇지만 모든 행에서 사용 가능한 공간을 모두 사용하면 데이터베이스의 크기가 상당히 커질 수 있습니다.

일부 데이터 세트는 데이터 구조를 여러 부분으로 분할할 수 있습니다. 작은 부분을 Cloud Bigtable로, 큰 부분은 Google Cloud Storage로 분할하는 것이 좋습니다. 애플리케이션에서 2개의 데이터 저장소를 관리해야 하지만 Cloud Bigtable에 저장되는 데이터 크기를 줄여 스토리지 비용을 절감하는 결과를 얻을 수 있습니다.

인스턴스 스토리지를 SSD에서 HDD로 마이그레이션

특정 애플리케이션의 스토리지 비용을 절감하기 위해 고려할 수 있는 마지막 옵션은 스토리지 유형을 SSD에서 HDD로 마이그레이션하는 것입니다. HDD 스토리지에서는 1GB당 스토리지 비용이 SSD보다 훨씬 적게 발생합니다. 따라서 온라인에서 대량의 데이터가 필요하다면 이 같은 마이그레이션 유형을 평가해 보는 것이 좋습니다.

그렇더라도 신중한 고려 없이 이 방법을 시도해서는 안 됩니다. 성능 저하를 종합적으로 평가하고 데이터 마이그레이션을 위한 작업 용량을 할당하고 난 후에 실행 가능한 방안으로 선택해야 합니다.  

백업 스토리지 비용 절감 옵션 

이 블로그를 작성하는 시점에 테이블당 최대 50개의 백업을 만들고 각 백업을 최대 30일간 보존할 수 있습니다. 확인하지 않은 상태로 두면 보존된 백업 수가 빠르게 증가할 수 있습니다.

잠시 시간을 내어 백업 빈도와 설정한 보존 정책을 평가해 보세요. 현재 보존하는 보관 파일에 대한 비즈니스 또는 기술 요구사항을 설정하지 않았다면 비용을 절감할 기회입니다. 

다음 단계 

Cloud Bigtable은 지연 시간이 짧은 데이터베이스 작업과 데이터 스토리지 및 데이터 처리 모두에 대한 선형 확장성을 제공하는 강력한 데이터베이스입니다. 인프라 스택에 프로비저닝된 구성요소와 마찬가지로 Cloud Bigtable 운영 비용은 작업에서 소비하는 리소스와 정비례합니다. 애플리케이션 성능 요구사항과 월별 지출 사이에서 균형을 찾기 위한 첫 단계는 리소스 비용, 조정 가능한 항목, 비용 최적화 권장사항을 이해하는 것입니다. 

이 시리즈의 다음 게시물에서는 활용 가능한 비용 최적화 옵션을 잘 이해할 수 있도록 애플리케이션에 수행할 수 있는 관측에 대해 알아봅니다. 

참고 자료:

• Cloud Bigtable 가격 책정 자세히 알아보기 
• SSD와 HDD 스토리지 중에서 선택 권장사항 검토
• Cloud Bigtable 성능의 다양한 측면 이해하기