株式会社CARTA MARKETING FIRMで、データエンジニアをやっている@pei0804 です。
普段の業務は、データエンジニアの仕事はもちろん、組織・採用戦略を考えたり、データエンジニア育成など、データ活用を推進するための色々なことをやっています。
当記事では、業務で開発・運用しているSnowflakeベースのデータ基盤に、SELECTを導入したら、めっちゃ良かったので、それについてシェアさせて頂きたいと思います。 CEOに確認したところ、SELECTの導入は国内初だそう。
ちなみに、ただの可視化ツールではありませんでした。導入しただけで、ウェアハウスの利用料が最大40%程度削減ができたりと、可視化で留まらないパフォーマンスを出してくれてるので、コストでお困りの方は必見です。また、ウェアハウスのサイズが大きいほど効果的です。
SELECT、と聞いてまず思い浮かぶのが、dbtパッケージ、get-select/dbt-snowflake-monitoringではないでしょうか。このパッケージは、Snowflakeのメタデータを使ってコストとパフォーマンスの監視を可能にするモデルを作成します。
今回は、この便利なパッケージの作成元が提供しているSELECTのクラウドサービス(SaaS形態)を採用しました。 その特長や、この採用の決め手、将来への展望について、この記事で解説していきます。
- 記事の読者対象
- 効率的なコスト管理を目指しており、Snowflakeを活用しているけれど、時間的な余裕がない皆さまのための記事です。
- 本記事から学べること
- SELECTがどのようなケースに適合するのか、従量課金サービスのコスト可視化がいかに営業活動に有益であるか、そしてコスト最適化サービスが事業にどのような価値をもたらすのか、といった事について理解を深めて頂けます。
SELECTとは
SELECTは、Snowflakeのコストを可視化しつつ、いい感じにコスト最適化もしてくれますよという便利なサービスです。
価格設定は非常にシンプルで、年間のSnowflake使用量の最大3%までの定額料金になります。 価格のページにも書いてますが、支払ったコスト以上のコスト削減をすると書いてあり、結構強気な姿勢で好みですw
このサービスの仕組みは至ってシンプルで、顧客のSnowflakeのメタデータを、定期的に転送して、それらを使って、各種可視化をやってくれています。 また、可視化だけではなく、ウェアハウスの自動節約機能があるんですが、実は利用料をペイするインパクトがあったりします。
導入背景
弊社では、Snowflakeとdbtを使ったデータ基盤を構築しています。 導入の背景などは、以下のスライドにまとめているので、興味がある方はそちらをご覧ください。 ぼくのかんがえる最高のデータ分析基盤 / strongest-data-architecture-discussion - Speaker Deck 構築してから約2年が経過し、dbtモデル数、クエリ発行数、ストレージ利用量が右肩上がりに増えていきました。この状況に対して、基盤チームも何も手を打たずに、手をこまねいていたわけではなく、あの手この手で、コストが下がる施策を打っていましたが、これには意外と手間がかかる問題がありました。
チームの開発体制と扱っている事業
弊社では、データ基盤を開発するメンバーが、フルタイム2名、業務委託1名の3名体制です。
各プロダクトチームが、データを適宜追加して、dbtを使って変換し、レポート、分析、機械学習の訓練データなど、様々なユースケースに利用をしています。プロダクトは広告配信プラットフォームで、比較的データ量が多く、油断してると、コストが爆発的に増えることがあります。
コスト削減施策のコスト増
Snowflakeには様々なメタデータが提供されていることを、冒頭にも紹介したget-select/dbt-snowflake-monitoringを使えば、コストのかかっているポイントを見つけ出す手助けにはなります。
しかし、これらを実際の意思決定に結びつけるには、いくつかのステップを踏む必要があります。
例えば、全体的にコストが上がってきてるので、改善できそうなところがあるかを調べたいケース。私なら、以下のようなフローでコストパフォーマンス最適化できそうなポイントをさがします。
- ウェアハウスで一番高いものを見つける。
- まずは全ウェアハウスのコストを集計し、最もコストが高いものを特定します。
- 高コストウェアハウス内のクエリを分析する
- 定常的なクエリで高いものを見つけれるとベスト。
- 高価なクエリの効率が悪いポイントの特定する
- クエリの書き方なのか、元データの性質なのか？
- コスト削減の可能性評価
- 改善するために、どの程度時間がかかりそうか？
- 改善した後に、どの程度の削減額が見込めそうか。
- 改善を実行する。
しかし、こうしたコスト改善は、常に効果的とは限らず、時には労力に見合わない結果となることも少なくありません。また、Snowflakeの利用が進むにつれて、利用シナリオが増え、実態の把握が難しくなりました。結果として、コストを把握し改善に取り組むためのコストも増大し、コスト削減の仕事自体のコストパフォーマンスが合わなくなってきていました。
そうした状況の中、簡単かつ効果的なコスト削減の手段が求められていました。そして、SELECTがそのニーズにぴったりと合致したのです。
SELECTの導入効果
直感的UIによってコスト把握がスムーズに
本当に同じデータ見てるのか？ってくらい見せ方がうまいです。
用意されている画面と、何が見られるかをざっくり書いてみました。
- Dashboard
- ここを見れば大体何が起きてるか分かるダッシュボード。
- Workloads
- All Workloads
- ワークロード全体のコスト可視化
- Query Patterns
- 同じと思われるクエリをいい感じに集計して、コスト可視化。
- Serverless
- SnowpipeやExternal tableなどのコスト可視化。
- Custom
- 特定のIDを付与して、集計する。https://select.dev/docs/custom-workloads
- dbt, Fivetran, Lookerなどのツール向けのUI
- ツールから発行されているクエリ。e.g. https://select.dev/docs/dbt
- All Workloads
- Warehouses
- Snowflakeウェアハウスのコストとオートセービング機能の有効化、無効化
- Storage
- データベース、テーブル単位で、コストを見れる。
- Usage Groups
- ロール、ユーザー、ウェアハウスなど、任意のフィルタをして、コスト集計。
- Contract Overview
- Snowflakeとの契約しているクレジットが、いつ頃に枯渇するかを可視化。
これらを実際どのように使うか、簡単なケーススタディでお見せします。
これは一例で、実際には、もっといろんな切り口でコストを把握できます。
ケーススタディ：高そうなクエリを見つける
一番高いウェアハウスを掘り下げていく。
Warehousesの画面で、ウェアハウスのコストの一覧が確認できます。
ここにあるChangeを見れば、コストが上昇傾向にあることが分かるので、便利です。
ウェアハウスで走っているクエリから、高価そうなクエリを見つける。
詳細を確認して、何が起きてるか把握する。
この画面を見た瞬間、Average Durationが異常なくらい長い(6分超)ので、これがコストが高くなってる原因だと判断できます。コスト原因を掘り下げる必要がある場合は、かかっているコスト、パフォーマンス、直近の実行状態などを見ていけます。また、こうした方がいいよと、Cloud側からレコメンデーションがある場合もあります。
具体的にかかっているコストや、傾向などがビジュアルで理解できます。
Run Historyを見れば、1つ1つのRun単位でも掘り下げていけます。
実際に行った対応
このデータは、1時間にそれなりの作成されるデータです。これに対応する施策を行いました。
before: 全部フルスキャンしたnot nullテストを実施
after: 直近のデータだけにテストを実施
この結果、コストは100分の1になりました。
それぞれのRunごとに見ても、一目瞭然です。
怪しそうな箇所から、ドリルダウンしていって、特定のクエリまで見つけ出す導線が、非常にスマートに実現されています。
ケーススタディ：使われてないテーブルを特定する
使われてない価値のないデータは消していきたいですよね。
画面上で90日間使われてないテーブルをポチッとフィルターでき、それぞれに対し具体的に放置した際にいくらくらいコストかかってしまうかが一目で分かります。
ウェアハウスの自動節約機能
https://select.dev/features/automated-savings
> Zero Effort Savings
> SELECT helps instantly lower your credit consumption by 10-30% with no effort required, freeing up budget for other valuable workloads.
公式ページには、上記のような言及があります。
そんなことある？って感じで、結構懐疑的だったんですが、本番に適用してみたところ、ウェアハウスに利用料を40％程度削減できてるワークロードも出てきて、この節約機能だけで、SELECT Cloudの利用料を回収できてしまうレベルのインパクトでした。
ちなみに、この機能が有効に働く場面は、ウェアハウスのサイズが大きければ大きいほど、動いている時間あたりの単価が高いこともあり、効果が大きいことが実績で見えてます。
使い方は、至って簡単です。Automated SavingsをONにするだけです。
サマリーレポート
地味に嬉しいのが、日次、週次、月次でレポートをSlackに投稿してくれることです。
弊チームでは、3週に1度、コストを確認する会を実施してますが、それとは別に、このレポートが毎日投下されるので、コストの増減を日々チェックできます。
異常コスト増アラート
サマリーレポートだけでは、当日発生した急なコスト増に気づけません。そこで便利なのが、Spend Anomaly Alertsです。 日々このくらい消費するドルを設定しておいて、そこを超えたものを通知させるというシンプルな機能ですが、ミスるとコストが爆増しがちなので、こういうのが地味にありがたいです。
コストがクレジットではなくドル表記
いくつかの画像を見て、お気づきになったと思いますが、利用クレジット数ではなく、それぞれのコストがドル表記になっています。
地味にこれが便利で、クレジットだと、ドルに戻して〜という作業があるのですが、SELECTは基本的に実際にかかってるドルが出てくるので便利です。
Blogがめっちゃ良い。
SELECTを知ったきっかけは、運営元が書いている面白い記事です。 Snowflakeのアーキテクチャの話から、コスト、パフォーマンス・チューニングまで、幅広くDeepDiveできる素晴らしい記事がたくさんあるので、是非読んでみてください。 select.dev
まとめと将来の展望
SELECTを導入したことで、短時間でコストを把握することが可能になり、少人数体制の弊チームにとっては、最高のサービスでした。 また、導入しただけで、トータルのコスト減にも繋がったため、非常に満足の行く効果を得られました。 ここでは、紹介しませんが、select.devは、非常に面白いロードマップを持っています。 それらも含めて、今回は採用に至っていて、将来性に期待しています。
