Tweet
Tweet

Slide 1

Slide 1 text

データ基盤の成長を加速させる： 
 アイスタイルにおける挑戦と教訓 
 2025/02/04
 @tsudash0


Slide 2

Slide 2 text

はじめに
 アイスタイルでは現行のデータ基盤の課題を解決するための、新しいデータ基盤を構築して います！
 その構築中に起きた技術的課題の共有と、データ基盤構築のプロジェクトを進めるにあたっ て起きた課題や振り返りを共有しようと思います。
 環境ごとに適切なデータ活用のあり方があると思いますので、皆様の環境ではどのように データ基盤構築を進めているか、ぜひご意見いただけたら嬉しいです。
 
 キーワード：
 Google Cloud, GKE, Prefect, dbt, GreatExpectations, Airbyte
 アジャイル, ウォーターフォール, プロダクトオーナー


Slide 3

Slide 3 text

プロフィール 
 X: @tsudash0
 職歴(2012-)： 
 ブレインパッド ：JavaやPythonでのアプリケーション開発や管理画面開発 
 →サイバーエージェント ：Hadoopクラスタ周辺の業務、データマネジメント業務（マネージャー） 
 →Slalom ：データエンジニアとしてのコンサルタント。ほぼSnowflake関連 
 →アイスタイル ：データ基盤の開発・運用（マネージャー）。GoogleCloudベース 
 
 タイトル： 
 データエンジニア/インフラエンジニア/SWE/マネージャー をうろうろ 
 一貫してデータ周辺で仕事しています 
 副業で Snowflake の導入支援もしています 
 
 宣伝：
 毎週月曜日の夜、Xでデータエンジニア向けのもくもく会を実施しています。 
 よければ気軽にご参加ください！ 
 職業柄 スキンケアも好きなので、お困りの方がいればお尋ねください。 


Slide 4

Slide 4 text

もくじ
 1. 会社＆サービス紹介
 2. 現行データ基盤の課題と新しいデータ基盤構築の構想
 3. 新データ基盤構築における技術的課題と解決
 4. 新データ基盤構築におけるプロジェクト進行方法に対する教訓
 5. 今後の展望


Slide 5

Slide 5 text

会社＆サービス紹介 


Slide 6

Slide 6 text

©istyle, Inc. 6 を運営している会社です。 国内最大のコスメ・美容の総合サイト

Slide 7

Slide 7 text

会社情報 商号　　　株式会社アイスタイル （英文表記： istyle Inc.） 設立　　　1999年7月27日 資本金　　57億1900万円（2024年6月末日現在） 売上高　　560億8500万円（2024年6月期実績） 役員 従業員　　　　　1,079名（連結） （2024年6月末日現在） 本社所在地　　　〒107-6034　東京都港区赤坂一丁目 12番 32号 アーク森ビル 34階 事業内容　　　　美容系総合ポータルサイト @cosme（アットコスメ） の企画・運営、関連広告サービスの提供 COMPANY COMPANY 01 ©istyle, Inc. 代表取締役会長 CEO 代表取締役社長 COO 取締役副会長 CFO 取締役（非常勤） 吉松 徹郎 遠藤 宗 菅原 敬 山田 メユミ 7

Slide 8

Slide 8 text

3つの主要事業 BUISINESS BUISINESS 02 ©istyle, Inc. 日本No.1の 化粧品専門店 正規品取扱数 日本No.1のECサイト 日本No.1の 美容情報メディア 01 02 03 8 ３大事業について

Slide 9

Slide 9 text

BUISINESS 02 生活者とブランドを繋げる。 複数のチャネルが生み出すシナジー。 私たちが実現すること 生活者 ブランド／クライアント メディア EC 店舗 広告ソリューション／販促（体験・イベント） コンサルティング 日本No.1 正規品取扱数 ECサイト 日本No.1 化粧品専門店 日本No.1 美容情報メディア ©istyle, Inc. 9 ３大事業について

Slide 10

Slide 10 text

10 Brand Official｜ブランド向けの月額制でデータ分析と情報発信 SaaS アイスタイルが保有する様々な生活者データを活用し、 ブランドのマーケティング戦略を支援する to B向けマーケティングダッシュボード BUISINESS 02 ブランドエンゲージメント ランクピラミッド出力 実施アクション 見える化 ユーザーアクション 傾向把握 ユーザー グロースマップ出力 他ブランドへの ユーザーアクション把握 過去と比較した ランクの変化把握 ユーザーランクアップ 傾向把握 ユーザー興味関心把握 （競合分析） ランク別重要指標把握 ©istyle, Inc. 強み４　ブランド向け SaaSについて

Slide 11

Slide 11 text

アイスタイルではエンジニアを積極採用中です！ 
 データエンジニアはもちろんの事、アイスタイルではエンジニアを積極採用中です！ 
 少しでもご興味あれば、ぜひお声がけください。 
 https://open.talentio.com/r/1/c/isytyle_career/homes/4344 
 
 ● Web(口コミ), EC, 実店舗を横断したデータ領域の仕事に興味がある 
 ● モダンテックを利用したデータ基盤を開発したい 
 ● 美容業界に興味がある（←弊社でも、エンジニアだと興味がある方の方が少ないです） 
 アイスタイル採用サイト https://www.istyle.co.jp/recruit/

Slide 12

Slide 12 text

現行データ基盤の課題と 
 新しいデータ基盤構築の構想 


Slide 13

Slide 13 text

アイスタイル データ基盤の変遷 
 データの観点から見る@cosmeの歴史
 https://qiita.com/anntoque/items/407db584ad097e8638b0 
 新 基 盤 の 構 築 プ ロ ジ ェクト開 始
 新 基 盤 構 築 完 了 
 2023年
 2024年
 2025年
 全 社 的 に デ ー タ活 用 の レベ ル を 向 上 させ る 
 組 織 横 断 プ ロ ジ ェクトの 発 足 
 2024年6月
 アイスタイルにジョイン(津田) 
 要件定義・設計・実装を
 半年程度のフェーズに分けて実装
 (ミニウォーターフォール)
 2023.07
 2024.07
 技 術 的 課 題 の 解 決 
 （後 述 ）


Slide 14

Slide 14 text

● 共通的なDWHが整備されておら ず、案件ごとにソースデータから 集計することが多く 、時間がかか る
 ● 本番環境と開発環境や、開発者 ごとの開発環境に差異があり、不 具合の原因究明に時間がかかっ ている
 
 ● 標準化された開発プロセスがなく 属人化した開発が行われている
 データモデルの柔軟性・再利用性の 欠如
 依頼を受けてからデータを提供 するまで時間がかかる
 整備されていないプロセス 
 運用や障害対応に時間が取ら れ、開発や改善の時間が取れな い
 ● 必要とするデータがどこにあるの か分からない
 
 ● 仮に見つかったとしても、中身の データ定義が分からず、元データ のデータ定義から調べる必要が ある
 データに関する情報の不足 
 どこにデータがあるのか、どのよ うなデータなのかがわかりにくい 
 現行データ基盤の課題 (1/2) 
 現行データ基盤は Embulk, Digdag, Trocco を組み合わせた構成のシステムですが、
 アイスタイルでは以下のような課題がありました：
 (

Slide 15

Slide 15 text

● データを基本全洗い替えで取り 込んでいるため時間がかかる
 
 ● オンプレの限られたリソース （サーバー・ネットワーク帯域）で 実行しているため、多くのジョブを 並行実行できず、スケジューリン グが難しい
 
 ● 実行中にデプロイができない（デ プロイすると実行中ジョブに影響 が出る）
 不適切なインフラ 
 データ収集に時間がかかる・メ ンテナンス性が悪い
 ● 同期されたデータに問題があっ ても検知できずにデータを提供し てしまうことがある 
 
 ● サービス側でのデータ定義の変更 を検知する仕組みがない（定義の 変更を連絡する仕組みも明文化・ 共有されていない）
 
 ● 依存関係のあるジョブの実行結果 を確認せずにジョブを実行し、誤っ たデータでジョブが実行されている
 テスト不足 
 データが正しくなくても検知でき ずに提供し続けるケースがある 
 現行データ基盤の課題 (1/2) 
 コスト意識の不足・優先度低下 
 運用費の管理が不十分
 運用ルールの欠如 
 セキュリティレベル
 不適切なツール 
 権限管理コストが高い


Slide 16

Slide 16 text

データの扱いやすさの改善 
 データ提供速度の改善
 データの検索性の改善
 データ品質の改善
 ● レイヤ構造を導入し再利用性を向上 
 ● dbt導入によるクエリの自動生成 
 ● データレイク〜DWHを変更に強いレイ ヤ構造とする
 ● データ検証の導入 
 ● リリース前テストの整備 
 ● SLAの整備と監視の強化 
 ● データ変化を監視し異常検知を行う 
 ● DWH層にスタースキーマを導入する 
 ● データ標準化を推進し、モデリングに反 映する
 ● データカタログの導入 
 ● ビジネスメタデータの整備 
 以下の4つを重点課題とし、新基盤の構築プロジェクトがスタート：
 重点課題の選定 
 現行データ基盤の置き換え 


Slide 17

Slide 17 text

新データ基盤のアーキテクチャ(当初設計) 
 データ
 ソース
 蓄積エリア
 加工エリア
 データ
 収集基盤
 ELT（データ加工基盤）
 Data Validation Tool
 データカタログ
 ジョブ基盤
 Push連携
 reverseETL
 提供準備
 エリア
 データ蓄積基盤
 Information
 Mart
 受入エリア
 Pull連携
 DB同期、
 エクスポート
 Data Observability Tool
 データ品質
 管理
 BI
 各種データ利用先
 無加工エリア


Slide 18

Slide 18 text

新基盤構築＆移行スケジュール 
 2023年 2024年 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 工程 統合分析 基盤 モデリング 標準 移 行 プロジェクト 1 プロジェクト 2 要件定義 デプロイ テスト 内部 結合 サンプル 実装 設計 インターフェース開発 内部結合 テスト 実装/構築 実装 内部 結合 Phase1 Step1 開発プロセス整備 パイロット プロジェクト計画 パイロット プロジェクト① 計画書 作成 Phase1 Step2 要件 定義 システム テスト 設計 内部 結合 設計 実装 Phase2 Step1 要件 定義 設計 実装/ 構築 システムテスト 計画 モデリング標準 改訂プロセス運用 プロセス改善検討 改訂プロセス運用 Phase2 Step2 要件 定義 設計 実装/ 構築 Phase2の計画はPhase1の 終了の際に検討 システムテスト / パイロット PJ 内部 結合 セキュリティ /可観測性に関する 要件整理 現行課題 整理 プロジェクト計画 テスト環 境 構築 パイプライン 実装 パイプラインテスト パイプライン 実装 パイプライン テスト 結合テスト サービステ スト 参照側開発＋外部結合 テスト DM 設計 プロジェクト 計画 移行設計 ・DWH設計 要件定義 設計 要件 定義 設計 サンプル実装② 要件定義 非機能要件の調査・ 整理・Step1での対応範囲決 め 実装/ 構築 ※簡略化したもの


Slide 19

Slide 19 text

新データ基盤構築における 
 技術的課題と解決 


Slide 20

Slide 20 text

当初の構築スケジュールが完了したときの技術的課題 
 私が入社したのは2024年6月で、当初の基盤構築計画が完了する直前でした。
 一部パイプラインの運用が始まった際、以下のような技術的課題が発生していました：
 
 1. 過剰な環境設計に加え、リリースサイクルが整えられていなかった
 ○ 一部パイプラインの本番運用に間に合わせるための急ピッチの開発
 ○ リリースサイクルが整えられていないために発生する手動ビルド＆デプロイ
 ○ マージされていないPRが大量発生中
 ○ 単体テストがなく、マージしてもデグレードが発生してしまう
 
 2. 安定しないツール群
 ○ すべてGKEの上で、かつOSS版を利用しているため、構築・運用負荷が高い 
 ○ Prefectが冗長化されておらず、GKEのメンテナンスにより頻繁にクラッシュ(後述)
 ○ Airbyteのバージョンアップをした際に致命的なバグが発生
 
 3. 当面の目的に対しての過剰な機能
 ○ 当面の目的は、現行データ基盤の廃止をすること 
 ■ 400以上あるテーブルを新基盤に引き込み、データ抽出業務やレポートの向き先をすべ て切り替える必要があるが、追加した機能が逆に開発工数の足枷になる


Slide 21

Slide 21 text

1. 環境設計＆リリースサイクルの整備 
 2024年7月から、現行基盤のデータとパイプライン処理を新基盤へ移すプロジェクトが進行。 
 約400テーブルを1年で移行する大プロジェクトなため、この作業の効率化を最優先し、環境設計の簡略化＆リリースサイク ルの全自動化を実施。
 環境設計＆リリースサイクルの見直し 
 
 DEV
 E2E
 UAT1,2,3,4 
 STG
 PRD
 環境の目的 
 個人開発環境
 統合テスト
 ユーザ受け入れテスト環境
 本番環境のデータでパイ プラインの動作確認を行 う環境
 本番環境
 見直し前
 (Git Flow) 
 
 develop
 
 main
 
 見直し後
 (Github Flow )
 -
 パイプライン開発者 の利用撤廃
 
 UAT1: main
 UAT2,3,4はfeatureブランチを個別 に適用できるように
 当面利用しない
 
 一度 develop に合流した後 release に分岐 するための cherry-picking が発生しており、 運用負荷が高いため Github Flow へ変更
 下記変更をリポジトリ数分実施(dbt, GreatExpectations, Prefect, Airbyte) 
 負荷試験、個人情報のマスキングテスト などを想定した環境だが開発不十分な領 域が多く、当面は現行基盤の再現が目的 なので不要と判断


Slide 22

Slide 22 text

2. ツールの安定化: Prefect / 概要 
 (ChatGPTより)
 
 Prefectは、データパイプラインのオーケストレーションを管理するPythonベースのツールです。タスクの実行、依存関係の管理、リトライ、スケ ジューリング、監視などを行い、クラウド環境やオンプレミスで動作します。特に、Airflowの課題を解決することを目的として設計されました。 
 Prefectの特徴 
 ● コードベースのワークフロー定義 : 直感的なPythonコードでワークフローを記述可能。 
 ● 動的なパイプライン構築 : 実行時にワークフローを変更可能で柔軟性が高い。 
 ● ローカル＆クラウド対応 : Prefect Cloudと連携するとGUIで監視・制御可能。 
 ● 軽量で導入が簡単 : 設定不要でシンプルに使い始められる。 
 結論
 Prefectは、開発のしやすさと柔軟性を重視したデータオーケストレーションツールです。他のツールと比較すると、AirbyteのようにETL特化で はなく、Dagsterほど型やデータ管理に強みがあるわけではありませんが、柔軟性とシンプルさを求める開発者には適した選択肢です。 


Slide 23

Slide 23 text

2. ツールの安定化: Prefect / サンプルコード 
 Flowの実行
 Taskの並列実 行
 Taskの並列実 行
 https://docs.prefect.io/v3/tutorials/pipelines 


Slide 24

Slide 24 text

2. ツールの安定化: Prefect 
 2024年6月時点では、1つのドメインに対して 1つのPodを割り当てており、Podごとに Prefect サーバやバックエンドの PostgreSQL を割り当てていた 
 ● セットアップが簡単
 ● ドメイン間で共有するものがなく、障害範囲が広範囲に 及ばない
 ● 管理画面がドメインごとに変わるため運用しづらい
 ● GKE Autopilot に適した構成ではなく、preemption や rebalancing などで Pod が kill された場合に障害が多発
 ● デプロイのたびに Pod 入れ替えが必要でリリースタイミ ングの調整が難しかった
 Pros 
 Cons 


Slide 25

Slide 25 text

2. ツールの安定化: Prefect 
 Server / Worker を分離し、どちらも Helm 経由で デプロイするよう変更して、それぞれ冗長化を設 定
 Server / Worker 間は WorkPool を経由し、ドメイ ンごとにキューを分離
 ジョブ設定がいつでもリリース可能に（ジョブ設定 の反映がクラスタに影響を及ぼさないように） 
 管理画面や PostgreSQL が共通となり、ジョブの 管理がしやすくなった
 新構成リリース後、エラーが激減し て安定稼働を実現できた 


Slide 26

Slide 26 text

3. 当面の目的に対しての過剰な機能 
 当面（向こう一年程度）の目的は、現行データ基盤とのリプレイスをすること
 400以上あるテーブルを新基盤に引き込み、データ抽出業務やレポートの向き先をすべて切り替える必要があるが、
 追加した機能が逆に開発工数の足枷になっていた
 （当初の基盤要件としては必要なものでしたが、実装が時期尚早だった可能性）
 データ基盤上における 
 個人データの暗号化 
 データ品質への取り組み 
 データ提供を 
 インフォメーション 
 マート経由で行う 
 現行データ基盤では個人データは取 り込まない方針だったが、新基盤では 暗号化等を行って安全に取り扱える 要件があった。
 ただし現行データ基盤の刷新を目的と した場合、個人データは含まれないた め、実装の緊急性は低いと判断。 
 データ品質向上の取り組みが重点課 題に含まれていたが、どのような観点 からデータ品質へ取り組むかが検討 できておらず、型チェックなど限定的な 利用に留まっていた。 
 現時点では GreatExpectations を利 用するまでの高度なデータ品質チェッ クを必要としないため、 dbt-expectations など類似ライブラリ での対応を検討中。 
 データをユーザへ提供するため、当初 は ReverseETL でインフォメーション マートへ書き込む予定だった(Tableau のライブ抽出に対するコストの削減な ども目的)。
 ただしこれも現行データ基盤の刷新を 目的とした場合、優先順位が下がり、 後述する新規プロジェクトの要件とも 合わないため実装見送り。 
 いずれも当面の目的や要件の再整理において
 実装優先度を下げたり、当面利用しないなどの判断


Slide 27

Slide 27 text

新データ基盤構築における 
 プロジェクト進行方法に対する教訓 


Slide 28

Slide 28 text

プロジェクト進行に関する課題 
 What are the challenges of building a data platform? 
 技術中心になりすぎる
 部門ごとの 
 データサイロ 
 低品質なデータ 
 データガバナンス の欠如 
 既存システムの複雑性とコストを過小評価する 
 “多くのデータプラットフォームプロジェクトは技術に偏りすぎて、ビジネス戦略との整合性を欠いてしま う。特に、技術チームが技術的な問題解決を優先し、ビジネスニーズやユーザー体験を考慮しない場 合、プラットフォームの導入が進まず、期待された成果を生まない。”
 “既存のシステムとの統合を軽視すると、導入後の運用が困難になり、コストが予想以上にかかる可能 性がある。特に、「簡単に導入できる」とうたわれているソリューションでも、実際には高度なカスタマイ ズが必要となることが多い。”
 UKのデータ系コンサルファーム The Oakland Group によって、データ基盤構築の課題が5つまとめられていました。 
 今進行している新基盤構築のプロジェクトでは、以下の2点が当てはまっています： 


Slide 29

Slide 29 text

プロジェクト進行に関する課題 
 What are the challenges of building a data platform? 
 技術中心になりすぎる 
 アジャイル開発を目指していたが、プロダクトオーナー が定まっていなかったため、フェーズ間の要件調整が されず、ミニウォーターフォールになってしまい、機能肥 大してしまった
 ● 元々はユーザ部門の責任者と合同で開発を進 めていたが、体制が変わった影響で開発部門だ けでプロジェクトを進行する形となった 
 ● 構築中に退職者が発生し、実際にユースケース が見えたタイミングで、新基盤の機能に対して ユーザとの認識齟齬が発生 


Slide 30

Slide 30 text

プロジェクト進行に関する課題 
 What are the challenges of building a data platform? 
 既存システムの複雑性とコストを過小評価する 
 ● データソース、利用者の切り替えを同時進行しようとしていた
 ○ データ利用者へは当然ながら、新基盤の利用案内をする必要があるが、Tableauレポートの抽出元切り替えなど時 間がかかる作業も含まれる
 ○ 一方で 全社の基幹システムをAWSへ移行するプロジェクトが同時に進行
 ○ データ連携元がオンプレからAWSへ切り替わるため、新基盤構築のスケジュールが上記プロジェクトに大きく影響を 受けてしまった
 ● 現行基盤から新基盤へ、データやパイプラインを全て移行する必要があったが、その計画がユーザと全く調整されていなかっ た
 いくつかのプロジェクトは、プロ ジェクト発足当初から新基盤で 利用予定だったが、その他は データ利用部門と調整できてい なかった


Slide 31

Slide 31 text

プロジェクト進行に関する課題 
 The Oakland Group のまとめには記載されていませんでしたが、個人的に振り返ると以下の課題もありました： 
 新基盤の構築期間が長く、 
 ユーザからの不満が蓄積してしまった 
 スキル蓄積ができなかった 
 SaaS版ではなく全てOSS版のコンポーネ ントをGKE上で動かす決定をしたが、 フェーズごとに人員調整していたため、技 術継承が上手くされなかった 
 プロジェクト進行中の2年間に、データ ニーズが高まった影響でレポート作成や データ抽出の支援の業務負荷が拡大。 
 新基盤構築中で現行基盤には改修を加 えない方針だったため、この業務負荷に システム面から支援することができなかっ た


Slide 32

Slide 32 text

今後の展望 


Slide 33

Slide 33 text

ユーザの方向を向いた基盤の開発 
 2025年1月から新しい組織横断プロジェクトが始動し、 
 ユーザが主体となってデータ活用を進められる状態を目指す 
 私も技術側の責任者としてプロジェクト参画中。 
 AS-IS
 
 中央集権型のリード・
 サポート体制
 TO-BE
 
 分散型の事業部との
 協同体制
 技術中心になりすぎる
 既存システムの複雑性とコストを過小評価す る
 新基盤の構築期間が長く、ユーザからの不 満が蓄積してしまった
 スキル蓄積ができなかった 
 プロジェクトを活用側組織と一緒に推進できることとなり、 
 振り返りで見てきた課題のうち3つは解消できる体制に 


Slide 34

Slide 34 text

ユーザの方向を向いた基盤の開発 
 新体制によるプロジェクトによって逆に生まれる懸念や、解決できていない課題についての考察:
 技術中心になりすぎる
 スキル蓄積ができなかった 
 活用側に寄りすぎてデータ基盤がサイロ化したり、管理しきれないデータが大量に発生するなどの懸念もありますが、データモデ リングを中心とした活用効率化を目的としたPoCや、法務部の方を招いた個人データの扱いについての検討などもプロジェクトに 含まれています
 またアセスメントをベースにした活用推進を行うため、全社的な視線でもプロジェクトを進行します
 人材不足はアイスタイルでも起きているため、完全にこの課題を解決するのは難しいですが、以下の意識を引き続き持ちながら 開発を続けて行こうと思います：
 ● 自動化できるところは自動化し、秘伝のタレを作らない
 ● 単体テスト・結合テストなどでデグレを防ぎ、コードの理解を支える
 ● 体制や人員、スキルに見合った技術選定を行う


Slide 35

Slide 35 text

まとめ/感想 


Slide 36

Slide 36 text

まとめ / 感想 
 約2年前に始まった新基盤構築プロジェクトの経緯、途中参画した私が出くわした技術的課題、そして振り 返った時にプロジェクト進行に問題はなかったかを振り返り、共有しました。
 
 入社してからはシステム改修に必死でプロジェクト全体を振り返る余裕がなかったのですが、チームビル ディングも上手くいき、システムも安定稼働し始めたので努力の甲斐がありました。（実際の開発はチーム メンバーの協力がほとんどです、本当にいつもありがとうございます）
 状況が落ち着いた今、プロジェクト進行を振り返ると、ユーザ部門との対話が足りていなかったり、目的に 対して機能が肥大化していたりと改善点が多く見つかりました。
 新しいプロジェクト体制でだいぶ改善すると思いますが、構築しているデータ基盤がユーザの課題を解決 するものかどうかは意識して開発を続けていこうと思いました。
 
 散漫な内容だったかもしれませんが、何か少しでも得るものがあれば幸いです。
 ご清聴ありがとうございました。


Slide 37

Slide 37 text

参考：dbt のリリースフロー 
 Github Flow を採択。これに応じて Github Actions を足りていない部分も合わせて実装 
 ● main から feature を切ってローカルで開発 
 ● main へマージして UAT1 環境へリリース 
 ● タグ発行したタイミングで PRD 環境へリリース 
 UAT2,3,4 は自由に feature ブランチをリリースできるよう、workflow dispatch を整備