Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

ysakura_
March 03, 2021

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

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

ysakura_

March 03, 2021
Tweet

More Decks by ysakura_

Other Decks in Technology

Transcript

  1. • 名前: 櫻 勇人(さくら ゆうと) • Twitter: ysakura_ • 関西開発本部

    テクニカルアーキテクトグループ リーダー • 複数の新規プロダクトで インフラとマイクロサービスの構築を担当 • 性能問題の解決を主とし 『マネーフォワード クラウド会計Plus』の技術改善に従事 • Go歴: 3年 • MFでは約2年、Goでマイクロサービス 自己紹介
  2. • 複数のドメインでプロダクトを展開 • 開発言語 ◦ Railsのプロダクトが多い ◦ Java: 社内の基盤サービス ◦

    Go: マイクロサービス • インフラ ◦ さくらインターネットからスタート ◦ 新規プロダクトはAWS ◦ さくら to AWSの移行も マネーフォワードの紹介 FY20 通期決算説明資料より引用
  3. • マネーフォワード クラウド会計Plus ◦ 櫻の担当プロダクト ◦ 上場企業向けの会計ソフト ▪ データ量が多いのが特徴 ◦

    監査向けに承認機能や履歴機能を提供 ◦ WebのメインシステムはRuby on Rails ◦ 一部をGoでマイクロサービス化 マネーフォワードの紹介
  4. 今日話すこと • MFにおけるGoの事例 • マイクロサービス化の背景 • Goを選んだ理由 • マイクロサービスでGoを活用してみて ◦

    Goで良かった点 ◦ Goを使う上で意識した方が良い点 ◦ Goを利用してみての課題感 • 今後のMFとGo
  5. MFにおけるGoの事例 • マイクロサービス ◦ 今回のメイントピック • ツール ◦ インフラ系が多い ◦

    簡単な言語仕様 ▪ サクッと作れる ▪ 利用者に改善して貰いやすい
  6. • これまではRailsのモノリシックなアプリケーション ◦ 大きなサービスでは、数十人で開発している • 徐々にリリース速度が低下 ◦ メンバー数の増加 ◦ コードの複雑性の増加

    • 開発速度を維持したまま、組織をスケールさせたい ◦ マイクロサービス化を進行中 • ※ 複雑度が低いうちは、モノリスの方が生産性が高い 組織スケールの問題 出典 https://martinfowler.com/bliki/MicroservicePremium.html
  7. • 現状の技術スタックでは満たせない非機能要件が出てきた ◦ MFのユーザー数の増加 ◦ 新しいターゲット層 ▪ 会計Plusでは上場企業を対象に • 非機能要件を満たせる技術選択をしたい

    ◦ マイクロサービスで疎結合にして、独自の技術選択を可能に ▪ 別言語のサーバー ▪ 独自のストレージ 性能問題の解決
  8. • マイクロサービス化の要件 ◦ 高速な言語 ◦ 静的型付けの言語 • Goを選んだ理由 ◦ 要件を満たせる

    ◦ Dockerとの相性が良い ◦ モチベーションの高いメンバーの存在 ◦ 採用市場の変化 Goを選んだ理由
  9. • 要件を満たせる ◦ この段階ではC#やJavaも候補になる • Dockerとの相性が良い ◦ Goはイメージサイズが小さい ▪ コンパイルしたバイナリを置くだけ

    ▪ Javaの様に仮想環境を必要としない ◦ MFでは、ECS/EKSでコンテナ化が進んでいるのでマッチした • モチベーションの高いメンバーの存在 ◦ 社内に経験者やGoを扱いたいエンジニアがいた Goを選んだ理由
  10. Goを選んだ理由 • 採用市場の変化 ◦ Goが流行っている ▪ ”今”の技術選択においてはGoは有力な選択肢の1つ • 採用のしやすさ •

    エンジニアのモチベーション • 情報のアクセスしやすさ ◦ 参考: 当社CTO中出の発信 ▪ マネーフォワードCTOが考えていること(2020年9月)
  11. • ハイパフォーマンス ◦ 数十分かかる処理が10分の1, 場合によっては100分の1に • 並行処理が扱いやすい ◦ 'g', 'o',

    ' 'の3文字を打つだけでgoroutineが起動する ◦ OSの違いを意識する必要がない ◦ 性能が求められるケースでは大きなメリット Goで良かった点
  12. • 言語仕様がシンプルゆえにコード量が多くなる ◦ 自前で実装する、もしくは、ライブラリのキャッチアップを意識する ◦ 下手をすると可読性の低いコードが生まれてしまう • goroutine leakには気をつける ◦

    goroutineが終了せずに、goroutine内部の変数がメモリを浪費しOOM ▪ 解決策の例 • context.Contextを用いて、タイムアウトや強制終了を可能にす る Goを使う上で意識した方が良い点
  13. • Goが最適な技術とは限らない ◦ JavaやC#の方が言語仕様はリッチ ◦ RESTfulなWebサーバーをスピーディーに作りたい ▪ Railsの方が良い ◦ フロントエンドを扱うには不向き

    • gRPCを扱いにくいケースもある ◦ MFではRailsをクライアントとして、gRPCを利用 ◦ 型を意識しない世界に、厳密な型を持ち込むので扱いづらい Goを使う上で意識した方が良い点
  14. • 他言語からのConvertに壁がある ◦ シンプルさが言語特有の癖 ◦ From Java/C#: 静的言語によくある仕様がない ▪ 例)

    継承やGenerics ◦ From Rails: フルスタックなフレームワークから移るにはシンプルすぎる ◦ MFでは、他言語のエンジニア向けのGo勉強会を開催 ▪ 当時のエンジニアの4分の1が初回は参加 Goを利用してみての課題感
  15. • 今後もマネーフォワードではGoを活用していきます ◦ マイクロサービス化は、今後の事業拡大を考えると必須 ◦ レイテンシ/可用性などGoが求められるケースは増えていく • 今後検討している取り組み ◦ 社内ライブラリの作成

    ▪ Goの開発速度を上げる ▪ Go利用のハードルを下げる ◦ Goを扱う機会の創出 ▪ 新規サービスのバックエンドをGoで • CTOの中出が、Goの導入相談を開始 ▪ サービス基盤をGoで • 性能要件が求められるのでマッチする 今後のMFとGo