クラウドネイティブで実現する、共通DBの課題解決 ～桃園の誓いアーキテクチャ～

＠IT Cloud Native Week 2025 冬「崖っぷちから這い上がる」で登壇した内容です
https://members06.live.itmedia.co.jp/library/ODIxMTc%253D

Transcript

1. 株式会社マネーフォワード ビジネスカンパニー 内⻄ 功⼀ クラウドネイティブを推進する マネーフォワード「共通DB分割」の舞台裏
2. 2 ⾃⼰紹介‧事業紹介
3. ⾃⼰紹介 3 株式会社マネーフォワード ビジネスカンパニー 横断BizOps本部 BizOps部 Adminグループ 2018- HRS本部 2021- 横断本部 2024- 横断BizOps本部 内⻄ 功⼀ 2018年にマネーフォワードに新卒⼊社。 「マネーフォワード クラウド勤怠」の⽴ち上げに携わり、その後 「マネーフォワード クラウドパートナー」のリニューアルを担当。 「桃園脱却プロジェクト」にてビジネスカンパニーのリード担当。
5. 5 会社組織体制 ５つのビジネスドメインで構成。法⼈向けには主にバックオフィスSaaSサービスを展開。
8. 8 個⼈事業主 中⼩企業 中堅企業‧IPO準備企業 上場企業 個⼈事業主向け 中⼩企業向け 中堅企業‧IPO準備企業∕上場企業向け あらゆる企業規模に対応 主に⼠業事務所向け 主に中堅企業向け 個⼈から中⼩企業、エンタープライズ企業まで、様々な企業に対応可能なバックオフィスSaaSを展開 事業内容
9. 9 マネーフォワードのサービスの拡⼤ 2020年から2021年にかけてサービスリリースが増加 toC toB向けで 共通データを利⽤ and more.. 推進チーム発⾜ 基盤サービス 完了 問題の顕在化 チームJOIN
10. 10 共通DBの当時の課題
11. 11 共通DBサーバーを複数サービスが共⽤ 共通DBの当時の課題
12. 三国志演義：桃園の誓い 
 12 桃園の誓いアーキテクチャとは？ 共通DBを複数のサービスが共⽤している状態 サービスのリリース時期は違っても 
 ダウンする時は同じ・・・ 
 「我ら生まれた日は違えども、 
 　死す時は同じ日同じ時を願わん」 
 画像は⽣成AIにより作成
13. 桃園アーキテクチャの課題 DB変更のリリースを行う際、複数サービスでタイミングを合わせる必要がある
 1サービスの影響範囲が分かりづらい
 固有サービスのデータが別サービスでも利用される 請求情報 / 勘定科目 / 従業員情報 など 重いSQLの実行で全体障害になっていた 13 開発スピードの鈍化 ビジネスカンパニーの障害が別のカンパニーに影響してしまう
 月に何度も障害が発生し、深夜にインフラが立ち会い 1 2 桃園の誓いアーキテクチャとは？
14. 14 桃園脱却プロジェクト開始時の構成 桃園の誓いアーキテクチャとは？
15. ビジネスカンパニーの桃園脱却後の構成 15 桃園の誓いアーキテクチャとは？
16. 16 ビジネスカンパニーの桃園脱却のゴール インフラ障害が他のサービスに影響しない状態 一部サービスはインフラの障害の影響を受けても、他サービスは稼働している状態 そのために、基盤サービスの共通DB分割＋AWS移行を目指す 桃園の誓いアーキテクチャとは？
17. 17 基盤サービスの共通DB分割 と AWS移⾏プロジェクト
18. 18 Q 今、桃園の誓いアーキテクチャは どうなったの？
19. 19 A 基盤サービスでは完了 ⼀部サービスに関しては進⾏中
20. 20 プロジェクト推進チーム：わり算チームのミッション データベースを割ることから、通称「わり算チーム」 •共通DBを分割する⽬的で作られたビジネスカンパニーの1チーム •桃園脱却のためイネーブリングを⾏う組織
21. 21 結果：DBの分割に成功 情報ごとにDBが分かれ、使いやすい状態に Before After
22. 22 共通DB上のデータ分類 1 共通情報 •全てのサービスに必須な情報 ◦ユーザー、事業者、課⾦ 2 サービス共有情報 •2つ以上のサービスで必須な情報 ◦勘定科⽬（サービスA-サービスB） ◦従業員（サービスA-サービスC） 3 サービス固有情報 •単独サービスで必須な情報 1 2 2 2 3 3 3
23. 23 共通DB上のデータ分類 1 共通情報 •全てのサービスに必須な情報 ◦ユーザー、事業者、課⾦ •対応⽅針 ◦case1. 基盤サービスの作成  ◦case2. 共通管理画⾯の機能縮⼩ Before After
24. 24 課題 • toB, toC サービスが共有で利⽤されている • 各サービスでログイン処理を実装 • ユーザー情報をメインで扱うチームがいなかった 基盤サービスの作成 ① 共通情報：全てのサービスに必須な情報
25. 25 基盤サービスの作成 ① 共通情報：全てのサービスに必須な情報 配布⽤ したこと 1. ユーザー基盤サービスの作成 a. 共通DBへ情報を書き込む 2. ユーザー基盤の更新系APIを利⽤ 3. 各サービスがDBへの直接参照 を停⽌、参照APIを利⽤する 4. 共通DBへの書き込みを停⽌ 🎉🎉 分離完了🎉🎉
26. 26 基盤サービスの作成 ① 共通情報：全てのサービスに必須な情報 解決したこと • ユーザーに関係することは、基盤チームに相談することができる • ログイン処理は、基盤サービスにお任せ • パスキーなど UX を向上する仕組みも先進的にできるようになった
27. 27 共通DB上のデータの分類 2 サービス共有情報 •2つ以上のサービスで必須な情報 ◦勘定科⽬（サービスA-サービスB） ◦パートナー（サービスA-サービスC） •対応⽅針 ◦case1. 主サービスとAPI連携 ◦case2. 新しいサービスにリプレイス Before After
28. 28 主サービスとAPI連携 ②サービス共有情報：2つ以上のサービスで必須な情報 課題 • ⾃サービスで独⽴した判断ができない • 共通DBに影響され、障害の際には呼び出される • 別サービスからどのように扱われているかブラックボックス化
29. 29 主サービスとAPI連携 配布⽤ したこと Aが送信元、Bが受信先の例 1. A から BにAPIの作成 2. Bにキャッシュテーブルの作成 3. テーブル同期のデータパッチ 4. ズレがないかの確認 5. Bから共通DBへのアクセス停⽌ 🎉🎉 分離完了🎉🎉 ②サービス共有情報：2つ以上のサービスで必須な情報
30. 30 主サービスとAPI連携 解決したこと • サービスの独⽴性の向上 • パフォーマンスの向上 • スケーラビリティの向上 • 可⽤性の向上 ②サービス共有情報：2つ以上のサービスで必須な情報
31. 31 共通DB上のデータの分類 3 サービス固有情報 •単独サービスで必須な情報 •対応⽅針 ◦case1. 固有カラムを利⽤停⽌ & 引越し ◦case2. 固有テーブルを引越し Before After
32. 32 固有カラムを利⽤停⽌ & 引越し ③サービス固有情報：単独サービスで必須な情報 課題 • 共通DBを分割したいが他サービスで利⽤されている • 他サービスでの利⽤は必須なのか判断できない ◦ 仕様の話になり PdM を巻き込む必要 • サービス毎に都度調査を⾏うのが煩雑 ◦ どのサービスで利⽤されているか不明確 ◦ 調査タスクは⼀度で完結させたい
33. 33 固有カラムを利⽤停⽌ & 引越し ③サービス固有情報：単独サービスで必須な情報 したこと 1. 横断的に利⽤状況を調査 2. 各サービスに利⽤停⽌の依頼 3. 利⽤が必須の場合にAPI連携 4. サービスDBに固有カラムの引越し 🎉🎉 分離完了🎉🎉 After 配布⽤
34. 34 固有カラムを利⽤停⽌ & 引越し ③サービス固有情報：単独サービスで必須な情報 • サービスDB が独⽴して稼働できるように！ ◦ インフラ移⾏も可能に • サービスの仕様を改めて⾒直せた • 他サービスの利⽤がAPI経由になり明確化 ◦ 別サービスから固有カラムの更新がなくなった 解決したこと
35. 35 結果：DBの分割に成功 情報ごとにDBが分かれ、使いやすい状態に Before After
36. 36 プロジェクトの進め⽅
37. 37 Q 社内に前例がなく どう進めたらいいかわからない
38. 38 A まずは推進チームの⽴ち上げから。 ⾃らサービス開発の中に⼊り 社内に仲間を増やしていきましょう！
39. 39 桃園脱却プロジェクトの関係者 プロジェクトの進め⽅
40. 40 1. 推進チーム プロジェクトの進め⽅
41. 「桃園脱却プロジェクト」を理解してもらう難しさ ⾃⾝初のリーダー職である中、若⼿‧多国籍メンバーを束ねる難しさ ⾃チームのみで完結できず、他チームとの連携が必須 41 課題：若⼿メンバーで構成されたチーム プロジェクトの進め⽅：1. 推進チーム 中途1年⽬ 新卒2年⽬ 新卒2年⽬ ベトナム⼈ 新卒1年⽬ ベトナム⼈ 学⽣ インターン リーダー メンバー リーダーの悩み リーダーを任されたけど 孤独を感じる‧‧ リーダー業務の他 ⾃分のタスクもある‧‧
42. 各サービスのチームに⼊り込んで開発する難しさ 42 課題：タスク量が多く、難易度も⾼い プロジェクトの進め⽅：1. 推進チーム サービス毎に異なるルールに則った開発が求められる ドメインや技術構成が異なる ルールを⾃ら調査し、設計‧実装することが求められる エンジニアとのコミュニケーションが必要 ⾃分の上司とサービス側のエンジニアと相談する必要がある 1
43. サービス同⼠のデータ連携⽅法を変更する難しさ 43 課題：タスク量が多く、難易度も⾼い プロジェクトの進め⽅：1. 推進チーム 発⽣するデータのズレを調整する必要がある 各サービスで異なるデータ登録⽅法や形式（UI、CSV⼊⼒、APIなど）をカバーし、 データを⼀致させて連携させる サービス間通信における、新技術の利⽤ニーズへの対応 PubSubなど新しい技術への挑戦、安全な移行方法の提案 2
44. 各サービスのチームに⼊り込んで開発をする難しさ サービス同⼠のデータ連携⽅法を変更する難しさ 44 課題：タスク量が多く、難易度も⾼い プロジェクトの進め⽅：1. 推進チーム 調査・開発・連携など、業務の幅が広いため、 
 タスクの種類が多く、自ずと業務量が多くなる。 
 若手メンバーにとって難易度の高い業務となる。 
 1 2
45. 課題 45 当時の課題解決から得た学び プロジェクトの進め⽅：1. 推進チーム チーム⼀丸となって取り組む 1 プレイングマネージャーとしてタスクが溢れていた 各メンバーが独⽴したプロジェクトのようになっていた アサイン後、放置はNG。⾃分のタスクに積極的に巻き込む 解決法
46. 課題 46 当時の課題解決から得た学び プロジェクトの進め⽅：1. 推進チーム お互いにポジティブになれるようフィードバックを⾏う ２ メンバーの成⻑を加速させたい思いがありつつも、 リーダーとしての振る舞い⽅がわからず、メンバーと衝突 難易度の⾼さを踏まえながら、メンバーにフィードバックする 解決法
47. 課題 47 当時の課題解決から得た学び プロジェクトの進め⽅：1. 推進チーム 時にはやめる決定をする勇気を持つ 3 ⾃チームの担当するメンテナンスサービスの継続負荷が⾼い 「メンテナンスをしない」選択肢を持つ 解決法
48. 48 2. サービスチーム プロジェクトの進め⽅
49. 49 課題：サービス-推進チーム間のコミュニケーション プロジェクトの進め⽅：2.サービスチーム サービス毎の Slack チャンネルがなく、プロジェクト全体のチャンネルは⼈が多い 推進チームには伝えておきたいけど、全体の相談事項が流れてしまう（→ 個別の相談は億劫になる） サービスごとの細かい相談がしづらい環境 各サービスの担当者に情報が属⼈化 休⽇のメンションをキャッチ出来ないことでタスクが漏れる リーダーなど忙しい⼈ / チーム内への共有が漏れがち 途中の⼊れ替わりなどで情報が引き継がれない ⼝頭確認による相互での認識ずれが発⽣ 情報共有をするドキュメントの不⾜ 1 2 3 関係性の構築と ⼼理的安全性の 確保が重要
50. 50 解決策：ハードルを下げてやってみる！ プロジェクトの進め⽅：2.サービスチーム 全サービスチームに個別チャンネル作成を促し、些細な相談をしやすい環境を作成 各チームの進⾏状況が⼀箇所でわかるようにし、サービスチャンネルに埋もれていたこともわかるように！ サービス毎のSlack のチャンネルの作成 複雑化するSlackコミュニケーションのルール化‧交通整理を実施 お互いにみやすくなったことで、 個々のコミュニケーションも活発に！ 各チームのメンション先と相談チャンネルを⼀覧化 ⼝頭のコミュニケーションを記録することを徹底した 別サービスの進捗も⾒える！抜けもれなく情報伝達が可能に！ 議事録の整備 1 2 3 相談事項が活発化し、より動きやすく！
51. 51 3. カンパニー プロジェクトの進め⽅
52. 52 課題：ビジネスカンパニー内のカオスな状態 プロジェクトの進め⽅：3.カンパニー プロジェクトの並⾏数が多く認識のキャパシティを超えていた 関わるサービス‧基盤サービスの数が多く、全体の進捗管理がしづらい 情報が分断され、分割作業の横の知⾒共有がない 横断組織視 点 今どれくらい進捗しているのか数値化して表現したい 隣のサービスの様⼦が⾒えず、都度確認作業が発⽣ 優先タスクにスムーズに⼊れず、前⼯程の作業に追われている サービス視 点
53. 53 解決策：全体のプロジェクト進捗を可視化 プロジェクトの進め⽅：3.カンパニー サービスごとの進み具合を⼀元管理 2023.08. 64% 完了 2024.08. 91% 完了
54. サービスB‧Cはどちらも 事業者DBの分割作業を実施中 54 解決策：サービス‧基盤間の情報分断をなくす プロジェクトの進め⽅：3.カンパニー 異なるサービス同⼠で 知⾒共有が可能に 例
55. 55 解決策：推進チームがボトルネックを巻き取る プロジェクトの進め⽅：3.カンパニー 推進チームが率先して 前⼯程の作業を巻き取り 例 サービスチームが メイン作業をスムーズに
56. 56 4. 対コーポレート プロジェクトの進め⽅
57. 57 課題：ゴールの共有 プロジェクトの進め⽅：4.コーポレート つまり しかし ⻑期かつ⼤規模なプロジェクトは ゴールを途中で⾒失いがち 基盤サービスがDB分離完了 ⼀部サービスは共通DBの障害の影響を受ける 全てのサービスが共通DBの障害の影響を受けない
58. 全員でのゴール共有が⼗分でなく、定例を持たない推進本部⻑‧VPoEへのレポートが不⾜ →終盤、経営陣への報告に困るという事態に 58 課題：ゴールの共有 プロジェクトの進め⽅：4.コーポレート
59. 59 プロジェクトの終盤‧‧‧ プロジェクトの進め⽅：4.コーポレート Aさん ※PJが終わった認識 担当サービスの分割が 完了しました、 お疲れ様でした！ ⻑期‧⼤型のプロジェクトにつき、終盤ではゴールに対する認識がバラバラに Cさん ※新⼊社員 すみません 『桃園脱却』って なんですか？ Bさん ※PJ継続中の認識 まだ全てDBの分割が 終わってないのでは？ Dさん ※上⻑ 経営陣に報告したい のだけど、結局成果って どうだったの？
60. 60 解決策：ゴールを定義し、ドキュメント化する プロジェクトの進め⽅：4.コーポレート コーポレートCTOに最終資料として共有 ビジネスカンパニー全体に情報を共有する ⼀緒に取り組む仲間を⾒つける →サービス側の担当者が協⼒してくれることに ステップ 1 ステップ 2 ゴールを定義するドキュメントの作成 ① ビジネスカンパニー + 全体へのヒアリングを⾏い、全体の現状を把握 ② 部⻑ + 仲間 と相談を⾏いドキュメントを作成 ③ VPoE / 本部⻑を巻き込んでドキュメントを確定 →ビジネスカンパニーとしてひとつの解にまとめる ステップ 3 ステップ 4
61. 61 取り組みの成果 今後に向けて
62. 62 障害耐性 と開発スピードの向上 取り組みの成果① 基盤アプリは東京に、 共通DBサーバーは 北海道に存在 1クエリごとに20ms かかっていたが、 サービスごとにDBを持つことで⾼速化 津軽海峡問題 の解消 1サービスが共通DBをダウンさせることは なくなった 開発リソースを個々のサービスへ割くこと ができるようになった 共通DBによる問題 の解消
63. 63 オンプレからクラウドへ 取り組みの成果② マシンが固定されており、スケールアップがしづらい △ コストが安い 〇 LANなど通信機器などの障害の影響を受ける △ 1 2 3 オンプレ Before 柔軟にオートスケールが可能 ◎ ⾊々できるようになったもののコスト⾼ △ → 経営層がOK マシン⾃体の交換をクラウドベンダーが担当できる ◎ クラウド After 1 2 3
64. 64 ダブルメンテナンス問題 サービスC 部⾨マスタ サービスA 部⾨マスタ サービスE 部⾨マスタ サービスB 部⾨マスタ サービスD 部⾨マスタ 部⾨マスタを変更したい、 関係するすべてのサービスに 更新をかけないと… 今後に向けて
65. 65 ダブルメンテナンス解消 サービスA サービスB サービスC サービスD サービスF 1回の更新で すべてのサービスに載っている 部⾨マスタが更新された！ サービスF マスターサービス 更 新 今後に向けて
66. 66 新たなチャレンジ！
67. 67 推進チームでの知⾒を活かし、次のチャレンジへ 新たなチャレンジ！：推進チームメンバー いろんなサービスの中に スポット的に⼊って開発できる 計画プロジェクトに対して 集中できる 横断プロジェクト開発 ⼀つのサービスでユーザー体験含め 深い開発ができる エラー調査など現場感が必要な 開発も含まれる サービス開発 解散後、メンバーがサービス開発側に挑戦 After Before 若⼿中⼼チームで衝突もあったものの、円満にプロジェクト終了 推進メンバーの退職者 “ゼロ”
68. 68 新たなチャレンジ！：内⻄の場合 営業活動、納品、請求、消込までを担当領域とする 推進チーム → BizOps (ビジネス オペレーション) AI活⽤、バックオフィス業務の効率化 顧客管理、マーケティングツール などの調整 機動性の⾼い相談⼒ 桃園で 磨いたスキル 問題の分解⼒ 桃園脱却前後のデータ構造が横断的にわかる BizOps で ⽣きている知識 エンジニアのバックグラウンド 推進チームでの知⾒を活かし、次のチャレンジへ
69. 69 ここで登壇しているのは⾃分ですが たくさんの⼈に感謝です たくさんの⼈たちのサポートで 桃園脱却は完了しました 分離をする 判断をしたCTO ⼈員の配置や ロードマップの 作成をしたマネージャー 実際に分離作業を ⾏なっていた 各チームのメンバー
70. 70 ご清聴ありがとうございました