この記事は、アイスタイルアドベントカレンダー2025 10日目の記事です。

はじめに

こんにちは、データ分析システム部の河野(@matako1124)です。

実はアイスタイルに入社させてもらったのは2025年4月で、まだまだ学びの連続ですが、そんな私の最初のミッションは『社内のデータ分析基盤を、活用できる状態にまでしっかり立て直すこと』でした。

本記事では、私が入社した当時のデータ分析基盤の状態と、現在どう改善が進んでいるのか、そして今後どう進化させていこうと考えているのかをざっくりと紹介します。

注意

執筆に当たり細心の注意を払っておりますが、不十分な説明や誤りがある可能性もございます
記事内の内容は一部こちらの登壇内容と重複する部分がございます

目次

はじめに
2025年4月時点でのデータ分析基盤のご紹介
現状の課題
データ分析基盤Replace PJ
- 今やっていること(2025年12月まで)
- これからやっていくこと
まとめ
終わりに

2025年4月時点でのデータ分析基盤のご紹介

私が入社した時点(2025年4月)でのデータ分析基盤は、ざっくり以下のような構成でした。

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

データ取り込みはオンプレのEmbulkを使い、BigQueryに取り込み(raw)
社内DB以外はTrocco経由があったり、Embulkで取っていたりとバラつきがある
BigQuery上では加工を行っておらず、rawデータを各利用者が個別に加工して利用している

つまり、とりあえずrawデータがBigQueryにある最低限の仕組みが整っているだけの状態でした。
データエンジニアの方ならお察しかと思いますが、この状態だとデータ活用において多くの問題が生じます。

現状の課題

大きな課題は上記3つですが、これ以外にも既存のデータ取り込み部分でも多くの課題が残っています。

Embulkはオンプレで動いており、不安定な状態になっている
dailyバッチで全件更新をしており、DB負荷が高い
- データ量の多いものではアプリ側への影響が出るケースも…

この状態ではデータ活用の促進どころの話ではないため、ほぼ全面的な改修が必要という判断をしました。

データ分析基盤Replace PJ

社内のデータ活用を促進するため、まずは今年いっぱい(2025年12月)までにデータ活用を促進していくためのスタートラインに立てる基盤にすることを目標とし、以下のように改善しようと考えました。

それぞれ説明していきます。

今やっていること(2025年12月まで)

①データ取り込みの改善

結論から言うと、以下のような課題が残っており、Embulkのままだと解消できないものが多く、ツールごと切り替える判断をしました。

メイン課題

バッチでの全件ロードだとDBに負荷がかかり、データ取り込みによるインシデントリスクが発生する可能性がある状態のため、更新されたタイミングでデータが入ってくるような形(CDC)にして、DB負荷を軽減したい
全件置き換えなので、履歴情報が欠損してしまっている。現状でもdailyでsnapshotをとって実装はできます(それぞれ活用側で実装しているところもある)が工数、コストともになるべくかけないような状態を担保したい

サブ課題

Embulkを動かしている環境もオンプレ環境で不安定な状態、メンテもされていない
Embulkの開発工数も高い
ツール自体が古い(直近で言うとサポート終了も明示された)

代替ツールは以下の条件で検討した結果、GCPのDatastreamとOSSのAirbyteを採用することにしました。

コンソールから設定できること
管理や運営の手間が少ないこと
コストが掛かりすぎないこと
CDC連携に対応したツールであること

Datastream一本でいかない理由としては、以下です。

単一障害点防止
何か障害が発生した時の代替策としてもう一本用意しておきたい(ツールの冗長性確保)
DBの仕様的にDatastreamで取り込みできないものもある

12月時点でほとんどのDBの新規取り込みが完了し、DB負荷が大幅に改善されることが判明しています。

②データ加工(モデリング)の実施

データ分析基盤の最も重要な部分であり、開発工数も多く投下している領域です。

オーケストレーションツール: Composer(airflow) x dbt Core
モデル構成: raw ⇨ cleansing ⇨ dwh ⇨ mart の一般的な3層構造
モデリング手法: ディメンショナルモデリング

細かいアーキテクチャの話をすると、ここだけで数万文字いってしまいそうなので、それはまた別の記事で紹介させてもらおうと思います。

一部の部署から徐々に展開していっており、rawデータを使って分析していた頃よりも圧倒的に活用しやすくなった、活用スピードが上がってきたというお声をいただいています。データの質向上についても少しずつ改善してきています。

③インフラ周りをTerraformで統一管理

今までGCPのリソース管理をきちんとできていなかったため、セキュリティ的にも問題がありました。

まずは以下を管理対象として、Terraformで整備しています。

IAM管理の集約
BigQuery リソース管理のコード化
活用ユーザーはrawデータの参照を不可とし、モデリング以降のレイヤのみ閲覧可能に変更

これにより最低限データを活用していくためのセキュリティを担保できる状態になりました。

④モデリング対象のデータカタログとしてdbt docsを採用し、全社展開(予定)

今までどこにデータがあるかわからない、誰に聞けばいいかわからないという状態が続いていました。

アイスタイルは事業が多い影響で、データの種類やステークホルダーが多く、存在しているデータをすべて追うというのは、正直非常に困難な状態となっています。

したがって、まずはデータ分析基盤側でモデリングしたデータからカタログ化していくことで、信頼性の担保されたデータを誰でも素早く見つけられる状態を目指しています。
そのためのツールとしてはdbt docsがお手軽なので、これをhostして全社展開をする予定で進めています。

これからやっていくこと

上記記載した内容が今年中に最低限やり切ると決めていることになります。
とはいえ、これができてもまだスタートラインに立てた程度だと思っています。

データ分析基盤としても、チームとしても、まずは『信頼を獲得する』ことを目標とし、今後は以下のようなことをやっていく必要があると考えています。

dwh, martの継続的整備と拡張
Embulkの完全廃止(コスト&パフォーマンス最適化、二重取り込み解消)
SA経由のrawデータ参照ブロック(RedashやTrocco等)(セキュリティ強化)
他全てのGCPPJの精査、棚卸し(セキュリティ強化&権限管理体制の強化)
権限管理体制の強化(セキュリティ強化)
自社DB以外のデータ(Thirdparty系等)の取り込み改善(データ取り込み管理の統一化)
dbt cloudの導入(データ活用促進、スピード向上)
dbt semantic layerの導入(データ活用促進、データ信頼性向上)
データテスト、監視の仕組み化(データ信頼性向上)
データコントラクトの仕組み化(データ信頼性向上&不具合防止&開発チーム連携強化)
BIツールのReplace(データ活用促進)
データ周りの技術水準の策定と浸透(データ分析基盤の信頼性向上&開発工数の削減)

etc..

やるべきことはたくさんあります。

まとめ

私はよく "守り" と "攻め" という言葉を使うのですが、データ分析基盤はまさにこの "守り" を固めないと話にならないと思っていて、現状のアイスタイルはこのフェーズかなと思っています。

データエンジニアリングは地道なことが多いですが、一歩ずつ前に進んでいくことで大きな成果を生むことができる領域だと思っています。
引き続き、チーム一丸となってデータ分析基盤を進化させ、活用促進に向けて日々精進し続けていこうと思います。
それぞれの領域の深いお話は、また別途紹介させていただきます。

終わりに

データエンジニア絶賛募集中です。人手が足りず、困っています。
インフラ領域に強い方、モデリング領域に強い方、マネジメント領域に強い方、データ領域でいろんなチャレンジをしていきたい方など。0⇨1開発も、1⇨100開発も経験できる環境をご用意できるかと思います。
少しでもご興味持っていただけた方、ぜひ情報交換という形でもお話しできたら嬉しいです。