ミラティブのサーバサイドを Go + Clean Architectureで 再設計した話 2022.04.14 Sumihiko Natsu Mirrativ, Inc. © 2022 Mirrativ, Inc. STRICTLY CONFIDENTIAL

■ 夏 澄彦 ■ 2015年 DeNA新卒入社 ● 入社とほぼ同じタイミングで社内でMirrativプロジェクト始動 ■ 事業部側のテックリード 兼 バックエンドの基盤開発 ● つい先日Go 1.18を本番投入 自己紹介

Mirrativの技術コンポーネント 今日はこちらのお話

バックエンドから見たMirrativ ■ 配信サービスとしてのMirrativ ● 視聴者から配信へのギフト ● 配信者へのコメント ● おすすめ配信 ■ SNSとしてのMirrativ ● フォロー・フォロワー ● チャット ● タイムライン ■ ゲームとしてのMirrativ ● ランキング ● ガチャ ● ライブゲーム ● リアルタイム性/即時性が高い ● データ量が多い ● アクセスの時間的局所性が高い

■ アーキテクチャが崩れかけている ● MVC + Serviceだが、依存関係がスパゲッティ ■ 膨れ上がるModel ● データ型 + 永続化 + Presenter ● SQLをORMにより、様々なレイヤーから発行される ● 果てはViewからも。。。 ● 負債が溜まったテーブルを再設計しづらい ■ Contextという名のもとにあらゆるレイヤーから密結合を 黙認されているGodなクラス Clean Architectureへ移行しようとした背景 開発開始から6年半近く経過しているプロダクト

Clear Architectureを導入 ■ 「コンポーネントの依存性を一方向にする」を最重要視 ● 外側の実装を修正した際に内側への影響を最小化したい ● 外側の依存性を内側に注入することで、モックを差し込みやすくしたい ● 各レイヤーの責任と依存・入力・出力を明確化する ■ まずは既存のPerlコードにClean Architectureを適用して、現実世界 の処理をレイヤリングできるか確認 ■ 本家本元のClean Architectureとは異なる場合がありますが、ご了承 ください

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層

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) }) }

Repository ■ データの集約、永続化の責務 ● 対応するDataSourceを活用し、UseCaseレイヤー が実際のテーブル構造などを把握しなくてもEntity の永続化を行える責務を負う ■ データの整合性が取れる最小単位 ● 例）MySQL側のDataSourceを更新したら、 Memcached側のDataSourceも更新 ■ DataSourceで取得したデータをEntityに変換 ■ CRUDなinterfaceを提供 ● 命名規則もCreate/Read/Update/Deleteを強制

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を更新 }

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 }

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) }

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

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) }

■ 外界からの入力をControllerへルーティングする責務 ■ 時刻情報も外界の一部としてみなし、このレイヤー以外 では現在時刻を取得しないように制限 ● これにより特別なライブラリを用いずともテストを決定的 にしたり、動作確認する際に任意の時刻への変更を行いや すくする Frameworks

■ HTTP RequestのURLなどを参照し、該当する ControllerへRequestを渡す ● Sessionの解決やCSRFの検証などもこのレイヤー ● RequestやResponseがOpenAPIの定義通りかどう かを検証 ● 実行速度が犠牲になるので開発環境のみ Frameworks Web

■ queueベースで動作している非同期処理の場合 は、dequeueする処理とdequeueされたイベント をControllerをつなげる ■ それ以外の非同期処理の場合は、指定された頻度 でControllerを実行する Frameworks Daemon

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 の責務

テスト戦略 ■ 基本的なカバレッジ率の達成にはユニットテストを用い、統合テスト では正常系のユースケースのみ検証 ■ CIでテストのカバレッジ率が90%以上であることを検証 ● go tool cover で出力されるカバレッジ率ではなく、エラーハンドリング だったり、delegateのように引数を一切加工せずにフィールドに渡すだけ の関数は除外

■ stringer, gomock, quicktemplate, wireを利用 ■ SQLからMySQL用のDataSourceのコードを生成 ■ wireの定義も自動生成 ■ Table Driven Test用のboilerplateも自動生成 Generator

■ golangci-lintをベースにいくつか内部で自作 ■ 整数オーバーフローのチェック ● 専用のutilityを利用するよう強制 ■ 命名規則の強制・関数の順番（公開 => 非公開で辞書順） ■ t.Parallelの強制 ■ time.Now()の使用の制限 Lint

■ 新規機能はほぼGoで開発 ■ 既存機能のGo移行が今後の課題 ■ サービスや組織の成長に合わせて、生産性を最大化するためのより良 いアーキテクチャを模索し続けられるエンジニアを募集中！！ Go移行の進捗と今後の展望 Perl Go