가비지 컬렉션

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

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

가비지 컬렉션 개요

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

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

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

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

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

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

타임스탬프

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

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

가비지 컬렉션 유형

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

만료 값(저장기간 기준)

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

버전 수

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

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

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

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

사용할 수 있는 가비지 컬렉션 정책에는 교차통합의 2가지 유형이 있으며, 이들 유형을 조합할 수 있습니다.

교차

교차 가비지 컬렉션 정책은 제공된 모든 규칙 집합과 일치하는 데이터를 모두 삭제합니다. 예를 들어 30일보다 오래된 프로필을 삭제하지만 사용자별로 최소 1개의 프로필을 항상 유지할 수 있습니다. 이 경우 프로필 열이 포함된 column family의 교차 정책은 만료 값 규칙 버전 수 규칙으로 구성됩니다.

통합

통합 가비지 컬렉션 정책은 제공된 규칙 집합 중 1개 이상 일치하는 모든 데이터를 삭제합니다. 예를 들어 30일 미만인 경우에 한해 사용자별로 최대 2페이지 분량의 레코드를 유지할 수 있습니다. 이 경우 만료 값 또는 여러 버전에 통합 정책을 설정합니다.

가비지 컬렉션 기본 설정

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

HBase 정책

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

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

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

데이터 삭제 시점

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

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

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

압축이 수행되고 가비지로 수집된 데이터가 삭제될 때까지 만료된 데이터의 스토리지 비용이 부과됩니다.

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

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

복제된 테이블의 가비지 컬렉션 정책 변경

테이블이 단일 클러스터 인스턴스에 있으면 언제든지 Cloud Bigtable에서 column family의 정책을 수정 또는 삭제할 수 있습니다. 반면에 복제된 인스턴스의 테이블에는 몇 가지 제한사항이 적용됩니다. 이러한 제한사항은 데이터를 보호합니다.

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

Cloud Bigtable에서는 복제된 테이블에 있는 column family의 TTL을 늘릴 수 없습니다. 그 이유를 알아보기 위해 column family의 TTL을 30일에서 60일로 변경하려는 경우를 살펴보겠습니다. 각 클러스터마다 저장기간 기준 가비지 컬렉션이 개별적으로 실행될 수 있습니다. 따라서 정책 변경 시점에 가비지 컬렉션이 테이블 사본 1개에서 31일이 경과된 값을 삭제했지만 다른 사본에서는 삭제하지 못했을 수 있습니다. 이러한 상황에서 가비지 컬렉션 정책을 변경하면 거의 한 달 동안 사본이 동기화되지 않은 상태로 남아있을 수 있습니다.

위와 같은 이유로 Cloud Bigtable에서는 복제된 테이블에 있는 column family의 저장기간 기준 가비지 컬렉션 정책을 삭제할 수 없습니다.

다음 단계