Terraform×Snowflakeにより、2人で始めたCARTAのデータ基盤革命とは

CARTA ZEROは、Snowflakeを中核に据えたデータ基盤を整備し、事業構造と親和性の高い柔軟かつ拡張性のある環境を構築した。Snowflakeの運用にIaC（Infrastructure as Code）ツール「Terraform」を導入して、少人数でも迅速な導入と運用を実現している。

同社の経験はデータ活用の必要性に迫られている企業にとって興味深い。なぜプラットフォームにSnowflakeを採用したのか、なぜデータ処理にTerraformを採用したのか、データ処理の組織上のボトルネックはどこに存在し、どのように解決したのか。

CARTA ZEROのVP of Data 近森淳平氏、CARTA ZERO データエンジニア竹内晴貴氏に、同社のデータ活用の取り組みについて聞いた。

左から、CARTA ZERO データエンジニア竹内晴貴氏、CARTA ZERO VP of Data 近森淳平氏

Snowflakeを選んだ理由：コストメリット

CARTA ZEROがデータプラットフォームとしてSnowflakeを採用した背景には、コスト効率・拡張性・マルチクラウド対応といった技術的利点に加えて、事業構造との親和性があった。

同社はグループ全体でAmazon Web Services（AWS）を基盤に業務システムを構築しており、Amazon S3上に各種ログデータが保存されている。SnowflakeはAWS上に展開して同一クラウド内でデータを転送することが可能なため、転送料が発生しないというコストメリットを享受できた。

例えば、BigQueryを扱う場合に発生する異なるクラウドにデータを転送する必要があるソリューションと比較して、構造的な優位性を持っているといえる。

Snowflakeはストレージとコンピューティングの分離という設計思想を持っており、スケーラビリティに優れている。Amazon Redshiftでは、大規模なクエリと小規模なクエリが混在する際にリソース最適化が困難だが、Snowflakeではワークロードごとに仮想ウェアハウスを柔軟にスケーリングできる。これにより、データ活用を円滑に行える基盤を整備できたという。

CARTA ZERO VP of Data 近森淳平氏

Snowflakeを選んだ理由：柔軟性と拡張性

Snowflakeのもう一つの特徴は、最初からマルチクラウド対応を前提とした構造にある。CARTA ZEROのように複数のプロダクトを運用し、多様なクラウド環境と接続する必要がある企業にとっては、クラウドロックインの回避は重要な要素だ。Snowflakeはこの要請に応えることで、データ統合と活用の中心的基盤としての地位を確立している。

Snowflakeはデータウェアハウスとしての本質を追求しており、SQLベースの操作や自動パイプ機能など、データ活用を主眼とした機能群がそろっている。これにより、「マーケティング支援というCARTA ZEROの事業において、データを素早く活用し、日々の実験を通じて成果を引き出す体制が実現された」と近森氏は語る。データを組織内の共通言語とし、意思決定を支えるインフラとしてSnowflakeが機能しているのだ。

CARTA ZEROがデータを活用した業務改善と利益向上を掲げる中で、Snowflakeの柔軟性と拡張性は重要だという。データの整合性・即時性を担保しつつ、異なる組織文化を持つ統合企業群の中で共通認識を形成するための手段として、「Snowflakeは他の候補を抑えて最適解になった」と、近森氏は話した。

CARTA ZEROにおいて、単なるコストや速度の問題だけでなく、組織全体のデータ活用文化を推進するための基盤として、Snowflakeは不可欠な存在だ。Snowflakeを採用したことにより、データ基盤がボトルネックにならず、実験と検証を高速に繰り返すというデータ主導の開発スタイルが実現されている。

Terraformが支えた、たった2人から始まったSnowflakeの運用

CARTA ZEROがSnowflakeの運用においてTerraformを採用することになった理由として、「初期のデータ基盤構築フェーズにおける人的リソースが不足していたこと」「繰り返し作業を自動化したかったこと」を近森氏は挙げた。当初、わずか2人でSnowflakeへの移行を短期間で成し遂げる必要があり、手動での設定作業では到底間に合わない状況に直面していた。特にデータソースが多岐にわたり、それぞれに対する接続・設定が膨大であったため、コードによる一括管理と再利用が求められた。

Terraformを用いた構成管理により、Snowflakeの各種リソース(パイプ、テーブル、ロールなど)を宣言的に記述し、バージョン管理可能な形でインフラコードとして扱えるようになった。これにより、間違いがあった場合でも容易に状態を巻き戻すことができ、開発のトライアンドエラーが格段に容易になった。従来のマイグレーションツールでは現在の状態を把握するのが難しかったが、Terraformではコードを読めば即座に理解可能であり、再現性が高いというメリットがある。

さらに、Terraformによってモジュール化が進み、データソースの追加や削除といった操作がテンプレート化された。例えば、パイプラインの作成においても、既定のモジュールに必要なパラメーターを渡すだけで実装可能となり、Snowflakeの知識が乏しい開発者でも扱えるようになった。このようにして、データ活用を進めるプロダクトチームに自律的な構築権限を与えることが可能になったという。

また、Terraformの導入によって、データ基盤チームが構築したベストプラクティスを他チームに配布する形が成立した。再利用可能なモジュールを提供することで、品質を担保しながら分散的な開発が可能となり、CARTA全体としてのスケーラビリティが高まった。これは、開発者がSnowflakeの構造を理解せずとも、必要な処理を安定して構築できる仕組みを提供することを意味している。

一方、Terraformの活用においては一定の技術水準が求められる。営業担当など非技術職が直接扱うことは難しく、ソフトウェアエンジニアやデータエンジニアといった職能の開発者が主に担当している。しかし近年では生成AIとの連携も進んでおり、定型的なコード生成などはAIに任せる動きも始まっている。

結果として、Terraformは単なる構成管理ツールにとどまらず、CARTA ZEROのデータプラットフォーム構築・運用において不可欠な基盤技術となった。再現性と可搬性に優れた構成管理が、組織の技術的俊敏性とスケールを可能にしている。

CARTA ZERO データエンジニア竹内晴貴氏

データ処理を担う「データオーナー」制度でスケーラビリティを実現

初期フェーズにおいては、プラットフォームチームがSnowflake上でデータ処理の全体を担っていた。しかし、プロダクトチームからの要望が増加するにつれ、プラットフォームチームのリソースが逼迫し、業務の遅延が問題となった。これにより、データ基盤の維持・進化が停滞し、活用フェーズへ十分にリソースを割けなくなるという本末転倒な状況が発生した。

この状況を打開するため、データ処理の実装責任をプロダクトチーム自身に移譲するという構造改革が行われた。具体的には、Terraformを用いたデータロード・変換モジュールを配布し、各プロダクトチームが自律的に構築・運用できる体制を整えた。これにより、プラットフォームチームはコア基盤の改善・最適化に集中できるようになった。

初期は、プロダクトチームが作成した構成に対してプラットフォームチームがレビューを行っていたが、レビュー工数が肥大化し、逆にボトルネックとなっていた。さらに、レビュー者が対象データの意味や文脈を十分に理解していないことから、レビューの質が担保されず問題が発生するという逆効果が生じた。このため、レビュー工程もプロダクトチーム内に内包し、エンドツーエンドでの責任と権限を持たせる方針へと転換された。

その上で導入されたのが「データオーナー」という役割だ。データを生産・変換・活用する一連の責任を同一チームに持たせることで、データ品質の向上と問題発見の迅速化を実現した。特に、障害時の対応スピードは大幅に向上し、原因究明もスムーズになった。プラットフォームチームがデータ内容に精通していないことによる非効率は、構造的に排除された。

この分担により、データエンジニアの人数を抑えつつ、全体のスケーラビリティと柔軟性が確保された。Terraformによって提供される統一されたモジュール群が、ガバナンスと自由度のバランスを担保する鍵となった。ベストプラクティスを埋め込んだ再利用可能なモジュールは、品質と効率を両立させる構造的仕組みとして機能している。

このような構造改革は、単なる技術選定ではなく、組織設計と運用体制の見直しという経営判断に直結するものだ。データ活用が確実に成果を生む保証がない以上、試行回数を増やすことが成功の鍵であり、それを支える体制としてのTerraformの役割は大きい。CARTA ZEROではこの仕組みにより、属人化を避けつつ、継続的な改善と実験を同時多発的に推進できる環境を構築している。