Bigtable 개요

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

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

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

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

장점

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

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

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

Bigtable 스토리지 모델

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

행과 열의 각 교차 부분에 여러 셀이 포함될 수 있습니다. 각 셀에는 행과 열에 대한 타임스탬프가 적용된 고유한 버전의 데이터가 포함됩니다. 하나의 열에 여러 셀을 저장하면 해당 행과 열에 저장된 데이터가 시간에 따라 어떻게 변화했는지에 대한 레코드가 제공됩니다. Bigtable 테이블은 희소 테이블입니다. 즉, 특정 행에 열이 사용되지 않으면 공간을 차지하지 않습니다.

Bigtable 저장용량 모델 다이어그램

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

  • 행에서 열이 사용되지 않을 수 있습니다.
  • 주어진 행과 열의 각 셀에는 고유한 타임스탬프(t)가 있습니다.

Bigtable 아키텍처

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

Bigtable의 전체 아키텍처

다이어그램과 같이 모든 클라이언트 요청은 프런트엔드 서버를 통과한 후 Bigtable 노드로 전송됩니다. 원본 Bigtable 자료에서는 이러한 노드를 '태블릿 서버'라고 합니다. 이러한 노드는 클러스터의 컨테이너인 Bigtable 인스턴스에 속하는 Bigtable 클러스터로 구성됩니다.

클러스터의 각 노드는 클러스터에 대한 요청 중 일부를 처리합니다. 클러스터에 노드를 추가하면 클러스터에서 처리할 수 있는 동시 요청 수를 늘릴 수 있습니다. 또한 노드를 추가하면 클러스터의 최대 처리량이 증가합니다. 클러스터를 추가하여 복제를 사용 설정하면 다른 유형의 트래픽을 여러 클러스터에 전송할 수도 있습니다. 그런 다음 클러스터 하나를 사용할 수 없게 되면 다른 클러스터로 장애 조치할 수 있습니다.

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

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

  • 실제 데이터는 복사되지 않으므로 태블릿이 한 노드에서 다른 노드로 빠르게 재균등화됩니다. Bigtable은 각 노드에 대한 포인터만 업데이트합니다.
  • 메타데이터만 교체 노드에 마이그레이션해야 하므로 Bigtable 노드 오류가 빠르게 복구됩니다.
  • Bigtable 노드가 실패해도 데이터는 손실되지 않습니다.

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

부하 분산

각 Bigtable 영역은 클러스터 내에서 워크로드와 데이터 볼륨 간의 균형을 유지하는 기본 프로세스로 관리됩니다. 이 프로세스는 사용량이 더 많거나 크기가 더 큰 태블릿을 둘로 나누고 액세스 빈도가 적거나 크기가 더 작은 태블릿을 병합하여 필요에 따라 노드 간에 태블릿을 재배포합니다. 특정 태블릿의 트래픽이 급증하면 Bigtable은 태블릿을 두 개로 분할한 다음 새 태블릿 중 하나를 다른 노드로 이동합니다. Bigtable은 분할, 병합, 재균등화를 자동으로 관리하므로 태블릿을 수동으로 관리하는 수고가 줄어듭니다. 성능 이해에서는 이 프로세스에 대한 세부정보를 제공합니다.

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

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

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

지원되는 데이터 유형

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

메모리 및 디스크 사용량

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

미사용 열

Bigtable 행에서 사용되지 않는 열은 해당 행의 공간을 차지하지 않습니다. 각 행은 기본적으로 키-값 항목의 모음이며, 여기에서 키는 column family, column qualifier, 타임스탬프의 조합입니다. 행에 특정 키의 값이 없다면 키-값 항목이 없는 것입니다.

Column Qualifier

한 행에서 사용된 각각의 column qualifier는 해당 행에 저장되기 때문에 행 공간을 차지합니다. 따라서 column qualifier를 데이터처럼 사용하는 것이 효율적인 경우가 많습니다.

column qualifier에 대한 자세한 내용은 열을 참조하세요.

컴팩션

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

변형 및 삭제

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

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

데이터 압축

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

  • 랜덤 데이터는 패턴이 있는 데이터만큼 효율적으로 압축할 수 없습니다. 패턴이 있는 데이터에는 지금 여러분이 읽고 있는 이 페이지와 같은 텍스트가 포함됩니다.
  • 압축 효율은 동일한 값이 동일 행에 있든, 인접한 행에 있든 간에 서로 가까이 있을 때 가장 높습니다. 동일한 데이터 청크를 포함하는 행이 서로 인접하도록 row key를 배열하면 데이터를 효율적으로 압축할 수 있습니다.
  • Bigtable은 크기가 최대 1MiB인 값을 압축합니다. 1MiB보다 큰 값을 저장할 경우 CPU 주기, 서버 메모리, 네트워크 대역폭을 절약할 수 있도록 데이터를 압축한 후 Bigtable에 기록하세요.

데이터 내구성

Bigtable을 사용할 때 데이터는 Google 데이터 센터의 스토리지 기기를 사용해서 Google의 내구성이 뛰어난 내부 파일 시스템인 Colossus에 저장됩니다. Bigtable을 사용하기 위해 HDFS 클러스터 또는 다른 파일 시스템을 실행할 필요가 없습니다. 실제로 Google은 표준 HDFS 3중 복제보다 높은 수준의 데이터 내구성을 구현하기 위해 고유한 저장 방법을 사용합니다.

복제를 사용하면 내구성이 더욱 향상됩니다. Bigtable은 복제된 인스턴스의 각 클러스터에 대해 선택한 위치에 데이터의 개별 복사본을 유지합니다.

일관성 모델

단일 클러스터 Bigtable 인스턴스는 strong consistency를 제공합니다. 기본적으로 클러스터가 두 개 이상 있는 인스턴스에서 eventual consistency를 제공하지만 일부 사용 사례의 경우 워크로드 및 앱 프로필 세팅에 작성한 항목을 읽을 수 있는 일관성 또는 strong consistency를 제공하도록 구성할 수 있습니다.

보안

Bigtable 테이블에 대한 액세스는 Google Cloud 프로젝트와 사용자에게 할당되는 Identity and Access Management(IAM) 역할에 의해 제어됩니다. 예를 들어 개별 사용자가 태블릿에서 읽기, 태블릿에 쓰기 또는 새 인스턴스 만들기 작업을 수행하지 못하게 하는 IAM 역할을 할당할 수 있습니다. 프로젝트에 대한 액세스 권한이 없거나 Bigtable에 대한 적절한 권한이 있는 IAM 역할이 없는 사용자는 어떤 테이블에도 액세스할 수 없습니다.

테이블 데이터의 하위 집합을 나타내는 테이블의 승인된 뷰를 만들어 테이블 데이터에 대한 액세스를 제어할 수도 있습니다. 그 다음 테이블 수준 권한을 부여하지 않아도 승인된 뷰 수준 권한을 일부 사용자에게 부여할 수 있습니다.

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

암호화

기본적으로 Bigtable 테이블의 데이터를 포함하여 Google Cloud 내에 저장된 모든 데이터는 암호화된 자체 데이터에 사용되는 것과 동일한 강화 키 관리 시스템을 사용하여 저장 상태에서 암호화됩니다.

Bigtable 저장 데이터를 암호화하는 데 사용되는 키를 더 세부적으로 제어하려면 고객 관리 암호화 키 (CMEK)를 사용하면 됩니다.

백업

Bigtable 백업을 사용하면 테이블 스키마와 데이터의 사본을 저장하고 나중에 새 테이블로 복원할 수 있습니다. 백업 및 백업 사본을 사용하면 소스 테이블의 위치에 관계없이 Bigtable 인스턴스가 있는 모든 리전 또는 프로젝트의 새 테이블로 복원할 수 있습니다.

변경 데이터 캡처

Bigtable은 변경 내역 형식으로 변경 데이터 캡처(CDC)를 제공합니다. 변경 내역을 사용하면 변경사항이 발생할 때 데이터 변경사항을 캡처하고 테이블에 스트리밍할 수 있습니다. 데이터 분석, 감사, 보관처리 요구사항, 다운스트림 애플리케이션 로직 트리거를 포함한 사용 사례를 지원하기 위해 Dataflow와 같은 서비스를 사용하여 변경 내역을 읽을 수 있습니다. 자세한 내용은 변경 내역 개요를 참조하세요.

앱 프로필을 사용한 요청 라우팅

앱 프로필 라우팅 정책을 사용하면 애플리케이션에서 들어오는 요청을 처리하는 클러스터를 제어할 수 있습니다. 라우팅 정책 옵션에는 다음이 포함됩니다.

  • 단일 클러스터 라우팅: 모든 요청을 단일 클러스터로 보냅니다.
  • 모든 클러스터로의 멀티 클러스터 라우팅: 다음 옵션을 포함하여 인스턴스에서 가장 가까운 클러스터로 요청을 전송합니다.
    • 모든 클러스터: 인스턴스의 모든 클러스터에서 요청을 수신할 수 있습니다.
    • 클러스터 그룹 라우팅: 인스턴스에서 지정된 클러스터 그룹이 요청을 수신할 수 있습니다.

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

Bigtable은 기존의 관계형 데이터베이스가 아닙니다. SQL 쿼리를 지원하지만 특정 사용 사례는 다른 데이터베이스 옵션이 더 적합할 수 있습니다.

  • OLAP(온라인 분석 처리)에 대화형 쿼리가 필요하면 BigQuery를 사용하는 것이 좋습니다.
  • 문서 데이터베이스에 고도로 구조화된 객체를 저장하고 ACID 트랜잭션 및 SQL과 비슷한 쿼리를 지원해야 하면 Firestore를 사용하는 것이 좋습니다.
  • 지연 시간이 짧은 인메모리 데이터 스토리지에는 Memorystore를 사용하는 것이 좋습니다.
  • 실시간으로 사용자 간에 데이터를 동기화하려면 Firebase 실시간 데이터베이스를 사용하는 것이 좋습니다.

다른 데이터베이스 옵션에 대한 자세한 내용은 데이터베이스 서비스 개요를 참조하세요. Google Cloud에도 다양한 스토리지 옵션이 있습니다.

다음 단계