Snowflakeのデータ保持期間とFail-safeでストレージ料金を抑えるコツ

Snowflakeのデータ保持期間とFail-safeでストレージ料金を抑えるコツ Snowflake
2026.05.07

はじめに:ストレージ料金は「見えない領域」も加算される

こんにちは!Snowflakeを使い始めると、コンピューティング(ウェアハウス)料金は意識しても、ストレージ料金のほうは「あれ、思ったより高い…?」と感じることがあります。じつはSnowflakeのストレージは、現在のデータだけでなく Time Travel(タイムトラベル)領域 と Fail-safe(フェイルセーフ)領域 の合計で課金されているんです。

この記事では、初心者の方でも「どこにデータが溜まっていて、どう設定すれば節約できるのか」がわかるように、データ保持期間とFail-safeの仕組みをやさしく解説します。読み終わるころには、テーブル設計でムダなストレージを減らせるようになりますよ!

Snowflakeのデータ保持期間とFail-safeでストレージ料金を抑えるコツ

Time TravelとFail-safeって何?

Time Travel:過去のデータに戻れる期間

Time Travelは、誤って削除・更新したデータを過去の任意の時点に戻せる機能です。保持期間は DATA_RETENTION_TIME_IN_DAYS パラメータで決まり、Standardエディションは最大1日、Enterprise以上は最大90日まで設定できます。詳しくは Snowflakeタイムトラベル入門|過去データを一発で復元する方法 もご覧ください。

Fail-safe:Snowflakeが守る最後の保険

Fail-safeは、Time Travel期間が終わったあと、さらに 7日間 Snowflake側でデータを保管してくれる「最後のセーフティネット」です。ユーザーは直接クエリできず、復元したい場合はSnowflakeサポートへ依頼します。期間も7日固定で、ユーザー側からは無効化できません。

ストレージ料金の内訳をイメージしよう

テーブルの更新・削除をすると、変更前のマイクロパーティション(データの塊)はすぐ消えるわけではなく、Time Travel領域 → Fail-safe領域へと順に移動します。つまり、更新が多いテーブルほど隠れストレージが膨らむのです。

  • アクティブストレージ:今使っている本体データ
  • Time Travelストレージ:0〜90日分の履歴
  • Fail-safeストレージ:+7日間の保険

節約のための具体的な設定方法

1. 保持期間を見直す

テーブル単位で保持日数を調整できます。ログテーブルや中間テーブルなど「過去に戻る必要が薄い」ものは短くしましょう。

-- アカウント全体のデフォルトを1日に
ALTER ACCOUNT SET DATA_RETENTION_TIME_IN_DAYS = 1;

-- 重要なテーブルだけ長めに
ALTER TABLE sales.orders SET DATA_RETENTION_TIME_IN_DAYS = 30;

-- 一時的な集計テーブルは0日に(Time Travel無効)
ALTER TABLE staging.tmp_calc SET DATA_RETENTION_TIME_IN_DAYS = 0;

2. テーブル種類を使い分ける

Snowflakeには3種類のテーブルがあります。通常・一時・トランジェントの違い を理解して使い分けるのがコスト最適化の近道です。

2. テーブル種類を使い分けるの解説図

  • PERMANENT(通常):Time Travel最大90日 + Fail-safe 7日
  • TRANSIENT(トランジェント):Time Travel最大1日、Fail-safeなし
  • TEMPORARY(一時):セッション中のみ、Fail-safeなし

ETLの中間テーブルやステージング層は TRANSIENT にするだけで、Fail-safe分の7日コストをまるごとカットできます。

CREATE TRANSIENT TABLE staging.daily_log (
  id NUMBER,
  payload VARIANT
)
DATA_RETENTION_TIME_IN_DAYS = 0;

3. 使用量を可視化する

どのテーブルが容量を食っているかは TABLE_STORAGE_METRICS ビューで確認できます。

SELECT table_name,
       active_bytes/POWER(1024,3)        AS active_gb,
       time_travel_bytes/POWER(1024,3)   AS tt_gb,
       failsafe_bytes/POWER(1024,3)      AS fs_gb
FROM   SNOWFLAKE.ACCOUNT_USAGE.TABLE_STORAGE_METRICS
WHERE  deleted = FALSE
ORDER  BY fs_gb DESC
LIMIT  20;

注意点:削ってはいけないテーブルもある

「全部TRANSIENTにすればお得!」と思いがちですが、本番の重要マスタや会計データなど 万一のときに復元したいテーブルはPERMANENT+十分な保持期間 にしておきましょう。Fail-safeは消したくても消せない代わりに、最後の砦として確実に守ってくれます。重要度ごとにメリハリをつけるのがコツです。

まとめ

  • Snowflakeのストレージ料金 = アクティブ + Time Travel + Fail-safe
  • DATA_RETENTION_TIME_IN_DAYS を見直すだけで履歴領域を圧縮できる
  • 中間・ステージングテーブルは TRANSIENT でFail-safeをカット
  • 重要データは保持期間を長めに、ログ系は短く、とメリハリ設計

ウェアハウスのコスト最適化と合わせて、ストレージ側もスリム化していきましょう!

参考リンク

関連記事