ここまで11回、設計と運用を扱ってきました。区切りとして、費用の観点で並べ直します。
順序は効果 ÷ 手間でつけています。上ほど、少ない労力で効きます。
1. まず内訳を出す（EP.3）
これを飛ばすと、以降がすべて当てずっぽうになります。ウェアハウス別・クエリの形別・利用者別に分解する。多くの場合、上位のいくつかで全体の大半を占めます。
並べるのは平均ではなく合計です。短いが大量に走るものが、総量では上回ります。この原則は パフォーマンスチューニング実践 でも共通です。
2. 使われていないウェアハウスを止める
作ったまま忘れられたウェアハウスは、意外なほど見つかります。検証用、一時的な用途、退職者が作ったもの。
WITH usage AS ( SELECT warehouse_name, COUNT(*) AS 実行数 FROM snowflake.account_usage.query_history WHERE start_time >= DATEADD(day, -30, CURRENT_TIMESTAMP()) GROUP BY 1),cost AS ( SELECT warehouse_name, ROUND(SUM(credits_used), 2) AS 消費 FROM snowflake.account_usage.warehouse_metering_history WHERE start_time >= DATEADD(day, -30, CURRENT_TIMESTAMP()) GROUP BY 1)SELECT c.warehouse_name AS ウェアハウス, c.消費, COALESCE(u.実行数, 0) AS 実行数, ROUND(c.消費 / NULLIF(u.実行数, 0), 4) AS 1実行あたりFROM cost cLEFT JOIN usage u ON u.warehouse_name = c.warehouse_nameORDER BY 1実行あたり DESC NULLS FIRST;1実行あたりの消費が異常に大きいものが、止め方の設定が甘いか、ほとんど使われていないウェアハウスです。実行数がゼロなのに消費があるものは、即座に止める候補になります。
3. 止め方を見直す（EP.4）
設定だけで済み、効果が大きい。ただし最短にすればよいわけではないというのが EP.4 の要点でした。クエリ間隔の中央値を測って決めます。
特に効くのが、バッチ用途で長く待っているケースです。使われ方が断続的でないなら、待つ意味がありません。
4. 実行時間の上限を入れる（EP.4）
終わらないクエリが起動を維持し続けるのが、想定外の費用の典型です。上限を入れておけば、そこで打ち切られます。
これは削減というより事故の防止です。効果が見えにくい対策ですが、一度起きれば元が取れる種類のものです。
5. 結果を使い回せる形にする（EP.4）
が効けば、計算資源を起こさずに返るため費用がかかりません。効くようにするには、毎回違う結果にしない書き方が必要でした。
「直近24時間」を「前日以降」に変える。それだけで使い回しが効くようになります。厳密さが本当に必要かを問い直すと、意外に多くが丸められます。
6. 保持期間を見直す（EP.6）
一時テーブルや中間データに、本番と同じ保持期間が設定されているのはよくある形です。これは保管費用に直結します。
特に毎回全件を入れ替える表が主犯になります。保持日数ぶんの複製が積み上がるためです。ここは全件入れ替えを差分更新に変えることで、性能と費用が同時に改善します。
7. 読み取り量を減らす（EP.5）
返す行は少ないのに、ほぼ全区画を読んでいるクエリを探し、書き方を直す。列に関数を適用していないか、条件が並び順と噛み合っているか。
ここからは手間が増えます。クエリを1本ずつ確認する必要があるためです。ただし上位のいくつかを直すだけで効くのは、性能改善と同じ構造です。
8. 中間層をビューにする（EP.11）
で全層を表として作っていると、中間層の作成費用と保管費用が積み上がります。軽い整形の層はビューで十分なことが多い。
ただし、何度も参照される中間層をビューにすると、参照のたびに計算されます。参照回数を見て判断してください。ここは単純な削減ではなく、作成回数と参照回数の比較になります。
9. ウェアハウスのサイズを見直す（EP.2）
上げっぱなしになっているものを探します。誰かが「遅いから」と上げ、誰も戻していない。EP.2 で「見直す条件を記録する」と書いたのは、これを防ぐためでした。
逆に、 が出ているなら上げると安くなります。処理時間が大きく縮むためです。下げる方向だけを見ないのが要点です。
10. 使われていない資産を消す
放置された複製、使われていない表、誰も見ていない集計。EP.7 で命名規則と期限の話をしましたが、これは棚卸しを可能にするための投資でした。
消す前に本当に使われていないかを確認してください。参照の記録を見れば判断できます。「たぶん使っていない」で消すと、月次の処理が止まります。
-- 過去90日間、一度も参照されていない表を探すWITH referenced AS ( SELECT DISTINCT value:objectName::string AS 表名 FROM snowflake.account_usage.access_history, LATERAL FLATTEN(input => base_objects_accessed) WHERE query_start_time >= DATEADD(day, -90, CURRENT_TIMESTAMP()))SELECT t.table_catalog || '.' || t.table_schema || '.' || t.table_name AS 表, ROUND(t.bytes / POWER(1024, 3), 2) AS GB, t.created AS 作成日, t.last_altered AS 最終更新FROM snowflake.account_usage.tables tLEFT JOIN referenced r ON r.表名 = t.table_catalog || '.' || t.table_schema || '.' || t.table_nameWHERE t.deleted IS NULL AND r.表名 IS NULL AND t.bytes > 0ORDER BY GB DESCLIMIT 30;参照の記録から判断するのが要点です。「たぶん使っていない」という印象で消すと、月次や年次でしか動かない処理が止まります。90日で足りない場合は期間を延ばしてください。それでも年次処理は捕捉できないので、消す前に関係者へ確認する手順は省けません。
11. 削りすぎないために
最後に注意点です。費用は数字で見えますが、失われたものは数字になりません。この非対称があるため、削減の議論は必ず削りすぎの方向へ寄ります。
| 削減 | 失うもの | 判断の目安 |
|---|---|---|
| 止めるまでを短くしすぎる | 断続利用での速度 | クエリ間隔を測って決める |
| 保持期間を短くしすぎる | 戻せる範囲 | 気づくまでの時間から逆算する |
| ウェアハウスを共用する | 費用の内訳と、干渉のなさ | 分けることは投資 |
| 中間層を全部ビューに | 参照時の速度 | 参照回数と比較する |
| サイズを一律で下げる | 処理時間（結果的に費用増も） | スピルの有無を確認 |
2行目が最も危険です。保持期間は保険なので、切り詰めた効果は平常時にしか現れません。事故が起きたときに「戻せない」と分かる。気づくまでの時間から逆算するという EP.6 の基準を守ってください。
費用の最適化とは、支出を減らすことではなく、支出と得ているものを釣り合わせること。
12. 継続する仕組みにする
一度削っても、放っておけば元に戻ります。継続的に見える状態を作るのが最後の仕事です。
- 1日次で内訳を記録する — 変化に気づける
- 2閾値を超えたら通知する — 請求が来る前に気づく
- 3四半期ごとに棚卸しする — 使われていない資産を洗い出す
- 4決めたことを記録する — サイズ、止め方、保持期間の根拠と見直し条件
4番目が効きます。根拠が残っていないと、誰も変えられず、誰も戻せません。「なぜこの設定なのか」が分かる状態を保つことが、継続的な最適化の前提になります。
内訳を出すことが最優先で、これを飛ばすと以降が当てずっぽうになる。効果が大きく手間が小さいのは、使われていないウェアハウスの停止・止め方の見直し・実行時間の上限。手間が増えるのは読み取り量の削減から先。そして削減では、失われるもの（速度、戻せる範囲）を必ず併記してください。ここまでの内容への反応や、扱ってほしい論点があれば記事下のリアクションからお寄せください。続編は随時追加していきます。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。