要約

  • Fly.ioでは、削除したボリュームのIDを取得できる期間は削除後24時間とされる。IDを保存していれば、残る保管期間内のスナップショットを探すために使える。
  • スナップショットは標準で5日、設定では1〜60日保管される。設定を延ばしても既存のスナップショットの期限は変わらない。
  • ボリュームの課金終了、IDを見つけられる期間、各スナップショットの失効を別々に扱うと、退役時の引き継ぎに何を残すべきかが見える。

消した一覧は、きれいに見える

使わなくなったクラウド資源を片付ける仕事には、分かりやすい達成感がある。一覧が短くなり、不要な項目が消える。だが最後まで取っておく価値があるものは、容量の大きなファイルではなく、一覧に載っていた小さな番号かもしれない。

Fly.ioの削除済みボリューム復旧手順には、IDを取得できるのは削除後24時間という条件がある。すでにIDを控えていれば、それを使って、保管期間内のスナップショットへ引き続きたどり着ける。

一方、スナップショットの標準保管期間は5日だ。番号を取り出す窓口と、保存内容の寿命が違う。削除から5日間の猶予が新たに始まるわけでもない。各スナップショットは、取得した時点からの自分の期限を持っている。

荷物はまだ倉庫にあるのに、伝票を再発行する窓口が先に閉まる。クラウドの片付けにも、そういう順番がある。

一つの削除に三つの時刻

Fly Volumesは物理ホストに結び付いたローカルの永続ストレージだ。利用者がボリュームを破棄すると、pending_destroyという状態に入り、24時間後に完全削除される。Fly.ioが別ホストへ移行させた時の旧ボリュームは、同じ状態で1週間保管される。

同じ状態名でも、そこに入った理由が違えば期間が違う。ホスト移行の1週間を利用者自身の削除計画へ借用すれば、存在しない6日間を予定表に足してしまう。

スナップショットはさらに別の対象である。毎日の自動取得が標準で有効になっており、保管期間は1〜60日に設定できる。復旧では残っているスナップショットを選び、元と同じかそれ以上の容量を持つ新しいボリュームを作る。

元のボリュームが消える時刻、元のIDを取得できなくなる時刻、各スナップショットの期限。この三つを一つの「削除日」に丸めると、必要な判断まで消える。

長くした設定は、過去へ届かない

Fly.ioの説明は、保管期間を変更しても新しいスナップショットにしか適用されないと明記している。既存分はそのままだ。

退役直前に設定を5日から60日へ変えたと仮定しよう。新しい数字を見て安心する前に、今残っているコピーがどの条件で作られたかを確認する必要がある。未来の取得方針を変えても、昨日のコピーへ追加の寿命は配られない。

手動で取得を依頼する場合にも、待機、実行中、作成済みという段階がある。受け付けられた依頼は、完成した退路とは違う。閉鎖の判断に使うべきものは、実際に存在するコピーの時刻と状態だ。

自動取得を止めても、既存のスナップショットは直ちに消えず、それぞれの保管期間の終わりまで残る。将来の設定と現在の在庫は、ここでも別の台帳になる。

請求が止まる場所も別々だ

Fly.ioはボリュームを時間単位で按分して課金する。未接続のボリュームや、停止中のMachineに接続したボリュームも対象だ。pending_destroyに入ったボリュームには、ボリューム料金が発生しない。

スナップショットの保存料金は独立している。無料枠を差し引いたうえで時間単位の按分となり、保存された増分データが計算対象になる。元のボリューム料金が止まったことから、アカウント全体の請求が終わったとは読めない。

ここには、無期限に旧資源を残す以外の選択がある。業務上いつまで戻れる必要があるかを決め、実在するスナップショットの期限と照合し、その期間に使うための参照情報を引き継ぐ。保存と費用を、意図した順番で終わらせればよい。

一覧を空にした担当者と、後日復旧を頼まれる担当者が違う場合ほど、この短い引き継ぎは効く。容量を保存していても、その所在を知る人だけ先にプロジェクトから退場すれば、購入した時間を使いにくくしてしまう。

番号は場所を示す。権限までは渡さない

残す情報は、元のボリュームID、所属アプリと組織、選んだスナップショットID、取得時刻、状態、実際の保管期限だ。元の資源が消えた後も、復旧権限を持つ人が参照できるところに置く。

IDは認証情報の代わりにはならない。保存内容が業務上十分かどうかも、番号だけでは分からない。新しいボリュームを作った後には、接続、アプリケーションの起動、データの確認が残る。

また、日次取得では直近の取得後に書き込んだ内容が含まれない場合がある。長期間残すことと、短い間隔で取ることは違う注文だ。まだ捕まえていない書き込みを、保管日数の延長で後から増やすことはできない。

IDを失った場合のサポートによる復旧保証は公開手順に示されていない。その保証があれば参照情報を失う経済的なリスクは変わるが、現時点で使える手順は、削除前の控えを持つ価値を十分に示している。

RIPE NCCの会員記録はFly.io, Incという事業者の身元を確認する資料になる。顧客のボリュームの場所を示す資料ではない。会社の所在地、実行リージョン、復旧対象のIDを、それぞれの役割のまま扱う方が実務は短くなる。

片付けは、過去との関係を切る仕事でもある。どの関係を、いつまで残すか。その判断が済んで初めて、きれいな一覧は完成の印になる。

公式資料