S3で未完成アップロードの家賃を止める人

要約

分割アップロードで送信済みのパートは、完了または中止までS3に残り、保存料金が発生する。業務アプリの「失敗」は、その保管を終わらせる指示ではない。
汎用バケットでは未完了アップロードの期限を設定できる。公式資料の7日間は設定例であり、ディレクトリバケットには同じライフサイクル機能がない。

「この案件は終わりです」。会議では一文で済む。しかしクラウド倉庫は会議に呼ばれていない。途中まで届いたデータは、誰かが続きを送ってくるつもりで、律義に置き場所を使い続ける。

たとえば映像制作会社が、大きな素材をAmazon S3へ送っている最中に依頼を取り消されたとする。担当者は転送を諦め、別の仕事を始める。これは架空の場面だが、その後に残る保存費用の仕組みはAWSが公開している。分割アップロードは各パートを個別に送り、最後の完了処理で一つのオブジェクトを組み立てる。保存済みパートへの課金を終えるには、完了か中止が必要になる。AWSの分割アップロード解説

再開できることには値段がある

この仕組みの長所は、途中の成果を捨てずに済む点だ。通信が切れても、成功した部分をもう一度送る必要がない。弱い回線や大きな素材を扱う現場には、待ってくれる倉庫が役に立つ。

その親切には、業務側の終了時刻が組み込まれていない。開始したアップロード自体に自然な有効期限はなく、再開を待つ状態を続けられる。技術的に残す理由があっても、商業的に残す理由が消えることはある。変更された納品物、廃止した作業、別の試行で済んだ転送。どれも、保存済みパートの行き先を改めて決める契機になる。

買っているものを「失敗したファイルの置き場」とだけ呼ぶと、価値を見誤る。買っているのは、その試行を途中から終えられる機会だ。その機会をまだ使う人がいるなら、待つ費用に理由がある。使う人がいなくなれば、過去の都合だけが家賃を払わせている。

7日後に片付く、とは誰が決めたのか

汎用バケットでは、AbortIncompleteMultipartUploadを使って開始からの日数を設定できる。指定期間を過ぎた未完了アップロードが中止対象になり、S3が停止してパートを削除する。範囲内の既存と新規のアップロードに適用でき、完成済みオブジェクトはこの処理では消えない。AWSのライフサイクル設定

資料にある7日という数字は、設定の見本である。読者が読んだだけで、その会社のバケットに清掃当番が配置されるわけではない。日数を選ぶことは、どこまで再開を待つかを決めることだ。

短すぎれば、まだ役立つ転送の進捗を捨てる。長すぎれば、撤退済みの仕事に場所を貸し続ける。同じ部署の作業でも、翌日に再開するものと、現地装置の復旧を待つものでは適した猶予が違う。きれいな一つの数字より、残す理由の違いを把握した方が支出を説明しやすい。

AWSは未完了パートの削除に早期削除料金を課さないと説明する。ただし完了した場合には、組み上がったオブジェクトの保存費用が続く。出口を選ぶ話であって、完了ボタンが無料倉庫への扉になる話ではない。

まだ運んでいる人を忘れるな

中止処理にも、現場らしい厄介さがある。既に送信中のパートは、その後に成功する場合も失敗する場合もある。AWSは全パートの保存領域を解放するために中止操作が複数回必要になり得るとし、ListPartsで空の一覧を確かめるよう説明している。AbortMultipartUploadの仕様

管理上の教訓は、操作名より責任の範囲にある。業務担当者が作業を止め、転送担当の仕組みがまだ動くなら、その二つを最後に結ぶ人が必要だ。個々の担当者の「終わりました」を足しても、保管の終了にはならないことがある。

また、ディレクトリバケットではS3 Lifecycleの設定が使えない。未完了パートの課金は続き、バケットを削除する前には、進行中の分割アップロードをすべて完了か中止にする必要がある。ディレクトリバケットの公式説明汎用バケット向けの期限設定を前提にした社内の約束を、そのまま別の種類へ持ち込むと、掃除する仕組みだけが抜け落ちる。

特定企業の無駄を金額にするには、パートの実在量、残す用途、実際の請求が足りない。生きた再開計画が見つかれば、同じ保存量の評価は変わる。だから最初の問いは「いくら削れるか」より先に来る。この未完成品を、いまも完成させたい人は誰か。

倉庫は約束どおり待っている。その約束を終わらせる権限まで、案件終了の拍手に紛れさせてはいけない。