10周年を迎えるモンストサーバコードの Ruby及びgemのアップデートにまつわるお話【MIXI TECH CONFERENCE 2023】

MIXI TECH CONFERENCE 2023
にてお話した岡住の資料です。

動画：https://youtu.be/LN28kB3eXXo
セッション詳細：https://techcon.mixi.co.jp/2023/d3-1

Transcript

1. ©MIXI 10周年を迎えるモンストサーバコードの Ruby及びgemのアップデートにまつわるお話 モンスト事業本部 ゲーム運営部 モンストサーバ1グループ 岡住 和樹
2. ©MIXI 自己紹介 岡住 和樹 2019年新卒入社 (4年目) モンスト事業本部 ゲーム運営部 モンストサーバ1グループ 機能開発、運用等を担当 2
3. ©MIXI はじめに 話すこと - 特定のバージョンに関係なく考慮・対応する必要のあった話 話さないこと - 具体的なRubyやgemのバージョンに関する話 3
4. ©MIXI はじめに 前半 - モンスターストライク (モンスト) について - サーバチームとサーバコード - APIサーバの構成とデプロイ体制 後半 - Ruby, gem のアップデートにまつわる話 - 様々な問題と工夫 - まとめ 4
5. ©MIXI モンスターストライクについて ひっぱりハンティングRPG 誰でも簡単に楽しめる爽快アクションRPG。一緒にいる友だちと最大4人ま で同時に遊べる協力プレイ（マルチプレイ）が特徴 2023年10月に、10周年を迎える 5
6. ©MIXI サーバチームとサーバコード 6
7. ©MIXI サーバチームとサーバコード 開発体制 - 開発・運用の両方を行う - 開発を支援する管理ツールなどの開発も行う - 10~15名程度 - オンコール対応 (2名、1週間ローテーション) - サーバコード本体 + 管理ツール etc… のモノレポ (GitHub) - 運用に関するツール類などは、別のモノレポで管理 7
8. ©MIXI サーバチームとサーバコード リポジトリの規模感 ※ コメント行、空行、自動生成コードを除く 8 リポジトリ全体 Ruby 約40万行 (約7000ファイル) 内、RSpec 約25万行 本体のコード (Controller, Model) Ruby 約7万行 RSpec 約18万行
9. ©MIXI サーバチームとサーバコード 次期バージョンへ向けた機能開発 ※ PR (GitHub Pull Request) 9 リリース頻度 - 1〜1.5ヶ月 - 次期バージョンに関係しないものは逐 次リリース リリースタイミング バージョンアップメンテナンス 1バージョンあたりの機能開発 PR数 50~100程度 ひと月にマージされる PR量 100~200程度
10. ©MIXI サーバチームとサーバコード コードカバレッジ - リポジトリ全体 約90% - 本体 95%以上 (94%のファイルがカバレッジ90%以上) - 計測しているが常に見ているわけではない - 普段から高めていこう！といった活動はしていない 10
11. ©MIXI サーバチームとサーバコード コードカバレッジ ただし・・・ - 足りないテストを見つけた時にPRを出す - 簡単な修正でも、可能であればテストは書く - 不具合の修正は、テストで再現させてから - コードレビュー時に、追加してほしいテストケースをコメントする (午後 のグループアサインの話もみてね) 11
12. ©MIXI APIサーバの構成とデプロイ体制 12
13. ©MIXI APIサーバの構成とデプロイ体制 APIサーバの構成 - Unicorn + Padrino + ActiveRecord - OSSをforkしたDB 垂直、水平分散ライブラリ - 数百台のオンプレマシン - App, DB, Memcached, Redis, Resque Worker, … - 様々なキャッシュ - Appサーバ(ローカルファイル、オンメモリ) - Memcached ※ 詳しくは https://mixil.mixi.co.jp/culture/16027#monsterstrike 13
14. ©MIXI APIサーバの構成とデプロイ体制 APIサーバの構成 14 App 数百台 Unicorn Worker 数万 DB 数百台 数万connection Memcached 100台弱 キャッシュ量 1TB 以上 ※ msgpackでシリアライズ済 App DB Redis (Queue) Memcached (Cache) Resque worker
15. ©MIXI APIサーバの構成とデプロイ体制 デプロイ体制 - 定時内なら基本的にいつでも本番デプロイ可能 - Capistranoによる手動デプロイ (コマンドを1つ実行する程度) - 容易なgemのアップデート、リファクタリングなどのコード変更は、この タイミングでデプロイ可能 15
16. ©MIXI Ruby, gem アップデートにまつわる話 16
17. ©MIXI Ruby, gem アップデートにまつわる話 基本方針 1. 各種gemのバージョンは、どのRubyバージョンまで対応しているのか を調査する 2. 調査結果に応じて、現状のRubyバージョンで上げれるところまでgem のバージョンを上げる 3. Rubyと同時に上げる必要のあるgemは、Rubyのバージョンアップと 同じタイミングで上げる 17
18. ©MIXI Ruby, gem アップデートにまつわる話 基本方針 ※ 緊急で対応が必要なものは担当者を決めることもある (先に誰かが動いてることの方が多い ) 18 担当者 明確には決まっていない (率先してやりたい人が担当 ) リリース前 (必ず) 開発環境で動作確認 (日々、多くの人が利用している ) リリース前 (必ずではない) Appサーバ1台〜数台 (全体の数％) にデプロイして動作確認 - 意図しないエラーが出ないか - リソースの変化を監視 etc… リリースタイミング - 日々のデプロイ - モンストのバージョンアップメンテナンス時
19. ©MIXI Ruby, gem アップデートにまつわる話 明確な担当者が決まっていない - 期日も決まっていない - 場合によっては、とても時間がかかる（1年ぐらいかかることも) 19
20. ©MIXI Ruby, gem アップデートにまつわる話 明確な担当者が決まっていない 少しでもモチベーションを維持するために・・・ - 少しでも進捗を出し続けれるように週一30分で進捗共有会をしてる - issueや社内ドキュメントに現状のことや、今後の方針を常にまとめて おく (あとから参加したい人が参加しやすいように) 20
21. ©MIXI 様々な出来事と工夫 21
22. ©MIXI 大きなgemのアップデート 大小様々な問題が起こる - 互換性のない記法 - 大量のエラーが発生する - 大量の警告 (warning) が発生する - 依存ライブラリが対応していない - そもそも、テストが実行できない etc… 大量のコード修正が必要になることも (100PR以上の修正・・・) 22
23. ©MIXI 大量のコード修正 何はともあれ、まずはテストが実行できるようにする - CIでテストを通過しないとPRはマージ出来ない - テストが通ればそれなりに動く状態を作れる (カバレッジのお陰) 23
24. ©MIXI 大量のコード修正 まずは、テストが実行できるようにする - エラーを修正していく - forkやパッチしているライブラリのコード修正 - テスト実行をプロファイリングして実行出来ない理由を探す - gemのコードを読む 24
25. ©MIXI 大量のコード修正 CIでテストを通過しないとPRはマージ出来ない - 実行するテストの範囲を指定する a. 実行範囲を絞る (例: Modelのみ) b. 落ちるテストの一覧を定義して、除外する c. 修正したら、除外リストから消してテストが実行されるようにする d. 修正PRを出す e. 修正が完了したら、実行範囲を広げていく 25 チームメンバーが修正PRを作りやすい状況を作る
26. ©MIXI 大量のコード修正 CIでテストを通過しないとPRはマージ出来ない - 次期バージョン開発に影響を及ぼす変更が必要になることもある 26 以前のバージョンと同様な振る舞いで、コードを書けるようにパッチを当てる （バージョンアップ完了後に撤去する）
27. ©MIXI 大量のコード修正 修正するコード量を減らす取り組み - 二度と開催されないコードの削除 (コラボなども含む) - 利用されていないコードの削除 - 依存gemを減らす Git管理されている & カバレッジが高い → 気軽に消すことができる 27
28. ©MIXI 大量のコード修正 コードカバレッジの向上 - 管理ツール系は、テストがほとんど書かれていなかった 28 - 最低限のテストを追加した - テストを書くようにコードレビューで声かけていく
29. ©MIXI 不具合の発見 多くの問題は、CIでテストを実行した際に発見される - それでもコーナーケースな不具合は発生する - 開発環境 で見つかることも多い 29 修正する際は、必ずテストを足す
30. ©MIXI キャッシュの問題 ライブラリのアップデートで、意図せずキャッシュキーが変わる - DBのReadが大量に増える - 場合によっては、DBが耐えられなくなる 30 キャッシュキーが変わらないようにモンキーパッチ
31. ©MIXI キャッシュの問題 アップデート前後でキャッシュの内容が読めなくなる - キャッシュしているオブジェクトの内容が変わったことが原因 31 事前に、前後で読める形式に変更する → 新形式でキャッシュをセット + 新・旧形式でキャッシュを読めるようにする
32. ©MIXI メンテナンス前後の不具合 一部APIは、メンテナンス実施前のバージョンでもリクエストが来る - サーバとゲームクライアントは、msgpackでやりとりしている - msgpackのアップデート時、互換性がなくエラーが多発した 32 前のバージョンでリクエストが来る可能性のある APIのみ互換性を残す修正をした
33. ©MIXI まとめ - テストの有無でアップデート難易度が大きく変わる - アップデートによって絶対に変わってはいけない挙動を把握しておく - アップデート前後の互換性を意識する - キャッシュキーが変更されていないか - etc… - 継続的にアップデートしていくための仕組みをつくる - チームメンバーが手伝いやすい状況をつくる - 消せるコードを消す - 起こった出来事を記録しておく - 次回のアップデートで参考になる 33
34. ©MIXI