HomeChef、Snowflakeコストを抑制しアナリティクスチームにコスト意識を根付かせる

SELECTは、HomeChefの社内ツールでは得られなかった即時のコスト可視化と最適化インサイトをもたらしました。セットアップに要した時間はわずか30分。dbtとの深い統合と網羅的なコスト内訳により、1,200を超えるdbtモデル全体から効果の高い最適化機会を素早く特定できるようになり、これまでカスタムダッシュボードを自作して得ていた可視性もそのまま手に入りました。

HomeChefは5年前にEMRからSnowflakeへ移行し、当初は日次のdbtバッチ更新でLookerダッシュボードを動かす用途に活用していました。安定的でコスト効率の高い構成です。状況が一変したのは、Snowflakeをより多くの運用workloadsの基盤として使い始めてからでした。クエリの実行頻度は1日1回から15分ごとへ。チャーンテーブルへのupsertが大量に発生すると、Snowflakeの支出は一気に跳ね上がります。ほぼ一夜にして、桁が一つ上がるほどの増加が起きたのです。

SELECT導入前、HomeChefはクエリ履歴の増分収集、dbt環境ごとの支出を追跡するためのウェアハウス分離、独自のLookerダッシュボードを組み合わせて、社内でコスト監視の仕組みを構築していました。この自社製ソリューションは定常的な監視には機能していたものの、新たな課題が生じるたびに行き詰まりました。機能を追加するにはテーブルへの新しいディメンションやダッシュボードへの指標をPRで取り込む必要があり、Snowflakeのメタデータ構造が複雑なためアドホック分析にも時間がかかります。慣性と摩擦は大きく、Snowflake内で使う機能が広がるたびに、新たな難解なデータセットを学び直しているような状態でした。

コストが急増した際、HomeChefには支出を押し上げている要因を即座に可視化する手段が必要でした。SELECTはわずか30分で稼働を開始。dbtエコシステムへの深い理解と網羅的なコスト可視化により移行はスムーズに進み、自社製ソリューションは不要になりました。

HomeChefはまずストレージの課題に対処して20%を削減し、続いてSELECTでパフォーマンス最適化の機会を特定してさらに40%を削減することで、大幅なコスト圧縮を達成しました。1,200を超えるdbtモデルを抱える中、最適化対象を手作業で洗い出すのは不可能だったはずです。SELECTのコスト内訳とパフォーマンスインサイトにより、チームは効果が最大化される領域に集中できました。SELECTは最適化対象を見つけ出すツールであると同時に、パフォーマンス改善の全体を見渡す監視基盤としても機能しました。

SELECTはHomeChefの姿勢を、後追いの火消しからプロアクティブな監視へと変えました。Devinは毎朝、SELECTのクイックレビューから1日を始めます。コーヒーを淹れ、パイプラインを確認し、SELECTを開く。Snowflake環境の状況を毎日2〜3分で把握できるルーティンです。これにより、異常値や新たなworkloads、コストの急増を、大きな問題になる前に早期に検知できます。利用状況の経時的な変化も把握でき、想定外の新たなユースケースが発生していないかも察知できるため、ビジネスアナリティクスチームがそのエンドユーザーと直接連携できるようになっています。

おそらく最も大きな文化的変化は、アナリティクスエンジニアがデプロイ後ではなく開発段階から最適化を意識するようになったことです。SELECTのインサイトを活用したペアリングセッションを通じて、チーム全体がクエリ最適化の原則を学びました。今ではアナリティクスエンジニアがプルリクエストを出す前に、自ら進んでパフォーマンスを最適化しています。AEたちは「これはコストがかさみそう」と先回りで伝え、「このウィンドウ関数は重くなりそうだったから、PRを出す前に実行時間をXからYまで短縮しておいた」と語るようになりました。同じく重要なのは、SELECTが「最適化しない」判断の指針にもなり、影響の小さいモデルに労力を浪費しないで済むという点です。