Snowflakeの落とし穴10選：PoC・検証で先に潰しておくべき罠

Snowflakeは「動かすだけ」なら驚くほど簡単に始められます。だからこそ、落とし穴は性能そのものよりも「課金」と「権限」に集中します。EMWはAWS上で、低コストの小規模導入から最大規模まで、複数業種でSnowflakeを設計・構築・運用してきました。その過程で得た教訓は一貫しています——事故になりやすい罠は、PoC・検証・テストの段階で意図的に踏み抜いておけば、本番では未然に防げる、ということです。本稿では、現場で繰り返し遭遇する10の罠を、コスト・設計・ガバナンスの3系統に整理して解説します。

01落とし穴は「性能」ではなく「課金」と「権限」に集中する

Snowflakeのストレージとコンピュートは分離しており、仮想ウェアハウス（Warehouse）を起動している時間だけクレジットを消費します。つまり多くの事故は、クエリが遅いことではなく、「気づかないうちにウェアハウスが動き続けている」「新しく作ったテーブルが特定ロールから見えない」といった、課金と権限の設計に起因します。EMWでは大手飲料メーカー様、大手冷凍倉庫事業者様、中堅の営業専門企業様など、規模も業種も異なる案件をAWS上で扱ってきましたが、要注意ポイントの多くは共通しています。まずは全体像を「コスト・課金」「設計・パフォーマンス」「権限・ガバナンス」の3系統でマップ化します。

02罠①②：自動停止の切り忘れと「監視の不在」でコストが爆発する

最初にして最大の罠が、AUTO_SUSPEND（自動停止）の設定です。ウェアハウスは起動または再開のたびに最低60秒ぶんが課金され、その後は秒単位課金になります。逆に言えば、AUTO_SUSPENDをNULL（無効）にしていると、誰も使っていない夜間や週末でも動き続け、静かにクレジットを溶かします。ここで重要なのは、最小サイズのXSでも同じ料率で課金され続けるという点です。私たちは検証環境で、ダッシュボード用のXSウェアハウスをうっかり自動停止なしにしたまま放置し、想定外にクレジットを消費することを先に確認しました。そのため本番では、対話用途は短め、バッチ用途も業務特性に合わせてAUTO_SUSPENDを必ず設定する運用に落とし込んでいます。なお自動停止を判定するバックグラウンド処理はおよそ30秒間隔で動くため、30秒未満や30の倍数でない値は意図どおりにならないことがあります。

設定と同じくらい重要なのが「上限の監視」です。Resource Monitorはクレジットのクォータ（一定期間の上限）を定め、しきい値に達したらNOTIFY（通知）、SUSPEND（実行中クエリ完了後に停止）、SUSPEND_IMMEDIATE（即時停止）といったアクションを起こせます。まずはNOTIFYで異常を検知し、暴走時のブレーキとしてSUSPENDを併用するのが定石です。ここに一つ落とし穴があり、Resource Monitorが制御するのはユーザー管理のウェアハウスであって、Snowpipeや自動クラスタリング、Cortex系のようなサーバーレス（Snowflake管理）コンピュートは対象外です。これらを含む全体を捉えるにはBudgets（予算）を併用します。

03罠③④：SELECT乱発と小ファイルの大量ロード

Snowflakeは列指向で、クエリが参照した列だけをスキャンします。ところが安易なSELECT *は全列を読み込ませ、この列プルーニングの利点を捨ててしまいます。さらにWHERE句に選択性の高い条件がないと、マイクロパーティションの枝刈り（pruning）も効かず、テーブル全体をなめる羽目になります。検証段階で、探索的に投げたSELECT *が大きなウェアハウスを長時間占有してクレジットを浪費することを先に体感しておき、本番のクエリレビューでは「必要な列だけ」「選択的な述語を必ず付ける」を徹底しています。

データ取り込み側の代表的な罠が「小ファイルの大量ロード」です。SnowflakeはS3などのステージ上のファイルを並列に取り込みますが、ファイルが小さすぎるとファイル単位のオーバーヘッドが積み上がり、Snowpipeではこのオーバーヘッド課金が無視できなくなります。公式は圧縮後でおおよそ100〜250MB程度のファイルを推奨しています。私たちは検証で、数KB〜数MBの細切れファイルを大量に流し込むと取り込みコストとレイテンシが悪化することを確認し、本番ではS3側でマイクロバッチを集約してからロードする設計にしています。データ生成が遅い場合でも、1分に1ファイル程度へまとめると、コストとレイテンシのバランスが取りやすくなります。

04罠⑤⑨：ACCOUNTADMINの濫用と権限継承の誤解

ACCOUNTADMINはSnowflakeで最も強い管理ロールで、AWSでいうrootアカウントに近い存在です。日常作業でこれを使い回すのは、rootでEC2を運用するのと同じ危うさがあります。公式のベストプラクティスは明確で、ACCOUNTADMINは限られた人数に絞る、少なくとも2名には付与する、対象ユーザーにはMFAを必須にする、そしてユーザーのデフォルトロールにはしない、というものです。日常のオブジェクト作成はSYSADMIN配下のカスタムロール階層で、権限付与はSECURITYADMINで、というように役割を分けます。AWS側でも、Snowflakeのストレージ統合が引き受けるIAMロールは対象バケットに絞った最小権限にしておくのが対になります。

もう一つの厄介な罠が「権限継承の誤解」です。あるロールにスキーマ内の全テーブルへのSELECTを付与しても、それはあくまで既存オブジェクトに対する付与であり、後から作られる新しいテーブルには自動では及びません。「BIロールに権限を付けたはずなのに、新テーブルだけ見えない」という典型的な事故はここから生まれます。将来のオブジェクトまで含めたいならGRANT ... ON FUTURE（future grant）を使うか、権限付与を一元管理するManaged Access Schemaを採用します。私たちはこの挙動を検証環境で必ず再現し、「新テーブルが見えない」を本番のリリース直後に起こさないよう、future grantの設計をテンプレート化しています。

05罠⑥⑦：過剰なTime Travelとクラスタリングの乱用

Time Travelは過去データへ遡れる強力な機能ですが、保持期間を延ばすほど、変更前のデータを保持するためストレージが増えます。デフォルトの保持は1日で、Enterprise Edition以上なら永続オブジェクトで最大90日まで設定できます。ここで「念のため全テーブル90日」に倒すと、更新頻度の高いテーブルほどストレージが膨らみます。さらに永続テーブルにはTime Travelの後段に7日間のFail-safe（構成変更不可）が控えており、これも保持コストになります。検証用やスクラッチ用途のテーブルは、Fail-safeが付かずTime Travelも最大1日のTransient/Temporaryテーブルにするのが有効です。私たちは検証で保持期間とストレージ増分の関係を測ってから、テーブルの重要度に応じて保持日数を段階的に設計しています。なお、これらの世代データはKMS（顧客管理鍵によるTri-Secret Secure含む）で暗号化されたまま保持されるため、保持期間の設計はセキュリティと課金の両面に効いてきます。

クラスタリングキーも「効きそうだから付ける」で乱用されがちな機能です。自動クラスタリングはデータを継続的に並べ替えるため、その処理でクレジットとストレージを消費します。公式は、対象が数TB規模の大きなテーブルで、かつクラスタリングキーで頻繁にフィルタ・ソートするクエリが多い場合にのみ有効だとしています。週に100回未満しか参照されないテーブルや、キーを使わないクエリでは、コストが性能改善に見合いません。私たちは本番適用の前にSYSTEM$ESTIMATE_AUTOMATIC_CLUSTERING_COSTSで維持コストを見積もり、「本当に大きく・よく検索されるテーブルだけ」に絞っています。

06罠⑧⑩：巨大Live接続とリージョン間転送という隠れコスト

BIツールのライブ接続やダッシュボードの自動リフレッシュは、便利な反面、静かにウェアハウスを起こし続けます。数秒〜数十秒間隔で更新クエリが飛び続けると、ウェアハウスはアイドルにならず、AUTO_SUSPENDが永遠に発火しない状態になり得ます。ここで誤解しやすいのがCLIENT_SESSION_KEEP_ALIVEで、これはセッションを維持するだけでウェアハウスの自動停止を止めるものではありません。にもかかわらず、大きなウェアハウスに常時ライブ接続を張ると、結果的に「止まらない大型ウェアハウス」が生まれます。私たちは検証で、更新間隔の短いダッシュボードが大型ウェアハウスを終日起こし続ける様子を先に観測し、本番ではBI用に専用の小さめウェアハウスを割り当て、キャッシュを活かす更新間隔に調整しています。

最後がリージョン間・クラウド間のデータ転送です。同一リージョン内の転送は無料ですが、別リージョンや別クラウドへデータを出すとテラバイト単位の転送料金が発生します。レプリケーション（DR構成など）でも、転送とコンピュートのコストがターゲット側に計上されます。これはAWSのリージョン間・AZ間転送と同じ発想で、PrivateLinkでネットワークを閉域化しても、リージョンをまたぐ転送そのものの費用は消えません。私たちは検証段階でDRやデータ共有の構成を組み、どこでクロスリージョン転送が発生するかを先に洗い出したうえで、本番ではSnowflakeアカウントとS3・処理系を同一リージョンに寄せ、不要なリージョンまたぎを避ける設計にしています。

07まとめ：10の罠は「検証で消化」してから本番へ渡す

ここまでの10項目——コスト爆発と監視の不在、自動停止の切り忘れ、SELECT乱発、小ファイルの大量ロード、ACCOUNTADMIN濫用、過剰なTime Travel、クラスタリング乱用、巨大Live接続、権限継承の誤解、リージョン間転送——は、いずれもドキュメントに沿って設計すれば防げるものばかりです。ただし、頭で理解しているだけでは本番で足をすくわれます。重要なのは、これらをPoC・検証・テスト環境で意図的に一度踏み抜き、挙動とコストを自分の目で確かめ、Resource Monitorや権限テンプレート、ファイル集約といった「ガードレール」に変換してから本番へ渡すことです。EMWが重大障害0を継続できているのは、派手な仕組みではなく、この地道な「先に踏み抜く」運用の積み重ねによるものです。SnowflakeはAWSの上で動くからこそ、S3・IAM・PrivateLink・KMS・Lambdaといったコンポーネントと合わせて設計することで、コストと権限の両面を安全側に倒せます。