マネーフォワード ME ブロックチェーン連携機能におけるGoの活用方法

Google Slide: https://docs.google.com/presentation/d/1w1oYTD31TqZbwufLXKOiWTy_mKWK04dDbagPL3ETCxg/edit?usp=sharing

Transcript

1. マネーフォワード ME ブロックチェーン連携機能にお けるGoの活用方法 Money Forward, Inc. uji
2. 【Gophers Talk】スポンサー4社による合同LT & カンファレンス感想戦 株式会社マネーフォワード CTO室 Web3グループ 大阪 2022/2 入社 ブロックチェーン領域のリサーチ Web3領域の新規プロダクトの開発に従事 Gopher 5年生 Kyoto.go 運営 Twitter @uji_rb uji Go Conference のセッションでも ブロックチェーンの話をしました
3. Today's goal 新規サービスでのGoの活用事例を共有し プロダクトにGoを利用している、またはしようとしている方に 技術選定の知見を提供する
4. ブロックチェーン領域でプログラミングが発生する場面は以下 • ブロックチェーン自体の開発 ◦ Go Conferenceで話しました https://docs.google.com/presentation/d/1TTw5Ff26Ze0oiDr2w-cDwXWD8NgGuI0ChI2iGeg4pu0/edit?usp=sharing • スマートコントラクト開発 • ブロックチェーンと接続するアプリ開発 今回はブロックチェーンと接続するアプリ開発の話
5. サービス紹介
7. マネーフォワード ME ブロックチェーン連携機能 ブロックチェーン上にある 暗号資産も可視化できるように 他の資産と同じように 日本円で資産が可視化される 対応チェーン
8. 開発の経緯 • オープンかつ公正で安心してお金を使える 「お金のプラットフォーム」を実現したい（会社のVISION） • ブロックチェーン技術やWeb3の文化には、 それを叶えるポテンシャルがあると考えている ◦ 透明性や対改ざん性、耐障害性など独自の価値がある • 仮説検証、目標の実現の最初の一歩として まずは暗号資産の資産管理に関するMVPを作成
9. アグリゲーション基盤が 異なる金融機関の複数の口座の情報を APIの利用やスクレイピングで取得し管理している マネーフォワード MEの仕組み マネーフォワード ME hoge銀行 fugaカード hogehogeマネー piyoポイント アグリゲーション基盤
10. 各種ブロックチェーン マネーフォワード ME ブロックチェーン連携 API ブロックチェーンの資産データを連携 するWeb APIをGoで実装 MEの口座連携基盤から ウォレットアドレスを受け取り、それに紐づく暗号資 産の残高を法定通貨に換算して返却する アグリゲーション基盤
11. 各種 ブロックチェーン マネーフォワード ME ブロックチェーン連携 アグリゲーション基盤 API CoinGecko 暗号資産価格API address addressに紐づく 暗号資産の残高を取得 各暗号資産の価格を取得 換算した資産情報を 返却
12. • アグリゲーション基盤からは 1アドレスにつき1日1回リクエストされる • ジョブスケジューラによってバックグラウンドで APIが利用されるため、多少レスポンスが遅くても ユーザーに影響が出ない • アグリゲーション基盤は別チームが運営しているため、 Open APIドキュメントで円滑に仕様を共有したい サービス要件
13. なぜGo？
14. 重要視したポイントは2つ • 開発の初速 ◦ ニーズが不明瞭のため、 ユーザーからの使われ方をなるべく早く検証したい ◦ MVPをなるはやで世の中に出す必要がある • 柔軟性 ◦ 開発したサービスは今後どうなるかわからない ▪ 機能要望が殺到、サービス終了、塩漬け、他チームに移譲、 etc… ◦ あらゆる事象に即座に対応できるようにしたい 設計方針
15. Goを選んだ理由（１） チームメンバー全員が慣れ親しんでいる言語だった • 単純に学習コストが減るので初速が上がる
16. ブロックチェーン領域のライブラリが充実 • Ethereum系チェーンを中心に、 ブロックチェーン自体の開発にも広く使われていることに起因 • ブロックチェーンと接続するサーバーサイドのアプリでは ライブラリの充実度からGoやNode.jsが使われる場合が多い Goを選んだ理由（２）
17. Simpleに重きをおいた設計・文化 • 複雑さを除外することで、変化に強くなる ◦ 必要となる前提知識が減り、学習コストが下がる ◦ 認知負荷が小さくなることで、変更しやすい （変更の影響がわかりやすい） • 本質的な部分の議論に集中できる ◦ レビューやペアプロの際に、重要でない細部の話に時間が取られない ◦ Simpleだからといってスピードが遅いわけでは無い Goを選んだ理由（３）
18. • チームメンバー全員が慣れ親しんでいる • ブロックチェーン領域のライブラリが充実 • Simpleに重きをおいた設計・文化 Goを選んだ理由
19. ライブラリ選定
20. Goのコミュニティでは、多機能なフレームワークよりも 小さく薄いライブラリが好まれる傾向がある • Go自体がSimpleを重視した言語なこともあり、 SimpleよりEasy重視なフレームワークを使う動機が弱い ◦ Easyを重視する場合、Goよりも良い選択肢がありそう • 「Goに入ってはGoに従え」 • ライブラリの選定においてもSimpleの評価基準をおくことで、 Goの恩恵を最大限に享受できる ライブラリ選定
21. Simpleな機能のライブラリを組み合わせて機能を実現することで • ライブラリに依存する実装が減り、柔軟性が生まれる • Go自体の仕様や慣習に関するノウハウが積み上がる ◦ フレームワーク固有の知識と比較すると再利用されやすい • 意識しないと行けないルールを最小限にできる ◦ 例: ディレクトリ構成、linterのルール ▪ フラットな状態で始めて、課題が出てきたタイミングで追加すれば良い ▪ フレームワークを利用していなくても、ルールを作り込みすぎると 複雑度はあがり、認知負荷がかえって高まってしまう 必要最低限の機能を持ち、インターフェースがGo標準に近いライブラリを利用 ライブラリ選定
22. ブロックチェーン連携で利用している主なライブラリ go-chi/chi net/httpをラップしたルーティングライブラリ deepmap/oapi-codegen OpenAPIドキュメントからGoコードを生成 volatiletech/sqlboiler DBスキーマからGoコードを生成 shopspring/decimal 固定小数点数を扱うパッケージ zap 構造化ログのライブラリ 1.21で標準に追加されるslogとインタフェースが近い hashicorp/go-retryablehttp リトライ機能つきHTTPクライアント ethereum/go-ethereum Ethereumの公式実装、サブパッケージに クライアントライブラリ ethclient がある wealdtech/go-ens ENSというEthereum上にあるアプリの APIクライアントライブラリethclientをラップしている ライブラリ選定
23. ライブラリ選定の反省 sqlboilerの利用は、 複雑さの増大に対して得られる利便性が見合わなかった （あくまでも今回のユースケースの話） • ある程度Simpleさを保ちつつ、初速を重視できる点から採用した ◦ sqlboiler派 vs 生SQLを書くライブラリ(sqlx, sqlc)派 の議論があった • 生成コードが結構なサイズで、内容の理解やトラブルの原因究明などで 結果的に時間がかかってしまった • 柔軟性に関しても、生SQLを書くライブラリの方が確保しやすい ◦ 生SQLを書くライブラリは、SQLを再利用できる
24. 相応しい言語やライブラリ・フレームワークは状況による ◦ プロダクトの要件や性質、フェーズ、チームの大きさや知識、思想など、あ らゆる項目を考慮しないといけない ▪ サービスを作り直す前提があるので、 SimpleよりEasyを重視している 言語やフレームワークを使って初速をあげる ▪ 利用者の多いサービスのリアーキテクチャのため、 初期の段階で高いパフォーマンスや秩序あるパッケージ構成を目指す 銀の弾丸は無い。 状況に応じて最適な意思決定をする必要がある さいごに
25. • Goを使ったシンプルさを重視した設計は、 開発の初速・柔軟性、両方に寄与する • ライブラリの選定においてもSimpleの評価基準をおくことで、Goの 恩恵を最大限に享受できる • 技術選定に銀の弾丸は無い。 状況に応じて最適な意思決定をする必要がある ©tottie / Renée French まとめ