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

by zosokh

Slide 1

Slide 1 text

アプリケーションをリプレイスしたらチームとサービス運用に向き合えた 2024/06/22 PHPConference FUKUOKA 2024 @zosokh

Slide 2

Slide 2 text

チャン（ヒエイカザト）株式会社ウエディングパーク Photorait・TECH戦略室サーバーサイドエンジニアチーフエンジニア　 @zosokh　#野球観戦 #ちなヤク #二児の父交流戦お疲れ様でした！どすこーーーーい！

Slide 3

Slide 3 text

Photorait フォトレイトフォトウエディング、前撮りなど結婚写真の撮影スタジオやロケ地を検索できる情報サイト www.photorait.net

Slide 4

Slide 4 text

今日の話長年運用しているサービスのリプレイスを検討している方へリプレイス計画と実行成果までの話をしますリプレイスの提案新基盤の設計リプレイス後の収穫

Slide 5

Slide 5 text

#phpconfuk #hall_fu

Slide 6

Slide 6 text

前段｜リプレイス方針

Slide 7

Slide 7 text

リプレイス前まで ● 2015年にローンチしたサービス ● PHPもフレームワークもバージョンが古い状態 CodeIgniter3 PHP8.0

Slide 8

Slide 8 text

● Fat Controller ● 不十分且つ拡張しにくいテストコード ● バージョンアップができていない ● 依存性の高いシステム設計 ● jQuery ・・・顕在化していた課題

Slide 9

Slide 9 text

新規でシステムを立ち上げ、稼働サービスを移行していく対応を始める新しく立ち上げた環境（以降：新基盤）今までの基盤を旧基盤と説明していきます CodeIgniter3 👉 Laravel11（2024年6月現在） PHP8.0 👉 PHP8.3（2024年6月現在） EC2 👉 ECS Fargate リプレイスの決断

Slide 10

Slide 10 text

こんなようなイメージ新基盤旧基盤サービス立ち上げた新基盤に、旧基盤からサービスをどんどん移行していく

Slide 11

Slide 11 text

こんなようなイメージ www.photorait.net 新基盤旧基盤

Slide 12

Slide 12 text

大型プロジェクト（以降A-PJ）の開発計画が元々あった新基盤へは主に以下のサービスを稼働（移行）させる方針を取った ● A-PJでの開発サービス ● A-PJ以外の案件でも、新規サービスを求められる案件上記ケース以外のサービスは案件の合間に移行を進めていく新基盤への移行方針

Slide 13

Slide 13 text

新基盤への移行方針 return switch ($pj){ case 'A-PJ': case '新規サービス開発が求められる PJ': case '工数に余裕のあるPJ': '新基盤'; break; default: '旧基盤'; };

Slide 14

Slide 14 text

リプレイスの提案事業責任者へ打診リプレイスの提案新基盤の設計リプレイスした成果

Slide 15

Slide 15 text

事業責任者と、ディレクターに提案を行った新基盤の提案時

Slide 16

Slide 16 text

登場人物私事業責任者偉大な先輩

Slide 17

Slide 17 text

提案内容：システムリプレイスをしたい初回の提案内容 ● システム課題とリプレイス恩恵の共有 ● A-PJはリプレイスした後にやる方が効率的です 👉工数いだきたい 👉A-PJのスケジュールを後ろ倒しさせてもらいたい

Slide 18

Slide 18 text

初回の提案内容

Slide 19

Slide 19 text

Slide 20

Slide 20 text

提案内容：A-PJ開発をシステムリプレイスしながらやりたい提案内容を変える ● 新基盤を立ち上げながらA-PJ開発を行いたい 👉新基盤構築も兼ねるので工数を追加で確保させてください

Slide 21

Slide 21 text

提案内容を変える

Slide 22

Slide 22 text

● 新基盤を立ち上げながらA-PJ開発を行いたい 👉新基盤構築も兼ねるので工数を追加で確保させてください提案内容：A-PJ開発をシステムリプレイスしながらやりたい提案内容を変える

Slide 23

Slide 23 text

提案内容：A-PJ開発をシステムリプレイスしながらやりたい提案内容を変える 2 ● 新基盤を立ち上げながらA-PJ開発を行いたい ● 旧基盤と新基盤開発での工数の差を共有 👉結果的に新基盤開発の方が効率化されるので工数恩恵もあります

Slide 24

Slide 24 text

提案内容を変える 2 案件1 案件2 案件3 案件4 案件5 案件6 案件7 案件8

Slide 25

Slide 25 text

案件1 案件2 案件3 案件4 案件5 案件6 案件7 案件8 提案内容を変える 2

Slide 26

Slide 26 text

何となく了承は得られた雰囲気になったので、新基盤構築を兼ねた A-PJ開発準備を開始する ● 具体的設計の開始 ● 新基盤構築と案件開発のスケジュール落とし込み開始 ○ 数パターンのスケジュールとアサイン案を作成新基盤で実行する準備をする

Slide 27

Slide 27 text

何となく了承は得られた雰囲気になったので、新基盤構築を兼ねた A-PJ開発準備を開始する ● 具体的設計の開始 ● 新基盤構築と案件開発のスケジュール落とし込み開始 ○ 数パターンのスケジュールとアサイン案を作成 👉新基盤とA-PJ開発、へ開発構想のベースにしていく新基盤で実行する準備をする

Slide 28

Slide 28 text

何となく了承は得られた雰囲気になったので、新基盤構築を兼ねた A-PJ開発準備を開始する ● 具体的設計の開始 ● 新基盤構築と案件開発のスケジュール落とし込み開始 ○ 数パターンのスケジュールとアサイン案を作成しかしここまでで、反省点がある新基盤で実行する準備をする

Slide 29

Slide 29 text

【反省点】急な技術提案

Slide 30

Slide 30 text

システム改善の提案やその効果の裏付けは大事だが、急な提案自体を無くしていきたい ● 急な提案は良くも悪くも驚かれる ● そもそも「課題」や「改善したい」という意見が、自分だけに留まっていた事が問題 👉 普段の会話でシステムの話を日常的に出していく 👉 これらの意見を良く聞いていたアレねに近づける根回しが大事【反省点】急な技術提案＼偉大な先輩のアドバイス／

Slide 31

Slide 31 text

新基盤の設計いよいよ開発だリプレイスの提案新基盤の設計リプレイス後の収穫

Slide 32

Slide 32 text

● ECSコンテナ化 ● PHP・Laravelの最新を追える設計 ● 全面テストコード ● Laravelアプリケーション ○ モジュラーモノリスアーキテクチャ新基盤の方針

Slide 33

Slide 33 text

モジュラーモノリス

Slide 34

Slide 34 text

モジュラーモノリス検証もしてみた

Slide 35

Slide 35 text

モジュラーモノリスを導入したかった理由 ● チーム事情でマイクロサービス運用は困難なので、あくまでモノリスアプリケーションを用意したかった ● 今後マイクロサービス化を検討できるように、モジュール（サービス）単位で疎結合なモノリスアプリケーションを構築したかった ● Laravel-Modulesを利用することでモジュラーモノリスを比較的簡単に構築できる点

Slide 36

Slide 36 text

【決断】モジュラーモノリス導入をやめる

Slide 37

Slide 37 text

モジュラーモノリス導入をやめる ● 旧アプリケーション構造もそこまで複雑ではなかった ● モジュール化によるルール認識やスムーズな拡張、設計の複雑化がチームの運用スタイルに現在の段階では合わない・困難が予想 ● 導入しなくてもLaravelアプリケーションで且つバージョンアップしやすい基盤であること、テストが整備された環境を用意したいなどの、リプレイスへの目的は達成できると考えた 👉モジュラーモノリスの採用をしない事を決断

Slide 38

Slide 38 text

設計方針ざっくりまとめ ● 全面リファクタリング ● Dockerによるローカル開発環境 ● ECS稼働 ● 全面テストコード設置 ● PHPUnit・Larastan・PHP-CS-Fixer・ESlint・Stylelint・Vitestを利用したテスト・静的解析を導入 ● Github Actionsによる上記テスト・静的解析、及びデプロイ機構作成 ● 依存サードパーティの置き換え ● 定期的なcomposer update機構 ● Feature Toggle導入 ● APIモックを簡潔化 ● ライブラリを共通パッケージで外部管理 ● octocovs使ったカバレッジ値表示 ● セッションを旧CodeIgniterアプリと共有できるようにする ● Laravel Auditingを使ったログ排出 ● VRTを使った差分チェック

Slide 39

Slide 39 text

リプレイス後の収穫成果についてリプレイスの提案新基盤の設計リプレイス後の収穫

Slide 40

Slide 40 text

新基盤で運用コストの削減 ● テストコードの整備 ● 定期的なcomposer updateによるパッケージ更新 ● 全面リファクタリング・・・上記から運用恩恵が得られている

Slide 41

Slide 41 text

Slide 42

Slide 42 text

バージョンアップのコスト削減案件回数開発工数（人日）実際のテスト工数（人日）テストコードが無かった場合の開発・テスト工数（人日） composer update 毎日 0 0 ？？？ PHPバージョンアップ PHP8.2 👉 8.3 1 1 0 40〜50 Framework バージョンアップ Laravel10 👉 11 1 1 1 40〜50 計り知れない。テストコードが無かったら定期的なupdateは出来ないかも旧基盤や他チームでバージョンアップ時の工数

Slide 43

Slide 43 text

リードタイムの減少案件リードタイム平均h（初回コミットからマージまで） PR作成数新基盤 4 32.5 旧基盤 8.1 27

Slide 44

Slide 44 text

リードタイムの減少大幅なリードタイムの差が現れる成功！！！案件リードタイム平均h（初回コミットからマージまで） PR作成数新基盤 4 32.5 旧基盤 8.1 27

Slide 45

Slide 45 text

現れているリプレイスの恩恵テストコード整備により、工数をかけないバージョンアップ対応が可能処理の最適化により、実装やレビュー時間の短縮傾向がある

Slide 46

Slide 46 text

アウトプットインプット現れているリプレイスの恩恵テストコード整備により、工数をかけないバージョンアップ対応が可能処理の最適化により、実装やレビュー時間の短縮傾向がある ←開発によって生み出された価値 ←開発に投入したリソース生産性成果物投入した資源

Slide 47

Slide 47 text

現れているリプレイスの恩恵テストコード整備により、工数をかけないバージョンアップ対応が可能処理の最適化により、実装やレビュー時間の短縮傾向がある立派なコスト削減！アウトプットインプット生産性成果物投入した資源 ←開発に投入したリソース

Slide 48

Slide 48 text

まとめ

Slide 49

Slide 49 text

● リプレイスと効果含めた提案。開発思想は普段からアウトプット ● 設計時の、やる決断・やらない決断 ● 運用コスト面の恩恵まとめリプレイスの提案新基盤の設計リプレイス後の収穫

Slide 50

Slide 50 text

ご清聴ありがとうございました