マネーフォワードにおけるGoとマイクロサービスの活用事例

マネーフォワードにおける
- Go化の背景
- Goを技術選定した理由
- Goを使って得られた知見
- 今後のGo利用
についてのドキュメントです

Transcript

1. マネーフォワードにおけるGoとマイクロサービスの活用事例 2021年3月3日
2. 自己紹介
3. • 名前: 櫻 勇人(さくら ゆうと) • Twitter: ysakura_ • 関西開発本部 テクニカルアーキテクトグループ リーダー • 複数の新規プロダクトで インフラとマイクロサービスの構築を担当 • 性能問題の解決を主とし 『マネーフォワード クラウド会計Plus』の技術改善に従事 • Go歴: 3年 • MFでは約2年、Goでマイクロサービス 自己紹介
4. • 複数のドメインでプロダクトを展開 • 開発言語 ◦ Railsのプロダクトが多い ◦ Java: 社内の基盤サービス ◦ Go: マイクロサービス • インフラ ◦ さくらインターネットからスタート ◦ 新規プロダクトはAWS ◦ さくら to AWSの移行も マネーフォワードの紹介 FY20 通期決算説明資料より引用
5. • マネーフォワード クラウド会計Plus ◦ 櫻の担当プロダクト ◦ 上場企業向けの会計ソフト ▪ データ量が多いのが特徴 ◦ 監査向けに承認機能や履歴機能を提供 ◦ WebのメインシステムはRuby on Rails ◦ 一部をGoでマイクロサービス化 マネーフォワードの紹介
6. 今日話すこと/話さないこと
7. 今日話すこと • MFにおけるGoの事例 • マイクロサービス化の背景 • Goを選んだ理由 • マイクロサービスでGoを活用してみて ◦ Goで良かった点 ◦ Goを使う上で意識した方が良い点 ◦ Goを利用してみての課題感 • 今後のMFとGo
8. • マイクロサービスアーキテクチャの詳細 • Goの具体的なコード例 今日話さないこと
9. MFにおけるGoの事例
10. MFにおけるGoの事例 • マイクロサービス ◦ 今回のメイントピック • ツール ◦ インフラ系が多い ◦ 簡単な言語仕様 ▪ サクッと作れる ▪ 利用者に改善して貰いやすい
11. • マイクロサービスの約半数がGo製 ◦ ※ 全社の基盤サービスを含む • 会計Plusのマイクロサービス ◦ 機能のジャンル(ドメイン)毎に作成 ▪ 会計帳簿の作成 ▪ 履歴管理 ▪ 他サービスからのデータ連携 マイクロサービス
12. アーキテクチャ紹介 会計帳簿を作成するサービスの 簡易的なアーキテクチャ図 • メインのWebシステムはRails • API CallはgRPCを利用 ◦ メソッドをRPCで丸々置き換え • 非同期処理はSQSで ◦ 重い処理をオフロード
13. マイクロサービス化の背景
14. • 次の2つの背景からマイクロサービス化を進行中 ◦ 組織スケールの問題 ◦ 性能問題の解決 マイクロサービス化の背景
15. • これまではRailsのモノリシックなアプリケーション ◦ 大きなサービスでは、数十人で開発している • 徐々にリリース速度が低下 ◦ メンバー数の増加 ◦ コードの複雑性の増加 • 開発速度を維持したまま、組織をスケールさせたい ◦ マイクロサービス化を進行中 • ※ 複雑度が低いうちは、モノリスの方が生産性が高い 組織スケールの問題 出典 https://martinfowler.com/bliki/MicroservicePremium.html
16. • 現状の技術スタックでは満たせない非機能要件が出てきた ◦ MFのユーザー数の増加 ◦ 新しいターゲット層 ▪ 会計Plusでは上場企業を対象に • 非機能要件を満たせる技術選択をしたい ◦ マイクロサービスで疎結合にして、独自の技術選択を可能に ▪ 別言語のサーバー ▪ 独自のストレージ 性能問題の解決
17. Goを選んだ理由
18. • マイクロサービス化の要件 ◦ 高速な言語 ◦ 静的型付けの言語 • Goを選んだ理由 ◦ 要件を満たせる ◦ Dockerとの相性が良い ◦ モチベーションの高いメンバーの存在 ◦ 採用市場の変化 Goを選んだ理由
19. • 高速な言語 ◦ 性能問題を解決する事が目的の1つ • 静的型付けの言語 ◦ 信頼性が求められるケースでは、静的型付けの安全性を重視 ◦ 開発チームが大きくなる事を考えても、静的型付けの安全性は大きなメリット マイクロサービス化の要件
20. • 要件を満たせる ◦ この段階ではC#やJavaも候補になる • Dockerとの相性が良い ◦ Goはイメージサイズが小さい ▪ コンパイルしたバイナリを置くだけ ▪ Javaの様に仮想環境を必要としない ◦ MFでは、ECS/EKSでコンテナ化が進んでいるのでマッチした • モチベーションの高いメンバーの存在 ◦ 社内に経験者やGoを扱いたいエンジニアがいた Goを選んだ理由
21. Goを選んだ理由 • 採用市場の変化 ◦ Goが流行っている ▪ ”今”の技術選択においてはGoは有力な選択肢の1つ • 採用のしやすさ • エンジニアのモチベーション • 情報のアクセスしやすさ ◦ 参考: 当社CTO中出の発信 ▪ マネーフォワードCTOが考えていること（2020年9月）
22. マイクロサービスでGoを活用 してみて
23. マイクロサービスでGoを活用してみて • Goで良かった点 • Goを使う上で意識した方が良い点 • Goを利用してみての課題感
24. • ハイパフォーマンス ◦ 数十分かかる処理が10分の1, 場合によっては100分の1に • 並行処理が扱いやすい ◦ 'g', 'o', ' 'の3文字を打つだけでgoroutineが起動する ◦ OSの違いを意識する必要がない ◦ 性能が求められるケースでは大きなメリット Goで良かった点
25. • gRPCのスキーマ駆動開発が便利 ◦ マイクロサービスとの通信に利用 ▪ 別チームとの開発を進めやすい • キャッチアップが容易 ◦ 言語仕様がシンプル Goで良かった点
26. • 言語仕様がシンプルゆえにコード量が多くなる ◦ 自前で実装する、もしくは、ライブラリのキャッチアップを意識する ◦ 下手をすると可読性の低いコードが生まれてしまう • goroutine leakには気をつける ◦ goroutineが終了せずに、goroutine内部の変数がメモリを浪費しOOM ▪ 解決策の例 • context.Contextを用いて、タイムアウトや強制終了を可能にす る Goを使う上で意識した方が良い点
27. • Goが最適な技術とは限らない ◦ JavaやC#の方が言語仕様はリッチ ◦ RESTfulなWebサーバーをスピーディーに作りたい ▪ Railsの方が良い ◦ フロントエンドを扱うには不向き • gRPCを扱いにくいケースもある ◦ MFではRailsをクライアントとして、gRPCを利用 ◦ 型を意識しない世界に、厳密な型を持ち込むので扱いづらい Goを使う上で意識した方が良い点
28. • 各チームで似たような事をやっているが、知見が共有されていない ◦ Goがスモールチームで活用される傾向にある為 ▪ チーム間の交流が必要 ◦ MFでは、Goのライブラリ勉強会を2021年から開始 ▪ go-forwardという活動 Goを利用してみての課題感
29. • 他言語からのConvertに壁がある ◦ シンプルさが言語特有の癖 ◦ From Java/C#: 静的言語によくある仕様がない ▪ 例) 継承やGenerics ◦ From Rails: フルスタックなフレームワークから移るにはシンプルすぎる ◦ MFでは、他言語のエンジニア向けのGo勉強会を開催 ▪ 当時のエンジニアの4分の1が初回は参加 Goを利用してみての課題感
30. • Goの案件がスポット的 ◦ マイクロサービスでは、改修が入る頻度が少ない ◦ 現在はマイクロサービス移行を進行中なので、もう少し先の時間軸 ◦ 解決策の例 ▪ 日々増加していく機能要件ベースで、Goを扱う機会を作る ▪ 大型の基盤をGoで作っていく Goを利用してみての課題感
31. 今後のMFとGo
32. • 今後もマネーフォワードではGoを活用していきます ◦ マイクロサービス化は、今後の事業拡大を考えると必須 ◦ レイテンシ/可用性などGoが求められるケースは増えていく • 今後検討している取り組み ◦ 社内ライブラリの作成 ▪ Goの開発速度を上げる ▪ Go利用のハードルを下げる ◦ Goを扱う機会の創出 ▪ 新規サービスのバックエンドをGoで • CTOの中出が、Goの導入相談を開始 ▪ サービス基盤をGoで • 性能要件が求められるのでマッチする 今後のMFとGo
33. We are hiring! Goを使って、ユーザーの課題を解決したいエンジニアを募集中です！ カジュアル面談から是非
34. • Railsを読み、Goを書く。大規模SaaSのマイクロサービス化の（生々しい）実際をマネーフォ ワードに聞いてきた！ • マネーフォワードCTOが考えていること（2020年9月） 参考資料