メンテが命: PHPフレームワークのコンテナ化とアップグレード戦略

Transcript

1. メンテが命: PHPフレームワークのコンテナ化とアッ プグレード戦略 PHPカンファレンス名古屋2025
2. 自己紹介 市川 俊太 いちかわ しゅんた (38歳) 株式会社助太刀 開発部 開発部長 • 猫が好き • 趣味はサッカー観戦 • Ruby/PHPなどのLL言語が好き • 三重県四日市出身、愛知県内の大学通ってました！
3. 会社紹介 事業者間マッチング 協力会社探し 正社員採用 工事会社の人手不足を マッチングと 正社員採用で解決
4. アジェンダ 1. サービスは生き物だ 2. レガシー環境が生まれる理由 3. 解決するための3つのアプローチ
5. アジェンダ 1. サービスは生き物だ 2. レガシー環境が生まれる理由 3. 解決するための3つのアプローチ
6. サービスは生き物だ サービスは生き物（or 水物?）。放置すると...? ?
7. サービスは生き物だ 腐ります。（鮮度が落ちます ）
8. ソフトウェアに例えると • PHP / アプリケーション（Laravelなど）/ データベース（MySQLなど）のバージョンが古い（EOL） • メンテされてないコード • AWSのインスタンスのスペックが古い • インデックス管理がされていない 放置すると...?
9. ソフトウェアに例えると • PHP / アプリケーション（Laravelなど）/ データベース（MySQLなど）のバージョンが古い（EOL） => セキュリティリスク • メンテされてないコード => デプロイ（リリース）するのが怖い • AWSのインスタンスのスペックが古い => パフォーマンス低下 • インデックス管理がされていない => クエリが遅くなる
10. これが続くと... • リリースするのが怖くなる • （開発しにくいから）エンジニアが離職 • ユーザ体験が悪化（バグ・遅い・クラッシュなど）
11. アジェンダ 1. 自己紹介 2. サービスは生き物だ 3. レガシー環境が生まれる理由 4. 解決するための3つのアプローチ
12. レガシー環境が生まれる理由 • 動いているから放置 • 新機能開発が優先され、アップデートなどは後回し
13. 動いているから放置 「壊れるリスクを負ってまで触りたくない」 「アップデートしなくても動いてるから大丈夫でしょ？」
14. 動いているから放置 「壊れるリスクを負ってまで触りたくない」 「アップデートしなくても動いてるから大丈夫でしょ？」 動いてるから「このままで問題ない」という心理が働き放置
15. 動いているから放置 「壊れるリスクを負ってまで触りたくない」 「アップデートしなくても動いてるから大丈夫でしょ？」 動いてるから「このままで問題ない」という心理が働き放置 突如、AWSからメールがやってきます...
16. 動いているから放置 放置すると最悪データベースが止まります...
17. レガシー環境が生まれる理由 • 動いているから放置 • 新機能開発が優先され、アップデートなどは後回し
18. 新機能開発が優先され、アップデートなどは後回し 「✅新機能開発」 「✅新機能開発」 「🚀 リリース」 「🚀 リリース」 「🛑アップデート後回し（忙しいから後で …）」
19. 新機能開発が優先され、アップデートなどは後回し 「✅新機能開発」 「✅新機能開発」 「🚀 リリース」 「🚀 リリース」 「🛑アップデート後回し（忙しいから後で …）」 「AWSからメールも来てるし、アップグレードするか …」
20. 新機能開発が優先され、アップデートなどは後回し 「✅新機能開発」 「✅新機能開発」 「🚀 リリース」 「🚀 リリース」 「🛑アップデート後回し（忙しいから後で …）」 「❌いざ変更変更しようにも、影響範囲がわからない…」 「😨当時を知る人間もいない...」 変更が怖くなり、そのまま放置
21. アジェンダ 1. 自己紹介 2. サービスは生き物だ 3. レガシー環境が生まれる理由 4. 解決するための3つのアプローチ
22. 解決するための3つのアプローチ 1. テストの導入（ユニット、機能テストなど） 2. コンテナ化 3. 継続的なアップグレード
23. 1. テストの導入（ユニット、機能テストなど） テストが存在しないと... • コードを変更したら、別の場所でエラーが発生 • リファクタリング、バージョンアップの度に確認が大変 • 変更の度に手動テストを頑張ることになる
24. 1. テストの導入（ユニット、機能テストなど） どうやって導入していくのか • テストがない環境で、いきなり理想的なテストを導入するのは難しい • 簡単なところから始める
25. 1. テストの導入（ユニット、機能テストなど） どうやって導入していくのか • テストがない環境で、いきなり理想的なテストを導入するのは難しい • 簡単なところから始める 「小さくはじめる」のが大事
26. 1. テストの導入（ユニット、機能テストなど） 例えば「ログインAPI」のレスポンスの機能テスト
27. 1. テストの導入（ユニット、機能テストなど） 例えば「ログインAPI」のレスポンスの機能テスト • 最初は大味なテストでも良い ◦ 最初から全てのケースを網羅しよう としなくていい ◦ APIのレスポンスが期待通りかどう かを確認するだけでいい • テストが習慣化されていることが大事 ◦ 最初は「最低限の動作確認」を意識
28. 1. テストの導入（ユニット、機能テストなど） CI/CD に組み込んでテストを継続的に実行する • テストは書くだけでは意味がない => 継続的に実行することが重要 • CI/CDに組み込むことで ◦ コード変更時に自動テストが実行される ◦ テストの陳腐化を防ぐ
29. 1. テストの導入（ユニット、機能テストなど） テストが存在すれば... • コードを変更したら、別の場所でエラーが発生 => 影響範囲が明確になり、エラーがすぐ検知できる • リファクタリング、バージョンアップの度に確認が大変 => テストがパスしていれば、既存の機能に大きな影響を与えずに変更できることが 確認できる • 変更の度に手動テストを頑張ることになる => 手動で行う必要はなく、テスト実行に関する負担を軽減
30. 解決するための3つのアプローチ 1. テストの導入（ユニット、機能テストなど） 2. コンテナ化 3. 継続的なアップグレード
31. 2. コンテナ化 • 環境差異によるエラー • デプロイの手間が増えることによるミス • ロールバックによるダウンタイム発生 コンテナ化しないと起こる問題
32. 2. コンテナ化 なぜコンテナ化するのか 1. 環境の一貫性 2. スケーラビリティの向上、リソースの最適化 3. CI/CDパイプラインとの統合が容易
33. 2. コンテナ化 • 環境差異によるエラー => コード管理されたイメージファイルを利用するだけ • デプロイの手間が増えることによるミス => GithubActionsなどのCI/CDパイプラインに統合することで ビルド 🏭 => テスト✅ => デプロイ🚀 まで自動化（属人化なども排除） • ロールバックによるダウンタイム発生 => 過去のイメージをデプロイするだけ コンテナ化しないと起こる問題
34. 解決するための3つのアプローチ 1. テストの導入（ユニット、機能テストなど） 2. コンテナ化 3. 継続的なアップグレード
35. 3. 継続的なアップグレード 時間とともに通常開発とアップグレード作業の差が開いていく
36. 3. 継続的なアップグレード 時間とともに通常開発とアップグレード作業の差が開いていく
37. • テスト・検証サイクルの高速化 ◦ CI/CDパイプラインにて自動実行 • ローカル環境での検証が容易 3. 継続的なアップグレード テストの導入とコンテナ化による開発・検証の効率化 通常開発と並行して、バージョンアップ作業もスムーズに実施可能
38. 3. 継続的なアップグレード • データベースをバージョンアップ予定のコンテナイメージを利用する • PHPなども同様、バージョンアップ予定のコンテナイメージを利用する データベースやPHPのバージョンアップがしたい バージョンアップ予定のコンテナイメージを利用しテスト実行する
39. • PHP7.1 => PHP8.3 • Laravel5.8 => Laravel11 • 同時にMySQL5系 => 8系 3. 継続的なアップグレード このアプローチを通して、通常の開発と並行しながら、 約3年間かけて… （無事故で）バージョンアップすることに成功🥳
40. サービスは生き物だ 鮮度を保つことができます
42. あなたはこの3つのアプローチなしで、バージョンアップを無 事故で行える自信がありますか？
43. とはいえ、やっていることは特別なことではなく...
44. テストとか、コンテナ化とかって
45. 「やらなきゃならないことをやるだけさ、だからうまくいくんだ よ」 映画「アイデン&ティティ」（みうらじゅん原作）
46. 皆様、ご清聴ありがとうございました！