AWS Startup ブログ

TROCCO®× dbt × Amazon S3で始めるコスト安なデータ分析ジャーニーとサンプルのご紹介

みなさまこんにちは。スタートアップソリューションアーキテクトの岸田です。
昨今データの重要性は増しています。ビジネスにおける意思決定に必要なインサイトを得るために、溜まったデータから必要な情報を得ることは当たり前の時代になってきました。しかしながら、データ分析を始めるためにも複数の壁があります。この壁に立ち向かうべく、AWSのスタートアップチームではスタートアップのためのデータ分析基盤のサンプルをリリースしました。このブログではスタートアップがフェーズごとのコストパフォーマンスを満たしながら、分析ジャーニーを進める手法とそのサンプルを解説します。

想定読者

  • 既存のリレーショナルデータベースに直接クエリをかけるのが心配な方
  • 初期費用は50USDくらいに抑え、データ量やクエリ量に応じて課金されるしくみを作りたい方
  • 複数のデータソースを取り込みデータ統合をしたい方
  • dbtを利用したモダンなデータモデル管理をしたい方

アーリーなスタートアップが分析導入時に直面する課題

データウェアハウスによるコスト高

昨今データSaaSの発展に伴い、データウェアハウスを中心にしたアーキテクチャがメジャーです。すべてのデータをデータウェアハウスに保存し、不特定多数のクエリをデータベースに集中させるという構成です。ですがこのとき初期フェーズからデータ量が多くなると、コストが高騰するリスクがあります。さらに要件が複雑化し、変換ジョブが重たくなるとよりコストは跳ね上がります。

データ統合パイプライン構築の負荷

データ分析基盤は、複数の”リソース”を対象に横断的な分析をすることが一般的です。この場合の”リソース”とは「アプリケーションデータを保持するRDBMS」「ユーザー行動ログを保持するGoogle Analytics」「営業データを保持するSalesforce」など様々です。ですが常にプロダクトの進化に尽力するスタートアップにとって、継続的にデータを取得するための開発時間・運用時間の確保は非常に困難です。

テーブル数とともに増える管理工数

対象のデータソースや分析時のユースケースが増えるたびに、テーブル数は膨れ上がります。数百ほどのテーブル数となると、テーブルの管理負荷は恐ろしいほどに増大していきます。管理者はテーブルの作成元や現在の利用状況がわからず、テーブルの整理が滞り使われないテーブルが増え続け、果てしないコスト高騰が発生するでしょう。

primeNumberとAWSスタートアップチームが考える理想的な分析ジャーニー

このような課題に貢献すべく、AWSスタートアップチームはAWSのパートナーであるprimeNumberとタッグを組みました。以下のような分析ジャーニーを推進します。

初期（Non-Data Warehouse構成）：Data Warehouse(DWH) を持たずAmazon Simple Storage Service( Amazon S3 )をベースにした分析基盤構成にする。TROCCO®を活用し複数データソースの転送パイプラインを作る。テーブルのモデル化をdata build tool ( dbt ) で行うことで、膨れ上がるテーブルを管理する。クエリをかけたい場合はAmazon Athenaを用いてコストを削減する。テーブルフォーマットにはApache icebergを採用することで、DWHを使う後期フェーズに備える。

後期（Data Warehouse構成）：DWHを導入する。すべてのデータはAmazon S3に集約しておく。クエリパフォーマンスが求められるテーブルはDWHに転送し、クエリを最適化する。DWHとAmazon S3を使い分けることで、全体コストを最適化する。

我々が推進するデータアーキテクチャは、primeNumberが提供するTROCCO®・エコシステムが整ったdbt ( data build tool ) を活用します。

TROCCO®とは

TROCCO®は、ETL/データ転送・データマート生成・ジョブ管理・データガバナンスなどのデータエンジニアリング領域をカバーした、データ基盤構築・運用の支援SaaSです。あらゆるデータの連携・整備・運用を自動化することでスピーディーにデータ活用環境を整備し、インサイトを得やすい状況に導きます。

dbt (data build tool) とは

dbtとは、データ変換ワークフローを提供するオープンソースです。SQLを利用してデータ変換を定義し、分析に最適なデータモデルを定義できます。dbtによりデータ定義はモデリング化され、バージョン管理、テスト、およびドキュメント化までをサポートします。

初期のデータ分析基盤 〜Non – Data Warehouse構成〜

AWSで完結するパターン

まずはAWSで完結するNon-Data Warehouseな構成について解説します。サンプルはこちらになります。
https://github.com/aws-samples/startup-data-pipeline-samples/tree/main/aurora-athena-sample

図1 – AWS完結のNon-DWH構成

ポイントは以下の通りです。

  • 生データをAmazon S3に集約し、dbt上で定義するデータモデルに沿ってマートテーブルを出力する。dbtにより大量のテーブルをデータモデル化・依存関係をdbt documentで出力しテーブル管理ができるようになる
  • クエリはAmazon Athenaで行いコストを抑える
  • Amazon S3での保存形式をiceberg Tableにすることで、DWH構成からもクエリをかけられるように備える

Amazon S3上のテーブルはiceberg形式で保存することで、将来DWHからもクエリをかけることができます。加えてデータのタイムトラベル/柔軟なパーティショニング/データ整合性の担保など様々な恩恵を得ることができます。dbtの table_type の設定を iceberg に変更することで、iceberg形式で保存することができます。

TROCCO®を利用するパターン

上記のパターンだとAWSで完結できる反面、以下を考慮する必要があります。

ここでprimeNumberが提供するTROCCO®を利用することで、GUI上で設定を行うだけで以下の分析基盤を実現できます。複雑な開発やメンテナンスをおこなわず、数百の外部SaaSのデータを対象にデータを取り込み、変換ジョブを設定できます。こちらの構成ではdbtは利用できませんが、すぐにデータの変換パイプラインを作りたい方にはおすすめできる構成です。

サンプルはこちらになります。
https://github.com/aws-samples/startup-data-pipeline-samples/tree/main/trocco-athena-sample

図2 – TROCCO®と組み合わせたNon-DWH構成

マートデータ用の変換SQLもUI上で定義することが可能です。

図3 – TROCCO®での変換SQL設定画面

おおよその費用

Non-Data warehouseの構成ではデータ量やクエリに伴う従量課金制のため、データを取り込みパイプラインを動作させなければ料金はかかりません。たとえば、実際に以下のデータ量を入れてパイプラインを動作させたケースを考えます。

  • 分析対象のデータ量は100GBあり、Parquetファイルに圧縮後は33GBとする
  • 一日に一回更新を行う

その際のおおよその月額利用金額は以下のようになります。実際に分析をおこなう際は、以下とは別にAmazon Athenaのデータスキャン料・Amazon QuickSightの課金が発生します。

初期費用： 41 USD

加えてTROCCO®を利用する場合、以下の料金が月額で発生します。ジョブの実行時間が4時間以内である場合は、無料で利用することができます。（Starterプランの場合は、サンプルにあるワークフロー機能は利用できません）

詳しくは、こちらをご覧ください：
https://primenumber.com/trocco/pricing#faq-processingtime

後期のデータ分析基盤 〜Data Warehouse構成〜

扱うデータ量・分析する人が増えてくると基盤のパフォーマンスを上げる必要があります。その場合はDWH中心としたアーキテクチャを導入することが一般的です。ですが素直にデータウェアハウスを導入して移行をしてしまうと、データ転送に時間と費用がかかります。加えて、変換ジョブでのデータ量やジョブ数が増えることで、コンピューティングコストが膨れ上がるリスクがあります。

今回お伝えするアーキテクチャは、DWHにすべてデータを集約する形式ではなく、Amazon S3を組み合わせたアーキテクチャです。Non-DWH構成の際に分析していたデータをAmazon S3上でiceberg形式で保存することで、DWHからもテーブルを参照できます。そのためデータを移行する必要がありません。加えてアクセス頻度やデータの鮮度が高いテーブルはDWHに入れ、それ以外はAmazon S3に保持しAmazon Athenaで検索する構成にします。これによりコストを抑えることができます。また、即時性が不要なデータに対してはAmazon S3上でデータ変換を行うことで、データウェアハウス上のリソースコストも削減できます。

図4 – DWH構成の概要図

その他にも以下のようなポイントを利用することで、守備範囲の広いアーキテクチャを構築することができます。

  • Google Analytics 4やSalesforceなどの外部SaaSのデータは、TROCCO®を利用することでAmazon S3もしくはDWHに転送します。履歴データはAmazon S3に、直近7日間のアクセス頻度の高いデータはDWHにいれることで、コスト最適化を行います
  • Amazon AuroraはAmazon RedshiftのZero-ETLを利用してデータを転送します。
  • DWH上でデータをマート化したい場合は、TROCCO®上でdbtジョブを定義することで複雑なパイプラインを実行できます。履歴データの大部分はAmazon S3上で変換することで、DWHにかかるコストを削減できます

上記を反映したアーキテクチャイメージは以下のとおりです。

図5 – DWH構成の詳細アーキテクチャ図

Amazon AuroraからAmazon RedshiftへのZero-ETLのサンプルは、こちらで公開されています。
https://github.com/aws-samples/startup-data-pipeline-samples/tree/main/zero-etl-sample

まとめ

今回はデータ分析をコスト安く始めたい方向けに、データ分析の需要にあわせて変化できる柔軟なアーキテクチャとそのサンプルをご紹介しました。Non-DWHの構成からエコシステムが整っているdbtを利用することでよりモダンに運用でき、さらにTROCCO®を利用することで開発コストを抑えて迅速にデータ分析を構築できます。ご興味いただいた方は、ぜひAWSが公開しているサンプルをご利用ください。コストパフォーマンスに見合った、分析ジャーニーに柔軟に対応できる分析基盤を構築しましょう。

著者について

岸田 晃季岸田 晃季 (Kouki Kishida)
スタートアップソリューションアーキテクトスタートアップにて機械学習エンジニア、プロダクトマネージャーを経験後、より多くのスタートアップと関わりたいと思い現職にジョイン。スタートアップのために何ができるか日々模索中。