運用中の大規模オンラインゲームで8年ぶりにPHPバージョンアップをした話

Transcript

2. 2 2012年 KLab株式会社 に入社
 2016年からBLEACH Brave Soulsにサーバサイドエンジニアとして参画。
 2021年からサーバチームのリーダーをしています。
 
 前職は、金融システムや物流管理のシステムを作っていました。
 
 福田 陽介
 エンジニア
 KLabGames事業本部
 KLab株式会社
 画像

3. 3 今日話すこと
 • 前提説明（ゲームの説明・バージョンアップの理由）
 • 開発方針（修正箇所洗い出し・ブランチについて）
 • 後回しにしたこと
 • 運用中プロジェクトでPHP8.1切り替えをどう進行したか
 • バージョン移行後に起こったトラブル
 • 数値で見る実績と効果
 • まとめ

4. 4 前提説明

5. 5 BLEACH Brave Soulsとは
 『BLEACH』を題材とした3Dアクションゲームです。 
 登場する人気キャラクターを操作し、
 本格的で爽快なアクションを楽しむ事ができます。
 

6. 6 サービスの特徴
 • 2015-07-23にリリースされ、8周年を迎えた
 • リクエスト数：1000 - 7000 rps
 • アップデート周期：1〜2ヶ月に1度、機能追加を実施
 • ゲームサーバ、運用ツール、バッチがPHPで実装されている
 BLEACH Brave Soulsとは

7. 7 • バージョンアップ前のPHPバージョンは
 ◦ 5.5.13
 ▪ 2014-01-26 リリース
 ▪ EOLは 2016-07-10
 なぜPHPバージョンアップをしたかったか？

8. 8 • PHPのセキュリティサポート懸念
 なぜPHPバージョンアップをしたかったか？

9. 9 • PHPのセキュリティサポート懸念
 • 導入しようとしたライブラリでPHP7.x以上が条件
 
 なぜPHPバージョンアップをしたかったか？

10. 10 • PHPのセキュリティサポート懸念
 • 導入しようとしたライブラリでPHP7.x以上が条件
 • 運用ツールのレスポンスタイムが遅い
 なぜPHPバージョンアップをしたかったか？

11. 11 • PHPのセキュリティサポート懸念
 • 導入しようとしたライブラリでPHP7.x以上が条件
 • 運用ツールのレスポンスタイムが遅い
 • PHPの新しい機能や記法を使いたい
 なぜPHPバージョンアップをしたかったか？

12. 12 • PHPのセキュリティサポート懸念
 • 導入しようとしたライブラリでPHP7.x以上が条件
 • 運用ツールのレスポンスタイムが遅い
 • PHPの新しい機能や記法を使いたい
 
 →　PHP8.1 にして全部解決や！
 なぜPHPバージョンアップをしたかったか？

13. 13 • PHPのセキュリティサポート懸念
 • 導入しようとしたライブラリでPHP7.x以上が条件
 • 運用ツールのレスポンスタイムが遅い
 • PHPの新しい機能や記法を使いたい
 
 →　PHP8.1 にして全部解決や！
 
 ただし、期間は6ヶ月。
 2023年1月スタートで2023年6月末にリリースしたい。
 なぜなら7月末に周年イベントで負荷が高くなる。
 その1ヶ月前までには、PHP8.1を安定動作させておきたい。
 なぜPHPバージョンアップをしたかったか？

14. 14 開発方針

15. 15 • 修正対象箇所の洗い出し
 ◦ PHP_CodeSniffer を使ってPHP8.1のコード記法に適していない 箇所を洗い出した
 • ひととおり修正し終わったあとで、ユニットテストを実施
 まず修正箇所を洗い出そう！

16. 16 • 洗い出した修正箇所:196件
 ◦ error:130件
 ◦ warning:66件
 
 まずはこれを足がかりに進めることに
 まず修正箇所を洗い出そう！
 
 

17. 17 PHP8.1対応を平和に進めるための戦略
 PHP8.1開発はPHP8.1専用のブランチで開発していた
 

18. 18 PHP8.1開発はPHP8.1専用のブランチで開発していた
 
 開発期間中はPHP8.1バージョンアップだけでなく、PHP5.5
 で新イベントや追加機能の開発も並行で行われる
 PHP8.1対応を平和に進めるための戦略
 PHP5.5での追加機能 

19. 19 PHP5.5での追加機能についてもPHP8.1対応する必要があるた め、定期的にPHP8.1用ブランチに取り込みが必要となる
 
 PHP8.1対応を平和に進めるための戦略
 PHP5.5での追加機能 

20. 20 PHP5.5での追加機能についてもPHP8.1対応する必要があるた め、定期的にPHP8.1用ブランチに取り込みが必要となる
 →ただし、PHP8.1のブランチは6ヶ月間という長い期間、開発が行 われるため差分が大きくなる。
 
 
 PHP8.1対応を平和に進めるための戦略
 PHP5.5での追加機能 

21. 21 PHP5.5での追加機能についてもPHP8.1対応する必要があるた め、定期的にPHP8.1用ブランチに取り込みが必要となる
 →ただし、PHP8.1のブランチは6ヶ月間という長い期間、開発が行 われるため差分が大きくなる。
 →差分が大きいとConflictする
 
 PHP8.1対応を平和に進めるための戦略
 PHP5.5での追加機能 

22. 22 なので、なるべくPHP8.1ブランチの差分を小さくしたい。
 
 PHP8.1対応を平和に進めるための戦略
 

23. 23 なので、なるべくPHP8.1ブランチの差分を小さくしたい。
 →PHP8.1ブランチの対応のうち、PHP5.5でも動作するものは PHP5.5のdevブランチに含めて事前リリースすることで差分をなる べく少なくしていた。
 
 PHP8.1対応を平和に進めるための戦略
 
 PHP5.5でも動作する修正 

24. 24 なので、なるべくPHP8.1ブランチの差分を小さくしたい。
 →PHP8.1ブランチの対応のうち、PHP5.5でも動作するものは PHP5.5のdevブランチに含めて事前リリースすることで差分をなる べく少なくしていた。
 
 PHP8.1対応を平和に進めるための戦略
 
 PHP5.5でも動作する修正 
 devブランチに入れて先にリリースする 

25. 25 なので、なるべくPHP8.1ブランチの差分を小さくしたい。
 →PHP8.1ブランチの対応のうち、PHP5.5でも動作するものは PHP5.5のdevブランチに含めて事前リリースすることで差分をなる べく少なくしていた。
 
 PHP8.1対応を平和に進めるための戦略
 
 PHP8.1対応の全体差分の
 約50％を事前にリリース

26. 26 事前リリースした具体例

27. 27 count対応
 
 事前リリースした具体例 count対応

28. 28 count対応
 
 事前リリースした具体例 count対応

29. 29 count対応
 • PHP8.0から配列やCountableオブジェクト以外を引数に渡すと エラーになるようになった
 事前リリースした具体例 count対応

30. 30 count対応
 • PHP8.0から配列やCountableオブジェクト以外を引数に渡すと エラーになるようになった
 ◦ →配列やCountableオブジェクトになるよう引数を調整した。 PHP5.5の段階でも変えられるもの。
 事前リリースした具体例 count対応

31. 31 PHPUnitはPHPのユニットテストフレームワーク
 
 私たちの運用では、新しいコード変更が提案されるたび、PHPUnit でテストを行っている。
 そして、そのテスト結果が問題ないことが確認された場合のみ、変 更をマージする。
 これによりコードの品質を維持している。
 
 PHPUnitについて

32. 32 事前リリースした具体例 @expectedException の廃止
 • 

33. 33 • @expectedException アノテーション
 ◦ PHPUnitで例外のテストを書きたい時に使用する
 ◦ PHPUnit9 で廃止
 事前リリースした具体例 @expectedException の廃止

34. 34 • @expectedException アノテーション
 ◦ PHPUnitで例外のテストを書きたい時に使用する
 ◦ PHPUnit9 で廃止
 • 対応方法
 /* - * @expectedException ValidationException */ public function testCannotPlay() { + $this->expectException(ValidationException::class); $this->game->play(); // should throw an exception } 事前リリースした具体例 @expectedException の廃止

35. 35 • @expectedException アノテーション
 ◦ PHPUnitで例外のテストを書きたい時に使用する
 ◦ PHPUnit9 で廃止
 • 対応方法
 /* - * @expectedException ValidationException */ public function testCannotPlay() { + $this->expectException(ValidationException::class); $this->game->play(); // should throw an exception } 事前リリースした具体例 @expectedException の廃止
 古いPHPUnitでは
 この書き方はできない 

36. 36 • @expectedException アノテーション
 ◦ PHPUnitで例外のテストを書きたい時に使用する
 ◦ PHPUnit9 で廃止
 • 対応方法
 /* - * @expectedException ValidationException */ public function testCannotPlay() { + $this->setExpectedException(ValidationException::class); $this->game->play(); // should throw an exception } 事前リリースした具体例 @expectedException の廃止
 PHPUnit4.5でも使える setExpectedExceptionに書 き換える

37. 37 • @expectedException アノテーション
 ◦ PHPUnitで例外のテストを書きたい時に使用する
 ◦ PHPUnit9 で廃止
 • 対応方法
 /* - * @expectedException ValidationException */ public function testCannotPlay() { + $this->expectException(ValidationException::class); $this->game->play(); // should throw an exception } 事前リリースした具体例 @expectedException の廃止
 リリース時に
 expectException に 
 一括置き換えする

38. 38 • PHPUnit_Framework_TestCase が PHPUnit\Framework\TestCase になった
 ◦ PHPUnit6で追加
 事前リリースした具体例 名前空間対応

39. 39 • PHPUnit_Framework_TestCase が PHPUnit\Framework\TestCase になった
 ◦ PHPUnit6で追加
 • 対応方法
 事前リリースした具体例 名前空間対応
 
 -class BleachUnitTestCase extends PHPUnit_Framework_TestCase +class BleachUnitTestCase extends PHPUnit\Framework\TestCase {
40. 40 • PHPUnit_Framework_TestCase が PHPUnit\Framework\TestCase になった
 ◦ PHPUnit6で追加
 • 対応方法
 
 
 
 • エイリアスを使うことでPHPUnit4.5でも名前空間っぽい記載が できる
 事前リリースした具体例 名前空間対応
 
 -class BleachUnitTestCase extends PHPUnit_Framework_TestCase +class BleachUnitTestCase extends PHPUnit\Framework\TestCase { +class_alias('PHPUnit_Framework_TestCase', 'PHPUnit\Framework\TestCase');
41. 41 後回しにしたこと

42. 42 PHPバージョンアップはやることが多い
 • ゲームサーバだけでなく、バッチ処理もPHP8.1対応
 
 • PHP7.3からMCrypt削除されたためOpenSSLに移行
 
 • xhprof代替の新パフォーマンスモニタリングの導入
 
 • PHPUnit10でwithConsecutiveの廃止

43. 43 PHPバージョンアップはやることが多い
 • ゲームサーバだけでなく、バッチ処理もPHP8.1対応
 
 • PHP7.3からMCrypt削除されたためOpenSSLに移行。
 
 • 新パフォーマンスモニタリングの導入（xhprof代替）
 
 • PHPUnit10でwithConsecutiveの廃止
 
 締め切りに間に合わない！
 

44. 44 PHPバージョンアップはやることが多い
 • ゲームサーバだけでなく、バッチ処理もPHP8.1対応
 
 • PHP7.3からMCrypt削除されたためOpenSSLに移行。
 
 • 新パフォーマンスモニタリングの導入（xhprof代替）
 
 • PHPUnit10でwithConsecutiveの廃止

45. 45 PHPバージョンアップはやることが多い
 • ゲームサーバだけでなく、バッチ処理もPHP8.1対応
 → バッチ処理は独立しているため、後日1つずつPHP8.1対応。
 • PHP7.3からMCrypt削除されたためOpenSSLに移行。
 
 • 新パフォーマンスモニタリングの導入（xhprof代替）
 
 • PHPUnit10でwithConsecutiveの廃止

46. 46 PHPバージョンアップはやることが多い
 • ゲームサーバだけでなく、バッチ処理もPHP8.1対応
 → バッチ処理は独立しているため、後日1つずつPHP8.1対応。
 • PHP7.3からMCrypt削除されたためOpenSSLに移行。
 →PECLでMCryptをインストールして一旦使い続ける
 • 新パフォーマンスモニタリングの導入（xhprof代替）
 
 • PHPUnit10でwithConsecutiveの廃止

47. 47 PHPバージョンアップはやることが多い
 • ゲームサーバだけでなく、バッチ処理もPHP8.1対応
 → バッチ処理は独立しているため、後日1つずつPHP8.1対応。
 • PHP7.3からMCrypt削除されたためOpenSSLに移行。
 →PECLでMCryptをインストールして一旦使い続ける
 • 新パフォーマンスモニタリングの導入（xhprof代替）
 →リリース後に考える
 • PHPUnit10でwithConsecutiveの廃止

48. 48 • ゲームサーバだけでなく、バッチ処理もPHP8.1対応
 → バッチ処理は独立しているため、後日1つずつPHP8.1対応。
 • PHP7.3からMCrypt削除されたためOpenSSLに移行。
 →PECLでMCryptをインストールして一旦使い続ける
 • 新パフォーマンスモニタリングの導入（xhprof代替）
 →リリース後に考える
 • PHPUnit10でwithConsecutiveの廃止
 →一旦削除
 
 PHPバージョンアップはやることが多い

49. 49 • ゲームサーバだけでなく、バッチ処理もPHP8.1対応
 → バッチ処理は独立しているため、後日1つずつ8.1対応。
 • PHP7.3からMCrypt削除されたためOpenSSLに移行。
 →PECLでMCryptをインストールして一旦使い続ける
 • 新パフォーマンスモニタリングの導入（xhprof代替）
 →リリース後に考える
 • PHPUnit10でwithConsecutiveの廃止
 →一旦削除
 
 
 PHPバージョンアップはやることが多い
 ＃あとでやる
 やることはたくさんあるので、 
 必須で対応しなければならないことに集中する 

50. 50 運用中プロジェクトで
 PHP8.1切り替えを
 どう進行したか

51. 51 1. 開発環境について 2. どう進行したか？ 3. 運用環境での出た問題
 運用中プロジェクトでPHP8.1切り替えをどう進行したか

52. 52 通常運用時のフロー
 1. 開発環境について

53. 53 通常運用時のフロー
 1. 開発環境について
 ① 開発者やデバッグチームは開発環境に アップロードされたマスタデータを 
 元にプログラムを開発したり、データを チェックしたりします。 

54. 54 通常運用時のフロー
 1. 開発環境について
 ② チェックし終わったデータは本番DBに アップロードされ、プレイヤーは新しいキャ ラクターやイベントが遊べるようになります 

55. 55 いきなりPHP8.1に切り替えてしまうと
 1. 開発環境について
 ①デバッグ中の不具合を見つけても、 PHP8.1が原因なのかマスタデータが原因 なのかの切り分けが難しくなります。 

56. 56 いきなりPHP8.1に切り替えてしまうと
 1. 開発環境について
 ② データ準備やチェックに遅れがでて、定 常運用に影響がでてしまいます 

57. 57 PHP8.1用のエンドポイントを準備して並行で動作
 2. どう進行したか？

58. 58 PHP8.1用のエンドポイントを準備して並行で動作
 2. どう進行したか？
 ① 定常運用のデバッグはPHP5.5でチェッ クするため影響なし 

59. 59 PHP8.1用のエンドポイントを準備して並行で動作
 2. どう進行したか？
 ② 定常運用を止めずに並行してPHP8.1 の検証を進めることができた 

60. 60 3. 運用環境で出た問題
 　

61. 61 3. 運用環境で出た問題(MessagePackの変更)
 　

62. 62 MessagePackとは
 3. 運用環境で出た問題(MessagePackの変更)

63. 63 3. 運用環境で出た問題(MessagePackの変更)
 なにが起こったか？

64. 64 3. 運用環境で出た問題(MessagePackの変更)
 なにが起こったか？
 →DBからのデータ読み込みに失敗するようになった
 

65. 65 3. 運用環境で出た問題(MessagePackの変更)
 なにが起こったか？
 →DBからのデータ読み込みに失敗するようになった
 なぜ？
 

66. 66 3. 運用環境で出た問題(MessagePackの変更)
 なにが起こったか？
 →DBからのデータ読み込みに失敗するようになった
 なぜ？
 →失敗していたのはMessagePackを使用していた箇所。 
 　msgpackのバージョンアップ0.5.5 -> 2.2.0 の際
 文字列の新シリアライズ方式(str8)が採用されたため。
 

67. 67 3. 運用環境で出た問題(MessagePackの変更)
 なにが起こったか？
 →DBからのデータ読み込みに失敗するようになった
 なぜ？
 →失敗していたのはMessagePackを使用していた箇所。 
 　msgpackのバージョンアップ0.5.5 -> 2.2.0 の際
 文字列の新シリアライズ方式(str8)が採用されたため。
 　新しいバージョンで保存したデータを古いバージョンで
 　読み込むことができなくなった
 　（msgpack v0.5.6から変わった）
 

68. 68 暫定対処
 3. 運用環境で出た問題(MessagePackの変更)

69. 69 暫定対処 並行稼働期間は新シリアライズ方式(str8)の設定をOFFにする 
 
 
 
 3. 運用環境で出た問題(MessagePackの変更)

70. 70 暫定対処 並行稼働期間は新シリアライズ方式(str8)の設定をOFFにする msgpack 0.5.5も 2.2.0 も同じデータ形式で保存される 
 
 
 
 3. 運用環境で出た問題(MessagePackの変更)

71. 71 暫定対処 並行稼働期間は新シリアライズ方式(str8)の設定をOFFにする msgpack 0.5.5も 2.2.0 も同じデータ形式で保存される 
 
 
 
 3. 運用環境で出た問題(MessagePackの変更)
 php.ini msgpack.use_str8_serialization = Off
72. 72 PHP8.1バージョンアップ後に 起こったトラブル

73. 73 バグ修正のためプログラムを本番環境にデプロイした際
 約3%の確率でSegmentation fault が起こるようになった。
 巨大PHPファイルのJITが時々壊れる問題

74. 74 バグ修正のためプログラムを本番環境にデプロイした際
 約3%の確率でSegmentation fault が起こるようになった。
 
 →バグ修正したプログラムが原因かと考えRevertしてデプロイす るも解消せず
 
 巨大PHPファイルのJITが時々壊れる問題
 

75. 75 バグ修正のためプログラムを本番環境にデプロイした際
 約3%の確率でSegmentation fault が起こるようになった。
 
 →バグ修正したプログラムが原因かと考えRevertしてデプロイす るも解消せず
 →Webサーバの再起動をするとなぜか解消した
 
 巨大PHPファイルのJITが時々壊れる問題
 

76. 76 バグ修正のためプログラムを本番環境にデプロイした際
 約3%の確率でSegmentation fault が起こるようになった。
 
 →バグ修正したプログラムが原因かと考えRevertしてデプロイす るも解消せず
 →Webサーバの再起動をするとなぜか解消した
 → $a = 1 + 1; のような関係ない差分をデプロイしても発生
 巨大PHPファイルのJITが時々壊れる問題

77. 77 色々調査したところ特定ファイルを本番環境にデプロイしたときだ け発生することがわかった
 
 巨大PHPファイルのJITが時々壊れる問題

78. 78 色々調査したところ特定ファイルを本番環境にデプロイしたときだ け発生することがわかった
 そのファイルがプロジェクトの中で一番大きい
 PHPファイル（8000行超、360KB）
 
 巨大PHPファイルのJITが時々壊れる問題

79. 79 色々調査したところ特定ファイルを本番環境にデプロイしたときだ け発生することがわかった
 そのファイルがプロジェクトの中で一番大きい
 PHPファイル（8000行超、360KB）
 二番目に大きいPHPファイル（4000行超え、140KB）では再現 せず
 
 巨大PHPファイルのJITが時々壊れる問題

80. 80 色々調査したところ特定ファイルを本番環境にデプロイしたときだ け発生することがわかった
 そのファイルがプロジェクトの中で一番大きい
 PHPファイル（8000行超、360KB）
 二番目に大きいPHPファイル（4000行超え、140KB）では再現 せず
 
 サーバ再起動すれば解決するが、このままデプロイする度に再起 動するのは運用コストがかかるため対策したい...
 巨大PHPファイルのJITが時々壊れる問題

81. 81 対策
 opcache.jit の設定をOFFにすることで解決した
 
 巨大PHPファイルのJITが時々壊れる問題

82. 82 対策
 opcache.jit の設定をOFFにすることで解決した
 
 なぜかはわからない。初回コンパイル時の挙動に関連?
 （わかる人いたら教えてください）
 
 
 
 
 
 巨大PHPファイルのJITが時々壊れる問題

83. 83 対策
 opcache.jit の設定をOFFにすることで解決した
 
 なぜかはわからない。初回コンパイル時の挙動に関連?
 （わかる人いたら教えてください）
 
 opcache.jit をOFFにすることでレスポンスタイムは多少悪化した （3%くらい）
 巨大PHPファイルのJITが時々壊れる問題

84. 84 対策
 opcache.jit の設定をOFFにすることで解決した
 
 なぜかはわからない。初回コンパイル時の挙動に関連?
 （わかる人いたら教えてください）
 
 opcache.jit をOFFにすることでレスポンスタイムは多少悪化した （3%くらい）
 予め適切なファイルサイズに分割するのが良いので、大きなPHP ファイルがあるプロジェクトは注意しましょう。
 （自分たちは今後のアップデートで分割予定）
 巨大PHPファイルのJITが時々壊れる問題

85. 85 アプリのバージョンアップの際の実機デバッグテストでNGとなり、 バグ報告がきたもの。
 そのテスト内容が
 
 PHP8.1速すぎ問題

86. 86 アプリのバージョンアップの際の実機デバッグテストでNGとなり、 バグ報告がきたもの。
 そのテスト内容が
 タイムアウトの動作チェックテスト
 タイムアウトまでの条件を1秒に変更するとサーバの処理 待ちで1秒以上かかりタイムアウトする
 
 
 
 PHP8.1速すぎ問題

87. 87 アプリのバージョンアップの際の実機デバッグテストでNGとなり、 バグ報告がきたもの。
 そのテスト内容が
 タイムアウトの動作チェックテスト
 タイムアウトまでの条件を1秒に変更するとサーバの処理 待ちで1秒以上かかりタイムアウトする
 →早くなりすぎてタイムアウトしなかった（テストNG）
 
 PHP8.1速すぎ問題

88. 88 アプリのバージョンアップの際の実機デバッグテストでNGとなり、 バグ報告がきたもの。
 そのテスト内容が
 タイムアウトの動作チェックテスト
 タイムアウトまでの条件を1秒に変更するとサーバの処理 待ちで1秒以上かかりタイムアウトする
 →早くなりすぎてタイムアウトしなかった（テストNG）
 （レスポンスデータを10倍くらいになるよう所持キャラを増やし てなんとか通過）
 PHP8.1速すぎ問題

89. 89 数値で見る実績と効果

90. 90 • 164人日
 ◦ リーダ：1名（26人日）
 ◦ メインの実装担当：1名（71人日）
 ◦ インフラ等相談役：3名（42人日+10人日+15人日）
 工数

91. 91 スケジュール（実績）

92. 92 バージョン情報
 5.5.13
 バージョンアップ前
 8.1.13
 バージョンアップ後
 PHP
 4.5
 10.3
 PHPUnit 
 1.4.10
 3.7.2
 PHP_CodeSniffer
 0.5.5
 2.2.0
 msgpack

93. 93 PHP8.1バージョンアップのプログラム修正量
 • PHP8.1バージョンアップによるプログラム修正量
 +16823 追加 -17638 削除 

94. 94 PHP8.1バージョンアップのプログラム修正量
 • PHP8.1バージョンアップによるプログラム修正量
 +16823 追加 -17638 削除 • 修正箇所の内訳は？

95. 95 PHP8.1バージョンアップのプログラム修正量
 

96. 96 PHP8.1バージョンアップのプログラム修正量
 
 全体の67％が
 テストコードの修正だった。 
 

97. 97 PHP8.1バージョンアップのプログラム修正量
 
 全体の67％が
 テストコードの修正だった。 
 PHPUnit対応が大変だった 

98. 98 バグチケット件数
 
 • デバッグ期間中に報告されたバグチケットは2件だけ
 ◦ いずれもサーバ設定に関連するもので、PHPバージョンアップの 修正に起因するものはなかった。
99. 99 バグチケット件数
 • デバッグ期間中に報告されたバグチケットは2件だけ
 ◦ いずれもサーバ設定に関連するもので、PHPバージョンアップの 修正に起因するものはなかった。
 ◦ →ユニットテストを通す過程で、PHP_CodeSnifferでは検知でき ていなかった修正漏れなどが見つかり対応できた。
 ◦ → デバッグ前にユニットテストを通したことで、修正必要な部分 は対応しきれていた。

100. 100 バグチケット件数
 
 • デバッグ期間中に報告されたバグチケットは2件だけ
 ◦ いずれもサーバ設定に関連するもので、PHPバージョンアップの 修正に起因するものはなかった。
 ◦ →ユニットテストを通す過程で、PHP_CodeSnifferでは検知でき ていなかった修正漏れなどが見つかり対応できた。
 ◦ → デバッグ前にユニットテストを通したことで、修正必要な部分 は対応しきれていた。
 ◦ ユニットテストのバージョンアップは大変だけど大切

101. 101 • ゲームサーバAPIの平均レスポンスタイム
 ◦ 0.238 秒 → 0.139秒 (42％改善) バージョンアップの効果
 PHP8.1切り替えタイミング 

102. 102 • ユニットテストの処理時間
 ◦ アプデ前後で変更のなかったテストを一部抽出
 ◦ 496秒 → 247秒 (50％改善)
 バージョンアップの効果

103. 103 • 運用ツールのレスポンスタイム
 ◦ 40％改善
 バージョンアップの効果
 

104. 104 まとめ

105. 105 開発方針
 • PHP_CodeSniffer を使ってPHP8.1のコード記法に適していない 箇所を洗い出した
 • ひととおり修正し終わったあとで、ユニットテストを実施
 • PHP5.5でも動作するものは事前にリリースすることでPHP8.1ブ ランチの差分を最小にし、Conflictリスクを低下
 まとめ

106. 106 運用中プロジェクトでPHP8.1切り替えをどう進行したか
 • PHP8.1用サーバのエンドポイントを分けることで、並行して運 用
 • MessagePackのバージョンアップで新シリアライズ形式が採用 されたことによるデータ読み込み失敗については、並行運用 期間中だけ設定をOFFにした
 まとめ

107. 107 バージョンアップ後に起こったトラブル
 • 本番環境デプロイ時に3%の確率でSegmentation faultが発生 する障害
 ◦ opcache.jit の設定をOFFにすることで暫定対応
 • PHP8.1が早すぎてタイムアウトのテストができない問題
 ◦ キャラ数を10倍に増やすことで対応
 まとめ

108. 108 数値で見る実績と効果
 • 164人日
 • ゲームサーバ 42％改善
 • ユニットテスト 50％改善
 • 運用ツール 40％改善
 まとめ

109. 109 まとめ
 PHPバージョンアップの修正箇所
 • 全体の67％がテストコードの修正だった
 • テストを通す過程で、PHP_CodeSnifferでは検知できていな かった箇所などが見つかり対応できた。
 • テストコードのおかげで、デバッグ時のバグが抑えられた。
 ◦ ユニットテストのバージョンアップは大変だけど大切

110. 110 今回事前リリースした部分は、もっと前から準備できた部分だっ た。
 実際に修正箇所の約50％を事前リリースにできた。
 164人日を確保するのはプロジェクトによっては難しい。
 ただ、事前リリース分をコツコツ対応していくのは可能。
 バージョンアップしたいを思っている方は、
 「PHP_CodeSnifferでチェックをする」や「PHPUnitのリリースノートを 見てみる」など30分でできることから始めるとアップデートコストが 減るのでやっていきましょう！
 
 さいごに

111. 111 ここまで聞いていただき、
 ありがとうございました。
 おわり