HeatWavejp_Meetup_12_最初のデータ基盤はいつ？どれ？

Money Forward Admina 最初のデータ基盤はいつ？どれ？ HeatWavejp Meetup #12 2025 年 2 月 26 日 マネーフォワード i 株式会社 村上 勝俊 (@umisora)

Money Forward Admina 本日のお話 現在 MySQL(そしてこのコミュニティに来ている方々)で、ビッグデータ・データウェアハウ ス・分析基盤として、手軽な一歩って何か？最初の一歩って何か？をお話ししたいと思います。 その中で、いくつかのアーキテクチャパターンがあり、実際に私が比較検討をしたのでその内 容もご紹介します。 特に昨今 AI 化で、AI にどうやって食わそう…とか、既存の MySQL も大分長大になってき たけどここからどうやって始めよう。そんな点共有できたら嬉しいです。

Money Forward Admina 自己紹介 ・名前 : 村上 勝俊 (@umisora__) ・会社 : Money Forward i 取締役・CPO ・担当 : Admina 製品の企画・開発・マネージャー ・経歴 : 金融系 SIer → MoneyForward → Money Forward i ・技能 : オンプレインフラ (Linux/Windows) → クラウドエンジニア → EM/PO ・趣味 : ちいさなコードを書くこと ・データ基盤の出会い : 社内で Embulk という ETL を使って MySQL に集計したデータ をヒストリカルに BigQuery に毎日書き込みたい！から始まりました。最初にヒストリ カルを対処したのは正解でもあり、茨でもありました…。

Money Forward Admina 章立て ■ データ基盤始める時に知っておくと良いこと 分析要件と技術スタック(キーワード)について理解し、短期・中期で気づいておくと良いこと を共有したいと思います。またそれらを理解することで Heatwave はデータ基盤技術スタッ クの中でどこを支援することができるか理解できます。 ■ MySQL HeatWave によるデータ基盤統合 Heatwave がハイパフォーマンス列指向データベースの側面だけでなく、データ基盤における DWH としての役割について再確認していきます。 ■ 比較結果 最後に、私が自社で最初のデータ基盤を比較する時に、Heatwave を含めた、いくつかの DWH パターンを整理したので共有させていただきます。

Money Forward Admina データ基盤を始める時に知っておくと良いこと 最初のデータ基盤はいつ？どれ？を考える前提の部分についてご説明し、Heatwave が何を 担うのか理解する手助けを行います。

Money Forward Admina データ基盤を始める時に知っておくと良いこと Agile Analytics Platform 構築 企業のフェーズに合わせた段階的で、手戻りもしやすく、将来の負債になりにくいことを考慮 したアジリティのある Agile なデータ基盤の構築戦略。(私個人が考えたので権威性はあ りません) Step 概要 1 Excel との併用を前提としつつも、幅広いデータにアクセス出来る基盤。主にキーとなるメトリクスの発見や、感 性・感想を裏付けするためのデータ観察が行える。 2 複数データソースの結合分析、統計分析などの高度な分析要件に応える。データマートの整備も始まる。 3 履歴データの分析や、より複雑な統計分析が可能に。データカタログやモニタリングも整備される。 4 機械学習への本格的なデータ利用、ML Ops の基盤との接続。分析結果やデータモデルのプロダクトへの提供が行 える。

Money Forward Admina データ基盤を始める時に知っておくと良いこと ■ 分析要件の整理方法 分析要件の要素としては以下のようなものがあります。 Step 単一データソース分析 複合データソース分析 履歴データ分析 統計データ分析 機械学習 レポート 1 ◯ △ x △ x △ 2 ◯ ◯ △ △ △ ◯ 3 ◯ ◯ ◯ ◯ △ △ 4 ◯ ◯ ◯ ◯ ◯ △ すごく優れた分析・ダッシュボードを見慣れているとこれらは最初から揃っているかのように 思いますが、これらをすべて揃えるにはまぁまぁコストが掛かります。データエンジニアもい ない環境で、データ基盤の実績もなく、これらを高いコストかけて構築しても案外使われず金 食い虫と言われるのは間違いなしです 😭 様々な要望が来ますが、どこから手を付けるのか？ その順序付けが大事です。

Money Forward Admina データ基盤を始める時に知っておくと良いこと 技術スタックの全体像 技術スタックや考慮すべき点も確認しておきましょう。このような観点が構築時に登場してき ます。(但し第 8 層政治層は除く) ETL/MART/BI にはさらなる奥地がありますが、データ基 盤エンジニアとしては後で考えることにしましょう。 Step NN/Sec IAM DWH ETL MART BI ML/Notebook Excel 併用 AI 利用 1 ◯ ◯ x x ◯ ◯ ◎ x 2 ◯ ◯ ◯ △ ◯ ◯ ◯ △ 3 ◯ ◯ ◯ ◯ ◯ ◯ △ ◯ 4 ◯ ◯ ◯ ◯ ◯ ◯ △ ◯ 要件を段階的にするためには、技術的側からも"何がローコストなのか"を提案と望ましい です。分析側は"今あるものでどうするか"と考えてくれます。そんな会話を元に最初のスコー プを決めていくと動きやすいです。

Money Forward Admina データ基盤を始める時に知っておくと良いこと データ基盤全体の運用上の考慮点 もちろん機能要件だけじゃないのがデータ基盤ですね。(ある意味選定要件でもあるけれど) 以下の観点も徐々に登場します。特に ETL/MART とはエラーで失敗する時にどうするか問わ れることが多いです。(それはインフラレイヤーのテーマではないケースも多いです) 項目 説明 データ規模/パフォーマンス データの増加に伴うパフォーマンスの維持と最適化が必要です。 バックアップ・リカバリ データの損失を防ぐためのバックアップと迅速なリカバリ手段を確保します。 PTR/RTO 計画的な復旧時間と目標復旧時間を設定し、システムの可用性を確保します。 セキュリティ データの保護と不正アクセスの防止を行います。 スケーラビリティ システムの拡張性を考慮し、将来的なデータ増加に対応できる設計を行います。 モニタリングとアラート システムの状態を監視し、異常が発生した際に迅速に対応できるようにします。

Money Forward Admina MySQL HeatWave によるデータ基盤統合 技術スタックの統合による複雑性の低減と、運用負荷の軽減について説明します

Money Forward Admina MySQL HeatWave によるデータ基盤統合 MySQL HeatWave のカバー範囲 ・ETL プロセス: MySQL を単一ソースとした DWH へのレプリケーションが同一製品内で 完結 (一般的なレプリケーション技術で完結する) ・データウェアハウス: 分析用の大規模データストアの役割を担う ・アクセス制御: IAM は今の MySQL と同じなので新しい運用や構成、設計が発生しない ・ネットワーク/セキュリティ: 既存ですでに考慮されている近くに置くので論点が少ない Heatwave で一発解決 Step NN/Sec IAM DWH ETL MART BI ML/Notebook Excel 併用 AI 利用 1 ◯ ◯ x x ◯ ◯ ◎ x 2 ◯ ◯ ◯ △ ◯ ◯ ◯ △

Money Forward Admina MySQL HeatWave によるデータ基盤統合 MySQL HeatWave の提案を受けた時の感想(おどろき) 1. アプリケーション側への迷惑が少ない。MySQL で慣れた普段のオペレーションの延長で DWH がついてくる。すごい。DBA 的には助かる！ 2. なんと、DWH を選定していたら、アプリケーションのパフォーマンス向上までついてく る。 3. 多分他の ETL より型変換も少なく、エラー落ちも少なそう！楽そう！！ 実際に DWH を構築すると、ETL の保守の重さに泣きたくなる日が来ます。 ただデータを DWH に入れて、高速に大量のデータを SQL を投げたいだけなのに！！！

Money Forward Admina 比較結果 実際に検討した DWH パターンとその比較結果について共有させていただきます。

Money Forward Admina 比較結果 比較のポイント ・DWH 単体としてのパフォーマンスは比較対象外 ・ETL など周辺要件を加味した総合コスト・運用コストを机上で比較 特に、ETL の部分で技術の進化が激しいので、より楽なマネージド構成を追求します。 ・スキーマ変更への追従性 ・ETL 処理の容易さ ・リアルタイム性 (CDC) ・技術構成のシンプルさ ・セキュリティ機能 ・コスト

Money Forward Admina 比較結果 RedShift + Zero ETL [メリット] ・DWH/ETL 完全マ ネージド ・スキーマ自動追従 ・高度な環境も構築 可 [デメリット] ・コストがやや高い ・AWS ロックイン ・ネットワークコス ト MySQL HeatWave [メリット] ・MySQL オフィシ ャルの互換性 ・シンプルな構成 ・アプリケーション にも好影響 [デメリット] ・マルチソース非対 応 ・MySQL 以外の ETL は別途必要 BigQuery + ETL [メリット] ・BigQuery 便利す ぎる ・コスト効率が良い ・スケーラビリティ ・業界のリード [デメリット] ・ネットワークコス ト ・ETL が別途必要 Snowflake/Databricks [メリット] ・マルチクラウド対応 ・大きなコミュニティ ・高度なセキュリティ ・独自性のある DWH/技術/ エコシステム [デメリット] ・ZeroETL みたいなのない ・何処まで行っても AP と距 離がある

No Query Engine E of ETL (Extract) T of ETL (Transform) L of ETL (Load) Automatic tracking of schema changes. (NoOps) CDC (RealTime) Simplicity of tech components Dynamic Masking for Query Users (Security) Cost Note 01 RedShift Serverless ZeroETL ZeroETL ZeroETL (Best) (Best) (Best) (Best) (Expensive) - Over 10万 XXX 02 RedShift Serverless DMS DMS DMS (Thinking) XXX (Good) (Good) (Best) (High) - 5万 There is a rumor that the failure rate of DMS replicas is high. 03 RedShift Serverless MySQL Exporter + S3 - S3 + COPY Load with Lambda ? (No Good) XXX No Way (No Good) (Best) (Low) - 3万 04 RedShift Serverless MySQL Exporter + S3 Glue + S3 (Track Schema) Redshift Spectrum as External (Good) No Way (No Good) (Soso) (Low) - 3万 05 Snowflake Variant DB MySQL Exporter + S3 - Scheduled Copy Into (Good) No Way (Soso) (Best) (Low) - 3万 Hard to write SQL XXX 06 Snowflake Icebarg MySQL Exporter + S3 Icebarg + Catalog(Sync Glue) (Track Schema) Dynamic Load from Object Storage (Good) No Way (No Good) (Best) (Low) - 3万 Not yet GA XXX 08 Databricks MySQL Exporter + S3 - Auto Loader + Delta Live Tables (Thinking) No Way Impossible in the future as well XXX (Soso) (Best) (Low) - 3万 07 BigQuery MySQL Exporter + S3 + GCS(Sync) - Scheduled BQ load (Thinking) No Way does impossible in the future ?? ⚠️ (No Good) Need to maintain one more laaS ?? (Cheaper) - 1万 Table単位 09 MySQL Heatwave MySQL Replication MySQL Replication MySQL Replication (Best) (Best) (Best) (Soso) (High) - 5万 No multi source.

Money Forward Admina