Go + Clean Architecture

Transcript

1. ミラティブのサーバサイドを Go + Clean Architectureで 再設計した話 2022.04.14 Sumihiko Natsu Mirrativ, Inc. © 2022 Mirrativ, Inc. STRICTLY CONFIDENTIAL
2. ▪ 夏 澄彦 ▪ 2015年 DeNA新卒入社 • 入社とほぼ同じタイミングで社内でMirrativプロジェクト始動 ▪ 事業部側のテックリード 兼 バックエンドの基盤開発 • つい先日Go 1.18を本番投入 自己紹介
3. Mirrativの技術コンポーネント 今日はこちらのお話
4. バックエンドから見たMirrativ ▪ 配信サービスとしてのMirrativ • 視聴者から配信へのギフト • 配信者へのコメント • おすすめ配信 ▪ SNSとしてのMirrativ • フォロー・フォロワー • チャット • タイムライン ▪ ゲームとしてのMirrativ • ランキング • ガチャ • ライブゲーム • リアルタイム性/即時性が高い • データ量が多い • アクセスの時間的局所性が高い
5. ▪ アーキテクチャが崩れかけている • MVC + Serviceだが、依存関係がスパゲッティ ▪ 膨れ上がるModel • データ型 + 永続化 + Presenter • SQLをORMにより、様々なレイヤーから発行される • 果てはViewからも。。。 • 負債が溜まったテーブルを再設計しづらい ▪ Contextという名のもとにあらゆるレイヤーから密結合を 黙認されているGodなクラス Clean Architectureへ移行しようとした背景 開発開始から6年半近く経過しているプロダクト
6. Clear Architectureを導入 ▪ 「コンポーネントの依存性を一方向にする」を最重要視 • 外側の実装を修正した際に内側への影響を最小化したい • 外側の依存性を内側に注入することで、モックを差し込みやすくしたい • 各レイヤーの責任と依存・入力・出力を明確化する ▪ まずは既存のPerlコードにClean Architectureを適用して、現実世界 の処理をレイヤリングできるか確認 ▪ 本家本元のClean Architectureとは異なる場合がありますが、ご了承 ください
7. Entity package entity type UserID uint64 type User struct { UserID UserID Name string } type Logger interface { Error(ctx context.Context, err error) Log(ctx context.Context, level LogLevel, label string, payload ...interface{}) } ▪ オブジェクトでビジネスロジックを表現する責務 ▪ Loggerのように全レイヤーから参照される interfaceなどもEntitiesに存在 • 実装はInfra層
8. UseCase Entity / Repositoryを使い、ユースケースを達成する責務 ▪ トランザクションのスコープを管理するのもお仕事の1つ package user type interactor struct { txm repository.TransactionManager repoUser repository.User } func (i interactor) UpdateRecommend(ctx context.Context, now time.Time) error { // おすすめユーザを計算 return i.txm.Do(ctx, func(ctx context.Context) error { return i.repoUser.UpdateRecommend(ctx, recommendUserIDs) }) }
9. Repository ▪ データの集約、永続化の責務 • 対応するDataSourceを活用し、UseCaseレイヤー が実際のテーブル構造などを把握しなくてもEntity の永続化を行える責務を負う ▪ データの整合性が取れる最小単位 • 例）MySQL側のDataSourceを更新したら、 Memcached側のDataSourceも更新 ▪ DataSourceで取得したデータをEntityに変換 ▪ CRUDなinterfaceを提供 • 命名規則もCreate/Read/Update/Deleteを強制
10. Repository package user type user struct { dsmemcachedRecommendUsers dsmemcached.RecommendUsers dsmysqlRecommendUser dsmysql.RecommendUser } func (r user) ReadRecommend(ctx context.Context) ([]entity.User, error) { // dsmemcachedRecommendUsersからおすすめユーザを取得 // なければdsmysqlUserから問い合わせ // 取得したDataSource固有の構造体をEntityへ変換 } func (r user) UpdateRecommend(ctx context.Context, userIDs []entity.UserID) error { // dsmysqlRecommendUserで更新してから、dsmemcachedRecommendUsersを更新 }
11. Repository Transaction ▪ 複数のDataSourceへのトランザクションを管理する責務 ▪ 複数のデータベースへの書き込みがある場合は、 すべての処理 が完了してからのcommitやエラー時のすべてのsql.Txの rollbackなどを抽象化 // commitとrollbackができるものをTransactionと定義 type Transaction interface { Commit(ctx context.Context) error Rollback(ctx context.Context) error } // 複数のTransactionを抽象化し、同一データベースへの Transactionはキャッシュ type Transactions interface { Get(key string, builder func() (Transaction, error)) (Transaction, error) // cache更新などrollbackできない処理を登録し、全てのcommitが成功した場合のみ実行 Succeeded(f func() error) } // トランザクションのスコープを管理するオブジェクト（ dry-run時は最後に全てrollback） type TransactionManager interface { Do(ctx context.Context, runner func(ctx context.Context) error) error }
12. DataSource ▪ Infraを活用し、Repositoryが要求するデータの取 得、永続化を達成する責務 • MySQLのtableや、Memcachedのkey、 Elasticsearchのtypeと1:1の関係 ▪ 該当するミドルウェア固有の操作名に沿った命名規則 type ds struct { infraMySQL infra.MySQL } func (ds ds) Update(ctx context.Context, users []*dsmysql.RecommendUserRow) error { txn, err := ds.infraMySQL.GetTxn(ctx, "BASE_W") // BASE_W はデータベース系統の名前 _, err = txn.ExecContext(ctx, "delete from recommend_user") _, err = txn.ExecContext(ctx, "insert into recommend_user ...") return err } func (ds ds) Select(ctx context.Context, limit int) ([]*dsmysql.RecommendUserRow, error) { return ds.selectRecommendUsers(ctx, limit, repository.DB_R) }
13. DataSource ▪ dsmysql.RecommendUserRow の構造体や selectRecommendUsers の処理などは、以下のような内製の テーブル定義から自動生成 • kyleconroy/sqlc をオマージュ ▪ このテーブル定義からDDLを生成し、 k0kubun/sqldef に食べ させることで、MySQLのマイグレーションなども実行 recommend_user: columns: - name: user_id type: uint64 foreign_key: user.user_id - name: score type: uint8 primary_keys: - user_id indexes: - columns: - score queries: - sql: select * from recommend_user order by score desc limit :limit
14. Infra ▪ ミドルウェアとの実際の接続や入出力などを担当 ▪ 内側のレイヤーが各ミドルウェアのI/Fを把握せず とも利用できる状態にする責務を負う type Transaction interface { repository.Transaction DB } type MySQL interface { // 複数系統のデータベースが存在するので aliasで指定する Get(ctx context.Context, alias string) (DB, error) Txn(ctx context.Context, txns repository.Transactions, alias string) (Transaction, error) } type DB interface { ExecContext(ctx context.Context, query string, args ...interface{}) (sql.Result, error) QueryContext(ctx context.Context, query string, args ...interface{}) (*sql.Rows, error) }
15. ▪ 外界からの入力をControllerへルーティングする責務 ▪ 時刻情報も外界の一部としてみなし、このレイヤー以外 では現在時刻を取得しないように制限 • これにより特別なライブラリを用いずともテストを決定的 にしたり、動作確認する際に任意の時刻への変更を行いや すくする Frameworks
16. ▪ HTTP RequestのURLなどを参照し、該当する ControllerへRequestを渡す • Sessionの解決やCSRFの検証などもこのレイヤー • RequestやResponseがOpenAPIの定義通りかどう かを検証 • 実行速度が犠牲になるので開発環境のみ Frameworks Web
17. ▪ queueベースで動作している非同期処理の場合 は、dequeueする処理とdequeueされたイベント をControllerをつなげる ▪ それ以外の非同期処理の場合は、指定された頻度 でControllerを実行する Frameworks Daemon
18. Controller package user type Controller struct { user inputport.User } func (c Controller) RecommendUsers(ctx context.Context, webCtx *web.Context) error { recommendUsers, err := c.user.ReadRecommendUsers(ctx) webCtx.RenderJSON(ctx, map[string]interface{}{ "users": presenters.Users(recommendUsers), }) return nil } ▪ 外界からの入力を、達成するユースケースが求める入力に変換 する責務 • HTTP Request内のパラメータを取り出したり、queueの中から必 要な情報を取り出して適切なInteractorに渡したり • また、ミラティブではInteractorから返ってきたEntityを Presenterで変換し、外界が求める出力に変更するのもController の責務
19. テスト戦略 ▪ 基本的なカバレッジ率の達成にはユニットテストを用い、統合テスト では正常系のユースケースのみ検証 ▪ CIでテストのカバレッジ率が90%以上であることを検証 • go tool cover で出力されるカバレッジ率ではなく、エラーハンドリング だったり、delegateのように引数を一切加工せずにフィールドに渡すだけ の関数は除外
20. ▪ stringer, gomock, quicktemplate, wireを利用 ▪ SQLからMySQL用のDataSourceのコードを生成 ▪ wireの定義も自動生成 ▪ Table Driven Test用のboilerplateも自動生成 Generator
21. ▪ golangci-lintをベースにいくつか内部で自作 ▪ 整数オーバーフローのチェック • 専用のutilityを利用するよう強制 ▪ 命名規則の強制・関数の順番（公開 => 非公開で辞書順） ▪ t.Parallelの強制 ▪ time.Now()の使用の制限 Lint
22. ▪ 新規機能はほぼGoで開発 ▪ 既存機能のGo移行が今後の課題 ▪ サービスや組織の成長に合わせて、生産性を最大化するためのより良 いアーキテクチャを模索し続けられるエンジニアを募集中！！ Go移行の進捗と今後の展望 Perl Go