こちらはヌーラボブログリレー2024 for Tech Advent Calendar 2024の18日目の記事です。
こんにちはこんばんは。RevOps部データインテグレーション課のonoeです。
今年の春から秋にかけて、社内のデータ基盤をAmazon Athena（以下Athena）からSnowflakeへ移行しました。本記事では移行した背景から選定プロセスについてお話したいと思います。
Snowflake上のインフラの話は弊社・大塚のブログ記事もご覧ください！
データ基盤をAmazon AthenaからSnowflakeに移行した話(インフラ編)
目次
移行前のデータ基盤の問題
ヌーラボのデータ基盤は2018年ごろから構築開始され、2022年の上場時には各種KPIの算出などに大きく貢献してきました。初期のデータ基盤構築については弊社・鶴田のブログ記事にも詳しく書かれています。
ですが、データ利活用を進める一方で、データ量・種類の増加にともない以下のような問題が顕在化していました。
1. Amazon Athenaパフォーマンスの限界
算出しているKPIの中で、AthenaのパフォーマンスではタイムアウトしてしまうSQLが発生していました。応急処置として、対象期間を絞るなどして対応していましたが、このままデータ量が増えていくといずれ破綻することが予想されました。
Athenaではプロビジョンドキャパシティという機能があり、リソースを予約してSQLを実行することができます。この機能を使えばパフォーマンスの向上は期待できるのですが、最小課金単価が1時間からとなっており、今のヌーラボのワークフローだと割高になる可能性がありました。
また、Athenaでは以下の対応を取ることでSQLが高速化する可能性があります。
https://aws.amazon.com/jp/blogs/news/top-10-performance-tuning-tips-for-amazon-athena/
- データのパーティション分割
- データのバケット化
- 圧縮の利用
- ファイルサイズの最適化
- 列指向のファイル形式の利用
2018年の構築開始時ではCSVでデータが保存されていたものが多かったので、高速化するためにParquet形式に変更したり、列指向を意識してSQLを修正（＊ではなくてカラム指定で取得する）するなどの取り組みはすでに実施していました。パーティション分割もある程度してあるので、現状を見直すとしても大きな改善が見込める可能性は低い・・・といった状況でした。
2. データモデリングの複雑さ
構築から6年が経ち、様々なデータモデルが追加されてきた一方で、命名規則や処理内容が複雑になってる箇所が増えてきていました。
モデリング手法としてディメンショナルモデリングを採用していたのですが、以下のような部分がうまく統一できていませんでした。
- 同じ意味をあらわすものでもカラム名が異なる
- factによって最小粒度が異なる
- テーブルの命名規則が統一されておらず意味が分かりづらい
上記のような状態だと、データ基盤チーム以外のメンバーがデータ基盤を使うことが難しく、全社でのデータ利活用を推進するうえで大きな障害になる可能性があったため、データモデリングの再設計が必要でした。
業務システムと分析システムは分離するべき
当初、Athena内でのデータモデル再構築の案を検討し、ディメンショナルモデリングの理解を深めるべく調査を進めていました。その中で、ぺい（pei0804）さんのブログ記事を読み、以下の箇所にハッとさせられました。
ぺい（pei0804）さんの記事より引用
そりゃそうだ、っていう話なんですよね。
目的が違うシステムは混ぜるな危険なんだと思います。
ヌーラボで言うと、会社の業績指標として利用する売上や契約数、解約率などのKPIをAthenaのデータ基盤で管理しているわけですが、それは業務システムと言えると思います。対して、全社でデータを利活用し、データ分析して示唆や傾向を得るというのは分析システムという面が強いと考えられます。
業務システムと分析システム、異なる２つのシステムを１つのAthenaで実現しようとしてることに無理がある、と気づいたので、新たなデータ基盤を構築するという方針に切り替えることにしました。
チームのチャットでつぶやく私
新データウェアハウス候補の選定
まず検討したのはAmazon Redshift Serverlss（以下Redsfhit）でした。
コンピューティングキャパシティの自動的なスケーリング、S3 に直接クエリを実行するAmazon Redshift Spectrumなど、Redsfhitが提供している機能で、抱えていた問題はクリアできたと思います。
しかし、ヌーラボでのAWSのアカウント構成上、AthenaとRedsfhitが同一のAWSアカウント内に存在する形となり、全社でデータ基盤を利用する際には、ユーザー／権限管理がかなり複雑になることが予想されました。
中長期的な運用を考えると、ユーザー／権限管理でリスクを抱えることは避けるべきと判断し、Redshiftは見送ることにしました。
AWSアカウント上の問題をクリアするためにはサードパーティのデータウェアハウス製品の方がよいのでは、ということで候補に上がってきたのがSnowflakeとDatabricksです。
ヌーラボの開発組織では、このような新しいサービスやアーキテクチャを意思決定する際の文書化のフォーマットとしてArchitecture Decision Records（ADR）を採用しています。
ADR採用の背景や、実際の活用については以下のブログ記事が参考になると思います。
ヌーラボにおけるSREの現在地
円滑なコミュニケーションのためにドキュメントで「空中戦」を回避しよう
今回は「新しいデータ基盤を構築する」という大きな意思決定なのでADRを作成しました。この時点ではまだ選定前なので、ADRのContextのところと、Decisionのための候補項目までを作成しています。
ADRを作成した後、Snowflake、Databricksの各サービスでそれぞれ2週間のPoC（Proof of Concept）を行いました。
ADRはBacklogに英語で作成します
Snowflakeを選定
すでに書いているとおり、2週間のPoCの結果、Snowflakeを選定しています。
まず、サードパーティのデータウェアハウス製品を使う場合、AWS側からのデータ転送が必須になるので、この部分がPoCでの大きな検証ポイントだったのですが、SnowflakeではいくつかのSQLを実行するだけでS3からデータ転送を行うことができました。また、Snowflakeではデータ保存場所のリージョンを自由に選ぶことができ、同一リージョンであればデータ転送料金がかからないというのも大きなポイントでした。
SnowflakeでS3からデータをロードするときのステップは以下のようになっています。
- snowflake上にstageを作成し、ロードするS3のパス、オブジェクト種別などを設定する
- snowflake上にロードするテーブルを作成する（空でOK）
- COPYコマンドでS3から2で作成したテーブルにデータをロードする
上記3つの作業はすべてSQLで操作します。
実際には、1の前にAWSにアクセスするためのロールの準備が必要ですが、これは一度だけの作業になります。
データ転送以外の部分だと、ウェアハウス（コンピューティングリソース）が１分単位の課金なのでコストの最適化がしやすいこと、ほとんどの操作がSQLで可能なのでコード管理がしやすいこと、データ基盤チームのメンバーが全員SQLに習熟していること、なども良いと感じた点です。
また、限られたリソースのなかで新しいデータ基盤の構築を進めるにあたり、標準でサポートへの問い合わせがついていることや、コミュニティが活発、なども選定の後押しとなりました。
これらの要因を総合的に評価し、Snowflakeがヌーラボに最適と判断し、導入を決定しました。
そして実装へ・・・・
方針が確定すれば、もうあとは頑張るだけです。
実は今回、Snowflakeとあわせてdbtも導入しました。
Snowflake導入にあわせてデータモデルも再設計しており、そのためのELT処理もあわせて刷新した形です。（これまではAthenaでELT処理を行っていました）
2つのサービス／ソフトウェアを同時に導入するのは学習コストも高く、大変な部分も多かったですが、今思えばやってよかったなあと思います。このあたりの話は、また別の記事でまとめたいと思います。
まとめ
新データ基盤構築の背景から、Snowflakeの選定までをまとめてみました。
どのサービスにも良いところがあり、選定に際してはかなり悩み、チーム内でもたくさんの議論をしましたし、時にはチーム外の人の意見も頂きながら検討を進めました。
また、各サービスのセールスやエンジニアの方にもたくさんのサポートをいただきました。末筆になりますが、この場を借りてお礼申し上げます。ありがとうございました。
この記事が同じような課題を抱えた方の一助になれば幸いです。
ヌーラボではこれからもSnowflakeを活用した、データのお話を皆様にお届けできるよう、がんばっていきたいと思います。
それでは！
