가비지 컬렉션 개요

이 페이지에서는 Bigtable에서의 가비지 컬렉션 작동 방법과 다음 주제를 설명합니다.

  • 가비지 컬렉션 유형
  • 기본 가비지 컬렉션 설정
  • 데이터 삭제 시점
  • 복제된 테이블의 가비지 컬렉션 정책 변경

가비지 컬렉션 개요

가비지 컬렉션은 Bigtable 테이블에서 만료되어 사용되지 않는 데이터를 지속적으로 자동 삭제하는 프로세스입니다. 가비지 컬렉션 정책은 개발자가 만든 규칙 집합으로 특정 column family의 데이터가 더 이상 필요하지 않은 시점을 나타냅니다.

가비지 컬렉션은 기본 제공되는 비동기 백그라운드 프로세스입니다. 가비지 컬렉션 대상이 되는 데이터가 실제로 삭제되기까지는 최대 일주일이 소요될 수 있습니다. 가비지 컬렉션은 삭제해야 하는 데이터 양에 관계없이 고정된 일정에 수행됩니다. 데이터는 삭제될 때까지 읽기 결과에 나타납니다. 읽을 때 필터를 사용하면 결과에서 이 데이터를 제외할 수 있습니다.

가비지 컬렉션 정책의 이점은 다음과 같습니다.

  • 행 크기 최소화 - 항상 행 크기가 무제한으로 커지지 않도록 해야 합니다. 행 크기가 커지면 성능에 부정적인 영향을 줍니다. 이상적인 행 크기는 100MB 이내, 한도는 256MB이어야 합니다. 이전 데이터나 현재 데이터의 이전 버전을 유지할 필요가 없는 경우 가비지 컬렉션을 사용하면 각 행의 크기를 최소화할 수 있습니다.
  • 비용 절감 - 가비지 컬렉션은 더 이상 필요하지 않거나 사용하지 않는 데이터의 저장 비용을 지불하지 않도록 해줍니다. 만료되거나 사용하지 않는 데이터의 스토리지 비용은 압축이 수행되고 가비지 컬렉션 대상 데이터가 삭제될 때까지 부과됩니다. 일반적으로 이 프로세스는 며칠에서 최대 일주일까지 소요될 수 있습니다.

프로그래매틱 방식으로 또는 cbt CLI를 사용하여 가비지 컬렉션 정책을 설정할 수 있습니다. 가비지 컬렉션 정책은 column family 수준에서 설정됩니다.

테이블의 각 column family마다 자체 가비지 컬렉션 정책이 있습니다. 가비지 컬렉션 프로세스에서는 각 column family의 현재 가비지 컬렉션 정책을 조회한 후 정책 규칙에 따라 데이터를 삭제합니다.

타임스탬프

Bigtable에서 행과 열의 교차 부분에는 교차 부분 타임스탬프 값 버전이 포함된 셀이 여러 개 있을 수 있습니다. 각 셀에는 타임스탬프가 있습니다. 타임스탬프는 Unix epoch(1970-01-01 00:00:00 UTC) 이후의 마이크로초 수입니다. 기본 타임스탬프를 사용하거나 쓰기 요청을 보낼 때 타임스탬프를 설정할 수 있습니다.

Bigtable로 전송하는 타임스탬프는 최대 밀리초 정밀도의 마이크로초 값이어야 합니다. 3023483279876543과 같은 마이크로초 정밀도의 타임스탬프는 거부됩니다. 이 예시에서 허용되는 타임스탬프 값은 3023483279876000입니다.

셀의 타임스탬프 속성은 셀 값을 작성한 실제 시간을 나타내는 '실제' 타임스탬프이거나 '인위적' 타임스탬프일 수 있습니다. 인위적 타임스탬프에는 셀을 작성한 실제 시간이 아닌 순차 번호, 0 또는 타임스탬프 형식의 값이 포함됩니다. 인위적 타임스탬프를 사용하기 전에 사용 시 위험을 포함한 인위적 타임스탬프 사용 사례를 검토합니다.

인위적 타임스탬프를 사용하여 사용 사례를 지원해야 하는 경우가 아니라면 쓰기 요청을 전송할 때 기본 타임스탬프를 설정합니다.

가비지 컬렉션 유형

이 섹션에서는 Bigtable에서 사용할 수 있는 가비지 컬렉션 유형을 설명합니다. 가비지 컬렉션의 각 유형별 코드 샘플은 가비지 컬렉션 구성에서 참조하세요.

만료 값(저장기간 기준)

각 셀의 타임스탬프를 기준으로 가비지 컬렉션 규칙을 설정할 수 있습니다. 예를 들어 현재 날짜와 시간부터 31일 이상 지난 오래된 타임스탬프가 있는 셀을 유지하지 않을 수 있습니다. 이 유형의 가비지 컬렉션 규칙을 사용하여 데이터의 TTL(수명)을 설정합니다. Bigtable은 가비지 컬렉션 중에 각 column family를 살펴보고 만료된 셀을 삭제합니다.

버전 수

column family의 모든 열에 유지할 최대 셀 수를 명시하는 가비지 컬렉션 규칙을 설정할 수 있습니다.

예를 들어 고객의 최신 사용자 이름과 이메일 주소만 유지하려는 경우에는 이러한 두 열이 포함된 column family를 만들고 column family에 대한 최댓값을 1로 설정하면 됩니다.

또는 비밀번호를 재사용하지 않도록 사용자 비밀번호 해시의 마지막 버전 5개를 유지하려는 경우에는 비밀번호 열이 포함된 column family의 최대 버전 수를 5로 설정합니다. Bigtable이 가비지 컬렉션 중에 column family 비밀번호 열의 6번째 셀이 작성된 것을 발견하면 가장 오래된 셀을 삭제하여 셀 수를 5개로 유지합니다.

만료 규칙과 버전 수 규칙 조합

가비지 컬렉션에 만료 규칙과 버전 번호 규칙을 조합하여 사용할 수 있습니다. 조합 유형은 교차, 통합, 중첩입니다. 구성 예시는 여러 기준에 따른 가비지 컬렉션을 참조하세요.

교차

교차 가비지 컬렉션 정책은 주어진 규칙 집합에서 모든 기준을 충족하면 데이터를 삭제하도록 표시합니다 예를 들어 30일보다 오래된 프로필을 삭제하지만 사용자별로 최소 1개의 프로필을 항상 유지할 수 있습니다. 이 경우 프로필 열이 포함된 column family의 교차 정책은 만료 값 규칙 및 버전 수 규칙으로 구성됩니다.

통합

통합 가비지 컬렉션 정책은 주어진 규칙 집합에서 모든 항목을 충족하면 데이터를 삭제하도록 표시합니다. 예를 들어 30일 미만인 경우에 한해 사용자별로 최대 2페이지 분량의 레코드를 유지할 수 있습니다. 이 경우 만료 값 또는 여러 버전에 통합 정책을 설정합니다.

Nested

중첩 가비지 컬렉션 정책은 통합 규칙과 교차 규칙의 조합으로 구성됩니다.

가비지 컬렉션 기본 설정

column family에는 기본 TTL이 없습니다. 열에 보관된 셀 수는 다음 섹션의 설명대로 열이 있는 column family를 만드는 방법에 따라 달라집니다.

HBase 정책

자바용 HBase 클라이언트, HBase 셸 또는 자바용 HBase 클라이언트를 사용하는 다른 도구로 column family를 만들면 규칙을 변경하지 않는 한 Bigtable은 column family의 각 열에 대한 최신 셀만 유지합니다. 이 기본 설정은 HBase와 일치합니다.

다른 모든 클라이언트 라이브러리 또는 도구

다른 클라이언트 라이브러리 또는 도구로 column family를 만들면 Bigtable은 column family의 각 열에 셀을 무한대로 보관합니다. 여기에는 gcloud column family와 cbt CLI로 생성된 column family가 포함됩니다. 버전 수를 제한하려면 column family의 가비지 컬렉션 정책을 변경해야 합니다.

데이터 삭제 시점

가비지 컬렉션은 Bigtable에서 각 column family의 규칙을 확인하고 그에 따라 만료되어 사용되지 않는 데이터를 삭제하는 연속 프로세스입니다. 일반적으로 데이터가 규칙 기준과 일치하는 시점부터 실제로 삭제되기까지는 최대 일주일 정도 소요될 수 있습니다. 가비지 컬렉션의 소요 시간은 변경할 수 없습니다.

만료된 데이터가 삭제되는 데 최대 일주일이 소요될 수 있으므로 읽기 요청이 원하는 데이터를 반환하도록 하기 위해 가비지 컬렉션 정책에만 의존해서는 안 됩니다. 항상 가비지 컬렉션 규칙과 동일한 값을 제외하는 필터를 읽기 요청에 적용해야 합니다. 열당 셀 수를 제한하거나 타임스탬프 범위를 지정하여 필터링할 수 있습니다.

예를 들어 column family의 가비지 컬렉션 규칙이 최신 버전의 프로필 5개만 유지하도록 설정되었고 5개 버전이 이미 저장되어 있다고 가정합니다. 새 버전의 프로필을 작성한 후 가장 오래된 셀이 삭제될 때까지 최대 일주일이 소요될 수 있습니다. 따라서 6번째 값 읽기를 방지하기 위해 항상 최신 버전 5개를 제외한 모든 항목을 필터링해야 합니다.

압축이 수행되고 데이터가 삭제될 때까지 만료된 데이터의 스토리지에 대한 요금이 청구됩니다.

가비지 컬렉션은 소급 적용됩니다. 새 가비지 컬렉션 정책이 설정되면 며칠 후에 테이블의 모든 데이터에 정책이 적용됩니다. 새 정책이 이전 정책보다 제한적이면 정책 변경 전에 작성한 데이터를 포함하여 백그라운드 작업이 진행되면 이전 데이터가 삭제됩니다.

가비지 컬렉션으로 표시된 데이터가 삭제되도록 하려면 테이블을 쿼리하고 데이터와 예상 결과를 비교하면 됩니다. Google Cloud Console에서 테이블 크기를 모니터링할 수도 있습니다. 테이블 크기가 전혀 작아지지 않는 경우 가비지 컬렉션 정책이 예상대로 작동하지 않는 것일 수 있지만 가비지 컬렉션이 지연되어 실행된다는 점을 기억하세요.

복제 및 가비지 컬렉션

복제는 몇 가지 방법으로 가비지 컬렉션에 영향을 줄 수 있습니다.

버전 기반 가비지 컬렉션 및 CPU 사용량

복제를 사용하는 인스턴스에서는 버전 기반 가비지 컬렉션에서 삭제된 항목이 애플리케이션 요청이 복제되는 것과 동일한 방식으로 인스턴스의 모든 클러스터에 복제됩니다. 이전 셀을 삭제 표시하는 새 셀을 빠르게 작성할 경우 Bigtable이 비활성 셀을 삭제하고 인스턴스의 다른 클러스터에 복제할 때 CPU 사용률이 증가할 수 있습니다. 버전 기반 가비지 컬렉션을 사용하는 테이블이 포함된 인스턴스에 클러스터를 추가하는 경우 CPU 사용량 증가에 대비하세요.

반면에 저장기간 기준 가비지 컬렉션은 복제된 인스턴스의 CPU 사용량을 늘리지 않습니다.

버전 기반 가비지 컬렉션 정책 변경

복제된 테이블에 있는 column family의 최대 버전 수를 수정할 수 있습니다. 하지만 column family의 버전 수를 줄이면 복제된 모든 클러스터가 줄어든 버전 수를 반영하기까지 최대 일주일이 소요될 수 있습니다. 따라서 데이터를 읽을 때는 항상 필터를 사용해야 합니다.

저장기간 기준 가비지 컬렉션 정책 변경

인스턴스의 복제 사용 여부에 관계없이 가비지 컬렉션 정책에 지정된 보관 기간을 늘리거나 줄일 수 있습니다. 저장기간 기준 가비지 컬렉션 정책은 삭제할 수도 있습니다.

보관 기간 줄이기

저장기간 기준 정책의 보관 기간을 줄이면 모든 클러스터가 동기화되고 새 정책이 사용되는 데 최대 일주일이 소요될 수 있습니다.

보관 기간 늘리기

복제된 테이블에서 가비지 컬렉션 정책의 보관 기간을 최대 90일까지 늘릴 수 있습니다.

column family의 보관 기간을 늘릴 경우 클러스터가 일주일 이상 동기화되지 않을 수 있습니다. 그 이유를 알아보기 위해 2개의 클러스터 인스턴스에 테이블이 있고 column family의 보관 기간을 30일에서 50일로 변경하는 가상의 경우를 가정해 보겠습니다.

  1. row key ip#685에 대한 쓰기 요청이 column family profile의 click-through 열에 대한 값이 2023-01-02인 클러스터 A로 전송됩니다. 데이터는 클러스터 B에 복제됩니다.
  2. 31일 후 클러스터 A에서 가비지 컬렉션이 발생하고 click-through 열의 값이 만료되어 삭제된 것으로 인식됩니다.
  3. column family profile의 가비지 컬렉션 정책을 변경하여 TTL을 30일에서 50일로 늘립니다.
  4. 하루가 지나면 가비지 컬렉션이 클러스터 B에서 실행됩니다. TTL이 50일이므로 2023-01-02 값이 유지됩니다.
  5. 이제 클러스터가 동기화되지 않고 클러스터 B에 있지만 클러스터 A에는 없는 값이 최종적으로 삭제될 때까지 약 20일 동안 유지됩니다.

다음 단계