アプリケーションをリプレイスしたら チームとサービス運用に向き合えた

2024 PHPカンファレンス福岡

Transcript

1. アプリケーションをリプレイスした ら チームとサービス運用に向き合えた 2024/06/22 PHPConference FUKUOKA 2024 @zosokh
2. チャン（ヒエイカザト） 株式会社ウエディングパーク Photorait・TECH戦略室 サーバーサイドエンジニア チーフエンジニア 　 @zosokh　#野球観戦 #ちなヤク #二児の父 交流戦お疲れ様でした！どすこーーーーい！
3. Photorait フォトレイト フォトウエディング、前撮りな ど結婚写真の撮影スタジオやロ ケ地を検索できる情報サイト www.photorait.net
4. 今日の話 長年運用しているサービスのリプレイスを検討している方へ リプレイス計画と実行成果までの話をします リプレイスの提案 新基盤の設計 リプレイス後の収穫
5. #phpconfuk #hall_fu
6. 前段｜ リプレイス方針
7. リプレイス前まで • 2015年にローンチしたサービス • PHPもフレームワークもバージョンが古い状態 CodeIgniter3 PHP8.0
8. • Fat Controller • 不十分且つ拡張しにくいテストコード • バージョンアップができていない • 依存性の高いシステム設計 • jQuery ・・・ 顕在化していた課題
9. 新規でシステムを立ち上げ、稼働サービスを移行していく対応を始 める 新しく立ち上げた環境（以降：新基盤）今までの基盤を旧基盤と説明していきます CodeIgniter3 👉 Laravel11（2024年6月現在） PHP8.0 👉 PHP8.3（2024年6月現在） EC2 👉 ECS Fargate リプレイスの決断
10. こんなようなイメージ 新基盤 旧基盤 サービス 立ち上げた新基盤に、旧基盤からサービスをどんどん移行していく
11. こんなようなイメージ www.photorait.net 新基盤 旧基盤
12. 大型プロジェクト（以降A-PJ）の開発計画が元々あった 新基盤へは主に以下のサービスを稼働（移行）させる方針を取った • A-PJでの開発サービス • A-PJ以外の案件でも、新規サービスを求められる案件 上記ケース以外のサービスは案件の合間に移行を進めていく 新基盤への移行方針
13. 新基盤への移行方針 return switch ($pj){ case 'A-PJ': case '新規サービス開発が求められる PJ': case '工数に余裕のあるPJ': '新基盤'; break; default: '旧基盤'; };
14. リプレイスの提案 事業責任者へ打診 リプレイスの提案 新基盤の設計 リプレイスした成果
15. 事業責任者と、ディレクターに提案を行った 新基盤の提案時
16. 登場人物 私 事業責任者 偉大な先輩
17. 提案内容：システムリプレイスをしたい 初回の提案内容 • システム課題とリプレイス恩恵の共 有 • A-PJはリプレイスした後にやる方が 効率的です 👉工数いだきたい 👉A-PJのスケジュールを後ろ倒しさせて もらいたい
18. 初回の提案内容
19. 提案内容：システムリプレイスをしたい 初回の提案内容 • システム課題とリプレイス恩恵の共 有 • A-PJはリプレイスした後にやる方が 効率的です 👉工数いだきたい 👉A-PJのスケジュールを後ろ倒しさせて もらいたい
20. 提案内容：A-PJ開発をシステムリプレイスしながらやりたい 提案内容を変える • 新基盤を立ち上げながらA-PJ開発を 行いたい 👉新基盤構築も兼ねるので工数を追加で 確保させてください
21. 提案内容を変える
22. • 新基盤を立ち上げながらA-PJ開発を 行いたい 👉新基盤構築も兼ねるので工数を追加で 確保させてください 提案内容：A-PJ開発をシステムリプレイスしながらやりたい 提案内容を変える
23. 提案内容：A-PJ開発をシステムリプレイスしながらやりたい 提案内容を変える 2 • 新基盤を立ち上げながらA-PJ開発を 行いたい • 旧基盤と新基盤開発での工数の差を 共有 👉結果的に新基盤開発の方が効率化され るので工数恩恵もあります
24. 提案内容を変える 2 案件1 案件2 案件3 案件4 案件5 案件6 案件7 案件8
25. 案件1 案件2 案件3 案件4 案件5 案件6 案件7 案件8 提案内容を変える 2
26. 何となく了承は得られた雰囲気になったので、新基盤構築を兼ねた A-PJ開発準備を開始する • 具体的設計の開始 • 新基盤構築と案件開発のスケジュール落とし込み開始 ◦ 数パターンのスケジュールとアサイン案を作成 新基盤で実行する準備をする
27. 何となく了承は得られた雰囲気になったので、新基盤構築を兼ねた A-PJ開発準備を開始する • 具体的設計の開始 • 新基盤構築と案件開発のスケジュール落とし込み開始 ◦ 数パターンのスケジュールとアサイン案を作成 👉新基盤とA-PJ開発、へ開発構想のベースにしていく 新基盤で実行する準備をする
28. 何となく了承は得られた雰囲気になったので、新基盤構築を兼ねた A-PJ開発準備を開始する • 具体的設計の開始 • 新基盤構築と案件開発のスケジュール落とし込み開始 ◦ 数パターンのスケジュールとアサイン案を作成 しかしここまでで、反省点がある 新基盤で実行する準備をする
29. 【反省点】急な技術提案
30. システム改善の提案やその効果の裏付けは大事だが、急な提案自体を無 くしていきたい • 急な提案は良くも悪くも驚かれる • そもそも「課題」や「改善したい」という意見が、自分だけに留 まっていた事が問題 👉 普段の会話でシステムの話を日常的に出していく 👉 これらの意見を良く聞いていたアレねに近づける根回しが大事 【反省点】急な技術提案 ＼偉大な先輩のアドバイス／
31. 新基盤の設計 いよいよ開発だ リプレイスの提案 新基盤の設計 リプレイス後の収穫
32. • ECSコンテナ化 • PHP・Laravelの最新を追える設計 • 全面テストコード • Laravelアプリケーション ◦ モジュラーモノリスアーキテクチャ 新基盤の方針
33. モジュラーモノリス
34. モジュラーモノリス 検証もしてみた
35. モジュラーモノリスを導入したかった理由 • チーム事情でマイクロサービス運用は困難なので、あくまでモ ノリスアプリケーションを用意したかった • 今後マイクロサービス化を検討できるように、モジュール （サービス）単位で疎結合なモノリスアプリケーションを構築 したかった • Laravel-Modulesを利用することでモジュラーモノリスを比較 的簡単に構築できる点
36. 【決断】モジュラーモノリス導入をやめる
37. モジュラーモノリス導入をやめる • 旧アプリケーション構造もそこまで複雑ではなかった • モジュール化によるルール認識やスムーズな拡張、設計の複雑 化がチームの運用スタイルに現在の段階では合わない・困難が 予想 • 導入しなくてもLaravelアプリケーションで且つバージョンアッ プしやすい基盤であること、テストが整備された環境を用意し たいなどの、リプレイスへの目的は達成できると考えた 👉モジュラーモノリスの採用をしない事を決断
38. 設計方針ざっくりまとめ • 全面リファクタリング • Dockerによるローカル開発環境 • ECS稼働 • 全面テストコード設置 • PHPUnit・Larastan・PHP-CS-Fixer・ESlint・Stylelint・Vitestを利用したテ スト・静的解析を導入 • Github Actionsによる上記テスト・静的解析、及びデプロイ機構作成 • 依存サードパーティの置き換え • 定期的なcomposer update機構 • Feature Toggle導入 • APIモックを簡潔化 • ライブラリを共通パッケージで外部管理 • octocovs使ったカバレッジ値表示 • セッションを旧CodeIgniterアプリと共有できるようにする • Laravel Auditingを使ったログ排出 • VRTを使った差分チェック
39. リプレイス後の収穫 成果について リプレイスの提案 新基盤の設計 リプレイス後の収穫
40. 新基盤で運用コストの削減 • テストコードの整備 • 定期的なcomposer updateによるパッケージ更新 • 全面リファクタリング ・・・ 上記から運用恩恵が得られている
41. バージョンアップのコスト削減 案件 回数 開発工数（人日） 実際のテスト工数（人日） テストコードが無かった場 合の開発・テスト工数 （人日） composer update 毎日 0 0 ？？？ PHPバージョンアッ プ PHP8.2 👉 8.3 1 1 0 40〜50 Framework バージョ ンアップ Laravel10 👉 11 1 1 1 40〜50
42. バージョンアップのコスト削減 案件 回数 開発工数（人日） 実際のテスト工数（人日） テストコードが無かった場 合の開発・テスト工数 （人日） composer update 毎日 0 0 ？？？ PHPバージョンアッ プ PHP8.2 👉 8.3 1 1 0 40〜50 Framework バージョ ンアップ Laravel10 👉 11 1 1 1 40〜50 計り知れない。テストコードが無 かったら定期的なupdateは出来な いかも 旧基盤や他チームでバージョン アップ時の工数
43. リードタイムの減少 案件 リードタイム平均h（初回コミッ トからマージまで） PR作成数 新基盤 4 32.5 旧基盤 8.1 27
44. リードタイムの減少 大幅なリードタイムの差が現れる 成功！！！ 案件 リードタイム平均h（初回コミッ トからマージまで） PR作成数 新基盤 4 32.5 旧基盤 8.1 27
45. 現れているリプレイスの恩恵 テストコード整備により、工数をかけないバージョンアップ対応が 可能 処理の最適化により、実装やレビュー時間の短縮傾向がある
46. アウトプット インプット 現れているリプレイスの恩恵 テストコード整備により、工数をかけないバージョンアップ対応が 可能 処理の最適化により、実装やレビュー時間の短縮傾向がある ←開発によって生み出された価値 ←開発に投入したリソース 生産性 成果物 投入した資源
47. 現れているリプレイスの恩恵 テストコード整備により、工数をかけないバージョンアップ対応が 可能 処理の最適化により、実装やレビュー時間の短縮傾向がある 立派なコスト削減！ アウトプット インプット 生産性 成果物 投入した資源 ←開発に投入したリソース
48. まとめ
49. • リプレイスと効果含めた提案。開発思想は普段からアウトプット • 設計時の、やる決断・やらない決断 • 運用コスト面の恩恵 まとめ リプレイスの提案 新基盤の設計 リプレイス後の収穫
50. ご清聴ありがとうございました