この記事は、LayerX Tech Advent Calendar 2025 の 10日目の記事です。前日は、 upamune さんの 「ローカル開発のシークレット設定を自動化する ── Go × AWS Secrets Manager」でした。
こんにちは。バクラク事業部 BizOps部 データグループの @TrsNium です。
バクラク事業部では、Snowflake を中心にデータ基盤を運用しています。機械学習モデルの精度検証、KPI のトラッキング、プロダクト機能からの直接参照、データを活用した営業効率化など、用途は多岐にわたります。また、取り込むデータ量や種類も多く、ユースケースもさまざまです。詳細については、弊社の中山(@civitaspo)が以前登壇した資料をご参照ください。
こうした幅広いニーズに対応するため、Snowflake の Warehouse はユースケースごとに分けて運用しており、どの領域でどれくらいクレジットが使われているのかという"ざっくりした傾向"は把握できるようにしていました。
ただ、それだけだと見えない部分もあります。同じ Warehouse の中で、どのクエリやどの dbt モデルが負荷の大半を占めているのかまでは分からず、ML 系の処理が重いことは分かっていても、Snowflake 上でどれくらい効いているのかは数字として拾えず、Query Historyなどからクエリの実行時間を眺めて「ああ、多分このモデルにコストがかかっているんだろう」みたいな推測をするしかない場面もありました。
Warehouseごとの大まかな傾向は掴めていたものの、その中でどのクエリやdbtモデルがコストがかかっているのかのかは分かりませんでした。これがバクラク事業部のSnowflake運用で抱えていた課題です。この記事では、SELECT.dev をトライアルして分かったことをまとめています。導入前は見えなかったコストの内訳が明らかになり、実際に改善できた部分もいくつかありました。Snowflakeを使っていて、運用面でモヤモヤしている方の参考になればと思います。
SELECT.dev とは
SELECT.devを導入すると、Snowflakeのコスト構造を細かく可視化し、クエリ単位・dbtモデル単位・チーム単位での改善提案や自動最適化が可能になります。
導入すると、曖昧だったコストの使われ方が具体的に分かるようになります。どのクエリがクレジットがかかっているか、どのdbtモデルのビルドコストが高いか、どのチームがどれだけリソースを使っているか、といった情報が一覧できます。
Warehouseごとの大雑把な数字ではなく、クエリ単位・dbtモデル単位・チーム単位といった細かい粒度でコスト構造が見えるのが、大きな価値だと感じました。
可視化だけでなく、改善の提案もしてくれます。非効率なクエリパターン、過剰なWarehouseサイズ、回しすぎているタスクなどを洗い出して、「ここを直せばコストが下がる」という具体的な指摘をくれます。
設定次第では、SELECT.dev側が自動でWarehouseの稼働状況やサイズを調整して、Computeコストをリアルタイムに最適化してくれる機能もあります。この機能だけで、導入直後から数パーセント〜十数パーセントのコスト削減が報告されているようです。
さらに、Usage Groupによる按分機能を使えば、チームごと・用途ごとのコスト管理も可能になります。「このチームがどれだけ使ってるか」「このプロジェクトでどれだけかかってるか」を、Usage Groupという単位で切り分けて集計できます。チーム、アプリ、dbtプロジェクト、クエリタグなど、色々な軸で見られるので、Snowflake管理者だけでなく各チームでコスト管理や予算管理をするときにも使えます。
アラート機能も便利です。クレジット消費が急増したり、クエリ実行量が増えたり、Warehouseの利用効率が落ちたりしたときに、Slackやメールでアラートを飛ばせます。「気づいたらコストが跳ねていた」を防げるようになります。
多様なユースケースを持つ環境だからこそ、細かく可視化する意味がある
私たちのように、機械学習、プロダクト利用、分析、BI、営業支援……など、複数の用途でSnowflakeを使うような環境では、負荷・コストの発生源は多岐にわたります。Warehouseをユースケースごとに切り分けていても、「その中のどの処理が重いか／何が無駄か」は見えづらい状況でした。
SELECT.devを導入することで、次のような価値が得られると考えています
- 利用者やデータ基盤運用者がコストを正確に把握し、チーム全体で同じ数字を見ながらROIを判断できる。データに基づいた意思決定が可能になる
- 細かい粒度でコストを部門・チーム・用途ごとに按分し、各チームが自分たちのコストに責任を持てる体制を構築できること。予算管理のオーナーシップを委譲することで、組織全体でのコスト最適化の精度を継続的に高められる
コスト構造が見えるようになれば、Snowflake管理者だけでなく各チームが自分たちで改善できるようになります。中長期で見ると、これが一番効いてきます。
SELECT.devを入れると、過去数ヶ月分のクレジット消費を振り返れます。「このクエリだけで月間コストの〇％を占めている」といった重いクエリを見つけて潰せます。MLや分析の重めのジョブを走らせるチームが、大きいWarehouseを使い続けているケースもあり、必要最小限のスペックに見直せます。
Usage Groupを使えば、コストをチーム別・用途別に割り振って把握できます。誰がどれだけ使っているか、どこを改善すべきかの議論がしやすくなります。
トライアルで見えたコストが高くなる構造
SELECT.dev を導入して分かったのは、想定していたコスト構造と、実際に Snowflake 上で起きている状況が大きく異なっていたことです。
クエリパターンを分析した結果、Streamlit in Snowflake の利用が想定以上に多く、それに伴うコストが積み上がっていることが判明しました。当初は試験的にアドホッククエリ用の Warehouse 上で Streamlit アプリを動かしており、専用 Warehouse を分離していませんでした。コスト削減策として、Warehouse の auto-suspend を最短（30秒）に設定する、専用の X-Small Warehouse を用意する等の対応は可能です。しかし、Streamlit アプリ自体の UI レンダリング等の処理は非常に軽量であり、本来は X-Small よりも小さいリソースで十分なところ、Snowflake の Warehouse は X-Small が最小サイズであるため、これ以上のコスト削減には限界があります。そこで、SPCS （Snowpark Container Services）上によく使われる Streamlit アプリケーションを持っていくなどの検討をしています。SPCSは、Snowflake 上で Docker コンテナを実行できるサービスです。Warehouse とは異なる課金体系（Compute Pool ベース）を持ち、より細かいリソース制御が可能です。詳細は Snowflake 公式ドキュメント を参照してください。
Warehouse の運用についても、実態と想定にギャップがありました。プロダクトからの初期利用時、適切なサイズが不明だったため Medium を選択しましたが、その後も惰性的に使い続けていました。SELECT.dev のダッシュボードで使用率を確認したところ、実際にはX-Small で十分なことが判明しました。すぐに改善できるポイントでした。
ML 系のワークロードについても、課題が明確になりました。従来は「ML 処理が重い」という認識はあったものの、具体的にどの程度の負荷がかかっているかは把握できていませんでした。SELECT.dev で確認すると、
- 単発クエリ自体が大きな負荷を発生させている
- さらに複数マシンで並列実行されているため、コストが増大していることが可視化されました。この状況を踏まえ、該当する dbt モデルをインクリメンタルモデル化し、不要なフルスキャンを削減しました。その結果、ML ワークロードのコストはトライアル期間中に明確に削減されました。
また、ユーザー単位・アプリケーション単位の負荷も可視化されたため、組織やサービスごとの Snowflake 利用状況を定量的に把握できるようになりました。チームや用途ごとのコスト把握・管理を行う上で重要な情報であり、SELECT.dev の導入により初めて具体的な議論の基盤が整いました。
SELECT.dev が改善活動を加速させた理由
SELECT.dev を導入して最も効果を感じたのは、改善に向けた意思決定までの距離が大きく短縮された点です。Snowflake の運用では、コスト増加の原因を突き止めるために Query History を調べたり、Warehouse の使用状況を個別に確認したりと、状況把握までの負担が小さくありません。情報が分散していることもあり、日常的に継続するには難易度の高い作業でした。
SELECT.dev を使うと、必要な情報が一箇所にまとまって見られます。重いクエリ、誰が実行したか、どのアプリから飛んできたか、Warehouse の状態、といった情報が紐づいているので、問題の所在を見つけるまでに必要な時間が大幅に減りました。クエリのパターンを自動で分類してくれる機能も便利で、どういう用途でどんな負荷がかかっているのかが一目で分かります。
これにより、「どこを改善すべきか」という議論が具体的なデータに基づいて行えるようになりました。たとえば、プロダクト系ワークロードの Warehouse サイズの適正化や、ML ワークロードのdbtモデルの見直しといったテーマは、SELECT.dev のダッシュボードを踏まえて議論が整理され、改善の優先順位も決めやすくなりました。
また、チーム内外での認識合わせにも効果がありました。チーム内では、従来は推測ベースだった会話が実データをもとにした議論に変わり、改善方針の合意形成がスムーズになりました。チーム外とも、同じ数値を見ながら課題を共有できるようになりました。こうした変化により、改善に着手するまでのプロセスが軽くなり、実際の対応スピードが明確に向上したと感じています。
まとめ
今回のトライアルを通じて最も実感したのは、コスト最適化とは「削減する」ことではなく「正確に把握する」ことだという点です。どれだけ適切にモデルを設計しても、どれだけ運用ガイドラインを整備しても、日々の運用の中で少しずつ実態とのズレが生じます。そして気づいた時には「なぜこれほどコストが高くなっているのか」という状況に陥っています。
SELECT.dev は、このズレを日常的に可視化してくれました。どのクエリが負荷を生んでいるのか、誰のワークロードがコストを消費しているのか、どこに無駄があるのかが明確に把握できます。基盤チームだけでなく、アプリケーション開発や分析を担当するメンバーも「コストを意識した開発」を行うきっかけとなりました。
もし「Snowflake のコストが高い」「何がコストを押し上げているのか分からない」「ボトルネックを特定したい」といった課題を抱えているなら、SELECT.dev は検討に値します。導入の負担も小さく、ログも分かりやすく、改善の方向性が自然と見えてきます。
来年も引き続き、可視化と改善のサイクルを回しながら、データ基盤の強化を進めていきます。
