この投稿は、2024年JINSのアドベントカレンダー15日目 の記事です。
はじめに
株式会社ジンズのバックエンドエンジニア兼開発環境保全活動家の中島です。
今回はアドベントカレンダーということで軽めな内容を一つ… Snowflakeのデバッグ環境を作るにあたって押さえておくべき設定値 についてお話しします。
背景
弊社JINSでは経営指標の算出やデータの分析・示唆出し等を行うためのデータ分析基盤として, Snowflake を利用しています。
Snowflakeとは米国Snowflake社が提供するSaaS型データクラウドプラットフォームです。
そのウリの一つがストレージと計算資源(Warehouse)が分離されたアーキテクチャ, これによりスケーラビリティの高いシステムを構築することが可能となります。
ただこのSnowflake, スケーラビリティの高いシステムであるがゆえに大規模なシステムではオトクに利用可能な反面, 小規模なシステムでは割高 になる傾向があります。
本番環境で使う分には気にならない話なのですが, 導入可否判断のためのプロトタイプの構築やSnowflakeの機能を掴むためのデバッグ環境等小さく色々行いたい場面も多々発生し得ます。特に個人で遊びたい場面もあるはず…。
といった背景から, 私の経験に基づく 小規模デバッグ環境を構築する上でコスト削減のために弄るべき設定値 をご紹介します。
前提
私個人で構築しているSnowflake環境は下記のようなものです。
- 3個のDatabase
- それぞれ3個のSchema
- それぞれ5個程度のTable・View
- 5個程度の定期実行ジョブ(dbt cloudから実行)
設定
WAREHOUSE_SIZE
WAREHOUSEのサイズ に関する設定です。
X-SMALLが最小で, サイズが1段階大きくなるにつれ単位時間あたりの費用が倍々で増えていきます。
処理速度に影響しますが, 小規模環境であれば基本的にX-SMALLで十分。
> ALTER WAREHOUSE <your_warehouse> SET WAREHOUSE_SIZE = X-SMALL;
明示的に指定しない場合はデフォルト値としてX-SMALLとなるため, 基本的には気にしなくても大丈夫です。
(ClassicConsoleから作成された場合はデフォルトがX-LARGEになるそうですが, 最近はSnowsightがスタンダードなので基本大丈夫。)
DATA_RETENTION_TIME_IN_DAYS
Snowflakeのオブジェクト(ACCOUNT/DATABASE/SCHEMA/TABLE)で設定可能な値です。
TABLEのTimeTravel履歴を何日分残すか を決定します。
TimeTravelとはSnowflakeにおけるバックアップ機能で, 1クエリでTABLEの過去の状態を取得できます。
その分ストレージコストを消費するので, デバッグ環境であれば基本的には不要なはず, ということで"0"を推奨します。
> ALTER ACCOUNT <your_account> SET DATA_RETENTION_TIME_IN_DAYS = 0;
デフォルト値は1日, かつStandardEditionの場合は最長で1日, Enterprise Editionで最長90日です。
またACCOUNTレベルで設定すればそのACCOUNTで作成されるオブジェクトに適用されます。
AUTO_SUSPEND
WAREHOUSEの自動停止 に関する設定です。
Snowflakeは動いていないWAREHOUSEを自動停止(=課金停止)する機能があり, この値は処理完了から自動停止がかかるまでの秒数を指定します。
自動停止処理は60秒ごとに走るとのことで細かい制御はできませんが 60秒以下にしておけばおおむねOKです。
(2024/12/15時点: 最近30秒になった可能性があるのでとにかく小さくしておけば大丈夫そう)
なお 0にすると自動停止が無効となる のでここだけは注意。
> ALTER WAREHOUSE <your_warehouse> SET AUTO_SUSPEND = 1;
デフォルトは600秒で, 処理完了後10分間は課金された状態となります。
これが結構無駄で, 数秒で終わる軽量なジョブを毎日実行している私の環境では一番コスト削減に効きました。
設定後はコストが約1/6になりました
まとめ
Snowflakeの導入を検討されている方や機能を探っている方はそこそこいらっしゃるのではないかなと考えています。
そういった方に参考にしていただきつつ, もっと良いtipsがあればぜひとも記事を書いていただきたく思います。
Discussion