요약

  • Fly.io는 삭제한 볼륨의 ID를 삭제 후 24시간 동안 조회할 수 있다고 설명한다. ID를 미리 보관했다면 남은 보관 기간 안에서 그 볼륨의 스냅샷을 찾는 데 쓸 수 있다.
  • 스냅샷 기본 보관은 5일이며 1~60일로 설정할 수 있다. 보관 기간 변경은 새 스냅샷에만 적용된다.
  • 볼륨 비용의 종료와 복구 경로의 유지는 별도 결정이다. 자원을 없애기 전에 실제 사본의 시각, 만료 조건, 식별자를 다음 담당자에게 넘겨야 한다.

비용을 닫는 버튼은 기억까지 정리한다

사용하지 않는 볼륨을 지웠다는 보고는 깔끔하다. 자원 목록이 줄었고 비용도 줄일 수 있다. 그런데 나중에 복구를 맡은 사람에게 가장 필요한 것이 바로 그 목록에 있던 번호라면, 정리의 완성도는 다시 계산해야 한다.

Fly.io의 삭제 볼륨 복구 문서는 ID를 찾아낼 수 있는 기간을 삭제 후 24시간으로 적는다. ID를 이미 가지고 있으면 스냅샷의 보관 기간이 남아 있는 동안 해당 사본을 조회하는 데 계속 사용할 수 있다.

스냅샷은 기본적으로 5일 보관된다. 이 둘을 합쳐 ‘삭제해도 5일은 괜찮다’고 읽으면 중요한 줄을 놓친다. 24시간은 번호를 다시 찾는 창구의 시간이고, 각 스냅샷은 생성된 뒤 자기 보관 기간을 따라 만료된다. 볼륨을 지웠다고 사본의 시계가 처음으로 돌아가지 않는다.

창고에 물건이 남아 있어도 보관표를 재발급하는 창구는 먼저 문을 닫을 수 있다. 클라우드에서도 작은 표 한 장의 값이 뒤늦게 커진다.

삭제의 세 가지 얼굴

Fly Volumes는 물리 호스트에 묶인 로컬 영구 저장소다. 사용자가 볼륨을 파기하면 pending_destroy 상태로 24시간을 보낸 뒤 영구 삭제된다. Fly.io가 다른 호스트로 옮기면서 남긴 원래 볼륨은 같은 상태로 1주일 보관된다.

이름이 같은 상태라고 같은 권리가 생기지는 않는다. 공급자의 호스트 이전 규칙을 고객의 삭제 계획에 가져오면 근거 없는 6일이 더 생긴다. 일정표에는 편리하지만 실제 데이터는 그 일정표를 읽지 않는다.

스냅샷은 또 다른 객체다. 기본적으로 매일 자동 생성되며 보관 기간은 1~60일로 정할 수 있다. 문서의 복구 경로는 살아 있는 스냅샷 하나를 선택해 원래 크기 이상인 새 볼륨을 만드는 방식이다.

원래 볼륨이 없어지는 시점, 그 ID를 조회할 수 있는 마지막 시점, 특정 스냅샷의 만료 시점은 따로 존재한다. ‘삭제 완료’ 한 줄로 세 가지를 대신하면 다음 담당자는 자신에게 남은 시간이 얼마인지 알기 어렵다.

설정을 늘렸는데 옛 사본은 그대로다

Fly.io는 보관 기간을 변경해도 새 스냅샷에만 적용되고 기존 사본에는 영향을 주지 않는다고 명시한다. 예컨대 종료를 앞두고 설정을 5일에서 60일로 늘렸다고 가정해 보자. 새 숫자가 보이더라도 기존 사본은 원래 수명을 유지한다.

미래에 만들 사본의 정책을 바꾸는 일과 이미 만들어진 사본을 더 오래 붙잡는 일은 다르다. 복구 계획은 현재 설정 화면보다 실제 사본의 생성 시각과 적용된 기간을 먼저 읽어야 한다.

수동 생성 요청도 즉시 완성품이 되지 않는다. 스냅샷은 대기와 실행 상태를 지나 생성 완료에 도달한다. 요청이 접수됐다는 메시지만 남기고 원래 자원을 정리하면 아직 진행 중인 작업을 비상구로 계산할 수 있다.

자동 생성을 꺼도 기존 스냅샷은 바로 없어지지 않는다. 각각의 보관 기간이 끝날 때 삭제된다. 앞으로 무엇을 할지 정하는 스위치로 현재 남아 있는 재고까지 설명할 수는 없다.

청구서도 두 갈래다

Fly.io의 볼륨 요금은 시간 단위로 비례 계산된다. 아무 Machine에도 붙지 않은 볼륨이나 정지된 Machine에 연결된 볼륨에도 비용이 생긴다. pending_destroy 상태의 볼륨에는 볼륨 요금이 붙지 않는다.

스냅샷 저장 비용은 별도로 계산한다. 무료 허용량을 먼저 빼고 시간 단위로 비례 청구하며, 이전 사본 이후 달라진 데이터를 증분 저장하는 방식이다. 볼륨 요금이 멈췄다는 사실이 전체 계정의 청구 종료를 뜻하지는 않는다.

그렇다고 불안하다는 이유로 옛 볼륨을 무기한 유지할 필요도 없다. 업무가 언제까지 되돌아갈 가능성을 필요로 하는지 정하고, 실제 남은 사본이 그 기간을 충족하는지 확인한 뒤, 사용할 수 있는 참조 정보를 인계하면 된다. 비용과 복구 선택을 각각 의도한 시점에 끝내는 것이다.

여기서 인수인계는 추가 저장 장치가 아니라 몇 줄의 기록이다. 볼륨 ID와 소속 앱·조직, 선택한 스냅샷 ID, 생성 시각, 상태, 실제 만료 조건을 남긴다. 복구 권한을 가진 다음 사람이 이 기록으로 대상을 찾을 수 있어야 한다.

번호는 열쇠가 아니라 위치표다

ID를 저장했다고 접근 권한이 생기지는 않는다. 실제 계정의 허가가 필요하며, 번호만으로 내용의 완전성도 입증되지 않는다. 새 볼륨을 만든 뒤에는 연결, 애플리케이션 실행, 업무 데이터 확인이 이어진다. 그 시간까지 복구 계획에 들어가야 한다.

매일 한 번의 스냅샷에는 마지막 촬영 뒤의 쓰기가 빠질 수 있다. 오래 보관하는 정책은 과거를 더 오래 남길 뿐, 촬영하지 않은 거래를 나중에 끼워 넣지 못한다. 빈도와 보관 기간을 별도의 구매 조건으로 봐야 하는 이유다.

ID를 보관하지 못했을 때 지원팀이 복구를 보장한다는 내용은 공개 절차에 없다. 그런 보장이 확인되면 참조 정보를 잃는 경제적 위험의 평가가 달라진다. 현재 문서만으로도 삭제 전에 번호를 넘길 이유는 충분하다.

RIPE NCC의 회원 기록은 Fly.io, Inc라는 사업자의 신원을 확인해 준다. 고객 볼륨의 위치를 알려 주는 기록은 아니다. 회사 주소, 실행 지역, 복구 객체의 ID를 각자의 용도로 쓰면 불필요한 추측을 줄일 수 있다.

자원을 만드는 동안에는 플랫폼이 이름과 상태를 부지런히 보여 준다. 지우는 순간에는 조직이 기억을 맡아야 한다. 목록이 깨끗해진 뒤에도 무엇을 되찾을 수 있는지 다음 사람이 알 때, 종료 작업은 비로소 잘 끝난다.

공식 출처