객체 라이프사이클 관리

객체 라이프사이클 관리 (Object Lifecycle Management)

저장 공간이 무한정 커지는 걸 막으려면 오래된 데이터를 자동으로 정리하거나 저비용 저장소로 옮겨야 해요. MinIO(현 AIStor)의 객체 라이프사이클 관리(ILM)는 시간·날짜 기반 규칙으로 객체의 전환(transition)과 만료(expiry)를 자동 처리해 줘요. 규칙 문법과 동작은 Amazon S3의 라이프사이클과 호환되도록 설계됐어요.

출처: Object Lifecycle Management — MinIO AIStor Documentation

본문

객체 전환 ("티어링", Tiering)

AIStor는 객체를 원격 저장소 "티어(tier)"로 자동 이동시키는 전환 라이프사이클 규칙을 지원해요. 지원하는 원격 티어 대상은 다음과 같아요.

객체 전환은 사설·공용 클라우드 인프라의 AIStor 클러스터에서 오래된 데이터를 저비용 사설·공용 클라우드 스토리지로 옮기는 용도 등에 써요. 이름이 /로 끝나는 0바이트 객체인 디렉터리 객체는 티어링되지 않아요. AIStor는 티어링된 객체를 추가적인 애플리케이션 로직 없이 즉시(on-the-fly) 가져와요.

티어링 대상을 만들려면 mc ilm tier add 명령을 쓰고, 그 티어로 객체를 지정된 달력 일수 후에 전환하려면 mc ilm rule add --transition-days 명령을 쓰면 돼요.

mc ls로 버킷이나 버킷 프리픽스의 티어링 상태를 확인할 수 있어요. 출력에 각 객체의 저장 티어가 표시돼요.

$ mc ls myaistor/mybucket
[2022-11-08 11:30:24 PST]    52MB  STANDARD log-data.csv
[2022-11-09 12:20:18 PST]    120MB WARM event-2022-11-09.mp4
  • STANDARD는 AIStor 배포에 저장된 객체를 표시해요.
  • WARM은 이름이 일치하는 원격 티어에 저장된 객체를 표시해요.

객체 전환은 백업/복구 솔루션이 아니에요. 데이터 유실 시 원격 티어를 복구 소스로 쓸 수 없어요. 백업/복구 요구에는 사이트 복제나 버킷 복제를 써야 해요.

원격 데이터에 대한 배타적 접근

AIStor는 원격 저장 티어의 전환 데이터에 배타적 접근을 요구해요. "핫" AIStor 소스의 객체 메타데이터는 "웜/콜드" 원격 티어의 객체 데이터와 강하게 연결돼 있어요. AIStor는 원격에 접근할 수 없으면 객체 데이터를 가져올 수 없고, 원격은 소스의 메타데이터를 복원하는 데 쓸 수 없어요.

전환된 객체에 대한 모든 접근은 S3 API 연산으로만 AIStor를 거쳐야 해요. 전환된 객체 — "핫" AIStor 티어의 메타데이터든, 원격 "웜/콜드" 티어의 객체 데이터든 — 를 수동으로 수정하면 객체 데이터가 유실될 수 있어요.

AIStor는 AIStor 배포가 명시적으로 관리하지 않는 원격 버킷·프리픽스의 객체는 무시해요. 자동 전환·투명 객체 조회는 다음 가정에 의존해요.

  • 원격 저장소의 객체에 대한 외부 수정·마이그레이션·삭제가 없을 것.
  • 원격 저장 버킷에 전환·만료 같은 라이프사이클 규칙이 없을 것.

AIStor는 모든 전환 객체를 원격 저장 버킷·리소스의 고유한 배포별 프리픽스 값 아래에 저장해요. AIStor는 원격 대상을 설정할 때 추가로 사람이 읽을 수 있는 선택적 프리픽스도 지원해요. 진단, 유지보수, 재해 복구와 관련된 운영에 도움이 될 수 있어요.

다른 AIStor 배포의 전환 객체를 포함해 다른 데이터가 담긴 원격 저장 티어에는 이 선택적 프리픽스를 지정하길 권장해요.

원격 데이터의 가용성

AIStor 티어링 동작은 원격 저장소가 요청 시 객체를 즉시(밀리초~초) 돌려줘야 한다는 점에 의존해요. 따라서 rehydration, 대기 기간, 수동 개입이 필요한 원격 저장소는 지원하지 않아요.

AIStor는 전환된 각 객체에 원격 저장소에서의 위치를 식별하는 메타데이터를 만들어요. 애플리케이션이 AIStor와 독립적으로 전환 객체를 식별·접근하는 건 쉽지 않아요. 따라서 전환 데이터의 가용성은 AIStor 배포의 모든 객체가 갖는 에라스처 코딩과 분산 배포 토폴로지가 제공하는 핵심 보호에 의존해요. 객체 전환 자체는 추가적인 비즈니스 연속성·재해 복구 이점을 주지 않아요.

보호가 필요한 워크로드는 AIStor 서버측 복제를 구현하세요. 복제는 객체가 원격 복제 사이트에 보존되도록 보장해서, 부분·전체 데이터 유실 시 원격에서 재동기화할 수 있어요.

버전 관리 버킷

AIStor는 버전 관리 버킷의 전환 규칙에 대해 S3 동작을 따르는데, 기본적으로 전환 연산을 현재 객체 버전에 적용해요.

이전(비현재) 버전을 전환하려면 규칙을 만들 때 --noncurrent-transition-days와 --noncurrent-transition-tier 옵션을 지정하세요.

객체 만료

AIStor 라이프사이클 관리는 버킷의 객체를 만료(expire)시킬 수 있어요. 객체 "만료"는 객체에 대해 DELETE 연산을 수행하는 거예요. 예를 들어 365일보다 오래된 객체를 만료하는 라이프사이클 규칙을 만들 수 있어요.

mc ilm rule add --expire-days로 지정된 달력 일수 후에 객체를 만료시킬 수 있어요.

복제가 설정된 버킷에서 라이프사이클 관리 만료 규칙으로 삭제된 객체는 AIStor가 복제하지 않아요.

사이트 복제는 기본적으로 라이프사이클 관리 구성을 다른 사이트로 복사하지 않아요. 사이트 복제를 설정할 때 만료 규칙의 복제를 켜거나, 기존 구성을 업데이트해 켤 수 있어요.

버전 관리 버킷

AIStor는 버전 관리 버킷의 만료 규칙에 대해 S3 동작을 따르는데, 기본 동작이 몇 가지 있어요.

  • AIStor는 현재 객체 버전에만 만료 옵션을 적용해요. 버전 관리 삭제처럼 DeleteMarker를 만들어서요.

이전 버전을 만료하려면 규칙을 만들 때 --noncurrent-expire-days 옵션을 지정하세요.

  • AIStor는 해당 객체의 다른 버전이 없어도 DeleteMarker를 만료하지 않아요.

객체 버전이 남아 있지 않을 때 delete marker를 만료하려면 규칙을 만들 때 --expire-delete-marker 옵션을 지정하세요.

  • delete marker가 없는 객체의 모든 버전을 지정된 일수 후에 만료하려면 --purge-all-object-versions-days 플래그를 써요. 이 플래그는 지정된 일수가 지나면 객체를 영구 삭제해요.

이 플래그는 delete marker가 없는 객체에만 적용돼요.

delete marker를 만료하려면 --purge-all-object-versions-delete-marker 플래그를 포함하세요.

객체 잠금(object locking)이 활성화된 버킷에서 객체의 모든 버전을 만료하는 라이프사이클 구성은 AIStor가 거부해요. --purge-all-object-versions-days와 --purge-all-object-versions-delete-marker 플래그가 설정하는 ExpiredObjectAllVersions, DelMarkerExpiration, AllVersionsExpiration 액션이 그 대상이에요.

구성 전체에 대해 검증이 실패하므로, 규칙은 적용되지 않고 AIStor가 오류를 반환해요.

라이프사이클 관리 객체 스캐너

AIStor는 내장 스캐너를 사용해 객체들을 설정된 모든 라이프사이클 규칙과 능동적으로 비교해요.

스캐너는 우선순위가 낮은 프로세스라 더 높은 우선순위 워크로드에 양보해서, 규칙 타이밍이 성능 스파이크를 일으키지 않아요. 따라서 스캐너가 객체를 설정된 전환·만료 라이프사이클 규칙에 적격으로 감지하는 시점이 라이프사이클 규칙 기간이 지난 뒤일 수도 있어요.

더 알아보기