実例に学ぶGoのアーキテクチャ - 「開発スピード優先」でGMOペパボが採用したのはMVC

——MVCでは「モデル層の肥大化」がよく課題として挙げられます。開発していてこの課題に直面することはありますか。

田中　現状ではそこまで顕在化した課題ではありません。しかし、いずれは直面する問題だと思います。それよりもモデルとコントローラーでロジックの分離がうまくできていないことの方が、大きな課題です。これは元々Railsを経験しているエンジニアが多かったことが原因の一つとしてあります。

RailsはActive Recordがあることで「モデルのロジックはモデルに書く」とルールが明確です。GoでもORマッパーとしてGORMというActive Recordに近い機能を持ったライブラリがありRailsエンジニアにとって使いやすくなっています。メソッドチェーンのような書き方ができ、作業しやすくプロジェクト立ち上げ時にGORMは非常に便利です。

しかし、Railsと同じ要領でGORMをコントローラー層に書いてしまったことが失敗でした。コントローラーにモデルのロジックがある状態になってしまったのです。さらにコントローラーにモデルと同じようなテストを書かなければならないという問題もあります。

小田　GORMの使い方でよくなかったのはメソッドを乱立させてしまったところです。コントローラーのメソッドごとにモデルのメソッドも増えていってしまい、密結合な関係になってしまっていました。

こういったGORMの間違った使い方を改めるべく、過去にGoCon（Go Conference）で発表をしたことがあります。カンファレンスではなく、まずは社内で発表しろ、という感もありますが（笑）。一例を挙げると……

package api
func GetUserWithProfile(c echo.Context) error {
 n := c.Param("username")
 u, e := model.FindUserByUsernameWithProfile(n)
 if e != nil {
 return NewError(http.StatusNotFound, e, "not found")
 }
 return c.JSON(http.StatusOK, u))
}
package model
func FindUserByUsernameWithProfile(n string) (*User, error) {
 u := new(User)
 if err := db.Preload("Profile").Scopes(Enabled).Where("username = ?", n).First(u).Error; err != nil {
 return nil, err
 }
 return u, nil
}

過去、こうした記述がありましたが非常に冗長です。Goらしいシンプルさを保とうと考えると以下のような記述が望ましいです。

package api
func GetUserWithProfile(c echo.Context) error {
 n := c.Param("username")
 u := new(model.User)
 if err := db.Preload("Profile").Scopes(Enabled).Where("username = ?", n).First(u).Error; err != nil {
 return NewError(http.StatusNotFound, e, "not found")
 }
 return c.JSON(http.StatusOK, f)
}

田中　使い方の問題だけでなく、GORMはJOINする際、パフォーマンスを上げるのに手間がかかるという課題がありました。そしてパフォーマンスを改善するために、どんどん複雑なコードやクエリが増えていってしまう。特殊な使い方をしているうちにGORMの本来の使い方からどんどん離れていってしまっている感覚があり、これはよくないな、と。

GORMの課題に関しては、こちらの小田さんの発表資料に詳細がある。

——GORM自体がボトルネックになってしまったのですね。

小田　GORMは優れたライブラリなのですが、僕らのプロジェクトにはマッチしていなかったといまは考えられます。パフォーマンスを考慮するフェーズになってくると特にミスマッチが実感できました。本来、DB接続のためには標準パッケージを使用すれば十分でした。

田中　「とりあえずディファクトだからGORMにしておこう」という判断がよくありませんでした。やりたいことに対してGORMの機能が大きすぎたのです。

——そういった問題を解決するために、現在のプロジェクトで設計変更する予定はあるのでしょうか。

田中　ライブラリの使いにくさなど、細かく気になる部分はありますが、まだアーキテクチャレベルの改修をする時期にはなっていません。その時期が来たとしてもテストはカバレッジよくやっているので、設計変更があっても怖くはありません。

小田　リファクタリングや設計変更は利益を生み出すための作業ではないので、どうしても優先度は低くなってしまいます。また、抜本的な設計変更はメンバーが主体的に動きだしてから進むものでしょう。チームの誰かから意見が出たり、実際に設計変更にまつわるプルリクが出た際、自然と動きだしていくものだと思います。

——もし現状で設計変更をしていくのであればどのように改善していきますか？

小田　先ほども言ったようにDB接続はGORMではなく標準ライブラリを使います。また、モデル層は抽象化したいと思います。モデル層がなくなるとDDDに近い構成になりますが、あくまで抽象化するだけです。Goらしいシンプルな構成を保つことは前提として考えているので、DDDを完全に踏襲することはないと思います。

田中　Goらしくない書き方になってしまっている部分が多く、MVCとしても改善すべき点もあります。もっとGo wayに忠実な書き方に直していきたいです。

ディファクトに従うのではなく、必要とされるものを選ぶ

——もしも新しいプロジェクトを始めるとしたらMVCでまた設計をしますか。

小田　僕はしないと思います（笑）。いや、正確に表現すると、直面する問題を解決するために手を動かして「これがいい」と思えるものを選ぶでしょう。ただ、MVCですらGoにとっては冗長だと僕は考えています。悩みを減らすために構成はシンプルにしておき、コード量が増えたときに適切にパッケージを分けるだけでも十分な対応です。そして先ほども言ったようにテスタブルであることを意識しておけば、設計変更時のコストを低くできるでしょう。

——実際に触っていてMVCはGoと相性がいいと思いますか。

小田　MVCを試してみるのはありだと思いますが、やはり完璧に相性があっているとは言えません。同時に、多様なケースにフィットする万能アーキテクチャというものも存在しません。

プロジェクト内容やプロジェクトメンバーの習熟度、どの程度の開発期間が用意できるか、など条件次第で設計は変わると思います。手を動かして自分たちに合うかどうか確認するのが大切です。

——逆にMVCにしておいてよかった点はありますか。

田中　やはり構成が分かりやすく、敷居が低い点は強みです。MVCによる開発スピードの高さは実感できています。しかし、今後の3～4年を考えるとコードの肥大化など、現状の設計では課題が見えてくる可能性があります。

——Goの設計は様々なものが提唱されていますが、これからディファクトは生まれると思いますか。

小田　むしろ、ディファクトがない状態が良いと僕は思っています。ディファクトに従うことが、直面する問題解決につながるとは限らず、ときに僕らの抱えているGORMのボトルネック問題のように、思わぬ課題をもたらすこともあります。

フレームワークやツールが多数投入されることで生じる開発の複雑化は、Goらしいシンプルさを実現するうえで、避けるべき状況です。すぐに書き始めることができるGoの利点を活かすためには、ディファクトがない状態の方が自然なのでは、と感じています。

——今後、プロジェクトで実現したいことはありますか。

田中　書き方がGoらしくないものを書き換えていきたいです。Go wayに沿った書き方をするだけでも、いま抱えている設計上の問題はかなり解消されると思います。

小田　サービスを分離し、「小さく作る」ことを目指したいです。モノリシックになっている部分を、細かくマイクロサービス化していくイメージです。小さく分けることでプロジェクトのディレクトリ構造の複雑化も避けられ、よりシンプルにGoを活用できると思います。

取材：megaya　{$image_5}megayaのブログ