변경 내역 개요

Bigtable은 변경 내역 기능을 통해 변경 데이터 캡처(CDC)를 제공합니다. 변경 내역은 변경사항이 발생할 때 Bigtable 테이블에 대한 데이터 변경사항을 캡처하여 처리 또는 분석을 위해 스트리밍합니다.

이 문서에서는 Bigtable 변경 스트림에 대해 간략하게 설명합니다. 이 문서를 읽기 전에 Bigtable 개요를 숙지해야 합니다.

변경 스트림은 다음을 비롯한 CDC 사용 사례에 유용합니다.

  • 지정된 변경사항이 발생할 때 다운스트림 애플리케이션 로직 트리거
  • 데이터 분석 파이프라인과의 통합
  • 감사 및 보관 요구사항 지원

변경 내역이란?

변경 내역은 일반적으로 Cloud Bigtable 클라이언트 라이브러리 중 하나를 사용하여 사용자 또는 애플리케이션에서 수행한 테이블 수준의 변경사항을 추적합니다. 가비지 컬렉션 변경사항도 캡처됩니다.

변경 내역이 사용 설정된 테이블에 적용된 모든 변경사항은 데이터 변경 레코드로 저장됩니다. 데이터 변경 레코드에는 다음을 통해 적용되는 데이터 변경사항이 포함됩니다.

  • Cloud Bigtable API 메서드 MutateRow, MutateRows, CheckAndMutateRow, ReadModifyWriteRow를 사용하여 전송되는 쓰기, 삭제, 업데이트
  • 가비지 컬렉션으로 인한 삭제
  • Admin API의 DropRowRange 메서드를 사용한 행 삭제

Bigtable 테이블로 전송할 수 있는 변경 유형에 대한 자세한 내용은 읽기, 쓰기, 삭제, 가비지 컬렉션 개요를 참조하세요.

변경 내역은 column family 추가 또는 수정과 같은 스키마 변경사항이나 클러스터 추가 또는 삭제와 같은 복제 토폴로지를 추적하지 않습니다.

각 행 키 및 각 클러스터의 데이터 변경 레코드는 커밋 타임스탬프 순서입니다. 그러나 다른 행 키 또는 클러스터의 데이터 변경 레코드 순서는 보장되지 않습니다.

테이블에서 변경 내역을 사용 설정하고 보관 기간을 1~7일로 지정합니다.

데이터 변경 레코드에 포함되는 항목

각 데이터 변경 레코드에는 단일 RPC 호출의 일부로 원자적으로 적용된 행의 모든 변경사항이 포함됩니다.

값이 덮어쓰기되면 새로 작성된 값이 데이터 변경 레코드에 기록됩니다. 데이터 변경 레코드에 이전 값은 포함되지 않습니다.

데이터 변경 레코드는 변경사항을 수신하는 첫 번째 클러스터에 변경사항이 적용되는 시점에 커밋 타임스탬프라는 타임스탬프를 수신합니다. 예를 들어 클러스터가 2개 있는 인스턴스를 생각해 보겠습니다. 클러스터 A의 테이블 1에 쓰기 요청을 보내면 클러스터 A가 쓰기를 수신할 때 데이터 변경 레코드 커밋 타임스탬프가 할당되고 이 쓰기에 대한 클러스터 B의 데이터 변경 레코드에 동일한 커밋 타임스탬프가 생성됩니다.

각 데이터 변경 레코드에는 다음이 포함됩니다.

  • 항목 - 다음 중 하나 이상을 포함한 행에 적용된 변경사항입니다.
    • 쓰기
      • Column family
      • column qualifier
      • 타임스탬프
      • 가치
    • 셀 삭제
      • Column family
      • column qualifier
      • 타임스탬프 범위
    • column family 삭제
      • Column family
      • 행 삭제 - 행 삭제는 행에 데이터가 있는 각 column family의 column family 삭제 목록으로 변환됩니다.
  • 행 키 - 변경된 행의 식별자
  • 변경 유형 - 사용자 시작 또는 가비지 컬렉션
  • 변경사항을 수신한 클러스터의 ID입니다.
  • 커밋 타임스탬프 - 변경사항이 테이블에 커밋된 서버 측 시간
  • Tie breaker - 스트림을 읽는 애플리케이션이 Bigtable의 기본 제공 충돌 해결 정책을 사용할 수 있게 해주는 값
  • 토큰 - 중단된 경우 사용 중인 애플리케이션에서 스트림을 재개하는 데 사용됨
  • 낮은 예상 워터마크 - 레코드 파티션이 모든 클러스터에서 복제를 따라잡은 후 경과된 예상 시간. 자세한 내용은 파티션 및 워터마크를 참고하세요.

데이터 변경 레코드의 필드에 관한 자세한 내용은 DataChange의 API 참조를 확인하세요.

변경 스트림 저장소

테이블과 변경 스트림은 노드 및 스토리지를 비롯한 동일한 클러스터 수준 리소스를 공유합니다. 따라서 변경 내역 데이터 저장소는 테이블 저장소의 일부입니다. 복제를 사용하는 인스턴스에서는 변경 내역의 데이터 사본이 변경 내역이 사용 설정된 테이블이 포함된 인스턴스의 모든 클러스터에 저장됩니다.

변경 내역 데이터에 사용되는 스토리지는 총 스토리지 사용률(최대 비율)에 포함되지 않습니다. 따라서 변경 내역 데이터가 소비하는 증가된 스토리지를 처리하기 위해 노드를 추가할 필요가 없습니다(추가 컴퓨팅 성능을 위해 노드를 추가해야 할 수는 있음). 하지만 변경 내역 데이터가 소비하는 스토리지에 대한 요금이 부과됩니다. 자세한 내용은 비용 고려사항을 참고하세요.

변경 내역 읽기

변경 내역을 읽으려면(스트리밍) 단일 클러스터 라우팅용으로 구성된 애플리케이션 프로필을 사용해야 하며 Dataflow를 사용하여 스트리밍하는 경우 단일 행 트랜잭션을 사용 설정해야 합니다.

라우팅 정책에 관한 자세한 내용은 라우팅 옵션을 참고하세요.

단일 행 트랜잭션에 대한 자세한 내용은 단일 행 트랜잭션을 참조하세요.

변경 내역 메서드는 Cloud Bigtable API(Data API)에서 제공합니다. 클라이언트 라이브러리 또는 커넥터를 사용하지 않고 API를 호출하는 대신 다음 옵션 중 하나를 사용하는 것이 좋습니다.

  • Dataflow 템플릿
  • Bigtable Beam 커넥터
  • Java 클라이언트 라이브러리

모든 옵션을 사용하면 분할 및 병합으로 인한 파티션 변경사항을 추적하고 처리할 필요가 없습니다.

자세한 내용은 ReadChangeStream를 참조하세요.

Dataflow 템플릿

Google에서 제공하는 다음 Dataflow 템플릿 중 하나를 사용할 수 있습니다.

Bigtable Beam 커넥터

Bigtable Beam 커넥터를 사용하여 파이프라인을 빌드할 수 있습니다.

자체 파이프라인을 빌드하지 않으려면 Bigtable 튜토리얼 또는 빠른 시작의 코드 샘플을 코드의 시작점으로 사용하면 됩니다.

Java 클라이언트 라이브러리

파티션

Bigtable은 높은 쓰기 또는 변경 비율과 일치하는 높은 읽기 처리량을 유지하기 위해 변경 내역을 동시에 읽는 데 사용할 수 있는 여러 파티션으로 변경 내역을 나눕니다. 각 변경 내역 파티션은 태블릿과 연결됩니다. 태블릿은 테이블 요청 워크로드의 균형을 맞추기 위해 필요에 따라 다시 분산되는 테이블의 하위 섹션입니다. 자세한 내용은 부하 분산을 참고하세요.

Java 클라이언트 라이브러리를 사용하면 각 파티션에 변경사항을 쿼리하고 분할 및 병합으로 인한 파티션 변경사항을 관리하는 데 필요한 정보를 제공할 수 있습니다.

워터마크

워터마크는 파티션이 모든 클러스터에서 복제를 따라잡은 후 경과된 시간을 추정하는 타임스탬프입니다. 파티션의 워터마크는 복제가 발생함에 따라 지속적으로 업데이트되며 시간이 지나면서 진행됩니다

각 ChangeStreamMutation(데이터 변경 레코드)에는 데이터 변경 레코드와 연결된 파티션의 워터마크인 estimatedLowWatermark 필드가 포함됩니다. 이 estimatedLowWatermark는 추정치이며 아직 스트림에 도착하지 않은 데이터가 없다고 보장하지 않습니다.

복제된 테이블의 워터마크

복제가 파티션을 완전히 따라잡지 않으면 파티션의 estimatedLowWatermark(낮은 워터마크)가 진행되지 않습니다. 모든 파티션 수준의 낮은 예상 워터마크 중 가장 낮은 워터마크인 스트림 전체의 낮은 워터마크는 파티션의 워터마크가 더 이상 진행되지 않으면 진행을 중지합니다. 진행을 중지한 워터마크는 중단된 것으로 간주됩니다. 이 경우 파이프라인에서 변경 내역을 스트리밍하면 파이프라인이 중단됩니다.

다음을 비롯하여 여러 가지 요인으로 인해 하나 이상의 파티션 수준 워터마크가 일정 시간 동안 중단될 수 있습니다.

  • 하나 이상의 파티션에서 복제가 지연되도록 하는 트래픽으로 클러스터를 오버로드
  • 네트워크 지연
  • 클러스터 사용 불가

Bigtable Beam 커넥터는 모든 데이터의 출력 타임스탬프를 0으로 설정하여 이를 처리합니다. 자세한 내용은 이벤트 시간 없이 데이터 그룹화를 참조하세요.

모니터링

변경 내역을 사용 설정하면 변경 내역이 사용 설정된 테이블이 포함된 인스턴스의 CPU 및 스토리지 사용량에 어떤 영향을 미치는지 이해할 수 있도록 두 가지 변경 내역별 측정항목을 제공합니다. Bigtable 모니터링 페이지에서 또는 Cloud Monitoring 도구 모음을 사용하여 이 측정항목을 볼 수 있습니다.

이러한 측정항목에 관한 자세한 내용은 모니터링을 참고하세요.

비용 고려사항

테이블에 변경 내역을 사용 설정하면 노드 및 스토리지 비용이 증가합니다. 특히 스토리지 비용이 더 많이 발생할 수 있습니다.

노드

일반적으로 데이터 변경 레코드를 사용 설정 및 처리하는 추가 트래픽을 처리하려면 클러스터에 노드를 추가해야 합니다(또는 자동 확장을 사용하는 경우 최대 노드 수를 늘려야 함).

변경 내역을 사용 설정하면 처리를 시작하기 전이더라도 CPU 사용량이 약 10% 증가할 수 있습니다. Dataflow 파이프라인을 사용하여 읽는 등 변경 내역을 처리하면 변경 활동 수준과 스트림 데이터를 읽는 방식에 따라 CPU 사용률이 약 20~30%까지 늘어날 수 있습니다.

스토리지

테이블의 데이터 변경 레코드를 저장하는 데 표준 Bigtable 스토리지 요금이 청구됩니다. 변경 내역 메타데이터를 추적하기 위해 만든 테이블을 저장하는 경우에도 요금이 청구됩니다. 지정한 보관 기간은 스토리지 비용에 직접적인 영향을 줍니다.

일반적으로 해당 날짜에 발생한 변형만 반영하는 하루 분량의 데이터 변경 레코드는 해당 날짜에 기록된 데이터가 디스크에서 소비하는 스토리지의 약 1.5배를 사용합니다.

네트워크 데이터 전송

리전 간 변경 스트림을 읽었으면 이 트래픽 비용이 발생할 수 있습니다. 네트워크 데이터 전송 가격 전체 목록은 Bigtable 가격 책정에서 네트워크 섹션을 참고하세요.

처리 비용

데이터 변경 레코드를 읽는 방법에 따라 Bigtable 이외의 서비스에 대한 추가 비용이 적용됩니다. 예를 들어 Dataflow를 사용하는 경우 처리되는 바이트와 작업을 처리하는 워커 머신에 대한 비용을 지불합니다. 자세한 내용은 Dataflow 가격 책정을 참고하세요.

행 범위 삭제

가능한 경우 변경 내역이 사용 설정된 테이블에서 행 범위를 삭제하지 마세요. 행 범위를 삭제해야 하는 경우에는 Bigtable이 작업을 완료하는 데 오래 걸릴 수 있으며 작업 중 CPU 사용량이 증가하니 유의하세요.

다음 단계