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