【Snowflake】Gen2 (第2世代)標準ウェアハウスとは？Gen1(第1世代)との比較からコスト検証のSQLまで徹底解説

1. はじめに

こんにちは、京セラコミュニケーションシステム株式会社の林（@kccs_koki-hayashi）と申します。

Snowflakeの標準ウェアハウスの次世代版として登場した「Gen2 (第2世代)」は、設定を変更するだけで簡単に導入できるコンピュートエンジンです。AWS Graviton3などの新世代アーキテクチャを採用しており、クエリコードの書き換えなしで処理性能の向上が期待できます。

しかし、クレジット単価（コンピュート費用) が上がる中で「どのような条件でコスト削減が成立するのか」を正確に把握しなければ、逆に追加コストが発生するリスクもあります。

なお、実運用においては auto_suspend（自動停止）による待機時間（例：60秒）が発生するのが一般的です。しかし、本記事は厳密な「コスト・パフォーマンス検証」であるため、待機時間という変動要素を排除し、純粋なコンピュート性能と「最低60秒課金仕様」の影響のみを浮き彫りにするべく、クエリ完了直後に手動で即時停止させた数値で算出しています。

データに関しては公式サンプルデータ（TPCH_SF100）を使用し、Gen1（第1世代）とGen2（第2世代）間にて「サイズ別比較（X-Small, Medium, X-Large）」と「60秒を超える高負荷クエリ比較」の2つのアプローチで検証した結果をまとめます。

2. 要約

本記事における検証の前提、損益分岐点、および検証結果の要約は以下の通りです。

【検証の前提と損益分岐点】

• Gen2の損益分岐点: クレジット単価が約1.35倍（AWS環境）となるため、コスト削減を成立させるには 約25.9%以上の処理時間短縮 が必要。

【検証結果】

• サイズ別検証のハマりポイント:
  • X-Small: ディスクスピルが発生しつつも、処理時間が100秒超と長いためGen2のCPU高速化が上回り約38.0%短縮（コスト16.3%削減）
  • Medium/X-Large: 数秒〜数十秒で完了する単体処理では、Snowflakeの「最低60秒課金仕様」によりクレジット単価アップ分（1.35倍）がダイレクトにコスト増へ直結する。
• 高負荷ワークロード検証: 1.5億件×6億件の大規模テーブル結合処理において、Gen1で75.3秒だった処理がGen2で40.5秒に短縮（約46.2%の高速化）。
• 結論: 単発の短い処理では待機時間や最低課金仕様が足を引っ張るため、Gen2は「連続バッチ処理（dbt等）」や「数十分単位の重い処理」に適用することで確実なトータルコスト削減を実現できる。

3. Gen1 vs Gen2 スペック・損益分岐点

【基本スペック】

比較項目	Gen1 (第1世代)	Gen2 (第2世代)
基盤アーキテクチャ	x86（Intelプロセッサなど）	AWS Graviton3など
クレジット単価	基準値（1.0倍）	AWS/GCP: 約1.35倍 / Azure: 約1.25倍

本記事の検証およびコスト算出は、AWS環境を前提として記載します。

【処理短縮率とコスト増減マトリクス】
Gen2のクレジット単価1.35倍を吸収するためには、以下の図の通り 「約26%以上の時間短縮」 がコスト削減の絶対条件となります。

4. 検証1：サイズ別ベンチマークと「評価のハマりポイント」

まずは、単一テーブル（LINEITEM 約6億行）を対象とした集計処理でサイズ別（X-Small, Medium, X-Large）の比較を行いました。
※意思決定支援ベンチマーク（TPC-H）をベースにした、GROUP BYによる集約とウィンドウ関数を含むクエリを使用しています。

測定結果（単一テーブル集計）

世代間の処理時間と推定コストの差異が分かりやすいよう、結果を並べて比較します。

コスト指数の算出根拠（クエリ完了直後の即時停止前提）

• Gen1 (X-Small): 1.0 credit/h × (103.51秒 / 3600秒) = 0.0288
• Gen2 (X-Small): 1.35 credit/h × (64.19秒 / 3600秒) = 0.0241

サイズ	処理時間 (Gen1)	処理時間 (Gen2)	コスト指数 (Gen1)	コスト指数 (Gen2)	評価・所感
X-Small	103.51秒	64.19秒	0.0288	0.0241	⭕ 高速化(38.0%) / コスト16.3%削減
Medium	37.30秒	21.33秒	0.0667	0.0900	⚠️ 高速化(42.8%)するも60秒補正に遭遇
X-Large	14.10秒	7.95秒	0.2667	0.3600	⚠️ 高速化(43.6%)するもオーバースペック

課金対象時間の算出前提と実運用の注意点

• 本検証における算出方法
  コンピュート性能および「起動時最低60秒課金仕様」の影響のみを純粋に比較するため、クエリ完了直後に手動で即時停止（SUSPEND）し、無効な待機時間を除外した値で算出しています。
• 実運用環境（AUTO_SUSPEND）での挙動
  AUTO_SUSPEND = 60 等の自動停止に任せる一般的な実運用では、実際の課金対象時間は「クエリ実行時間 ＋ 待機時間（60秒）」となります。
  (例：実行時間 37.30秒 の場合 ➔ 37.30秒 ＋ 60秒 ＝ 97.30秒分が課金対象)

サイズ別検証からの考察と注意点

パターン①：ディスクスピル下でのコンピュート性能とサイジングのリスク

X-Smallサイズで大容量データを処理した場合、メモリ領域に入り切らずローカルディスクへの書き出し（約6GBのディスクスピル）が発生しました。
本検証では処理時間が100秒を超えていたため、CPU性能により約38.0%の短縮（コスト16.3%削減）を達成しました。
しかし、メモリ不足が発生している状態自体が根本的なボトルネックです。実際にウェアハウスをサイズアップしていくと、Mediumサイズへの拡張でディスクスピル量は約2GBまで減少し（処理時間21.33秒）、X-Largeサイズまで拡張するとディスクスピルは完全に解消（0GB）され、処理時間は7.95秒（X-Smallの約8分の1）まで圧倒的に高速化されます。
実運用においては、スピルが発生している環境を単にGen2化するよりも、先にウェアハウスのサイズアップを行ってメモリを確保するのが本来のサイジング原則となります。

パターン②：大きすぎるサイズ（X-Large）による「最低60秒課金」の罠

X-Largeでは7.95秒という驚異的なスピードを記録しましたが、Snowflakeの仕様上「ウェアハウス起動時は最低60秒分が課金される」ため、60秒未満で終わる単体クエリでは、短縮の恩恵を受けられずクレジット単価が1.35倍になった分だけ費用が増加してしまいます。

5. 検証2：60秒超え高負荷クエリでの限界性能測定

次に、60秒の課金下限を考慮し、約1.5億件のテーブルと約6億件のテーブルの全件JOINを含む高負荷なワークロード（Mediumサイズ）で再検証を行いました。
※このSQLはDBベンチマークで一般的なTPC-Hをベースとしており、大規模なJOIN処理、集約（GROUP BY）、複雑なウィンドウ関数を複合的に実行し、ウェアハウスの純粋なコンピュート・メモリ耐性を比較する意図があります。

測定用SQLスクリプト

-- ① ウェアハウスの初期化
CREATE OR REPLACE WAREHOUSE TEST_GEN2_HEAVY_WH
  WAREHOUSE_SIZE = 'MEDIUM'
  GENERATION = '1'
  AUTO_SUSPEND = 60
  AUTO_RESUME = TRUE
  INITIALLY_SUSPENDED = TRUE;

ALTER SESSION SET USE_CACHED_RESULT = FALSE;

-- ② Gen1でのテスト（キャッシュリセット含む）
ALTER WAREHOUSE TEST_GEN2_HEAVY_WH SET GENERATION = '1';
ALTER WAREHOUSE TEST_GEN2_HEAVY_WH RESUME;
ALTER SESSION SET QUERY_TAG = 'BENCH_HEAVY_GEN1';

SELECT
    o.o_orderpriority,
    YEAR(o.o_orderdate) AS order_year,
    QUARTER(o.o_orderdate) AS order_quarter,
    l.l_shipmode,
    l.l_returnflag,
    COUNT(DISTINCT o.o_orderkey) AS distinct_orders,
    COUNT(*) AS lineitem_count,
    SUM(l.l_extendedprice * (1 - l.l_discount)) AS net_revenue,
    RATIO_TO_REPORT(SUM(l.l_extendedprice)) OVER (PARTITION BY YEAR(o.o_orderdate)) AS revenue_share_in_year,
    RANK() OVER (PARTITION BY YEAR(o.o_orderdate), o.o_orderpriority ORDER BY SUM(l.l_extendedprice * (1 - l.l_discount)) DESC) AS revenue_rank
FROM SNOWFLAKE_SAMPLE_DATA.TPCH_SF100.ORDERS o
INNER JOIN SNOWFLAKE_SAMPLE_DATA.TPCH_SF100.LINEITEM l ON o.o_orderkey = l.l_orderkey
GROUP BY 1, 2, 3, 4, 5
ORDER BY order_year, order_quarter, net_revenue DESC;

-- ③ Gen2でのテスト（キャッシュリセット含む）
ALTER WAREHOUSE TEST_GEN2_HEAVY_WH SET GENERATION = '2';
ALTER WAREHOUSE TEST_GEN2_HEAVY_WH SUSPEND;
ALTER WAREHOUSE TEST_GEN2_HEAVY_WH RESUME;
ALTER SESSION SET QUERY_TAG = 'BENCH_HEAVY_GEN2';

-- （②と同じクエリを実行）

-- ④ クリーンアップ
DROP WAREHOUSE IF EXISTS TEST_GEN2_HEAVY_WH;

測定結果（大規模JOINワークロード）

世代	処理時間	課金対象時間	クレジット単価	推定コスト指数
Gen1	75.34秒	75.34秒	1.00倍	0.0837
Gen2	40.50秒	60.00秒	1.35倍	0.0900

• 処理短縮率: 46.2% 短縮 （75.34秒 → 40.50秒 / 約1.86倍の高速化）
• 損益分岐点クリア: 達成 （必要な短縮率25.9%を大幅超過）

データが示す通り、計算性能面において Gen2は約46.2% という圧倒的なパフォーマンス向上を叩き出しました。しかし、75秒クラスの重いクエリであっても、単独実行して即座に停止した場合、60秒の課金下限に引っかかりコスト指数は微増にとどまります。

6. 考察：単体クエリの見た目と実運用のギャップ

今回の高負荷クエリ検証でも、Gen2が40.5秒で終わってしまったため「最低60秒課金仕様」に引っかかり、単体クエリのコスト指数上は Gen1(0.0837) < Gen2(0.0900) となりました。

しかし、実際のプロダクション環境では、必ずしもこの通りになるとは限りません。素直にウェアハウスが60秒以上稼働し続けるような連続処理であれば、Gen2によるコスト削減の恩恵を十分に受けることができます。

なぜ「60秒を超えて連続稼働するワークロード」ではGen2でコスト削減になるのか？

• 連続クエリ実行（パイプライン）の場合:
  ウェアハウスを起動したまま複数のパイプライン処理を連続して流す場合、60秒の最低課金保証は「全体の起動時」に一度かかるのみです。各クエリの処理時間が約46%短縮されれば、パイプライン全体の稼働時間が約46%削減され、トータルコストは約27%削減 されます。
• Gen2でも60秒を超える単独処理:
  元々Gen1で3分〜数十分かかっているような大規模な集約処理であれば、Gen2で高速化されても60秒を割り込まないため、処理時間の削減がダイレクトにクレジット消費量の削減に繋がります。

7. Gen2導入でコスト削減を成功させる条件

実証実験から見えた「Gen2ウェアハウス導入・運用ガイドライン」は以下の通りです。

【Gen2 移行判断チェックリスト】

• 単発の秒速クエリではなく、長時間の重い処理または連続バッチか？
  • 60秒未満で終わる単発クエリ中心ならGen1を維持し、26%以上の時間短縮が見込めるコンピュート重視のワークロードであればGen2へ変更します。
• 該当のウェアハウスでメモリ不足（ディスクスピル）が発生していないか？
  • 大規模なディスクスピルが発生している場合は、Gen2ではなくウェアハウスのサイズアップ（XS→S等）が先決です。これは今回の検証結果が示す通り、サイズアップによってディスクスピルを軽減・解消するアプローチの方が、同一サイズでのGen2以上に抜本的なパフォーマンス改善が見込めるためです。

【Gen2 運用時の必須設定】

• AUTO_SUSPEND の設定は最適化されているか？
  • 処理完了後に無駄に起動し続けないよう、バッチ用ウェアハウス等は AUTO_SUSPEND = 60 （1分）等の短い値に設定します。これはGen1でも共通のベストプラクティスですが、クレジット単価が高いGen2では待機時間の無駄がより大きなコスト増に直結するため、導入時に必ず見直すべき項目となります。

8. まとめ

Gen2ウェアハウスは、「適切なサイズ選定」と「最低60秒課金仕様の理解」を行えば、コード変更一切なしで処理速度向上とコスト削減を同時に達成できる強力な機能です。
単体のベンチマーク結果の数値だけに惑わされず、自社のワークロード特性に合わせた適用をぜひ進めてみてください！