ふるさと納税サイトをPHP8化した時の話.pdf

2012年に日本初のふるさと納税ポータルサイトとして立ち上がった「ふるさとチョイス」は、最後のリニューアルを2018年3月に行い、そこから開発・運用を続けてきました。

リニューアル当時はPHP7.4 + FuelPHP1.8.2で構築されていましたが、言語のEOLに伴ってこの度PHP8.3 ＋ FuelPHP1.9-Dev へアップデートしましたため、
その時のつまづきポイントや苦労したところなどをお話させていただこうと思います。

PHPのバージョンアップはここ数年で実施している所も多く、目新しい構成や情報はそれほど多くないかもしれませんが、今後もアップデートを実施してく方の参考・助けになれば幸いです。

お持ち帰りポイント
・既存のリリースを止めずにバージョンアップを完遂させた方法と、想定通りに行かなかったポイント
・トラフィックの切り替え方法とその際の失敗パターン
・移行に伴って苦労したのはテンプレートエンジンでした（弊社はPHPTALを使用）

ふるさとチョイスの数字的特徴（2024年10月時点）
・PV：2億 / 月
・品の数：76万超
・利用自治体数：1700超
・決済種別：14種類

技術スタック
・PHP7.4
・FuelPHP1.8.2
・PHPTAL1.2.2
・MySQL5.6

ふるさとチョイス開発組織の特徴
・開発部門の人数： 80人
・リリースチケット件数：約25件/週

Transcript

1. 2025/3/22 サイトも開発も止めずにPHP8へ移行できました 大規模ふるさと納税サイトをPHP8化した時の苦労話
2. 0. 自己紹介(0.5min) 1. ふるさとチョイスの紹介(3min) 2. バージョンアップする際の前提条件と方針(3min) 3. 事前作業(3min) 4. PHP8化作業の主な内容(3min) 5. 切り替え方法(3min) 6. まとめ(1min) 7. 最後は告知(0.5min) アウトライン
3. SECTION 3 00 自己紹介 0. 自己紹介 1. ふるさとチョイスの紹介 2. バージョンアップする際の前提条件と方針 3. 事前作業 4. PHP8化作業の主な内容 5. 切り替え方法 6. まとめ 7. 最後は告知
4. 自己紹介 氏名 瀬尾 一矢（せお かずや） 所属 TechLeadグループ 趣味 散歩・旅行 得意言語 PHP・SQL・得意じゃないけど goと TypeScriptが好き
5. SECTION 5 01 ふるさとチョイスの紹介 0. 自己紹介 1. ふるさとチョイスの紹介 2. バージョンアップする際の前提条件と方針 3. 事前作業 4. PHP8化作業の主な内容 5. 切り替え方法 6. まとめ 7. 最後は告知
6. “国内初”ふるさと納税総合サイト「ふるさとチョイス」 ※1 JMRO調べ 調査概要：2024年10⽉期 指定領域の検証調査 ※2 2024年10⽉現在
7. 地域創⽣を⽬的とし、地域と寄付者をつなぐ様々な取り組みを⾏っています。 ふるさと納税払い チョイスPay ふるさと納税のお礼の品や ⾃治体情報を連携するOEMサービス 7 ふるさと納税のお礼の品や ⾃治体情報のモール/スーパーアプリ展開 課題解決への資⾦調達 災害時の資⾦調達
8. 8 たくさんある中でも今回は 「ふるさとチョイス」 のPHP8化した際のお話をさせていただきます。 今回のお話
9. ふるさとチョイスっぽい特徴 • 12月が最繁忙期でPVは約数億 • 12月31日は平常時の20倍ぐらいのアクセスが来ます • 決済システム・CMSもPHPで内製化してます 実際のトラフィックの推移 (9月1日〜12月31日まで)
10. ふるさとチョイスの技術スタック 移行前 移行後 開発言語 PHP7.4 PHP8.3 FW FuelPHP 1.8.2 FuelPHP 1.9-dev TemplateEngine PHPTAL1.2.2 PHPTAL1.2.2 DB MySQL5.6, 5.7 MySQL5.6, 5.7 OS CentOS7 AlmaLinux9
11. 開発組織の特徴 • 開発部門の人数は 80人程度 （BE・FE・QA） • リリースチケット件数は約25件/週 • ソース管理はGithub使ってます • IDEはPHPStorm使ってる人多め
12. SECTION 12 02 バージョンアップする際の前提条件と方針 0. 自己紹介 1. ふるさとチョイスの紹介 2. バージョンアップする際の前提条件と方針 3. 事前作業 4. PHP8化作業の主な内容 5. 切り替え方法 6. まとめ 7. 最後は告知
13. 13 最初にPHP8化進める際に決めた前提条件を記載してます。
14. 14 • 既存の開発を進めながらの言語アップデートを実施 • 移行前と移行後で「挙動を変えない」が原則 前提条件
15. 15 • 既存の開発（約25件/週）は維持しつつ並行してアップデー トする • アップデート向けの新チームを立ち上げてアップデート開発 を実施、機能開発チームには既存の開発を実施 • PHP7とPHP8両方の環境での開発などは出来るだけ行わない 既存の開発を進めながらの言語アップデートを実施
16. 16 • 「挙動を正しく」する際、仕様の確認コストが膨らむので、 「挙動を変えない」を正とする • 「改善できそう」な機能も変更はしない • 「動作しない」（画面が白くなったり、動きが止まったりす る）は修正する 移行前と移行後で「挙動を変えない」が原則
17. 17 これらの前提から、大枠の方針を決めました。
18. 18 1. 「PHP7版リポジトリ」と「PHP8版リポジトリ」を用意し、PHP7 版の開発をPHP8側に定期的に取り込む 2. PHP8リポジトリを作成する前と作成した後、最後にmergeする時 にすることを明確に分けて取り組む 3. 「挙動は変えない」が、コードの変更内容はアップデートチーム と機能開発チームに必ず共有する 方針
19. 19 TimeLine 事前作業 機 能 取 り 込 み PHP8化対応 リ ポ ジ ト リ 作 成 動作検証 リリース ソース凍結 PHP7 リポジトリ PHP8 リポジトリ PHP7開発中 ソース移行 取り込み ＋ 動作検証 × α 開 発 中 の 機 能 移 行 機 能 取 り 込 み 機 能 取 り 込 み プロダクトの機能開発・リリース プロダクトの機能開発 ・リリース再開
20. SECTION 20 03 事前作業 0. 自己紹介 1. ふるさとチョイスの紹介 2. バージョンアップする際の前提条件と方針 3. 事前作業 4. PHP8化作業の主な内容 5. 切り替え方法 6. まとめ 7. 最後は告知
21. 21 TimeLine 機 能 取 り 込 み PHP8化対応 リ ポ ジ ト リ 作 成 動作検証 リリース ソース凍結 PHP7 リポジトリ PHP8 リポジトリ PHP7開発中 ソース移行 取り込み後 動作検証 × α 開 発 中 の 機 能 移 行 機 能 取 り 込 み 機 能 取 り 込 み プロダクトの機能開発・リリース プロダクトの機能開発 ・リリース再開 事前作業
22. 22 1. ライブラリの徹底調査 2. APC → APCuへの移行 3. PHPStanの導入 4. PHP_CS_Fixer の導入
23. 23 1. ライブラリの徹底調査 2. APC -> APCuへの移行 3. PHPStanの導入 4. PHP_CS_Fixer の導入
24. 24 目的：依存関係が原因でプロジェクトが止まらないようにするため 内容：Packagistを参照し、PHP8に対応していないライブラリが 　　　無いか確認（200個以上） 感想：歴史や最新情報を知れて面白いけど作業が結構大変... ライブラリの徹底調査 依存ライブラリも含めて全て調査してスプシにまとめた
25. 25 1. ライブラリの徹底調査 2. APC → APCuへの移行 3. PHPStanの導入 4. PHP_CS_Fixer の導入
26. 26 目的：APCはPHP8で確実に使えないのでやらねばならぬ 内容：「apc -> apcuと変える」（簡単じゃん！と思った 感想：「簡単じゃん！」と思ったけど検証が少し大変だった APC → APCu への移行
27. 27 1. ライブラリの徹底調査 2. APC → APCuへの移行 3. PHPStanの導入 4. PHP_CS_Fixer の導入
28. 28 PHPStanの導入 目的：形による問題を検知できる状況を作る 内容：Lv3を目標にPHPStanの導入と指摘事項の修正を実施 反省：PHPStanによる指摘の修正はLv1の途中で時間切れ...
29. 29 1. ライブラリの徹底調査 2. APC → APCuへの移行 3. PHPStanの導入 4. PHP_CS_Fixer の導入
30. 30 PHP_CS_Fixer の導入 目的：merge(定期取り込み) 時の Conflict発生を減らす 実施：PHP_CS_Fixerを使い一括置換を実施＋CIへの組み込み 感想：一括置換のPRファイル数が数千ファイルあってレビュアー が笑ってた
31. SECTION 31 04 PHP8化作業の主な内容 0. 自己紹介 1. ふるさとチョイスの紹介 2. バージョンアップする際の前提条件と方針 3. 事前作業 4. PHP8化作業の主な内容 5. 切り替え方法 6. まとめ 7. 最後は告知
32. 32 TimeLine 機 能 取 り 込 み リ ポ ジ ト リ 作 成 リリース ソース凍結 PHP7 リポジトリ PHP8 リポジトリ PHP7開発中 ソース移行 取り込み後 動作検証 × α 開 発 中 の 機 能 移 行 機 能 取 り 込 み 機 能 取 り 込 み プロダクトの機能開発・リリース プロダクトの機能開発 ・リリース再開 事前作業 PHP8化対応 動作検証
33. 33 PHP8化作業 • 内部関数の仕様変更に伴う修正が多かった • 一番時間を取られたのはテンプレートエンジン内で使われている 配列内の null 判別 • 修正内容はドキュメントにまとめて両方のチームに展開
34. 34 strlen() PHP7.4までは 第1引数に nullが来ると falseを返していたが、 PHP8以降はerrorになる。 number_format() PHP 8.2 から 第1引数に null を渡すとエラーになる 仕様変更でエラーになった関数達① str_replace() 第3引数に null を渡すとエラーになるようになってた explode() 第2引数にnullを渡すのは非推奨になった
35. 35 strtotime() PHP7.4 までは第1引数に null が渡ると false が返されたが、PHP8.1 以降は非推奨エラーが発生するようになってた preg_match() PHP7.4 までは第2引数に null が渡ると 0 が返されたが、PHP8.1 以降は非推奨エラーが発生するようになってた 仕様変更でエラーになった関数達② mb_ereg_match() 第2引数に null がわたるとエラーになるようになっていた html_entity_decode() 第1引数に null が渡るとエラーになるように成っていた
36. 36 配列内のnull対応は null合体演算子(??)で対応 • 「挙動を変えない」ようにするための対応策 • テンプレートエンジンにロジックを入れることは困難 • 結果以下のような修正（力技）で対応
37. 37 ドキュメント化 • チームを横断したコミュニケーションは本当に大事 • ドキュメント作成は見ない人がいると心が折れそうになるけ ど「役に立った」の言葉が多くてやってよかった 修正方針から対応した関数まで細かくnotionに記載
38. 38 • 他社からいただいているライブラリがPHP8化非対応で E_DEPRECATED(非推奨)エラーが画面に大量に出た • リポジトリに登録されていないけど使ってるソースをよく見たら そもそもPHP4の記法だった... • 外部決済の認証方式がOpenID Authentication 2.0だったの で、OpenIDConnectに書き換えもした 苦戦したのはまさかの外部ライブラリ...
39. 39 TimeLine 機 能 取 り 込 み リ ポ ジ ト リ 作 成 リリース ソース凍結 PHP7 リポジトリ PHP8 リポジトリ PHP7開発中 ソース移行 開 発 中 の 機 能 移 行 機 能 取 り 込 み 機 能 取 り 込 み プロダクトの機能開発・リリース プロダクトの機能開発 ・リリース再開 事前作業 PHP8化対応 動作検証 取り込み後 動作検証 × α
40. 40 定期ソース取り込み
41. 41 • 実施したこと ◦ ひたすら git merge + conflict解消 ＋ QA • ここで撒いた種が花開く ◦ PHP_CS_Fixerによってmerge時Conflict発生を抑止できた ◦ 関数毎の修正点をドキュメント化する事で取り込み担当者の属人化を 防げた • 結果 ◦ 週ごとの取り込みが約1時間程度で出来るようになりました！！
42. SECTION 42 05 切り替え方法 0. 自己紹介 1. ふるさとチョイスの紹介 2. バージョンアップする際の前提条件と方針 3. 事前作業 4. PHP8化作業の主な内容 5. 切り替え方法 6. まとめ 7. 最後は告知
43. 43 TimeLine 機 能 取 り 込 み リ ポ ジ ト リ 作 成 ソース凍結 PHP7 リポジトリ PHP8 リポジトリ PHP7開発中 ソース移行 開 発 中 の 機 能 移 行 機 能 取 り 込 み 機 能 取 り 込 み プロダクトの機能開発・リリース プロダクトの機能開発 ・リリース再開 事前作業 PHP8化対応 動作検証 取り込み後 動作検証 × α リリース
44. 44 • リリース方式はカナリアリリースを採用 • LBを用いて特定の流量を新サーバーに流す方法 移行方法
45. リリース手順 LBサーバ DBサーバ 旧 ＝ 100 現WEBサーバ 現APPサーバ 現WEBサーバ 現APPサーバ
46. DBサーバ PHP8化された 新サーバーを準備 旧：新 ＝ 100：0 リリース手順 現WEBサーバ 現APPサーバ 現WEBサーバ 現APPサーバ 新WEBサーバ 新APPサーバ 新WEBサーバ 新APPサーバ LBサーバ
47. DBサーバ 旧：新 ＝ 75：25 リリース手順 現WEBサーバ 現APPサーバ 現WEBサーバ 現APPサーバ 新WEBサーバ 新APPサーバ 新WEBサーバ 新APPサーバ 新サーバーに向けて LB→WEBサーバー の疎通開始 LBサーバ
48. DBサーバ 旧：新 ＝ 50：50 リリース手順 現WEBサーバ 現APPサーバ 現WEBサーバ 現APPサーバ 新WEBサーバ 新APPサーバ 新WEBサーバ 新APPサーバ 新サーバーに向けて LB→WEBサーバー の疎通開始 LBサーバ
49. DBサーバ 旧：新 ＝ 25：75 リリース手順 現WEBサーバ 現APPサーバ 現WEBサーバ 現APPサーバ 新WEBサーバ 新APPサーバ 新WEBサーバ 新APPサーバ 旧サーバーに向けて の接続を解除 LBサーバ
50. DBサーバ 旧：新 ＝ 0：100 リリース手順 現WEBサーバ 現APPサーバ 現WEBサーバ 現APPサーバ 新WEBサーバ 新APPサーバ 新WEBサーバ 新APPサーバ 旧サーバーに向けて の接続を解除 LBサーバ
51. DBサーバ 新 ＝ 100 リリース手順 現WEBサーバ 現APPサーバ 現WEBサーバ 現APPサーバ 新WEBサーバ 新APPサーバ 新WEBサーバ 新APPサーバ LBサーバ
52. 52 • ライブラリの更新に伴って外部決済との認証方式に一部変更 が入った • そのためCallbackが発生した時の向き先が同じサーバーでな いと認証エラーが発生していた … が！ 旧：新 ＝ 75：25 の段階で外部決済に不具合
53. DBサーバ 現WEBサーバ 現APPサーバ 新WEBサーバ 新APPサーバ 外部決済 システム LBサーバ 認証実施
54. DBサーバ 現WEBサーバ 現APPサーバ 新WEBサーバ 新APPサーバ 外部決済 システム LBサーバ 認証が成功したので Callbackで1度戻る 認証実施
55. DBサーバ 現WEBサーバ 現APPサーバ 新WEBサーバ 外部決済 システム LBサーバ 認証状態確 認でエラー 新APPサーバ
56. 56 この不具合のため一括切り替え方式に変更
57. 57 最終的には DBサーバ 現WEBサーバ 現APPサーバ 現WEBサーバ 現APPサーバ 新WEBサーバ 新APPサーバ 新WEBサーバ 新APPサーバ ユーザーの動きが少ない時間帯 に新サーバーへ100%向け、 ユーザーの動きが多くなる時間 帯は旧サーバーへ戻す。 この作業を繰り返し新サーバー の稼働時間を長くしていく。 LBサーバ
58. 58 無事リリース！
59. SECTION 59 06 まとめ 0. 自己紹介 1. ふるさとチョイスの紹介 2. バージョンアップする際の前提条件と方針 3. 事前作業 4. PHP8化作業の主な内容 5. 切り替え方法 6. まとめ 7. 最後は告知
60. 60 • 言語やFWのバージョンアップはこまめに、間が開くほどバージョ ンアップに伴う作業と仕様の確認工数が増えます。 • 開発チームとアップデートチームを分ける場合は共通認識は必ず 取ろう！（今回はコード規約統一と修正箇所のドキュメント化） • 自分たちが作ったコード以外も動いているコードには気を張り巡 らせましょう。 まとめ
61. 61 規模の大きいサービスのPHP8化をさせていただきましたが、 「どうしても行き詰まる」ようなことはなかったので 検討している方は 勇気 を持ってチャレンジ！ 継続したバージョンアップで 先進的 且つ セキュア な開発を楽しみましょう。
62. SECTION 62 07 最後は告知 0. 自己紹介 1. ふるさとチョイスの紹介 2. バージョンアップする際の前提条件と方針 3. 事前作業 4. PHP8化作業の主な内容 5. 切り替え方法 6. まとめ 7. 最後は告知
63. PHPer積極採用中！ サーバーサイドエンジニア アーキテクト EM