6.1 수명 정책과 비용 관리
시험이 끝난 branch를 삭제해도 저장량이 줄지 않았다면 삭제 진행 단계를 먼저 확인합니다. 사용자 목록에서 사라진 시각과 스토리지 참조가 해제된 시각은 구분해 기록합니다. 두 시각을 같은 사건으로 기록하면 남은 비용을 설명하기 어렵습니다. 부모의 변경과 복구 이력도 함께 기록합니다. 그래야 자식의 쓰기량만으로 비용을 추정하는 오류를 피합니다.
이 장의 상태 모델, 필수 태그, quota와 경보 기준은 운영 정책 제안입니다. 특정 공급자가 모두 제공하는 기능 목록은 아닙니다. 제품별 동작은 사실 대장의 확정 범위로 제한합니다. 비교 기준일은 2026-09-30입니다. 실제 회수 지연과 청구 변화는 미실측입니다. 따라서 숫자 대신 관찰 항목과 종료 조건을 정합니다.
생성부터 공간 회수까지의 상태
다음 상태 전이는 서비스 운영자가 관리할 논리적 모델입니다. 제품 API의 상태 이름을 그대로 옮긴 그림은 아닙니다. 생성 요청을 접수한 뒤 SQL 접속과 정책 검사를 마쳐야 사용 상태로 전환합니다. 삭제 상태는 사용자에게 제공하던 자원이 제거됐다는 뜻으로 한정합니다. 참조 해제와 공간 회수는 후속 관찰 결과로 남깁니다.
TTL은 생성 시각부터 허용하는 수명으로 정하되 실제 저장값은 만료 시각으로 남깁니다. PR 종료 이벤트와 TTL을 함께 사용하는 정책을 제안합니다. 이벤트를 받지 못했을 때도 만료 대상 목록에서 다시 정리하도록 구성합니다. 연장이 필요하면 사유와 새 종료일을 기록합니다. 원래 만료 시각과 승인 이력은 그대로 보존합니다.
만료 직후 삭제할지, 사용자에게 통지한 뒤 정리할지는 업무별로 정합니다. 사고 재현이나 결과 검토에 필요한 사본에는 예외 기간을 부여합니다. 예외 기간에도 소유자와 비용 귀속을 유지합니다. 접근 중지 시각과 데이터 삭제 시각을 구분합니다. 그러면 조사 담당자가 증거를 추출할 마지막 시점을 판단하기 쉽습니다.
삭제 요청의 성공 응답을 받은 뒤에도 정리 결과를 확인하는 정책을 권합니다. Branch 식별자로 자원 목록과 endpoint 상태를 재조회합니다. 실패한 생성 요청에도 잔여 자원이 없는지 확인합니다. 내부 참조를 공개하지 않는 서비스에서는 참조 해제를 미확인으로 남깁니다. 외부에서 보이는 저장량 감소만으로 내부 GC가 모두 끝났다고 추정하지 않습니다.
운영 대시보드는 현재 상태와 마지막 전이 시각을 함께 표시하도록 설계합니다. 만료 후 삭제 대기 시간과 삭제 후 회수 대기 시간을 별도로 집계합니다. 정리 담당자는 삭제 실패를 재시도합니다. 회수 담당자는 남은 의존성과 관찰 지표를 검사합니다. 같은 경보에 두 문제를 합치면 재시도만 반복하면서 참조 의존성을 놓치기 쉽습니다.
부모 참조와 청구 귀속
ZFS clone은 snapshot에서 생성한 writable dataset입니다. Origin snapshot에 의존합니다. Clone이 남아 있는 동안 origin snapshot 삭제가 제한됩니다. 보존된 참조는 이전 block의 해제도 막습니다. 이 구조에서는 부모가 데이터를 갱신하고 자식은 읽기만 해도 이전 block이 남습니다. 따라서 이를 유지하는 공간을 고려해야 합니다. OpenZFS clone 매뉴얼과 개발자 설명이 근거입니다.
운영 목록에는 직접 부모뿐 아니라 기준 snapshot의 식별자도 저장하도록 제안합니다. 정리 전에 같은 snapshot을 참조하는 사본을 조회합니다. 삭제가 거절되면 의존 자원의 식별자와 오류를 남깁니다. 공간 부족 때문에 일괄 삭제 범위를 확대하는 절차는 두지 않습니다. 보존할 사본과 폐기할 사본을 구분한 뒤 각 의존성을 해소합니다.
파일시스템 clone의 기동 절차는 ZFS Snapshot과 Clone에 정리되어 있습니다. 여기서는 명령을 반복하지 않고 origin 관계를 수명 기록에 연결합니다. PostgreSQL 파일시스템 snapshot에는 일관된 시점을 확보해야 한다는 조건도 유지합니다. 대상은 전체 cluster와 필요한 WAL 및 tablespace입니다. 관리 목록의 기준 시점에는 이 일관성 검증 결과를 연결합니다.
Aurora는 원본 또는 clone의 변경으로 새 page 공간을 사용합니다. 원본을 삭제해도 남은 clone의 데이터를 유지합니다. 공유 page의 청구 소유권은 남은 clone으로 재배분합니다. 따라서 원본 삭제 전후의 clone 청구량 변화가 자식의 추가 쓰기를 뜻하지는 않습니다. 이 동작은 Aurora clone 문서에 설명되어 있습니다.
비용 비교 기간에 원본을 삭제했다면 그 시각을 별도 사건으로 기록합니다. 변경량, 물리 저장량, 서비스 청구량은 서로 다른 지표 이름으로 각각 수집합니다. 공급자가 물리 저장량을 공개하지 않으면 미확인으로 남깁니다. 청구량이 유지됐다는 결과만으로 공간 회수 실패를 판정하려면 추가 근거가 필요합니다.
Tiger의 현행 fork 문서는 생성 경로에 따라 과금을 구분합니다. CoW 경로는 달라진 chunk에, 전통적 복원 경로는 전체 서비스 스토리지에 과금합니다. Neon도 compute와 데이터 저장, 복구 이력을 별도 비용 항목으로 다룹니다. 비용표에는 제품명 외에 생성 모드와 적용 요금제를 기록합니다. 기존 Neon 비용 모델에서는 비용 항목의 연결을 참고합니다. 이 장에서는 개별 단가를 재사용하지 않습니다.
원본 수집과 WAL 보존
운영 정책에서는 원본에서 기준 데이터를 수집하는 경로와 생성한 branch의 사용 경로를 분리합니다. 전자에는 수집 읽기와 WAL 전송을 기록합니다. 후자에는 시험 쿼리와 변경 데이터의 자원 사용을 기록합니다. 정지 시점 사본이라는 사실만으로 branch별 replication slot의 필요성을 판단하지 않습니다. 운영 PostgreSQL의 slot 사용 여부는 수집 구성에서 확인합니다.
PostgreSQL의 replication slot은 소비자가 필요로 하는 WAL의 제거를 막습니다. 소비 지연이 길어지면 원본의 WAL 보존량을 감시해야 합니다. 이 조건은 PostgreSQL 18의 replication slot 설명에서 재확인합니다. Clone 개수와 원본 WAL 보존량을 일대일로 대응시키는 대신 소비자와 slot의 관계를 기록합니다. 어느 소비자가 어떤 slot을 사용하는지 남깁니다.
경보에는 WAL 보존 바이트와 증가 추세를 포함하도록 제안합니다. 소비자의 마지막 정상 처리 시각도 포함합니다. 임계값은 원본 여유 공간과 재수집에 허용할 시간을 바탕으로 정합니다. 적체를 해소하려고 slot을 삭제하기 전에는 소비자의 복구 경로를 검토합니다. 공간 경보를 지우는 조치와 데이터 수집을 정상화하는 조치를 구분해 작업 기록에 남깁니다.
WAL archive 보존은 과거 복구 요구와 연결합니다. PostgreSQL PITR에서는 기준 backup과 필요한 WAL을 함께 준비합니다. Snapshot이나 branch가 남아 있다는 이유만으로 archive 정리 기준을 바꾸지 않습니다. 보존 정책을 변경할 때는 복구할 목표 시점과 필요한 자료를 먼저 대조합니다. 실제 복구 시험을 통과한 범위에서 보존량을 조정합니다.
기준 데이터의 최신성과 사본 수명도 따로 기록합니다. 오늘 생성한 branch라도 오래된 수집본에서 출발했다면 생성 시각으로 최신성을 판단하기 어렵습니다. 수집 완료 시각과 원본 기준 시점을 구분합니다. 허용 지연을 넘으면 새 시험의 접속 정보 배포를 보류하도록 제안합니다. 기존 작업의 조사 목적 때문에 고정한 데이터는 자동 갱신 대상에서 분리합니다.
필수 태그와 자원 한도
생성 요청에는 아래 여섯 태그를 필수로 받는 정책을 제안합니다. 제품에 태그 기능이 없으면 서비스 관리 DB에 저장합니다. 이름은 preview-저장소-PR번호, perf-작업번호-실험번호처럼 목적과 업무 식별자를 조합합니다. 이름 변경과 무관하게 유지할 내부 식별자를 별도로 사용합니다. 이름에 접속 비밀번호나 개인정보를 넣지 않습니다.
| 태그 | 기록값 예시 | 값의 형식 |
|---|---|---|
| 소유자 | 개발팀의 내부 식별자 | 팀 또는 사용자 ID |
| 목적 | preview, 성능 검증, 사고 재현 | 관리 코드 |
| 원본 | source ID와 parent ID | 불변 식별자 |
| 기준 시점 | snapshot ID, timeline과 LSN | 시각과 계보 식별자 |
| 만료 | 작업 종료 예정 시각 | 시간대 포함 timestamp |
| 비용 태그 | 프로젝트 또는 비용 부서 | 비용 집계 코드 |
원본 태그에서는 외부 수집 원본과 직접 부모를 구분합니다. 기준 시점의 LSN은 PostgreSQL cluster와 timeline 정보를 함께 기록합니다. 같은 숫자의 LSN만으로 다른 계보의 데이터 상태를 비교하지 않습니다. 만료 태그가 비어 있으면 생성 요청을 거절하는 정책을 제안합니다. 무기한 보존이 필요하면 일반 branch와 다른 승인 및 검토 주기를 적용합니다.
| Quota 종류 | 계량 단위 | 적용 범위 예시 |
|---|---|---|
| 보유 개수 | branch 수 | 사용자, 팀, 프로젝트 |
| 동시 생성 | 진행 중 생성 요청 수 | 팀, 서비스 전체 |
| 실행 compute | 동시 용량, 누적 실행 시간 | 작업, 팀 |
| 저장량 | 변경 데이터 바이트, 보존 이력 바이트 | branch, 프로젝트 |
| 동시 시험 | 실행 중 대형 시험 수 | 공유 스토리지 그룹 |
| 비용 예산 | 기간별 청구 금액 | 비용 태그 |
이 표는 공급사의 현재 한도표가 아닙니다. 동시 생성 quota는 준비 작업의 폭주를 제한합니다. 보유 개수 quota는 사용 후 방치를 제한합니다. 이미 생성된 사본의 실행량이나 짧은 생성 요청의 집중을 통제하려면 두 quota가 모두 필요합니다. 예약한 용량과 실제 소비한 용량을 함께 관리하도록 설계합니다.
삭제 중인 branch를 개수 한도에서 언제 제외할지도 명시합니다. 사용자에게는 사라졌지만 저장 공간이 남은 자원은 잔여 비용 항목으로 계속 집계하도록 권합니다. 비용 경보가 발생하면 신규 생성 차단과 기존 작업 정지를 구분합니다. 사고 조사나 복구 작업을 일괄 중단하지 않도록 목적별 예외 담당자를 정합니다.
주기적인 검토에서는 소유자 없는 자원, 만료 예외의 종료일, 삭제 재시도 실패를 확인합니다. 물리 회수 지표와 청구 지표의 관찰 기간도 기록합니다. 공개되지 않은 내부 상태는 미확인으로 남긴 채 문의나 추가 시험으로 확인합니다. 확인된 삭제 결과와 비용 변화는 검증 기록에 보존합니다.