🧸

「幸運」と「Databricks」で運用負荷を軽減しつつ開発生産性を手に入れたデータ基盤

reonah

2023/12/12に公開

Azure Synapse Analytics

tech

この記事は AEON Advent Calendar 2023 の 12 日目の記事です🎄

自己紹介

イオン株式会社の AI・Data 系部署でデータエンジニアをしている @reonah です。

位置情報ビッグデータ系企業にて5.5年バックエンドエンジニアとして勤務後、2022 年 10 月にデータエンジニアとして本組織にジョインしました。

AEON Advent Calendar 2023 の他の投稿者とは所属組織が全く異なるので、組織文化の違いを味わいながらアドベントカレンダーを楽しんでいます。企画者の方ありがとうございます。

本稿について

15 名程度が内部利用する比較的小規模なデータ基盤を Azure Virtual Machines （以降、 Azure VM ）＋ Azure Synapse Analytics の構成から Azure Databricks （以降、Databricks）へ移行したことをテーマにしています。

タイトルに Databricks とありますが、データ基盤的な内容というよりは課題とその解決プロセスの部分に言及した記事です。

そのため、技術については最小限に留めており、登場する各サービスの特性・技術選定・パフォーマンス比較などについては、深く言及しておりませんのでご注意ください。（別の機会で公開できればと。）

技術的負債の返却 や 開発と運用の分離 などソフトウェア開発における「あるある」に直面しながらも、少しは解決・改善できたと感じているので、似たような問題で困っている方の心の支えになれば幸いです。

分かり辛い点や知識不足による間違いはご容赦ください🙇
（コメントいただけると大変助かります！）

所属部署について

理解の円滑化のため、簡易に所属部署の紹介をさせてください。

所属部署は、「グループのさまざまなデータを横断的に活用し新たな価値創出を行うこと、グループ各社でのデータの活用を促進すること」を目的とし、2021 年 3 月に発足された部署です。

データドリブン経営に貢献するため「グループに存在するデータ」と「データサイエンス」を組み合わせて様々なことに取り組む R＆D 的な機能を担っています。

具体的には、グループ会社より取得した商品データ・POS データ・ポイントカードデータ等から需要予測や顧客属性分析を行っているほか、生成 AI を活用した商品説明生成などにも取り組んでいます。

約 20 名が所属しており、開発系のロールはデータサイエンティストとデータエンジニアの大きく 2 種に分かれています。各々の構成とデータ基盤への関わり方は以下の通りです。

データサイエンティスト（約 10 名）：データ基盤の上でデータサイエンスを実施
データエンジニア（約 3 ＋ α 名）：データ基盤の構築、拡張、改善を実施
- ※αは運用専任（手順書に従い作業をする）メンバー

また、他の組織と比べ特徴的な点が以下です。

ほぼ全名が中途採用
コンサルを中心に多様な業界出身のメンバーで構成
（ソフトウェア開発をやってきたメンバーは比較的少ない）

データ基盤

本題のデータ基盤に話を進めます。

概要

本稿のデータ基盤は、イオングループの保有する全データを扱うデータ基盤を指すのではなく、「部署内の 15 名程度のメンバーがイオングループのデータの一部（商品データ/POS データ）を触ること」を目的とした、比較的小さな基盤を指しています。

概略図は以下の通りです。
（簡単化のため NW 等の情報は割愛します。以降も同様です。）

文章で補足します。

ステークホルダ
- データ提供者(Data Provider)：グループ内外の複数社
- データ利用者(Data User)：部署内 15 名程度のメンバーのみ
ワークロードとその規模感
- ETL
  - ほぼ全てが日次、一部月次やアドホックなものが存在
    - パイプライン数：約 20 本/day
    - 処理サイズ：数百 GB/day
- ML/Analytics
  - アドホック利用が主で、定常なワークロードは 1 割未満

ざっくり、以下のように捉えてください。

ステークホルダは社内メンバーのみで少数
定常ワークロードも小規模
アドホック利用がメイン（≒ サービスレベルは存在しない）

旧アーキテクチャ

構成図

ジョイン時点でのアーキテクチャを示します。（以降これを旧アーキテクチャと呼称します。）

※図示以外に、ハイスペックなラップトップが貸与されています。

大まかな流れは Fig.1 概念図と変わらないものの、複雑化していることがわかります。
ポイントを言葉で補足します。

Raw Data Store
- Azure Datalake Storage Gen2 (オブジェクトストレージ）
ETL Pipeline
- Azure Synapse Analytics のサービス群で開発/オーケストレーション
ETLed Data Store
- ETL 結果を以下の 3 つのデータストアに格納
- ※ストア特性に応じデータを分けているのではなく全てに同じデータを格納
  - Data Warehouse：Azure Synapse Analytics Dedicated SQL Pool
    - BI ツールのバックエンドの利用が主
    - BI 以外にアドホックなクエリが散発
  - Delta Lake：Azure Data Lake Storage Gen2
    - 主なデータストア
      - 基本はこれを利用するルール
  - Data Lake(parquet)：Azure Data Lake Storage Gen2
    - 後段の VM へデータを（クエリエンジンを介さずに）ファイルとしてコピーするための用途
ML/Analytics Services
- BI:Power BI
  - PoC レベル（＝ビジネスクリティカルでない）ダッシュボードが数個存在
- MLs/Analytics on Spark:Azure Synapse Analytics Spark Pool
  - データ分析利用が主
- VM:Azure VM
  - 可視化/簡易レポート作成
  - GPU Heavy なワークロード（学習/推論）

運用

運用関連については以下の通りでした。

Azure VM
- データサイエンティストが 1 人 N 台（ 1 ~ 3 台）保有
- 追加/拡張は運用専任メンバーへ依頼
- パッチ等のメンテナンスは運用専任メンバーが実施
- 自動シャットダウン設定は任意
- 一部に SpotVM を利用
- Code Hosting Serviceに GitLab を利用
Azure Synapse Analytics Spark Pool
- データエンジニア・データサイエンティストが利用
- 数人で Spark クラスタを共有
- Code Hosting Service に Azure DevOps Repos を利用
  - ※ Azure Synapse Analytics が GitLab と統合されていないため
その他
- 金銭コストは運用専任メンバーが管理

課題

開発・運用双方の点で早期から辛かったです。
具体的なものは以下のとおりです。

開発観点の課題

Azure Synapse Analytics(Azure DevOps Repos) と Azure VM(GitLab) の相互利用
- 例：Azure Synapse Analytics でクレンジングして、Azure VM で学習/推論のケース
  - データのやりとりが面倒（都度 Azure VM へファイルをコピー）
  - コードベースが分離されているので、メモや記憶に頼るシーンが存在
Azure VM のサイズ選定
- 処理に応じて使い分けるのが金銭コスト観点で理想
  - 環境構築が面倒なのでとりあえず大きいものを使用
GPU クラスタどうする問題
- Azure Synapse Analytics ではパブリックプレビュー
- Azure VM で自前クラスタ組んだとして誰が面倒見る？
Airflow/MLflow オーケストレーションの導入難問題
- Container or 別 VM でやるとして誰が面倒見る？

旧アーキテクチャの運用観点の課題

Azure VM の運用
- VM 追加
  - 開発パートナーが残した PowerShell スクリプトを運用専任メンバーが実行
    - エラーが起きたら即 Azure サポートへ
- Disk 拡張
  - 数 TB 単位で拡張依頼
    - そのサイズ必要か？のヒアリング（＋VM へのデータ永続化はやめてという説明）
- メンテナンスタスク
  - 使用者と都度スケジュール調整
金銭コスト
- コンピュートコストを使用者自身が確認できない問題
  - コスト感が身につかない
    - Azure VM の停止忘れなどが頻発
- Azure Synapse Spark Pool は SpotVM が使えないので高くなりがち

課題サマリ

Well-Architected なクラウド利用に関する知識不足に起因する課題
- 組織の状態と使用サービスの不均衡
  - インフラ/SRE 系ロールが存在しない組織で、IaaS を利用するにはそれなりの覚悟がいる。。。
開発と運用の分断による課題
- 短期的にはアジリティの低下
  - 依頼 → ヒアリング → 実施というリードタイム
- 中長期的には負債が蓄積
  - 互いのことを知らない（疎なコミュニケーション）ので、Better な案になりづらい
    - 少しのズレが積み重なり、無視できない負債に
  - 責任の所在が曖昧になりがち、改善のモチベーションも湧きづらい
サービス特性による課題
- Azure VM と Azure Synapse Analytics の統合と隙間をどうするか問題

（備考）歴史

なぜ、このようなアーキテクチャ・運用方式だったのか？ですが、わかりませんでした。。。

ヒアリングベースで得られた情報は以下の通りです。

データ基盤を触る人が2,3名程度のときにとった構成
実際にこのアーキテクチャを構築したのはパートナー（以降、開発パートナーと呼称）
途中、開発パートナーから別のパートナー（以降、運用パートナーと呼称）へ委任
- 私自身は運用パートナーに委任された段階でにジョイン

ドキュメントの掘り起こしも行ったのですが、以下の通りでした。

パラメータシートのような現状の状態を示すものが保存
- Design Docにあたるものはなさそう
PowerPoint でドキュメントされていて掘り起こす心が折れた
- PowerPointだと検索が難しい
- 名前バージョニング（例：〇〇_v2.pptx, 〇〇_最新.pptx, 〇〇_202302.pptx）の壁

新アーキテクチャ

移行プロセスについて述べる前に結果、つまり新アーキテクチャを示します。

構成図

Fig.1 概念図に近くだいぶシンプルにできました。

課題の多くは Databricks へ移行するだけで解決し、残りも工夫することで解決させています

Databricks へ移行するだけで解決したもの
- Azure VM と Azure Synapse Analytics の相互利用問題
  - Single Node Compute, Cluster Compute 双方、Databricks Managedで作成可
  - GPU Node 対応
  - GitLab 対応
- Azure VM 拡張、メンテナンス問題
  - 同上
- オーケストレーションツール導入
  - Airflow 相当の Workflows あり
  - Managed MLflow あり
工夫して解決したもの
- VM の追加、使い分け、コスト問題
  - Compute Policy でガードレールを敷設した上で、申請不要で各自自由に作成可とした
    - 主なガードレール
      - 各自のコスト把握のためのカスタムタグポリシー
      - コスト高騰を防ぐためのノードタイプの限定、ワーカー数の限定、SpotVM の強制、自動停止の強制

また、移行によって整理できたものは以下です。

旧アーキテクチャにおける 3 つの ETLed Data Store
- Delta Lake 1 つに統合
運用パートナー
- 運用が発生しなくなったので契約終了

恩恵

いいことづくめでした。列挙します。

開発が圧倒的に楽に便利に
運用はゼロに
コストパフォーマンス良し
- Azure Synapse Analytics vs Azure Databricks で、いくつかのワークロードでベンチしたところ金銭コストは約 4 割減という結果
  - Azure Synapse Analytics Spark Pool　では SpotVM が使えないのでフェアな比較ではないことに注意
- 旧アーキテクチャ時代のデータ分析関連金銭コスト vs 新アーキテクチャのデータ分析関連金銭コストは、ほぼ同等
  - 新アーキテクチャでは開発が楽に早くできるようになったので、同一時間でより多くのことができるようになったという理解

移行

「よしやろう！」となってから、「新アーキテクチャ開始」（データサイエンティストが使い始められる状態 ≠ 旧アーキテクチャの完全廃止）まで、およそ 2 ヶ月で移行できました。

この早期移行は、幸運要素と下準備が見事に噛み合ったからでした。
幸運要素を[イベント]、下準備を[施策]として、以下に時系列でまとめます。

他の幸運要素

時系列以外に幸運だった点が以下です。

旧アーキテクチャの段階で Delta Lake を構成していたこと
- Delta Lake on Azure 構成だったので、技術選定段階で Databricks ほぼ一択
定常ワークロードが ETL 20 本程度だったこと
- 移行の検証題材として程よい本数
リアルタイム性の高いワークロードがなかったこと
- 最もリアルタイム性が高いものでも日次なので、気持ち的に余裕があった

上記のため、データエンジニアリング観点では、技術的な移行ハードルははぼゼロでした。

また、旧アーキテクチャの歴史が不明だったことは、幸運と捉えていました。
歴史が残されていない ≒ 旧アーキテクチャに拘る強い理由がないと考え、
ドラスティックな判断を下せたためです。

ネゴや予算取りは？

運要素は少なく、予算交渉、全体説明、オンボーディングを極めて一般的に行いました。
（予算交渉は、よりコスト効果うむ事前購入プランのために行っています。 2023/08 から適用済みです。）
8割のメンバーが 2023/08 中にオンボードしてくれました。

移行振り返り

「IaaS の利用によって拡張性/運用性に悩んでいた基盤をマネージドなサービスに置き換える。」という、
それほど珍しくないことを、説得材料を集め、仮説検証を短期で実施し、効果を確認後、全体展開の王道の流れをやっただけです。
ただ、幸運要素が 1 つでも欠けていれば王道はできない、もしくは中途半端な形になっていたと想像できます。

特に、人の入れ替わりは素晴らしいタイミングでした。
これがなければ、いまでも旧アーキテクチャを使用していた可能性が高いです。
しかし、この記事の言いたいことが「人の入れ替わりを待て。」だとあまりにもなので再現性のある言い方をすると、
「何かを変えたいときは、まず味方をつくれ。味方を作るための準備/努力はしておけ。」です。
今回でいえば準備は、早期にハンズオンに参加していたこと、timesチャンネルをつくったことにあたります。

ブロッカーはなかったの？

ブロッカーは全く無しでした。

強いて言えば、「よし 6 月から Databricks さわっていくぞ！」というタイミングで、
Microsoft Fabric のアナウンスがあったことでしょうか。Power BIは引き続き使うことがありそうなので、Databricks の Dashboard 機能との共存案を模索中です。

少し技術の話

最後に少し技術の話をしておきます。

投げっぱなしの課題回収

いくつか投げっぱなしになっていた課題を回収します。

運用課題の部分の PowerShellスクリプト
- Databricksに関しては、IaC（Terraform, Pulumi）を使用しています。
運用課題の部分で触れたコンピュートコストを使用者自身が確認できない問題
- コストダッシュボードの提供と定期通知を行うようにしました。
歴史の部分で触れたドキュメント問題
- Design Doc をリポジトリに紐付く形で残しています。

Databricks の推し：Unity Catalog

あまりにも Databricks の話をしていないので、最後に推し機能 Unity Catalog の紹介です。

Unity Catalog
- ユーザやデータのガバナンスを提供してくれるもので、他のデータプラットフォームと比べても優位な機能の一つかなと思います。
- 当初は考え方をつかむのに苦労しましたが、Unity Catalogに対応するものがリリースされたらすぐ利用するくらいには推しです。
- 初期からUnityCatalogを有効にしておくことをおすすめします。

さいごに

プロトタイピングを一緒にやってくれたメンバー（Aさん、新マネージャ、チームメンバー）、DatabricksのSA/営業の方、MSのSA/営業の方がいなければ、新アーキテクチャの完成はなかったと思います。本当に感謝しています。いつもありがとうございます。

そして、なんと Databricks Japan さんオフィスが、すぐ近く（シェアオフィスの2部屋隣）に移転されてきました。

これも何かの縁なのでしょうか。
タイミングが良過ぎて逆に怖いですね。。。

AEON TECH HUBPublication

AEONグループのテックブログです！今後様々なグループ会社を巻き込みながらAEONのテクニカルな側面をお届けしていきます！（いきたい！）

「幸運」と「Databricks」で運用負荷を軽減しつつ開発生産性を手に入れたデータ基盤

自己紹介

本稿について

所属部署について

データ基盤

概要

旧アーキテクチャ

構成図

運用

課題

開発観点の課題

旧アーキテクチャの運用観点の課題

課題サマリ

（備考）歴史

新アーキテクチャ

構成図

恩恵

移行

関連の時系列

他の幸運要素

ネゴや予算取りは？

移行振り返り

ブロッカーはなかったの？

少し技術の話

投げっぱなしの課題回収

Databricks の推し：Unity Catalog

さいごに

Discussion