delete marker 와 비현행 버전

한 줄 요약

버저닝을 켜면 삭제는 지우는 것이 아니라 "지웠다는 표시(delete marker)"를 하나 더 올리는 것이 된다. 원본은 그대로 남아 있고 요금도 계속 나온다.

왜 이게 필요했나

S3 는 오랫동안 최종 일관성이었습니다. 객체를 덮어쓰고 바로 읽으면 옛 값이 올 수 있었고, 이 때문에 많은 애플리케이션이 재시도 로직을 넣었습니다. 2020년 12월부터 AWS S3 는 강한 읽기-쓰기 일관성을 제공합니다. PUT 직후의 GET 이 새 값을 봅니다.

다만 이 보장은 객체 데이터에 대한 것이고, 목록 조회나 다른 구현(MinIO, SeaweedFS, Ceph)의 보장 수준은 각각 확인해야 합니다. "S3 는 이제 강한 일관성"이라는 문장을 모든 S3 호환 스토리지에 그대로 적용하면 안 됩니다.

어떻게 동작하나

버저닝은 다른 문제를 풉니다. 실수로 덮어쓰거나 지운 것을 되돌리는 문제입니다.

버저닝을 켜면 같은 키에 쓸 때마다 새 버전 ID 가 생깁니다. 최신 것이 현행 버전이고 나머지는 비현행 버전입니다. 옛 버전은 버전 ID 로 언제든 읽을 수 있습니다.

삭제가 흥미롭습니다. 버전 ID 없이 DELETE 하면 실제로 지워지지 않고 delete marker 라는 특수한 버전이 맨 위에 올라갑니다. 그래서 보통 GET 은 404 를 받지만, 데이터는 그 아래 그대로 있습니다. delete marker 를 지우면 바로 아래 버전이 다시 현행이 됩니다. 이것이 실수 복구의 메커니즘입니다.

진짜로 지우려면 버전 ID 를 명시해 DELETE 해야 합니다. 이 동작은 되돌릴 수 없습니다.

현장에서 만나는 모습

버저닝의 비용이 자주 놓칩니다. 로그 파일을 매일 같은 키에 덮어쓰는 코드에 버저닝을 켜면, 1년 뒤 그 키 하나에 365개 버전이 쌓여 있습니다. 목록에는 객체 하나로 보이는데 요금은 365배입니다. 그리고 "다 지웠는데 요금이 그대로"인 상황도 delete marker 때문입니다.

그래서 버저닝을 켤 때는 반드시 수명주기 규칙을 함께 겁니다. 비현행 버전을 30일 뒤 삭제하고, 만료된 delete marker 를 정리하고, 미완료 멀티파트 업로드를 7일 뒤 중단하는 세 규칙이 기본 세트입니다.

다음 실습에서 할 것

버저닝을 켜고 같은 키에 세 번 써서 버전을 쌓고, 옛 버전을 읽고, 삭제 후 delete marker 를 확인하고, 그것을 제거해 복구하고, 비현행 버전이 차지하는 용량을 계산한 뒤, 수명주기 규칙을 적용합니다.