コトダマンサーバーアプリのリアーキテクチャへの挑戦

「技術的負債、どうやって解消した？リアーキテクチャ・リファクタ事例から学ぶLunch LT」の登壇資料です
https://findy.connpass.com/event/288877/

Transcript

1. ©MIXI コトダマンサーバーアプリの リアーキテクチャへの挑戦 2023/07/19 田中 恭友 デジタルエンターテインメント事業本部 コトダマン事業部 エンジニアグループ
2. ©MIXI 自己紹介 田中恭友 (Kyosuke Tanaka) デジタルエンターテインメント事業本部 コトダマン事業部 エンジニアグループ マネージャー 2018年4月　株式会社ミクシィ（現MIXI）新卒入社 　　　　　　モンストドリームカンパニー 　　　　　　サーバーサイドの新規開発・運用 2020年3月　コトダマン事業部に異動 　　　　　　サーバーエンジニアとしてスクラムTで開発・運用 2022年9月　エンジニアマネージャー就任 2
3. ©MIXI 自己紹介 田中恭友 (Kyosuke Tanaka) デジタルエンターテインメント事業本部 コトダマン事業部 エンジニアグループ マネージャー 2018年4月　株式会社ミクシィ（現MIXI）新卒入社 　　　　　　モンストドリームカンパニー 　　　　　　サーバーサイドの新規開発・運用 2020年3月　コトダマン事業部に異動 　　　　　　サーバーエンジニアとしてスクラムTで開発・運用 今日のLTはこの頃の話 2022年9月　エンジニアマネージャー就任 3
4. ©MIXI 4 目次 1. 共闘ことばRPG コトダマンの紹介 2. コトダマン開発における課題 3. サーバーアプリケーションの技術負債 4. リアーキテクチャの狙い・戦略 5. 結果のふりかえり 6. まとめ
5. ©MIXI 5 共闘ことばRPG コトダマン
6. ©MIXI 6 共闘ことばRPG コトダマン 「ことば」で闘う、スマートフォン向け新感覚ことば遊びゲーム
7. ©MIXI 7 MIXI移管 2019年10月にミクシィ（現 MIXI）に運営移管 引用元: 2019.08.09 https://www.sega.jp/topics/detail/190809_7/
8. ©MIXI 8 2023年4月にリリース5周年を迎えました タイトル移管以降も継続的に新機能の開発や改善を行い、 5周年を迎えた現在でも多くのユーザーさんにプレイいただいています
9. ©MIXI 9 コトダマンの開発上の課題 なぜリアーキテクチャに至ったのか
10. ©MIXI 10 コトダマンのアーキテクチャ概要 　APIサーバー 　Java 8(Amazon Corretto) tomcat struts2 DB (Amazon Aurora) 　チャットサーバー 　Java 8(Amazon Corretto) tomcat struts2 その他 　　　　運用用途サーバー ゲームクライアント （Unity製） マルチプレイサーバー 　　　　　 monobit engine APIサーバー : ゲーム上の様々な処理を実現するためのAPIを提供（クエスト開始・ガチャ・etc…） 今回のリアーキテクチャ対象
11. ©MIXI 11 APIサーバーの課題 • APIサーバーの実装は複雑化し、保守が困難に（内部品質の低下） • 既存機能の改修時にエンバグが多発 • 開発速度の低下（既存実装の調査にコストがかかる） • 中には、エンバグを恐れて改修できない機能も...
12. ©MIXI 12 内部品質低下の原因 • ドメインモデルの不在 • 手続き的に書き下されたビジネスロジック • メソッドに渡される大量のプリミティブ型の引数たち • ユニットテストの存在しない・後からかけないレガシーコード • 責務の分割されていない巨大メソッド • 状態を持つsingletonクラス（マスタデータや時刻の管理クラス）に 依存せざるを得ない構造 • 制御されていない、縦横無尽の依存関係 • viewに依存したビジネスロジックが汎用性を低下 • ほとんど全てのusecaseが public static な メソッドの集合体として書かれている
13. ©MIXI 13 組織的な原因 • 現状が辛いことはわかっていても、どう直せば良いかわからないメンバーも • 機能開発に追われて根本の改善が行えない状況 • バックログに技術負債解決のアイテムが載っていなかった • 10%ルール では手に負えない規模の負債が散在 • 木こりのジレンマ
14. ©MIXI 14 解決策を探る • PRレビューを重ねるだけではなかなか改善しない状況 • 過去実装に合わせた作り方を一新する必要があった • ある程度正しい「型」「指針」を作ることが必要だと感じた
15. ©MIXI 15 解決策を探る • PRレビューを重ねるだけではなかなか改善しない状況 • 過去実装に合わせた作り方を一新する必要があった • ある程度正しい「型」「指針」を作ることが必要だと感じた → リアーキテクチャに着手することに決定
16. ©MIXI 16 想定した技術負債の改善ロードマップ リアーキテクチャ ビジネスサイドから理解を得る取り組み メンバーのスキルアップ テストを書く文化 モデリングのスキル レガシー実装の 書き直し 新規実装に 負債のない （少ない）状態 読書会の開催
17. ©MIXI 17 サーバーアプリケーションのリアーキテクチャ 具体事例の紹介
18. ©MIXI 18 リアーキテクチャの狙い • ルールに従って実装しているうちに、 オブジェクト指向らしい設計ができるようになること • ドメインモデルを作成・ビジネスロジックをモデルに集約することを強制し ルールに従った実装をしているうちに学習が進むような設計であること • ルールを元にレビューが行えること • 設計の良し悪しを議論するための土台にできること • レビューコストを低下させること • 自動テストを書く文化を成熟させること • ルールに従って実装すればテスタブルな設計になること • 自動テストを必須とする部分・そうでない部分を分けて 少なくともコアなロジックに自動テストを書くことを当たり前にする • TDDが自然と行われる下地を作る
19. ©MIXI 19 新アーキテクチャ Presentation UseCase DAO Entity Response Request MasterData Model Service IRepository Repository Action • オニオンアーキテクチャを参考にシンプルなアーキテクチャに設定 • ビジネスロジックをModel層に集約することを狙う • 依存の方向性を制御し、変動しやすいレイヤにコアロジックが依存しないようにする 依存の方向性
20. ©MIXI 20 Modelレイヤ　 Presentation UseCase DAO Entity Response Request MasterData Model Service IRepository Repository Action • ビジネスロジックを受け持つ層 ◦ DDDでいう値オブジェクトやエンティティをこのレイヤに置く ◦ 例: User, Character, Gacha, Quest … etc • Modelレイヤのクラス中の公開メソッドには原則単体テストを必須とする ◦ 自動生成された getter は対象外
21. ©MIXI 21 Serviceレイヤ　 Presentation UseCase DAO Entity Response Request MasterData Service IRepository Repository Action • 複数のModelを利用してアプリケーションに必要な機能を実装するレイヤ ◦ 複数のコンテキストで利用される、汎用的かつ複数のModelが関連する処理を置く ◦ 例: ItemService（アイテムの付与） • できる限りModelのみで実装を行うが、綺麗にまとまらない場合にはServiceを使う • 旧実装（Tool）との繋ぎ込みを担う、腐敗防止層として利用されることもある Model
22. ©MIXI 22 UseCaseレイヤ　 Presentation UseCase DAO Entity Response Request MasterData Service IRepository Repository Action • アプリケーションの機能を実現するために、処理順序を規定するためのレイヤ ◦ 例: ExchangeItemUseCase（アイテムを消費し、別のアイテムを獲得する） • DIされたRepositoryを利用してModel / Serviceを取り出し、ビジネスロジックを順に実行 Model
23. ©MIXI 23 Presentationレイヤ　 Presentation UseCase DAO Entity Response Request MasterData Service IRepository Repository Action • ゲームクライアントとのやりとりを担うレイヤ • クライアントからのリクエストに応じて必要なUseCaseを実行し、 実行結果をクライアントの求める形式のレスポンスに変換し、返却する Model
24. ©MIXI 24 Presentation Repository UseCase DAO Entity Response Request MasterData Service IRepository Repository Action • DB上に永続化されたユーザーデータや、メモリ上にキャッシュされたマスタデータからModelを再構築する • ビジネスロジックは持たず、Modelの永続化に集中する • UseCaseから利用する場合にはインタフェースを介して依存性を逆転する Model
25. ©MIXI 25 移行のフロー 新アーキテクチャの提案・議論 検証期間 新アーキテクチャに則った実装を必須とせず、 有志が新アーキテクチャで開発を進めていく 実装中に出てきた疑問点について議論し、ルールを成長させる 並行してオブジェクト指向設計に関する読書会も実施 本実行：新規実装に関しては基本的に新アーキテクチャに則って開発する 新アーキテクチャへの移行はチームの状況を見ながら緩やかに進めていきました
26. ©MIXI 26 結果のふりかえり
27. ©MIXI 27 Keep • 新機能はアーキテクチャに則って実装されるようになった • レイヤ毎の依存関係が制御されるようになった • チーム内で設計に関する議論が活発に行われるようになった • GitHub Discussionsに議論の場を用意 • 普段の開発中に気になったことや提案を記録し、週次定例で繰り返し議論の場を設けるようになった • レビューがアーキテクチャを中心に行われるようになった • 共通認識を持てているので議論が捗る • テストを書く文化が生まれた • 新アーキテクチャ導入前のテストカバレッジ（Line） : 0.6% • 新アーキテクチャ導入後のテストカバレッジ（Line）: 12% • 新実装に限ると7割程度
28. ©MIXI 28 Problem • ボイラーテンプレートコードによる実装スピードの低下 • 特にRepositoryの実装において頻発 • 曖昧なルールが混乱を呼んでしまった • 特にServiceの用途が理解されづらく、乱用されがちになった • 議論の結果決まったルールの集約が甘く、 新メンバーのオンボーディングにかかるコストが増加した（新たな暗黙知の発生） →　デザインドキュメントを常に最新の状態に保つコスト 　　設計意図をチーム内に浸透させるコストを惜しんではいけない • ユニットテスト自体のメンテナンス性はまだまだ課題が残る状態
29. ©MIXI 29 これからの取り組み
30. ©MIXI 30 これからの取り組み • 組織体制の変更も含めた改善を推進 • 改善を推し進めるチームとしてSREチームを組成 • インフラ・CI/CDを中心に改善を推進中 • ビジネスサイドの理解を得て、レガシーな過去実装の再実装を検討中
31. ©MIXI 31 技術負債の改善ロードマップ（再掲） リアーキテクチャ ビジネスサイドから理解を得る取り組み メンバーのスキルアップ テストを書く文化 モデリングのスキル レガシー実装の 書き直し 新規実装に 負債のない （少ない）状態 読書会の開催
32. ©MIXI 32 まとめ • サーバーアプリケーションの内部品質向上・チームのスキルアップを目的として 新アーキテクチャの導入を進めました • 新規機能を新アーキテクチャで実装しました • 実装スピードはやや低下したものの、テスタブルな設計になりました • チームもアプリケーションと共に成長しました • 事業部全体を巻き込んで既存機能の書き直しに動き出しつつあります • より多くの価値をユーザーに届けるために これからも技術負債の解決を進めていきます！
33. ©MIXI