DEA-2.3データのライフサイクルを管理する。

ヒントボタン

svv_table_info で deleted が 25 ％、unsorted が 35 ％ と報告されると Amazon Redshift のゾーンマップが崩れ、sale_date や product_id の条件が効かずフルスキャンが発生します。空きブロックを掃除する VACUUM DELETE ONLY と、インタリーブソートキーの断片化を直す VACUUM REINDEX を併用することで、ストレージ回収とソート最適化を同時に達成できる点を意識してください。

RA3 ノード 6 台で 3TB を抱える環境では、テーブル全体を書き換える VACUUM FULL や S3 への UNLOAD→COPY フルリロードはネットワーク転送と圧縮展開だけで数時間を要し、30 分の保守枠には収まりません。並列度を高くした VACUUM DELETE ONLY はスライス単位でマルチスレッド実行され I/O を使い切れるため短時間で削除領域を除去でき、その直後に軽量な VACUUM REINDEX を続ければ同じウィンドウ内でソートも整います。

本件の要件は「消した 25 ％の領域を即時に reclaim し、unsorted 35 ％を 20 ％未満まで下げ、かつ 30 分以内に完了する」ことですから、Amazon S3 経由の再ロードや翌日持ち越しは片手落ちとなります; Redshift の並列 Vacuum 設定を最大化して削除掃除を先に行い、その流れでインタリーブキー対応の REINDEX を続ける一筆書きの手順が時間・容量・性能すべての観点で最もバランスの良い解となります。

ヒントボタン

IoTセンサの新着 2TB/日 を Athena で 30 日間集中的に分析する場合、S3 Standard や Glacier に直接格納すると読み出し料金やリストアの手間が増えてコストが跳ね上がりますが、S3 Intelligent-Tiering なら PUT したまま何も設定せずとも最初の 30 日間は頻繁アクセス階層に留まり高速クエリが可能で、投入時からの性能と料金を最適に両立できます。
その 30 日経過後はアクセス頻度が読めず再取得は最大 12 時間で許容されるため、Intelligent-Tiering が備えるアーカイブアクセス階層（数時間）とディープアーカイブアクセス階層（最長 12 時間）への自動移行が監視料金だけで実現でき、かつマルチ AZ で 99.9% 以上の可用性という S3 の SLA も同時にクリアできます。
望むのは 365 日後の自動削除と保守の単純化なので、Intelligent-Tiering に Expiration ルールを 1 行置くだけで済み、Standard-IA などを日数別に段階設定する複雑な Lifecycle や One Zone-IA への手動切替を避けつつ、保管料金・復旧時間・可用性・運用負荷を総合的に見たとき最も合理的な選択となります。

ヒントボタン

1行目
Athena が直接スキャンできるのは Amazon S3 Standard・Standard-IA・Intelligent-Tiering だけで、Glacier 系は一度 Restore が必要です。よって書き込み後 30 日間は Standard に置き頻繁分析をこなし、その後はアクセス頻度低下を見越してコストの低い層へ段階移行する構図を考えると道筋が見えてきます。

2行目
S3 Lifecycle ルールを使えば、Standard から 30 日で S3 Standard-IA、さらに 90 日で S3 Glacier Deep Archive へ自動移行し、満了した 7 年後に Expiration で削除という連鎖がワンクリックで構成できます。Deep Archive は最大 12 時間の取り出し猶予があるため監査の「突発アクセス 12 時間以内」も満たし、総コストは 70％以上圧縮できます。

3行目
バージョニングで保存の安全性を高めながら完全自動のライフサイクルに委ねると運用負荷はほぼゼロになります。一方、即時検索を優先して最初から Glacier 系に置くと Restore 手数料や待機時間が頻繁発生し、手動コピー運用ではヒューマンリスクも増します。全要件を横串で比べると、段階的自動階層化こそ最適解と判断できます。