サービスを長期的にGoで開発・運用していくためにやっていること

長期的にGoで開発・運用していくために考える必要のあることは
・アーキテクチャ設計
・コード設計
・実装方法検討
・技術・ライブラリ選定
・運用体制
・監視
・DevSecOps
・コスト最適化
その他、など多数ありますが、技術・ライブラリ選定の部分にフォーカスを当てて、3rd Party 技術の評価について考えていることを共有します。

Transcript

1. サービスを長期的にGoで開 発・運用していくために 岡本 洋輔
 @yoskeoka

2. 目次 • 自己紹介 • 会社紹介 • 長期的にGoで開発・運用していくために ◦ 3rd Party 技術の評価
3. • Engineer@Money Forward, Inc. • MFBC API推進部 • 京都拠点所属 • 最近よく書く言語 ◦ JavaScript/Go/YAML/HCL 我が家のGopherくんたち
4. Money Forward について
5. マネーフォワードの事業 『 統合報告書「Forward Map」2022』より引用
6. 開発体制
7. 開発チームごとにそれぞれのやり方でやっている
 自分の所属している開発チームの例
 • 構成: PdM, PO, デザイナー, エンジニア
 • エンジニアはFEからインフラまで一気通貫
 ◦ 各メンバーで得意領域は異なる 
 • スクラム開発を採用
 
 開発体制
8. • インフラ運用は社内のインフラ専任チームにある程度お任せしている
 ◦ 各サービスごとのAWS/k8sをプロビジョニングしてくれる社内基盤サービスがある 
 ◦ どんなリソースが必要かは開発チームが設計する必要がある 
 ◦ アプリケーションの運用責任は開発チームにある (AWSのように責任共有モデル )
 ◦ 社内インフラ基盤を紹介している blog記事
 ▪ https://moneyforward.com/engineers_blog/2021/12/28/next-service-platform/
 ▪ https://aws.amazon.com/jp/solutions/case-studies/moneyforward/
 • アプリケーションの利用技術はチームの裁量で決まる
 • デプロイワークフローはGitHub -> CircleCI -> k8s(EKS) が基本の流れ
 社内の開発基盤
9. 長期的に運用するサービ スを開発するために
10. API推進部では「Money ForwardはAPIが全然公開されていない」という課題を解 決するため、「Money Forward 法人向け」の全サービスが利用するAPI基盤サー ビスを開発しています。
 話の背景
11. 20以上のサービスがAPIを公開するときに利用してもらう重要基盤なので、運用が 始まったら長期で利用される前提！！
 話の背景
12. 長期間使われることを考慮しつつ、API基盤が整わなければ他サービスのAPI開 発が進まないので、基盤を最速で提供する必要がある 
 • 早く作りたいから、よくあるパーツはライブラリ等を利用しコード量は少なくした い
 • でも適当に選んでしまうとスタートから技術的負債をたくさん抱えた状態に 
 
 技術的負債は作った瞬間から発生するので、0にはできない。
 が、技術選定や設計で最小化する努力はするべき。
 こんなことを考えていました
13. • アーキテクチャ設計
 • コード設計
 • 実装方法検討
 • 技術・ライブラリ選定
 • 運用体制
 • 監視
 • DevSecOps
 • コスト最適化
 • その他、多数・・・
 長期的に開発・運用するために必要な要素 今回話すこと
14. 3rd Party 技術の評価
15. OSSや有償で技術を提供してくれているものが3rd Party技術
 
 インターネットの成長、ソースコード共有サービスの登場などを背景に、
 3rd Party技術の選択肢、ありがたいことに非常に沢山あります
 3rd Party 技術の評価
16. ありふれたアルゴリズム・技術要素なら標準も含め、ライブラリも複数あ る、でもどうやって選ぶ？
 • GitHub stars ⭐ が多いもの？
 • awesome-go に載っているもの？
 • 技術記事(medium, dev.to, Qiita, Zenn, etc..)に載っている？
 • Stack Overflow で教えてもらう？
 3rd Party 技術の評価
17. リストアップはしたとして、どのように比較する？
 Webサーバーのライブラリを例にしても大量にある。
 • net/http (Go standard library)
 • Gin (https://github.com/gin-gonic/gin)
 • Echo (https://github.com/labstack/echo)
 • Beego (https://github.com/beego/beego)
 • Revel (https://github.com/revel/revel)
 • その他多数・・・ 
 (2022/12月時点だと awesome-go の Web Frameworks には52個載ってる)
 
 3rd Party 技術の評価
18. 自分たちに合う技術・ライブラリかどうかは外野の評判ではなく、自分たちにとって のメリット・デメリットを比較する。
 • 必須機能を満たしているか
 ◦ 単体・または組み合わせで技術的課題を解決できるのか 
 • 便利機能や拡張性が、運用していくと役立ちそうか
 • ドキュメントの量やコミュニティによる技術記事は適量か
 ◦ コードベースが大きく難解なものであればあるほど、これらが充実していないと扱っていくの が難しい
 ◦ 逆に、コードベースが小さく、シンプルであればコードを読めば済む 
 ◦ チームの技術力によって相対的に変わる 
 3rd Party 技術の評価
19. 比較要素
 • メンテナンス体制は？
 ◦ メンテナは誰？個人？企業？コミュニティ？ 
 ◦ 色々なケースがあるので、どの体制が良いとは一概に言えない 
 ◦ 個別のライブラリについてメンテナンスの実態を把握しておきたい 
 3rd Party 技術の評価
20. 比較要素
 • メンテナンスの実態は？
 ◦ issueやPull Requestは対応されているか 
 ▪ バグ報告や機能提案の Feedbackを行ったときに対応されそうか 
 ▪ issueが立っていないなら、いずれ自分が作成する側になるが、選定段階で確 認するのは難しい・・・ 
 ◦ 必要に応じたリリースはされているか 
 ▪ 機能追加とかは無くていいので、セキュリティ Fixが迅速におこなわれるか 
 ▪ 毎年2回のGoの新バージョンリリースがあるので、互換性確認はされているか 
 • メンテされているなら CIのtarget version等に追加が発生する 
 3rd Party 技術の評価
21. 比較要素
 • コードは読みやすいか？
 ◦ Goはソースコードへのアクセスしやすい言語なのでドキュメントにない挙動の理解は ソースコードが頼りになる 
 ◦ 奇抜なことをせずに、素直に実装してあるコードが読みやすい 
 ◦ テストコードやExampleが充実していると読み解きやすい 
 • 自分たちの環境と共通点を持つところでの利用実績があるか
 ◦ システムの規模感など 
 ◦ ちょっと試してみた系のブログ記事は沢山あるかもしれないが、多大なワークロード に耐えられるかのベンチマークが必要 
 3rd Party 技術の評価
22. 比較要素
 • ライセンス
 ◦ Copyleft系ではないか? 
 ▪ 商用コードとしては意図しないライセンス汚染をされないようにしたい 
 ◦ 商用の場合のライセンスは？商用は別のデュアルライセンスではないか？ 
 ▪ その場合のコストは適正か 
 ◦ No Licenseではないか？
 ▪ ライセンス無しであれば、使ってはいけない 
 ▪ ソース公開されていても利用許諾してないことになる 
 ▪ どうしてもの場合は、メンテナにライセンス明記してくれと頼む 
 3rd Party 技術の評価
23. 比較要素
 • まずは小さく試してみる
 ◦ サンプルがあれば動かしてみる 
 ◦ プロトタイプとして使ってみたい箇所に組み込んでみる 
 
 評価の観点は色々あるけれど、カテゴリ毎に何十個と候補のあるGoのライブ ラリそれぞれについて丁寧に評価なんてしていられない！
 3rd Party 技術の評価
24. 色々な考えはあるけど、メンテされなくなったときのことも考えてみよう。
 これから新しい技術、ライブラリを使うということで新しいものに対するワクワ クが先行して、メリットばかりに目が行きがち。
 しかし、OSSでも商用サービスでも、いつかは終わりが来る。
 今はイケイケの流行っているライブラリでも、2年3年後にどうなっているかは わかりません。
 終わることも考慮
25. Webライブラリの例だと
 • net/http: メンテ◎
 • Gin: メンテ△ (issues/PR が溜まりすぎて処理できていない)
 • Echo: メンテ◎
 • Beego: メンテ◎
 • Revel: メンテ× (2019に入った頃からほとんど開発動いていない)
 ※個人の主観による判断です (2022/12時点)
 • Gorilla Toolkit (gorilla/mux等) メンテ終了しました😢
 ◦ https://github.com/gorilla/mux/issues/659
 ◦ 2022/12/10にメンテしないことが決定し、アーカイブされた 
 終わりは身近なところに
26. メンテされなくなり、メンテを引き継ぐことも出来なければ、ライブラリのライフサイク ルは終わりに向かう。
 メンテされていないものを使い続けることはできない。
 そのとき代わりを用意しやすいかの指標が「捨てやすさ」。
 
 
 
 「捨てやすさ」を評価
27. 捨てやすさのイメージ ・・・プログラムを構成するブロック ・・・捨てる必要が生じたプログラム 捨てやすい 捨てられない (運命共同体) 捨てづらい
28. 以下の観点で評価が高い場合、捨てやすいと判断できる
 • 解決したい課題を最小で解決してくれる
 • 適切な抽象化がされたinterfaceが公開されている
 • 標準ライブラリとの互換性や親和性が高い
 • メンテを引き継ぐことができるコードライセンスである
 
 
 
 具体的に捨てやすいとは
29. • 必要な箇所で必要なデータを渡せば、求める結果をくれる
 ◦ こちらのコードにそれ以上の干渉をしてこない 
 • フレームワークと呼ばれるものはその逆で、こちらのコードの書き方、設 計を変更することを求めてくる
 
 自分たちの失敗例:
 • wireがDI Frameworkだということを認識せずに導入し、コードの書き方が wireありきのも のになってしまった
 • wireの不満があっても、からみつく鉄線のごとく抜けるのにはひと苦労しそう 
 1. 解決したい課題を最小で解決してくれる
30. interfaceを接点として、既存コードへの影響を与えずに差し替えることができる。 
 
 例えば、io.Reader, io.Writerは適切な抽象化がされているので、メモリ、ストレー ジ、ネットワーク等を扱う様々なI/O系ライブラリが依存している。
 そのため、ストレージの読み書きに使うとあるライブラリを捨てて、別のものに入れ 替えるといったことが容易にできる。
 
 
 
 2. 適切な抽象化がされたinterfaceが公開されている
31. • 標準ライブラリで再実装することが容易になる
 ◦ Goがv1.0リリースから10年間、互換性を最大限保ってきたので、 Goの標準ライブラ リには安心して依存できる 
 • GoのGin, Echoといった軽量Webフレームワークはほとんどnet/httpと 1:1での書き換えが可能なため、メンテナンスされなくなったとしてもダ メージは少ない
 ◦ 逆にnet/httpでいいじゃないという Gopherが多い理由でもある 
 
 
 
 3. 標準ライブラリとの互換性や親和性が高い
32. 4. メンテを引き継ぐことができるコードライセンスである メンテがされなくなって、代わりを探すことも、自前での再実装も難しいような 重要なライブラリならば、引き継ぐしかない
 • 前のメンテナとかろうじて連絡が取れるならばメンテナにしてもらうことが できる
 ◦ メイン業務を持ちながらアクティブなメンテナを続けるのも難しいが・・・ 
 • ライセンスが改変、配布自由のいわゆるPublic Licenseであれば、自分 たちのorgにforkして必要なメンテナンスを続ける
 

33. 以下のようなライブラリは、捨てやすい
 • ライブラリの大きさが解決したい課題にフィットしてる
 • 依存関係をコントロールできる
 • 標準ライブラリをinterface互換で機能強化したもの
 以下のような場合は終わりが来ても継続して使える
 • 引き継げるライセンス体系
 具体的に捨てやすいとは
34. まとめ
35. まとめ サービスを長期的に開発・運用していくために・・・
 • 3rd Partyのライブラリを使うときは、利用できなくなるリスクにも目を向 けて、「捨てやすさ」も評価してみよう
 • 捨てる必要が生まれたときにプログラム全体が崩壊しないようにするた めに、依存関係がシンプルになるコード設計をしよう

37. おまけ
38. APIはこれだけやって初めて価値提供できたと言える
 • 0. APIの基盤を用意する
 • 1. APIの開発と公開 (社内の他サービスがそれぞれ提供する)
 • 2. APIを利用するアプリ開発または連携機能実装 (社内または社外)
 • 3. 連携機能を利用するユーザーが使う
 大元となる「0. APIの基盤」を早くリリースしないと、
 その後の価値提供に続かない󰝊💨
 API基盤を最速で提供する必要性
39. Ginがあまりメンテされていないというのはどうやって判断したのか？
 GitHubのOpenなissues/PRを確認
 https://github.com/gin-gonic/gin
 
 メンテあまりされていない例 475 issues の中には1年以上放置されているものも多数ある。
 それに対しアクティブなメンテナは2人。
 弊社内で、実際に使っていて困ったバグの issue/PRが存在しているが、1年ほど放置されている。

40. Revelがメンテされていないというのはどうやって判断したのか？
 
 メンテされていない例 GitHubのContribution Graphを確認
 https://github.com/revel/revel/graphs/contributors
 最初のメンテナが一通り作り上げて、停滞していたの を次の方が少しメンテナンスを続けていたが、今はほ ぼ触られていない。
 という状況が見える。

41. ホットリロードツールで freshやrealizeがよく使われていたが、もう何年もメン テされていない。(最近は代わりにairがよく使われるようになっている。)
 ※airはfreshがメンテされていないこと＆機能面の不満により作られたと READMEにて説明されている
 - https://github.com/cosmtrek/air
 メンテされていない例は沢山ある
42. 持ち直した例も
 gqlgenは一時期メンテする人がいなくなったが、「メンテされてないので は？」というissueをきっかけにコミュニティが復活した。
 • https://github.com/99designs/gqlgen/issues/1571
 メンテされなくなった後持ち直すことも
43. 捨てやすさを気にしない例外もある プロダクトの寿命が短期または長期化するか不明なときはその限りではない
 • PoCのとき
 ◦ なんでもいいので、まず動いて評価できないといけない 
 • 新サービスで勝負するとき
 ◦ まず動いて価値を届けることが必要