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

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

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

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

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

会社＆サービス紹介  

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

会社情報商号　　　株式会社アイスタイル（英文表記： 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

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

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

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

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

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

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

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

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

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

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

新基盤構築＆移行スケジュール   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での対応範囲決め実装/ 構築 ※簡略化したもの 

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

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

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

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

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

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

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

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

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

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

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

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

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

今後の展望  

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

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

まとめ/感想  

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

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

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

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

tsudash0

Other Decks in Technology

Featured

Transcript