컨테이너 레지스트리를 작게 유지하면서도 여전히 배포 중인 이미지는 지우지 않는 보존 규칙은 무엇인가?

열린 질문

(인용한) Distribution 문서는 레이어가 콘텐츠 주소별로 한 번만 저장되어 매니페스트끼리 공유되며, API로 매니페스트를 삭제해도 참조만 제거될 뿐이고, 이후 가비지 컬렉션이 어떤 매니페스트도 참조하지 않는 블롭을 mark-and-sweep 방식으로 삭제한다고 설명합니다. 이 작업이 실행되는 동안에는 레지스트리가 읽기 전용이어야 합니다. 매니지드 레지스트리는 이를 수명 주기 규칙으로 감싸 둡니다. (인용한) ECR 가이드는 규칙 우선순위에 따라 일치한 지 약 24시간 이내에 이미지를 만료시키는 정책을 설명하며, 정책을 적용하기 전에 어떤 이미지가 만료될지 미리 확인해 볼 것을 권장합니다.

문서가 말해 주지 않는 것은, 커밋마다 이미지를 빌드하고 다이제스트로 배포하며 몇 주 뒤에 가끔 롤백도 하는 팀에게 어떤 규칙이 안전한가입니다:

• 나이나 개수 기준 만료("N일보다 오래된 태그 없는 매니페스트 삭제", "저장소마다 최근 N개만 유지") 대 실행 중인 워크로드나 릴리스 기록이 현재 무엇을 참조하고 있는지를 살펴보는 배포 인지형 규칙.
• 풀 리퀘스트 빌드와 브랜치 빌드를 릴리스 빌드와 어떻게 구분해서, 전자는 규칙이 후자를 건드리는 일 없이 수명이 짧게 유지되도록 하는지.
• 태그 불변성 설정, 서명된 이미지, 또는 참조자(referrer)로 첨부된 증명(attestation)이 수명 주기 규칙이 반드시 유지해야 할 대상을 바꾸는지. (인용한) ECR 가이드는 매니페스트 목록이 참조하는 이미지는 그 목록 자체보다 먼저 만료될 수 없으며, 참조자 아티팩트는 대상 이미지와 함께 자동으로 만료된다고 명시합니다. 다른 레지스트리도 같은 방식으로 동작하는지는 이 질문의 일부입니다.
• 규칙이 잘못되었을 때 실제로 어떤 일이 있었는지: 롤백이나 포렌식에 필요한 이미지가 사라졌었는지, 그리고 어떻게 복구했는지.
• 그 규칙들이 레지스트리의 증가 속도를 어느 정도로 억제했는지, 그리고 스토리지 비용과 풀(pull) 지연 시간 중 무엇이 애초의 동기였는지.

유용한 답변에 담겨야 할 것

레지스트리 종류와 그 보존 메커니즘, 순서를 포함한 정확한 규칙, 릴리스 이미지를 일회성 빌드와 구분하는 방법, 그 규칙이 변경 없이 운영된 기간, 적용 전후의 스토리지 추이, 그리고 그 규칙으로 인한 사고나 아슬아슬했던 사례 최소 한 건. 공급자의 기본값을 그대로 옮긴 답변이라면 그렇다고 밝혀야 하고, 매우 큰 규모의 환경에서 나온 답변이라면 어느 부분이 소규모 팀에는 없는 도구에 의존하는지 짚어 주어야 합니다.