Cloud Bigtable 개요

Cloud Bigtable은 수십억 개의 행과 수천 개의 열까지 확장하여 수 테라바이트, 심지어 수 페타바이트의 데이터까지 저장할 수 있으며 데이터 밀도가 낮은 테이블입니다. 각 행의 단일 값에 대한 색인이 생성되는데, 이러한 값을 row key라고 부릅니다. Cloud Bigtable은 매우 낮은 지연 시간으로 매우 많은 양의 단일 키 입력 데이터를 저장하는 데 적합합니다. Cloud Bigtable은 낮은 지연 시간으로 높은 읽기 및 쓰기 처리량을 지원하며, 맵리듀스 작업에 이상적인 데이터 소스입니다.

자바용 Apache HBase 라이브러리에서 지원되는 확장 프로그램을 포함한 여러 클라이언트 라이브러리를 통해 애플리케이션에 노출됩니다. 따라서 오픈소스 빅데이터 소프트웨어로 이루어진 기존의 Apache 생태계와 통합됩니다.

Cloud Bigtable의 강력한 백엔드 서버는 자체 관리형 HBase 설치보다 여러 가지 중요한 이점을 제공합니다.

  • 뛰어난 확장성. Cloud Bigtable은 클러스터에 있는 머신 수에 따라 확장됩니다. 자체 관리형 HBase 설치는 특정 임계값에 도달한 후 성능이 제한되는 설계상의 병목 지점이 있습니다. Cloud Bigtable은 이러한 병목 지점이 없으므로 클러스터를 계속 확장하여 더 많은 읽기 및 쓰기를 처리할 수 있습니다.
  • 간단한 관리. Cloud Bigtable은 업그레이드 및 재시작을 투명하게 처리하고, 높은 데이터 내구성을 자동으로 유지합니다. 데이터를 복제할 때 두 번째 클러스터를 인스턴스에 추가하기만 하면 복제가 자동으로 시작됩니다. 더 이상 마스터 또는 지역을 관리할 필요가 없으며, 테이블 스키마만 디자인하면 Cloud Bigtable에서 나머지를 자동으로 처리합니다.
  • 다운타임 없이 클러스터 크기 조절. 몇 시간 동안 Cloud Bigtable 클러스터 크기를 늘려서 대규모 로드를 처리한 후 클러스터 크기를 다시 줄일 수 있습니다. 다운타임 없이 이 모든 작업을 수행할 수 있습니다. 클러스터 크기를 변경하면 일반적으로 Cloud Bigtable에서 클러스터에 있는 모든 노드의 성능을 균등화하는 데 몇 분 정도 걸립니다.

장점

Cloud Bigtable은 구조화되지 않은 키/값 데이터에 매우 높은 처리량과 확장성이 필요한 애플리케이션에 적합합니다. 여기서 각 값은 보통 10MB 이하입니다. Cloud Bigtable은 또한 일괄 맵리듀스 작업, 스트림 처리/분석, 머신러닝 애플리케이션을 위한 스토리지 엔진으로도 탁월합니다.

Cloud Bigtable를 사용하면 다음 유형의 데이터를 모두 저장하고 쿼리할 수 있습니다.

  • 시계열 데이터 - 여러 서버의 시간별 CPU 및 메모리 사용량
  • 마케팅 데이터 - 구매 내역 및 고객 선호도
  • 재무 데이터 - 거래 내역, 주식 가격, 통화 환율
  • 사물 인터넷 데이터 - 에너지 측정기 및 가전제품의 사용량 보고서
  • 그래프 데이터 - 사용자가 서로 연결되는 방법에 대한 정보

Cloud Bigtable 스토리지 모델

Cloud Bigtable은 각각 정렬된 키/값 매핑으로 구성되어 있고 대규모로 확장 가능한 테이블에 데이터를 저장합니다. 이 테이블은 일반적으로 단일 항목을 기술하는 과 각 행의 개별 값을 포함하는 로 구성됩니다. 각 행은 단일 row key로 색인이 생성되고, 서로 연관된 열은 일반적으로 column family로 그룹화됩니다. 각 열은 column family와 column family 내 고유 이름인 column qualifier의 조합으로 식별됩니다.

각 행/열 교집합에는 서로 다른 타임스탬프에 다양한 또는 버전이 포함될 수 있으므로 시간에 경과함에 따라 저장된 데이터가 어떻게 바뀌었는지에 대한 기록을 확인할 수 있습니다. Cloud Bigtable 테이블은 희소 테이블이므로, 셀에 데이터가 없으면 공간을 차지하지 않습니다.

예를 들어 미국의 역대 대통령들을 위한 Prezzy라는 소셜 네트워크를 구축한다고 가정해 보겠습니다. 각 대통령은 다른 대통령이 올린 게시물을 팔로우할 수 있습니다. 다음 다이어그램은 Prezzy에서 각 대통령이 팔로우하는 사람을 추적하는 Cloud Bigtable 테이블을 보여줍니다.

각 사용자 이름당 하나의 행을 포함하는 Cloud Bigtable 테이블

이 그림에서 주목해야 할 부분이 몇 군데 있습니다.

  • 이 테이블에는 column family가 한 개(follows 그룹) 있습니다. 이 그룹에는 여러 개의 column qualifier가 포함됩니다.
  • column qualifier는 데이터처럼 사용됩니다. 이러한 디자인 옵션은 Cloud Bigtable 테이블의 희소성과 새로운 column qualifier를 즉석에서 추가할 수 있는 기능 덕분에 가능합니다.
  • 사용자 이름은 row key로 사용됩니다. 사용자 이름에 알파벳이 고르게 사용되었다면 전체 테이블에서 데이터 액세스가 고르게 이루어지는 것이 당연합니다. Cloud Bigtable이 균일하지 않은 부하를 처리하는 방법은 부하 분산을, row key 선택에 대한 자세한 내용은 row key 선택을 참조하세요.

Cloud Bigtable 아키텍처

다음 다이어그램은 Cloud Bigtable의 전체 아키텍처를 간단하게 보여줍니다.

Cloud Bigtable의 전체 아키텍처

다이어그램에 표시된 것처럼 모든 클라이언트 요청은 프런트 엔드 서버를 통과한 다음 Cloud Bigtable 노드로 전송됩니다. (원본 Bigtable 백서에서는 이러한 노드를 '태블릿 서버'라고 부릅니다.) 이러한 노드는 클러스터의 컨테이너인 Cloud Bigtable 인스턴스에 속하는 Cloud Bigtable 클러스터로 구성됩니다.

클러스터의 각 노드는 클러스터에 대한 요청 중 일부를 처리합니다. 클러스터에 노드를 추가하면 클러스터가 처리할 수 있는 동시 요청 수를 늘리고, 전체 클러스터의 최대 처리량을 늘릴 수 있습니다. 두 번째 클러스터를 추가하여 복제를 활성화한 경우에는 다른 유형의 트래픽을 서로 다른 클러스터에 전송하고, 한 클러스터를 사용할 수 없을 때 다른 클러스터로 장애 조치를 수행할 수도 있습니다.

Cloud Bigtable 테이블은 태블릿이라고 하는 연속된 행의 블록으로 분할되어 쿼리 워크로드를 분산시킵니다. (태블릿은 HBase 리전과 유사합니다.) 태블릿은 Google 파일 시스템인 Colossus에 SSTable 형식으로 저장됩니다. SSTable은 영구적이고 불변하며 정렬된 키-값 매핑을 제공하며, 키와 값은 모두 임의 바이트 문자열입니다. 각 태블릿은 특정 Cloud Bigtable 노드와 연결됩니다. SSTable 파일 외에도, 모든 쓰기 작업은 Cloud Bigtable에서 인식되는 즉시 Colossus의 공유 로그에 저장되어 내구성이 향상됩니다.

중요한 사실은 데이터가 Cloud Bigtable 노드 자체에 저장되지 않는다는 것입니다. 각 노드는 Colossus에 저장되는 태블릿 집합에 대한 포인터를 갖습니다. 결과는 다음과 같습니다.

  • 실제 데이터가 복사되는 것이 아니기 때문에 한 노드에서 다른 노드로의 태블릿 재균등화가 매우 빠르게 수행됩니다. Cloud Bigtable은 단순히 각 노드에 대한 포인터만 업데이트합니다.
  • 교체 노드에 메타데이터만 마이그레이션하면 되기 때문에 Cloud Bigtable 노드 오류도 매우 빠르게 복구할 수 있습니다.
  • Cloud Bigtable 노드가 실패해도 데이터는 손실되지 않습니다.

이러한 기본적인 구성 요소를 사용하는 방법에 대한 자세한 내용은 인스턴스, 클러스터, 노드를 참조하세요.

부하 분산

각 Cloud Bigtable 영역은 클러스터 내에서 워크로드와 데이터 볼륨을 분산시키는 마스터 프로세스로 관리됩니다. 마스터 프로세스는 사용량이 더 많거나 크기가 더 큰 태블릿을 둘로 나누고, 액세스 빈도가 낮거나 크기가 더 작은 태블릿을 병합하여, 필요에 따라 노드 간에 태블릿을 재분배합니다. 특정 태블릿의 트래픽이 갑자기 증가하면 마스터 프로세스가 이 태블릿을 둘로 분할한 후 새로운 태블릿 중 하나를 다른 노드로 이동합니다. Cloud Bigtable은 분할, 병합, 재균등화를 모두 자동으로 관리해서 사용자가 태블릿을 수동으로 관리할 필요가 없습니다. Cloud Bigtable 성능 이해에서는 이러한 프로세스에 대한 세부정보를 제공합니다.

Cloud Bigtable의 쓰기 성능을 최대한 활용하기 위해서는 노드 간에 쓰기 작업을 가능한 한 균일하게 분배하는 것이 중요합니다. 이러한 목표를 달성하기 위한 한 가지 방법은 예측 가능한 순서를 따르지 않는 row key를 사용하는 것입니다. 예를 들어 사용자 이름에는 특정 알파벳이 더 많이 사용되는 경향이 있습니다. 따라서 row key의 시작 위치에 사용자 이름을 포함하면 쓰기가 비교적 고르게 분배될 것입니다.

이와 동시에, 연관된 행을 서로 인접하도록 그룹화해서 보다 효율적으로 여러 행을 동시에 읽을 수 있게 하면 유용합니다. 예를 들어 여러 유형의 날씨 데이터를 시간별로 저장할 경우 row key는 데이터가 수집되는 위치 다음에 타임스탬프가 오는 형식이 될 수 있습니다(예: WashingtonDC#201803061617). 이러한 유형의 row key는 하나의 위치의 데이터 전체를 연속적인 행으로 그룹화합니다. 다른 위치의 경우에는 행을 다른 식별자로 시작하게 됩니다. 많은 위치가 동일한 속도로 데이터를 수집하기 때문에 태블릿 간에 쓰기 작업이 균일하게 분산될 것입니다.

데이터에 적절한 row key를 선택하는 방법에 대한 세부정보는 row key 선택을 참조하세요.

지원되는 데이터 유형

Cloud Bigtable은 대부분의 경우 모든 데이터를 원시 바이트 문자열로 취급합니다. 대상이 8바이트 big-endian 값으로 인코딩된 64비트 정수여야 하는 증분 작업의 경우에만 데이터 유형을 확인합니다.

메모리 및 디스크 사용량

다음 섹션에서는 Cloud Bigtable의 여러 구성요소가 사용자 인스턴스의 메모리 및 디스크 사용량에 어떤 영향을 주는지 설명합니다.

빈 셀

Cloud Bigtable 테이블의 빈 셀은 공간을 차지하지 않습니다. 각 행은 기본적으로 키/값 항목의 모음이며, 여기에서 키는 column family, column qualifier, 타임스탬프의 조합입니다. 행에 특정 키의 값이 없다면 키/값 항목이 없는 것입니다.

column qualifier

한 행에서 사용된 각각의 column qualifier는 해당 행에 저장되기 때문에 행 공간을 차지합니다. 따라서 column qualifier는 데이터처럼 사용하는 것이 효율적인 경우가 많습니다. 위에 표시된 Prezzy 예시에서 follows 그룹의 column qualifier는 팔로우된 사용자의 사용자 이름이고, 이러한 열의 키/값 항목은 단순히 자리표시자 값입니다.

컴팩션

Cloud Bigtable은 삭제된 항목을 없애고, 읽기 및 쓰기 효율성이 높아지도록 데이터를 재구성하기 위해 테이블을 주기적으로 재작성합니다. 이러한 프로세스를 컴팩션이라고 부릅니다. 컴팩션을 위한 구성 설정은 존재하지 않으며 Cloud Bigtable에서 사용자 데이터를 자동으로 컴팩션합니다.

변형 및 삭제

Cloud Bigtable에서는 변형을 순차적으로 저장하고, 정해진 시간에만 컴팩션하기 때문에 행에 대한 변형 또는 변경 사항은 스토리지 공간을 추가로 차지합니다. Cloud Bigtable은 테이블을 컴팩션할 때 더 이상 필요하지 않은 값을 삭제합니다. 사용자가 셀의 값을 업데이트하면 데이터 컴팩션이 이루어질 때까지 일정 시간 동안 원래 값과 새 값이 디스크에 저장됩니다.

삭제도 일종의 변형이기 때문에 단기적으로라도 스토리지 공간을 추가로 차지합니다. 테이블 컴팩션 전까지는 삭제 시 스토리지 공간이 비워지는 것이 아니라 추가로 사용하게 됩니다.

데이터 압축

Cloud Bigtable은 지능형 알고리즘을 사용해서 데이터를 자동으로 압축합니다. 테이블에 대한 압축 설정은 구성할 수 없습니다. 하지만 효율적으로 압축될 수 있도록 데이터를 저장하는 방법을 알아두면 유용합니다.

  • 랜덤 데이터는 패턴이 있는 데이터만큼 효율적으로 압축할 수 없습니다. 패턴이 있는 데이터에는 지금 여러분이 읽고 있는 이 페이지와 같은 텍스트가 포함됩니다.
  • 압축 효율은 동일한 값이 동일 행에 있든, 인접한 행에 있든 간에 서로 가까이 있을 때 가장 높습니다. 동일한 데이터 청크를 포함하는 행이 서로 인접하도록 row key를 배열하면 데이터를 효율적으로 압축할 수 있습니다.

데이터 내구성

Cloud Bigtable을 사용할 때 데이터는 Google 데이터 센터의 스토리지 기기를 사용해서 Google의 내구성이 뛰어난 내부 파일 시스템인 Colossus에 저장됩니다. Cloud Bigtable을 사용하기 위해 HDFS 클러스터 또는 다른 파일 시스템을 실행할 필요가 없습니다. 인스턴스에서 복제를 사용하는 경우, Cloud Bigtable은 인스턴스의 각 클러스터 데이터 사본 한 개를 Colossus에 보관합니다. 각 사본이 다른 영역(zone) 또는 리전에 위치하므로 내구성이 더욱 향상됩니다.

실제로 Google은 표준 HDFS 3중 복제보다 높은 수준의 데이터 내구성을 구현하기 위해 고유한 저장 방법을 사용합니다. 또한 Google은 치명적 재해로부터 데이터를 보호하고, 재해 복구에 사용할 수 있는 데이터의 백업본을 만듭니다.

보안

Cloud Bigtable 태블릿에 대한 액세스는 Google Cloud Platform 프로젝트와 사용자에게 할당되는 Cloud ID 및 액세스 관리 역할로 제어됩니다. 예를 들어 개별 사용자가 태블릿에서 읽기/태블릿에 쓰기/새 인스턴스 만들기 작업을 수행하지 못하게 하는 Cloud IAM 역할을 할당할 수 있습니다. 다른 사람이 사용자의 프로젝트에 대한 액세스 권한을 갖고 있지 않거나 Cloud Bigtable에 대한 적절한 권한이 부여된 Cloud IAM 역할을 갖고 있지 않은 경우에는 사용자의 테이블에 액세스할 수 없습니다.

보안은 프로젝트 수준 및 인스턴스 수준에서 관리할 수 있습니다. Cloud Bigtable은 테이블 수준, 행 수준, 열 수준, 셀 수준의 보안 제한을 지원하지 않습니다.

기타 스토리지 및 데이터베이스 옵션

Cloud Bigtable은 관계형 데이터베이스가 아니며, SQL 쿼리 또는 조인을 지원하지 않고, 다중 행 트랜잭션도 지원하지 않습니다. 또한 1TB 미만의 데이터를 저장하기에 적합한 솔루션도 아닙니다.

  • OLTP(온라인 트랜잭션 처리) 시스템에 전체 SQL 지원이 필요한 경우에는 Cloud Spanner 또는 Cloud SQL을 사용하는 것이 좋습니다.
  • OLAP(온라인 분석 처리)를 위해 양방향 쿼리가 필요한 경우에는 BigQuery를 사용하는 것이 좋습니다.
  • 10MB보다 큰 대용량 이미지 또는 동영상과 같은 불변의 Blob을 저장해야 할 경우에는 Cloud Storage를 사용하는 것이 좋습니다.
  • 문서 데이터베이스에 고도로 구조화된 객체를 저장하고 ACID 트랜잭션 및 SQL과 비슷한 쿼리를 지원해야 할 경우에는 Cloud Firestore을 사용하는 것이 좋습니다.

다른 데이터베이스 옵션에 대한 자세한 내용은 데이터베이스 서비스 개요를 참조하세요.

다음 단계