長期保管/ Long-term Storage

画面から引ける範囲は 2 年です。切り離しの設定は 25 ヶ月で、1 ヶ月ぶん余裕を持たせています。

差を付けているのは、切り離しが週に 1 回しか動かないためです。24 ヶ月ちょうどで設定すると、約束の期間内の月が、次の整備が回るまでの数日のあいだ「切り離し待ち」に入る余地が生まれます。1 ヶ月の余裕があれば、その隙間は構造的に生じません。

月ごとの子テーブルを作ること、そして古い月を切り離すことは、データベースの中の拡張機能が受け持っています。退避と削除を受け持つ月次のバッチとは、担い手が分かれています。

この分担には意味があります。切り離す側は消しません。切り離しは「親から外して別のスキーマへ移す」までで、データはそのまま残ります。消すのは、退避が終わって突合まで通った後段のバッチだけです。つまり、退避される前にデータが消える経路が構造的に存在しません。

起動の時刻は、重ならないようにずらしています。週次の整備と日次の集計が同じ時刻に走るため、月次の退避はそれと重ならない時刻に置いています。

月次のバッチは 4 つの手順を順に回します。それぞれ独立に試し、途中で失敗したものは記録して次へ進み、最後にまとめて失敗として投げ直します。1 つの失敗で残りを止めると、直せる分まで止まってしまうためです。

この章でいちばん気を配ったところです。消す判断の材料を 2 系統持っています。

どちらかが合わなければ、そのテーブルは消しません。台帳に失敗として残し、次のテーブルへ進みます。台帳は同じ名前への上書き追加なので、翌月の実行で自動的に再試行されます（失敗のまま残り続けることはありません）。

記録の無い削除経路を作らない

退避待ちのテーブルが0 行だった場合、期間（いつからいつまでの分か）を導き出せません。この場合は触らず、警告だけを出して次へ進みます。期間を適当に埋めた台帳の行を作って消す、という選択はしていません。

月に 1 件も監査の記録が無いというのは現実にはほぼ起きませんが、そのために自動の掃除を作るよりも、痕跡を残して人が判断するほうを選びました。結果として、コードのどこにも「台帳に記録を残さずにテーブルを消す」経路が存在しません。

外へ出た月を調べたいときは、15 分だけ有効な URL を都度発行します。復元の手続きは要りません。

置き場のクラスは Archive です。保管の料金がいちばん安い代わりに、最低 365 日は置いた扱いで課金されます（それより早く消すと 1 年分かかる）。25 ヶ月を超えたデータは、どう考えても 1 年以上は残すものなので、この選択で困りません。

重要なのは、このクラスが読み出しに待ち時間を要求しないことです。冷たい保管というと「取り出しの申請をして数時間待つ」形を想像しますが、このクラスは普通のファイルと同じようにミリ秒で読めます。そのため、復元の機構を持っていません。クラスを一時的に戻すような処理は、コードのどこにも書いていません（書ける経路を作らない、という形にしてあります）。

月次のバッチが失敗すると、重大なアラートが上がります。起票は全バッチ共通のヘルパ 1 本が唯一の実装で、バッチごとに独自の書き方を作りません。

使うバケットは 監査エクスポートバケット の 1 つだけで、用途をプレフィクス（置き場所の接頭辞）で分けています。役割が違うので、クラスも寿命も別に設定しています。

バケットの既定は Archive にしてあり、取り出しの一時出力だけを書き込むときに個別で Standard に指定しています。あとからクラスを付け替える処理（書き直しが発生する）は使っていません。7 日で消えるものに Archive の最低保管期間を適用すると、消しても 1 年分の料金が発生してしまうためです。

取り出しの依頼の台帳は 90 日で消えます。オブジェクト（7 日）より台帳（90 日）のほうが長いので、8 日目から 90 日目までは「依頼の記録はあるが、実物は消えている」状態になります。この期間の依頼に対しては、窓口が期限切れと判定してダウンロード用の URL を発行しません。押せるのに落ちてこない URL を出さないためです。