コトダマンサーバーアプリのリアーキテクチャへの挑戦

Slide 1

Slide 1 text

©MIXI コトダマンサーバーアプリのリアーキテクチャへの挑戦 2023/07/19 田中恭友デジタルエンターテインメント事業本部コトダマン事業部エンジニアグループ

Slide 2

Slide 2 text

©MIXI 自己紹介田中恭友 (Kyosuke Tanaka) デジタルエンターテインメント事業本部コトダマン事業部エンジニアグループマネージャー 2018年4月　株式会社ミクシィ（現MIXI）新卒入社　　　　　　モンストドリームカンパニー　　　　　　サーバーサイドの新規開発・運用 2020年3月　コトダマン事業部に異動　　　　　　サーバーエンジニアとしてスクラムTで開発・運用 2022年9月　エンジニアマネージャー就任 2

Slide 3

Slide 3 text

©MIXI 自己紹介田中恭友 (Kyosuke Tanaka) デジタルエンターテインメント事業本部コトダマン事業部エンジニアグループマネージャー 2018年4月　株式会社ミクシィ（現MIXI）新卒入社　　　　　　モンストドリームカンパニー　　　　　　サーバーサイドの新規開発・運用 2020年3月　コトダマン事業部に異動　　　　　　サーバーエンジニアとしてスクラムTで開発・運用今日のLTはこの頃の話 2022年9月　エンジニアマネージャー就任 3

Slide 4

Slide 4 text

©MIXI 4 目次 1. 共闘ことばRPG コトダマンの紹介 2. コトダマン開発における課題 3. サーバーアプリケーションの技術負債 4. リアーキテクチャの狙い・戦略 5. 結果のふりかえり 6. まとめ

Slide 5

Slide 5 text

©MIXI 5 共闘ことばRPG コトダマン

Slide 6

Slide 6 text

©MIXI 6 共闘ことばRPG コトダマン「ことば」で闘う、スマートフォン向け新感覚ことば遊びゲーム

Slide 7

Slide 7 text

©MIXI 7 MIXI移管 2019年10月にミクシィ（現 MIXI）に運営移管引用元: 2019.08.09 https://www.sega.jp/topics/detail/190809_7/

Slide 8

Slide 8 text

©MIXI 8 2023年4月にリリース5周年を迎えましたタイトル移管以降も継続的に新機能の開発や改善を行い、 5周年を迎えた現在でも多くのユーザーさんにプレイいただいています

Slide 9

Slide 9 text

©MIXI 9 コトダマンの開発上の課題なぜリアーキテクチャに至ったのか

Slide 10

Slide 10 text

©MIXI 10 コトダマンのアーキテクチャ概要　APIサーバー　Java 8(Amazon Corretto) tomcat struts2 DB (Amazon Aurora) 　チャットサーバー　Java 8(Amazon Corretto) tomcat struts2 その他　　　　運用用途サーバーゲームクライアント（Unity製）マルチプレイサーバー　　　　　 monobit engine APIサーバー : ゲーム上の様々な処理を実現するためのAPIを提供（クエスト開始・ガチャ・etc…）今回のリアーキテクチャ対象

Slide 11

Slide 11 text

©MIXI 11 APIサーバーの課題 • APIサーバーの実装は複雑化し、保守が困難に（内部品質の低下） • 既存機能の改修時にエンバグが多発 • 開発速度の低下（既存実装の調査にコストがかかる） • 中には、エンバグを恐れて改修できない機能も...

Slide 12

Slide 12 text

©MIXI 12 内部品質低下の原因 • ドメインモデルの不在 • 手続き的に書き下されたビジネスロジック • メソッドに渡される大量のプリミティブ型の引数たち • ユニットテストの存在しない・後からかけないレガシーコード • 責務の分割されていない巨大メソッド • 状態を持つsingletonクラス（マスタデータや時刻の管理クラス）に依存せざるを得ない構造 • 制御されていない、縦横無尽の依存関係 • viewに依存したビジネスロジックが汎用性を低下 • ほとんど全てのusecaseが public static なメソッドの集合体として書かれている

Slide 13

Slide 13 text

©MIXI 13 組織的な原因 • 現状が辛いことはわかっていても、どう直せば良いかわからないメンバーも • 機能開発に追われて根本の改善が行えない状況 • バックログに技術負債解決のアイテムが載っていなかった • 10%ルールでは手に負えない規模の負債が散在 • 木こりのジレンマ

Slide 14

Slide 14 text

©MIXI 14 解決策を探る • PRレビューを重ねるだけではなかなか改善しない状況 • 過去実装に合わせた作り方を一新する必要があった • ある程度正しい「型」「指針」を作ることが必要だと感じた

Slide 15

Slide 15 text

©MIXI 15 解決策を探る • PRレビューを重ねるだけではなかなか改善しない状況 • 過去実装に合わせた作り方を一新する必要があった • ある程度正しい「型」「指針」を作ることが必要だと感じた → リアーキテクチャに着手することに決定

Slide 16

Slide 16 text

©MIXI 16 想定した技術負債の改善ロードマップリアーキテクチャビジネスサイドから理解を得る取り組みメンバーのスキルアップテストを書く文化モデリングのスキルレガシー実装の書き直し新規実装に負債のない（少ない）状態読書会の開催

Slide 17

Slide 17 text

©MIXI 17 サーバーアプリケーションのリアーキテクチャ具体事例の紹介

Slide 18

Slide 18 text

©MIXI 18 リアーキテクチャの狙い • ルールに従って実装しているうちに、オブジェクト指向らしい設計ができるようになること • ドメインモデルを作成・ビジネスロジックをモデルに集約することを強制しルールに従った実装をしているうちに学習が進むような設計であること • ルールを元にレビューが行えること • 設計の良し悪しを議論するための土台にできること • レビューコストを低下させること • 自動テストを書く文化を成熟させること • ルールに従って実装すればテスタブルな設計になること • 自動テストを必須とする部分・そうでない部分を分けて少なくともコアなロジックに自動テストを書くことを当たり前にする • TDDが自然と行われる下地を作る

Slide 19

Slide 19 text

©MIXI 19 新アーキテクチャ Presentation UseCase DAO Entity Response Request MasterData Model Service IRepository Repository Action ● オニオンアーキテクチャを参考にシンプルなアーキテクチャに設定 ● ビジネスロジックをModel層に集約することを狙う ● 依存の方向性を制御し、変動しやすいレイヤにコアロジックが依存しないようにする依存の方向性

Slide 20

Slide 20 text

©MIXI 20 Modelレイヤ　 Presentation UseCase DAO Entity Response Request MasterData Model Service IRepository Repository Action ● ビジネスロジックを受け持つ層 ○ DDDでいう値オブジェクトやエンティティをこのレイヤに置く ○ 例: User, Character, Gacha, Quest … etc ● Modelレイヤのクラス中の公開メソッドには原則単体テストを必須とする ○ 自動生成された getter は対象外

Slide 21

Slide 21 text

©MIXI 21 Serviceレイヤ　 Presentation UseCase DAO Entity Response Request MasterData Service IRepository Repository Action ● 複数のModelを利用してアプリケーションに必要な機能を実装するレイヤ ○ 複数のコンテキストで利用される、汎用的かつ複数のModelが関連する処理を置く ○ 例: ItemService（アイテムの付与） ● できる限りModelのみで実装を行うが、綺麗にまとまらない場合にはServiceを使う ● 旧実装（Tool）との繋ぎ込みを担う、腐敗防止層として利用されることもある Model

Slide 22

Slide 22 text

©MIXI 22 UseCaseレイヤ　 Presentation UseCase DAO Entity Response Request MasterData Service IRepository Repository Action ● アプリケーションの機能を実現するために、処理順序を規定するためのレイヤ ○ 例: ExchangeItemUseCase（アイテムを消費し、別のアイテムを獲得する） ● DIされたRepositoryを利用してModel / Serviceを取り出し、ビジネスロジックを順に実行 Model

Slide 23

Slide 23 text

©MIXI 23 Presentationレイヤ　 Presentation UseCase DAO Entity Response Request MasterData Service IRepository Repository Action ● ゲームクライアントとのやりとりを担うレイヤ ● クライアントからのリクエストに応じて必要なUseCaseを実行し、実行結果をクライアントの求める形式のレスポンスに変換し、返却する Model

Slide 24

Slide 24 text

©MIXI 24 Presentation Repository UseCase DAO Entity Response Request MasterData Service IRepository Repository Action ● DB上に永続化されたユーザーデータや、メモリ上にキャッシュされたマスタデータからModelを再構築する ● ビジネスロジックは持たず、Modelの永続化に集中する ● UseCaseから利用する場合にはインタフェースを介して依存性を逆転する Model

Slide 25

Slide 25 text

©MIXI 25 移行のフロー新アーキテクチャの提案・議論検証期間新アーキテクチャに則った実装を必須とせず、有志が新アーキテクチャで開発を進めていく実装中に出てきた疑問点について議論し、ルールを成長させる並行してオブジェクト指向設計に関する読書会も実施本実行：新規実装に関しては基本的に新アーキテクチャに則って開発する新アーキテクチャへの移行はチームの状況を見ながら緩やかに進めていきました

Slide 26

Slide 26 text

Slide 27

Slide 27 text

©MIXI 27 Keep • 新機能はアーキテクチャに則って実装されるようになった • レイヤ毎の依存関係が制御されるようになった • チーム内で設計に関する議論が活発に行われるようになった • GitHub Discussionsに議論の場を用意 • 普段の開発中に気になったことや提案を記録し、週次定例で繰り返し議論の場を設けるようになった • レビューがアーキテクチャを中心に行われるようになった • 共通認識を持てているので議論が捗る • テストを書く文化が生まれた • 新アーキテクチャ導入前のテストカバレッジ（Line） : 0.6% • 新アーキテクチャ導入後のテストカバレッジ（Line）: 12% • 新実装に限ると7割程度

Slide 28

Slide 28 text

©MIXI 28 Problem • ボイラーテンプレートコードによる実装スピードの低下 • 特にRepositoryの実装において頻発 • 曖昧なルールが混乱を呼んでしまった • 特にServiceの用途が理解されづらく、乱用されがちになった • 議論の結果決まったルールの集約が甘く、新メンバーのオンボーディングにかかるコストが増加した（新たな暗黙知の発生） →　デザインドキュメントを常に最新の状態に保つコスト　　設計意図をチーム内に浸透させるコストを惜しんではいけない • ユニットテスト自体のメンテナンス性はまだまだ課題が残る状態

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

©MIXI 32 まとめ • サーバーアプリケーションの内部品質向上・チームのスキルアップを目的として新アーキテクチャの導入を進めました • 新規機能を新アーキテクチャで実装しました • 実装スピードはやや低下したものの、テスタブルな設計になりました • チームもアプリケーションと共に成長しました • 事業部全体を巻き込んで既存機能の書き直しに動き出しつつあります • より多くの価値をユーザーに届けるためにこれからも技術負債の解決を進めていきます！