マネーフォワードの Rails プロダクト群を支え、 同時にくっついてなかなか離してくれない共有リソースとの向き合い方

- マネーフォワードを支える Rails プロダクト群のこれまで
- 共有リソースの課題
- 我々は共有リソースとどう向き合っているのか
- 有志での取り組み
- 専門チームでの取り組み
- 全社的な取り組み

についての資料です

Transcript

1. マネーフォワードの Rails プロダクト群を支え、 同時にくっついてなかなか離してくれない共有リソースとの向き合い方
2. 自己紹介
3. 自己紹介 • GitHub: furuhama • 名前: 古濱 有佑(ふるはま ゆうすけ) • マネーフォワード ビジネスカンパニー クラウド横断本部 わり算グループ リーダー • マネーフォワードには新卒で入社して 3 年目 • 最近のプチ自慢: ISUCON 10 で Ruby を使ったチームで唯一本選に行きました • 最近の悲しいこと: ISUCON 10 本選で 最終結果が 0 点(失格)でした
4. 所属組織についてもう少し • プロダクトの数が多い • ほとんどが Rails バックエンド • 誕生した時期は様々 • それゆえインフラ構成や共有リソース との関わり方も複数パターン存在す る (FY20 3Q 決算説明会資料より引用 )
5. 今日話すこと
6. 今日話すこと • マネーフォワードを支える Rails プロダクト群のこれまで • 共有リソースの課題 • 我々は共有リソースとどう向き合っているのか ◦ 有志での取り組み ◦ 専門チームでの取り組み ◦ 全社的な取り組み • 補足: 目指したい世界のその先に見えている課題 (時間があれば)
7. マネーフォワードを支える Rails プロダクト群のこれまで (今の選択だから得られたこと)
8. マネーフォワードを支える Rails プロダクト群のこれまで • ざっくり以下の流れで会社のプロダクトが増えていった ◦ 家計簿プロダクトができる ◦ 個人の確定申告ニーズに応えるために確定申告プロダクトができる ◦ 小規模法人向けの会計機能が確定申告プロダクトを拡張する形で追加される ◦ そこから toB のバックオフィス領域向けにいくつかプロダクトができていく
9. マネーフォワードを支える Rails プロダクト群のこれまで • 大きく 2 つのリソースを共有している ◦ ライブラリ ◦ DB • 共有度合いによって大きく 3 つのパターン ◦ どちらも共有(パターン①) ◦ DB の一部とライブラリのみ分離 (パター ン②) ◦ どちらも分離(パターン③)
10. マネーフォワードを支える Rails プロダクト群のこれまで • パターン①がメインの時期があった • 以下のメリット ◦ 共有のライブラリがプロダクト提供のた めの汎用的な機能を吸収してくれてい る ◦ 共有の DB によってトランザクションや JOIN が利用可能 ◦ ActiveRecord の強みを活かしやすい • シリーズとして関連し合うプロダクトの開発に おいて 0->1 や 1->10 がスムーズに
11. 共有リソースの課題 (くっついて離してくれない)
12. 共有リソースの課題 • プロダクトの成長と共に様々な変更を共有リ ソースに加える ◦ 共有ライブラリ上のモデルに新しいコー ルバック追加したり既存のメソッドに新 しい条件を追加したり ... ◦ 共有の DB にどんどんテーブルを追加 したり一部のテーブルレコードが膨れ上 がったり...
13. 共有リソースの課題 • 共有リソースにより思わぬ副作用が ◦ 共有ライブラリ上のコードがすべてのプ ロダクトで想定した通りに動かなかった り... ◦ 特定のプロダクトの実行したクエリによ る性能劣化で全プロダクトが影響を受 けたり... • 副作用によって以下の課題が露呈 ◦ 開発速度の低下 ◦ 安定性の低下
14. ひとまず目指したい世界 • プロダクトをまたぐ副作用が極力発生しない、 当たり前の世界を目指したい • 開発者の関心事を自身のプロダクトに閉じさせ ることによる開発速度の向上 • 共有 DB をなくすことによる障害単位の縮小
15. 我々は共有リソースと どう向き合っているのか (どうやって離れる？)
16. 我々は共有リソースとどう向き合っているのか(有志での取り組み編) • DB の安定性の向上のためにアプリケーション開発者とインフラから有志が集まった ◦ ディスク容量の大きいテーブルを分割 ◦ スロークエリの改善、もしくは参照分割 ◦ ActiveRecord 経由で実行されるクエリにバックトレース情報をコメントとして付与 ▪ アプリケーションコードと DB のクエリのコンテキストを繋ぐ
17. 我々は共有リソースとどう向き合っているのか(専門チームでの取り組み編) • 有志での活動だとどうしても優先度が上がりきらないという問題があり、共有リソース分割のための専 門チームを組成 • それがわり算グループ • ライブラリと DB の解体を主眼に置いている • 例えば以下のようなことをやってきた ◦ ライフサイクルとコールバックを考えてモデルを持ち帰る ◦ まず更新を特定のプロダクトに集約してライブラリでは参照専用モデルにする ◦ ライブラリが提供する機能のオプショナル化 ◦ ライブラリアップデートの自治活動
18. 我々は共有リソースとどう向き合っているのか(専門チームでの取り組み編) • ライフサイクルとコールバックを考えてモデルを持ち 帰る ◦ create, update, delete それぞれのタイミング と実行されるコールバックを整理 ◦ read をどのプロダクトで行っているのかを整 理 ◦ 実は create, update, delete のタイミングを read に間に合うようにずらして特定のプロダ クトに集約できるケースがあった (整理によっ て見えてきた)
19. 我々は共有リソースとどう向き合っているのか(専門チームでの取り組み編) • まず更新を特定のプロダクトに集約してライブラリでは参照専用モデルにする ◦ 更新タイミングがバラバラかつ更新者となるプロダクトがバラバラだと不整合が起きやすいし、将 来のバグも生みやすい ◦ なるべく参照専用にしていけるとシンプルに考えることができるようになる ◦ 以下のようなコードを共有ライブラリに置く
20. 我々は共有リソースとどう向き合っているのか(専門チームでの取り組み編) • ライブラリが提供する機能のオプショナル化 ◦ 汎用的な機能の各プロダクトへの持ち帰りに際してどうし ても進捗に差異が生まれてしまう ◦ Configuration クラスを導入し、どちらのケースもサポート するために Rails の initialize フェーズで渡すフラグを設 定 ◦ フラグが増えすぎると全パターンの考慮が難しくなる (boolean のフラグだとして 2^N)のであまり積極的にはや りたくない...
21. 我々は共有リソースとどう向き合っているのか(専門チームでの取り組み編) • ライブラリアップデートの自治活動 ◦ 共有ライブラリは gem の形式で提供している ◦ どうしてもプロダクト側でのアップデートが疎かに ◦ その他にも主要ライブラリの脆弱性対応の進捗管理な どもしたかった ◦ バージョン一覧をさっと取れるようなコードを書いてみん なのお尻を叩いている
22. 我々は共有リソースとどう向き合っているのか(全社での取り組み編) • ライブラリの機能や DB のテーブルの役割を 分解していくと、どうしてもプロダクト間で共有 したい箇所が出てくる ◦ 基盤サービスとして切り出して API の通 信経由での機能利用をする形に置き換 え ◦ 利用側の置き換えはすべてのプロダクト で行う必要がある ◦ Ruby の client であれば gem として実装 を提供 ◦ 全社的な取り組みとして推進
23. 我々は共有リソースとどう向き合っているのか(全社での取り組み編) • 基盤サービスにはそれぞれ専門のチームがついて開発 /運用を行っている • 例えば以下のようなサービスをはじめ現在では 20 を越えるサービスができはじめている ◦ ユーザー管理/認証部分を担うサービス ◦ toB 向けの事業者管理を担うサービス ◦ ユーザーの金融機関情報の参照や更新を担うサービス ◦ toC/toB 向け課金を担うサービス ◦ メール配信を担うサービス ◦ PDF 生成を担うサービス ◦ etc • これらだけでなく特定のプロダクト内での機能を切り出したサービスもできはじめている (今回は省 略)
24. 目指す世界とユーザーへの価値提供 • 紹介してきた取り組みがすべて結実してようやくこ の状態になれるか...???というところ ◦ とはいえあと 1 年くらいでだいぶ近づくので はと思っている • 会社としてこういった内部的な改善ばかりやって いればいいわけではない ◦ ビジネス要件を折り込み、走りながら直して いるような状態
25. We’re hiring! カジュアル面談もあるので気軽にどうぞ 今日時間の関係で端折ってしまった話も結構あるので話聞きに来るだけでも歓迎です！
26. 補足: 目指したい世界の その先に見えている課題 (時間があったら)
27. 目指したい世界のその先に見えている課題 • まだまだ課題はある ◦ 通信によるデータの更新・参照がメインとなった世界での ▪ 整合性の担保 ▪ 最適なメッセージングの方法の模索 ◦ プロダクト間のインフラ構成の差異を減らす ▪ プロダクトの誕生時期によって構成が異なり運用コストが増加 ◦ インフラ運用をプロダクト横断のチームが行っている ▪ プロダクト開発チームに運用を委譲しないとインフラ運用チームがボトルネックに ▪ そもそもスモールチームでのスムーズな開発には開発・運用のサイクルがチームで閉じて いることが不可欠 • 最終的には一貫して開発運用を行える、リソースを共有せず疎に繋がった自律的なチームの集合とし て会社が存在するような状態になるといいのかな、と個人的に考えている