📚 参考書籍

※この記事は書籍の一部をベースに再構成しています。もう少し踏み込んだ内容（設計や具体例）は書籍の中でまとめているので、気になる方はそちらもどうぞ。

####『ゼロから触ってわかった！AI Agent Observability入門― MLflow・Databricksで実践するAIエージェントの評価・監視・安全性・説明可能性』
本書は、AI Agentを「作って動かす」だけでなく、その品質をどう観測し、どう評価し、どう守り、どう説明可能にするかを体系的に学ぶための入門書です。
https://link.amazon/B04VaTlR3

📚 その他参考書籍一覧

※全書籍・全ブログ・週刊Databricksリリース情報
https://modern-tech-hub.mellow-launc-5442.chatgpt.site/books

⚡Snowflake PoC入門⚡ Virtual Warehouseの性能評価とは？スケーリング・クエリ最適化・ワークロード分離を検証する

SnowflakeのPoCでは、データロードやパイプライン構築に加えて、クエリ性能の評価が重要になります。

特にSnowflakeでは、Virtual WarehouseによるComputeの分離やスケーリングなど、従来のDWHとは異なる性能モデルを採用しています。

今回は、Warehouseの性能をどのように評価すべきか、PoCで確認するポイントを整理します。

1. Virtual Warehouseの基本構造

Virtual Warehouseは、SnowflakeでSQLやデータ処理を実行する計算リソースです。

主なサイズには、次の種類があります。

• X-Small（XS）
• Small（S）
• Medium（M）
• Large（L）
• X-Large（XL）

Warehouseのサイズを1段階上げると、基本的にComputeリソースが約2倍になります。

例えば、従来のGen1 Standard Warehouseでは次のようになります。

サイズ	Credits/時間
X-Small	1
Small	2
Medium	4
Large	8
X-Large	16

※Gen2 Warehouseなどでは消費Creditが異なるため、実際の構成を確認します。

2. 線形スケーリングを検証する

Snowflakeでは、Warehouseサイズを大きくすることで、クエリ性能の向上が期待できます。

例えば、次のような結果が理想的です。

Warehouse	処理時間
Small	60秒
Medium	30秒
Large	15秒

※数値は説明用の仮定です。

ただし、リソースを2倍にしても、処理時間が必ず半分になるわけではありません。

クエリの複雑さ、スキャン量、Join処理、メモリ使用量などによって効果は異なります。

小規模なクエリでは、サイズを大きくしても性能改善が限定的な場合があります。

PoCでは、同じSQLを複数サイズで実行し、処理時間とCredit消費量を比較します。

重要なのは、最速のWarehouseではなく、性能とコストのバランスがよいWarehouseを選択することです。

3. Auto-SuspendとAuto-Resumeの評価

Snowflakeには、Warehouseの自動停止・自動再開機能があります。

• Auto-Suspend：一定時間使用されなければ停止
• Auto-Resume：クエリ実行時に自動再開

例えば、60秒間アイドル状態が続いたら停止する設定が可能です。

PoCでは、次の項目を確認します。

• 設定時間で停止するか
• 再開時にどの程度待つか
• BIツールの応答時間への影響
• 不要なComputeコストを削減できるか

注意点として、Warehouseは起動・再開のたびに最低60秒分の課金が発生します。

また、Warehouseの停止によってローカルデータキャッシュは失われます。

頻繁な停止・再開が必ずしも最適とは限りません。

4. マイクロパーティションとData Pruning

Snowflakeでは、テーブルデータをマイクロパーティション単位で管理しています。

各パーティションには統計情報が保持されており、クエリに不要なデータを読み飛ばすことができます。

これが**Data Pruning（データプルーニング）**です。

例えば、

• テーブル全体：10TB
• 実際のスキャン量：200GB

であれば、全体の一部だけを読み取っていることになります。

PoCではQuery Profileを確認します。

• Partitions Scanned
• Partitions Total
• Bytes Scanned
• Spilling
• 実行時間

特に、スキャン対象パーティションの割合は、クラスタリングやフィルター条件の効率を判断する指標になります。

ただし、スキャン量だけで性能を判断せず、実行計画全体を確認することが重要です。

5. ワークロード分離の検証

Snowflakeでは、異なるWarehouseを利用してComputeを分離できます。

例えば、

• ETL Warehouse：大量データの変換
• BI Warehouse：ダッシュボードの参照

という構成です。

PoCでは、ETL処理とBIクエリを同時実行し、BIの応答性能を比較します。

Warehouseを分けることで、計算リソースの競合を減らせます。

ただし、共有サービスなどの影響まで完全にゼロになるわけではありません。

また、同一Warehouseで大量の同時実行が発生する場合は、Multi-Cluster Warehouseも選択肢です。

• Scale Up：Warehouseサイズを拡大
• Scale Out：クラスター数を増加

単一クエリの高速化と同時実行性能の改善は、分けて評価することが重要です。

6. PoCで確認すべき性能評価ポイント

実際の性能テストでは、次の観点を整理します。

評価項目	確認ポイント
スケーリング	サイズ別の処理時間
起動・停止	再開時間・課金
Pruning	スキャン割合
クエリ最適化	Query Profile
ワークロード分離	ETL実行中のBI性能
コスト効率	処理時間とCredit消費

さらに、結果キャッシュによる影響を除外するため、次の設定を利用できます。

ALTER SESSION SET USE_CACHED_RESULT = FALSE;

ただし、これは結果キャッシュの制御であり、Warehouseのデータキャッシュまで無効化するわけではありません。

比較時にはキャッシュ状態や同時実行数などの条件をそろえます。

まとめると

Snowflakeの性能PoCでは、単純なSQL実行速度だけでなく、次の5つを評価することが重要です。

• Warehouseサイズと性能の関係
• Auto-Suspend / Auto-Resumeの挙動
• Data Pruningによるスキャン効率
• Query Profileによるボトルネック分析
• Warehouse分離による性能安定性

Snowflakeの性能評価とは、速いSQLを確認するだけでなく、必要な性能を適切なコストで継続的に提供できるかを判断することです。

次節では、WarehouseのComputeコスト構造について詳しく検証します。