Snowflakeで高負荷分析SQLを可能にするデータ基盤を実現（株式会社ヌーラボ）

参考になった

会員限定コンテンツです。無料登録すると制限なしでお読みいただけます。

無料登録してアーキテクチャを見る

レビュー投稿日の情報になります

株式会社ヌーラボ / wonohe

メンバー / データエンジニア / 従業員規模: 101名〜300名 / エンジニア組織: 51名〜100名

最終更新日2025/02/06投稿日2025/02/06

ツールの利用規模

ツールの利用開始時期

事業形態

11名〜50名

2023年11月

B to B

B to C

ツールの利用規模

11名〜50名

ツールの利用開始時期

2023年11月

事業形態

B to B

B to C

アーキテクチャ

会員限定コンテンツ無料登録してアーキテクチャを見る

アーキテクチャの意図・工夫

Data Sources

データソースとして各サービスのデータ、その他Google Spreadsheetで管理されているものなどを取り込んでおり、データ取り込みのツールとしてAWS GlueとTROCCOを併用しています。AWS GlueとTROCCOを使ってAmazon S3に取り込んだあとで、Snowflakeにコピーしています。

Data Storage, infra management

Snowflakeの構成管理はTerraformで行っており、またSnowflake内でのデータモデルの構築はdbtで行っています。TerraformでSnowflakeにテーブルとstageを作成し、Snowflake上でCOPY文を実行することでAmazon S3からデータを取り込みます。

Data Visualize, Analyze

BIツールとしてTableauとAmazon Quicksightを利用しており、SnowflakeにあるデータはTableauで可視化しています。Amazon QuicksightはAmazon Athena専用で、Snowflakeでは利用していません。また、Snowflakeでの可視化やダッシュボード作成も使える状態にしてあります。

Data Pipeline

ELTデータパイプラインはApache Airflowで管理しています。 Apache Airflowが管理しているのは以下の処理です。

データソースからAmazon S3へのデータ取り込み（AWS Glue）
Amazon S3からSnowflakeへのデータ取り込み
dbtを使ったSnowflakeでのデータモデル変換
Amazon Athenaでのデータモデル変換
Amazon Quicksightのデータセット作成・更新

工夫

Snowflake導入時、データパイプラインをSnowflakeタスクで構築する案もあったのですが、Amazon Athenaで扱っているデータセットをSnowflake側でも使うため、Apache Airflowで実装しました。 Amazon AthenaとSnowflakeに依存関係があり、Amazon Athena側でのデータセットの作成とSnowflakeへの取り込みの処理順を担保する必要があったため、Snowflakeタスクを利用した場合に複数システムの整合性をとることが難しくなると判断し、Airflowでの構築を選択しました。その結果、Apache AirflowにSnowflakeへの認証情報を保持するなどの実装が必要になりましたが、データパイプラインの管理は１箇所でシンプルになりました。

導入の背景・解決したかった問題

導入背景

ツール導入前の課題

社内のデータ基盤としてAmazon Athenaを利用していましたが、扱うデータ量の増加に伴い、SQLがタイムアウトする事象が発生していました。また、旧データ基盤には機密情報が含まれていることから社内の一部の人しか利用できておらず、全社に展開する場合、権限管理が煩雑になる問題がありました。全社でのデータ活用を推進するために、全社員が安全に利用できるデータ基盤の構築が必要でした。

どのような状態を目指していたか

高負荷なSQLが実行可能になること
データ量の増加に耐えうるアーキテクチャを持っていること
全社員が利用するための権限管理機能とインターフェースを有していること

比較検討したサービス

Amazon Redshift
Databricks

比較した軸

既存データ基盤（Amazon Athena/Amazon S3）からのデータロード方法
BIツールとの連携機能
サービスが持つ可視化機能
権限管理機能

すでに運用しているデータ基盤があり、新データ基盤を構築後も並行運用する計画であったため、既存データ基盤からのデータロードが容易に行えるかどうか、ということが１つのポイントでした。新データ基盤を全社に展開するにあたり、利用者がデータを可視化・分析するための機能や、セキュリティ的な観点から権限管理機能も重要視していました。

選定理由

多くの操作がSQLで実行可能であること
UI/UXが分かりやすいものであったこと
ウェアハウスの起動が高速であること
ウェアハウス起動時間のコストが1分単位で最適化しやすいこと
テクニカルサポートが標準で提供されていること

データ基盤チームにSQLが得意なメンバーが多かったため、ほとんどの操作がSQLで完結できることは大きな利点でした。また、UIが直感的で分かりやすかったため、全社展開がスムーズに行えると感じたのも魅力です。運用面では、1分単位のウェアハウス課金によりコストの最適化が容易であること、さらにテクニカルサポートが標準で提供されている点も、選定の決め手となりました。

導入の成果

改善したかった課題はどれくらい解決されたか

すべて解決されました

どのような成果が得られたか

データチーム以外のメンバーがデータ基盤にアクセスできるようになった
大きなデータの分析が可能になった

導入に向けた社内への説明

上長・チームへの説明

ADR（Architecture Decision Record）を作成し、サービス導入の背景や必要条件、候補サービスのPros/Consを記載した上で、チーム・上長に説明をしました。それぞれのサービスにPros/Consがありましたが、弊社の事業や今後の展望、チームメンバーのスキルなど様々な要素を踏まえ、チーム・上長とディスカッションを複数回行い、導入を進めました。