오브젝트 라이프사이클(Object Lifecycle)
lakeFS Enterprise, v1.101.0부터 제공되는 기능이에요. 무료 체험을 시작해 보세요.
출처: 문서
본문
개요
main, staging, production 같은 오래 사는 브랜치는 데이터가 가장 빠르게 쌓이는 곳이에요. 수집 파이프라인은 실행할 때마다 새로운 날짜 프리픽스 아래에 새 객체 집합을 쓰고 아무것도 오래된 것을 지우지 않으며, 중간 산출물은 그것이 만들어낸 결과물 옆에 커밋된 뒤 그대로 남고, 민감한 데이터는 컴플라이언스 정책이 약속한 보존 기간보다 오래 살 수 있어요.
이걸 손으로 정리하면 객체를 하나씩 나열하고 삭제하는 스크립트를 써야 하는데, 데이터 레이크 규모에서는 느리고 어떤 정책이 언제 적용되었는지 영속적인 기록도 남지 않아요.
Object Lifecycle은 그 정리를 리포지토리 수준의 규칙으로 바꿔요. 어떤 객체를, 어떤 브랜치에서, 얼마 후에 만료시킬지 정하는 규칙을 정의하면 lakeFS가 스케줄에 따라 적용해요. 규칙이 선택한 객체는 대상 브랜치의 커밋을 통해 소프트 삭제(soft-delete)되므로, 그 정리는 여러분의 데이터에 대한 다른 변경과 똑같이 버전 관리되고, 검토 가능하고, 되돌릴 수 있어요. 만료된 객체는 이후 Garbage Collection이 영구 제거할 대상이 돼요.
Object Lifecycle은 Amazon S3, Azure Blob Storage, Google Cloud Storage의 라이프사이클 구성과 유사한 규칙 기반 구성 모델을 사용하되, 버킷 대신 lakeFS 브랜치에 적용해요.
이점
-
확장성: 규칙이 100개 객체를 만료하든 1천만 개를 만료하든 정리는 빨라요.
-
감사 가능: 모든 정리는 무엇이 어떤 규칙에 의해 만료되었는지 정확한 기록을 남겨요.
-
되돌릴 수 있음: 정리 이전 상태는 Garbage Collection이 데이터를 제거할 때까지 도달 가능해요.
사용 사례
-
컴플라이언스 기반 만료:
pii/같은 프리픽스 아래의 민감 데이터를 정책이 허용하는 보존 기간이 지나면 제거하거나, 모든 객체에 걸친 단일 규칙으로 리포지토리 전체의 보존에 상한을 두세요. -
스토리지 비용 통제: 어떤 파이프라인도 삭제하지 않는
raw/나tmp/같은 프리픽스 아래의 커밋된 데이터를 만료시키세요.
동작 방식
리포지토리에 규칙을 정의해요. 규칙은 한 문장처럼 읽혀요: main에서 raw/ 아래 객체를 90일 후 만료한다.
rules:
- id: raw-landing-expiry
branches: ["main"]
prefix: "raw/"
expire_after_days: 90
객체의 키가 규칙의 프리픽스로 시작하고 나이가 expire_after_days를 초과하면 만료돼요. 나이는 객체 스토어가 아닌 lakeFS에 기록된 객체의 최종 수정 시간을 기준으로 측정돼요. 커밋된 객체만 평가돼요.
스케줄된 작업이 규칙을 평가하고, 각 대상 브랜치에 대해 일치하는 모든 객체를 단일 커밋으로 제거해요. 평가는 비동기적이라서 새 규칙이나 편집된 규칙은 즉시가 아니라 다음 주기에 적용돼요. 작업은 기본적으로 매일 실행되며 서버 관리자가 변경할 수 있는 스케줄을 따라요(서버 설정 참고), lakeFS가 여러 레플리카로 배포되어 있어도 한 번에 한 인스턴스만 실행해요. 커밋되지 않은 변경이 있는 브랜치는 그 주기에서 건너뛰어요. 건너뛴 브랜치와 다른 이유로 정리에 실패한 브랜치는 손대지 않고 다음 주기에 다시 처리되므로, 한 브랜치가 나머지 실행을 붙잡고 있지는 않아요.
규칙 필드
| Field | Required | Description |
|---|---|---|
| id | yes | 규칙의 식별자. 리포지토리 안에서 고유. 최대 64자의 소문자 영숫자와 하이픈, 하이픈으로 시작할 수 없음 (예: raw-landing-expiry). |
| branches | yes | 규칙이 적용되는 브랜치의 정확한 이름. 보호된 브랜치 포함. 와일드카드 없음. 최소 1개, 모든 규칙을 통틀어 최대 20개의 서로 다른 브랜치. 존재하지 않는 브랜치는 허용되지만 아무 효과가 없어요. |
| prefix | yes | 리터럴 키 프리픽스. 와일드카드나 정규식 없음. 비어 있지 않은 프리픽스는 /로 끝나야 해요 (예: raw/ 또는 tmp/staging/). 빈 프리픽스는 리포지토리의 모든 객체에 일치해요. |
| expire_after_days | yes | 일치하는 객체가 만료되는 나이(일). 1에서 3650 사이의 정수. |
| description | no | UI와 CLI에 표시되는 자유 형식 메모. |
Note
리포지토리는 최대 1,000개의 규칙을 지원해요.
빈 프리픽스는 전부 만료시켜요
빈 프리픽스를 가진 규칙은 대상 브랜치의 리포지토리 모든 객체에 일치해요. 웹 UI에서는 규칙 폼에 명시적인 All objects 옵션으로 이 선택이 제공되므로, 프리픽스 필드를 빈 채로 두어 선택할 수는 없어요.
겹치는 규칙
규칙은 독립적으로 평가되며 순서나 우선순위가 없어요. 그래서 겹치는 프리픽스가 허용되고 중첩 프리픽스는 예측 가능하게 동작해요. 여러 규칙에 일치하는 객체는 그중 가장 짧은 expire_after_days에 도달하는 순간 만료되고, 그 만료는 그 규칙에 귀속돼요. 두 일치 규칙이 같은 일수를 지정하면 ID의 알파벳 순으로 첫 번째 규칙에 귀속돼요.
정리 커밋
각 주기는 브랜치당 최대 하나의 커밋을 만들며, 그 커밋이 그 브랜치를 겨냥하는 모든 규칙을 커버해요:
-
커미터는 전용 시스템 사용자
object-lifecycle-manager예요. -
커밋 메타데이터는 규칙별 귀속 정보와 실행이 판정 기준으로 삼은 시각을 기록해요 (Monitoring cleanup runs 참고).
Note
정리 커밋에는 커밋 훅이 실행되지 않으므로,
pre-commit훅이 그것을 차단하거나 주석을 달 수는 없어요.
규칙 관리
규칙은 lakeFS UI, lakectl, 또는 API에서 관리할 수 있어요. 리포지토리에 대해 이 기능을 끄려면 규칙을 비우세요.
Web UICLIAPI
-
리포지토리로 이동하세요.
-
Settings → Data Retention으로 가세요.
-
Object lifecycle 섹션에서 Create rule을 클릭하거나, 기존 행의 액션 메뉴로 규칙을 편집하거나 삭제하세요.
-
Rule ID와 규칙이 적용되는 Branches(쉼표로 구분된 정확한 브랜치 이름 목록)를 채우세요.
-
Apply to 아래에서 Objects under a prefix를 선택하고 프리픽스를 입력하거나, 리포지토리 전체 규칙을 위해 All objects를 선택하세요.
-
Expire after를 일 단위로 설정하고, 선택적으로 설명을 추가한 뒤 저장하세요.
규칙을 YAML 또는 JSON 파일로 작성해 적용하세요. 아래 예시는 YAML을 사용하며 JSON도 받아들여져요.
cat > rules.yaml <<'EOF'
rules:
- id: "raw-staging-expiry"
prefix: "raw/"
branches: ["main"]
expire_after_days: 90
description: "Expire raw staging objects"
- id: "temp-object-expiry"
prefix: "tmp/"
branches: ["main", "staging"]
expire_after_days: 7
EOF
lakectl object-lifecycle set lakefs://my-repo -f rules.yaml
set은 파일 내용으로 리포지토리의 전체 규칙 집합을 교체하므로, 유지하고 싶은 모든 규칙을 포함하세요. -f -로 stdin에서 규칙 집합을 읽을 수 있어요.
기타 명령:
lakectl object-lifecycle get lakefs://my-repo
lakectl object-lifecycle get lakefs://my-repo --json
lakectl object-lifecycle clear lakefs://my-repo
get은 기본적으로 규칙 집합을 YAML로, --json이면 JSON으로 출력해요. clear는 리포지토리의 모든 규칙을 제거하며 멱등(idempotent)이라 규칙이 설정되어 있지 않아도 성공해요.
세 개의 엔드포인트가 리포지토리 수준에서 규칙 집합을 관리해요:
| Method | Path | Description |
|---|---|---|
| GET | /repositories/{repository}/settings/object_lifecycle | 모든 규칙 조회 |
| PUT | /repositories/{repository}/settings/object_lifecycle | 모든 규칙 교체 |
| DELETE | /repositories/{repository}/settings/object_lifecycle | 모든 규칙 삭제 |
API는 완전한 규칙 집합을 대상으로 하고 규칙별 엔드포인트는 없어요. 단일 규칙의 추가, 변경, 제거는 읽기-수정-쓰기 흐름이에요: 규칙 집합을 GET하고, 수정한 뒤, PUT으로 되돌려요.
다음은 저장된 형태이자 GET이 반환하는 형태인 정규(canonical) JSON이에요:
{
"rules": [
{
"id": "raw-landing-expiry",
"prefix": "raw/",
"branches": ["main"],
"expire_after_days": 90,
"description": "Expire raw landing data"
},
{
"id": "max-retention",
"prefix": "",
"branches": ["main", "staging"],
"expire_after_days": 1095,
"description": "Compliance: expire everything older than 3 years"
}
]
}
권한
다음 RBAC 액션이 이 기능을 게이트해요:
-
retention:GetObjectLifecycleRules- 리포지토리의 규칙 읽기. -
retention:SetObjectLifecycleRules- 규칙 생성, 업데이트 또는 삭제.
둘 다 리포지토리 리소스 arn:lakefs:fs:::repository/{repositoryId}로 스코프돼요.
정리 실행 모니터링
세 곳에서 정리가 무엇을 했는지 볼 수 있어요:
-
대상 브랜치의 커밋. 그 diff가 만료된 객체의 목록이고, 메타데이터에 규칙별 집계(
.lakefs.object-lifecycle.expired_by_rule), 실행 총계(expired_total), 나이 판정 기준 시각(evaluated_at)이 담겨요. -
감사 로그. 각 정리 커밋이
operation_id: CleanupCommit,service_name: object_lifecycle으로 기록되고object-lifecycle-manager시스템 사용자에게 귀속돼요. -
lakeFS 서버 로그. 각 실행이 소요 시간, 평가한 브랜치와 규칙, 만료된 객체, 건너뛰었거나 실패한 브랜치의 이유를 기록해요.
더 알아보기 (Learn more)
공식 문서의 오브젝트 라이프사이클 페이지는 https://docs.lakefs.io/data-retention/object-lifecycle 에서 확인할 수 있어요.