Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
メンテが命: PHPフレームワークのコンテナ化とアップグレード戦略
Search
shunta ichikawa
February 21, 2025
Programming
0
120
メンテが命: PHPフレームワークのコンテナ化とアップグレード戦略
shunta ichikawa
February 21, 2025
Tweet
Share
More Decks by shunta ichikawa
See All by shunta ichikawa
20240711_RAGを用いたシンプルな 社内情報検索システムを導入した話とつらみ
shunta27
2
4.9k
Other Decks in Programming
See All in Programming
データベースのオペレーターであるCloudNativePGがStatefulSetを使わない理由に迫る
nnaka2992
0
150
『テスト書いた方が開発が早いじゃん』を解き明かす #phpcon_nagoya
o0h
PRO
2
200
Writing documentation can be fun with plugin system
okuramasafumi
0
120
時計仕掛けのCompose
mkeeda
1
300
Lottieアニメーションをカスタマイズしてみた
tahia910
0
130
Amazon S3 TablesとAmazon S3 Metadataを触ってみた / 20250201-jawsug-tochigi-s3tables-s3metadata
kasacchiful
0
160
負債になりにくいCSSをデザイナとつくるには?
fsubal
9
2.4k
Open source software: how to live long and go far
gaelvaroquaux
0
630
ARA Ansible for the teams
kksat
0
150
Formの複雑さに立ち向かう
bmthd
1
850
CSS Linter による Baseline サポートの仕組み
ryo_manba
1
100
クリーンアーキテクチャから見る依存の向きの大切さ
shimabox
1
240
Featured
See All Featured
Navigating Team Friction
lara
183
15k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
120k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
160
15k
Java REST API Framework Comparison - PWX 2021
mraible
28
8.4k
Building a Scalable Design System with Sketch
lauravandoore
461
33k
Site-Speed That Sticks
csswizardry
4
380
Designing for Performance
lara
604
68k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
4
410
Visualization
eitanlees
146
15k
RailsConf 2023
tenderlove
29
1k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
GraphQLとの向き合い方2022年版
quramy
44
13k
Transcript
メンテが命: PHPフレームワークのコンテナ化とアッ プグレード戦略 PHPカンファレンス名古屋2025
自己紹介 市川 俊太 いちかわ しゅんた (38歳) 株式会社助太刀 開発部 開発部長 •
猫が好き • 趣味はサッカー観戦 • Ruby/PHPなどのLL言語が好き • 三重県四日市出身、愛知県内の大学通ってました!
会社紹介 事業者間マッチング 協力会社探し 正社員採用 工事会社の人手不足を マッチングと 正社員採用で解決
アジェンダ 1. サービスは生き物だ 2. レガシー環境が生まれる理由 3. 解決するための3つのアプローチ
アジェンダ 1. サービスは生き物だ 2. レガシー環境が生まれる理由 3. 解決するための3つのアプローチ
サービスは生き物だ サービスは生き物(or 水物?)。放置すると...? ?
サービスは生き物だ 腐ります。(鮮度が落ちます )
ソフトウェアに例えると • PHP / アプリケーション(Laravelなど)/ データベース(MySQLなど)のバージョンが古い(EOL) • メンテされてないコード • AWSのインスタンスのスペックが古い
• インデックス管理がされていない 放置すると...?
ソフトウェアに例えると • PHP / アプリケーション(Laravelなど)/ データベース(MySQLなど)のバージョンが古い(EOL) => セキュリティリスク • メンテされてないコード
=> デプロイ(リリース)するのが怖い • AWSのインスタンスのスペックが古い => パフォーマンス低下 • インデックス管理がされていない => クエリが遅くなる
これが続くと... • リリースするのが怖くなる • (開発しにくいから)エンジニアが離職 • ユーザ体験が悪化(バグ・遅い・クラッシュなど)
アジェンダ 1. 自己紹介 2. サービスは生き物だ 3. レガシー環境が生まれる理由 4. 解決するための3つのアプローチ
レガシー環境が生まれる理由 • 動いているから放置 • 新機能開発が優先され、アップデートなどは後回し
動いているから放置 「壊れるリスクを負ってまで触りたくない」 「アップデートしなくても動いてるから大丈夫でしょ?」
動いているから放置 「壊れるリスクを負ってまで触りたくない」 「アップデートしなくても動いてるから大丈夫でしょ?」 動いてるから「このままで問題ない」という心理が働き放置
動いているから放置 「壊れるリスクを負ってまで触りたくない」 「アップデートしなくても動いてるから大丈夫でしょ?」 動いてるから「このままで問題ない」という心理が働き放置 突如、AWSからメールがやってきます...
動いているから放置 放置すると最悪データベースが止まります...
レガシー環境が生まれる理由 • 動いているから放置 • 新機能開発が優先され、アップデートなどは後回し
新機能開発が優先され、アップデートなどは後回し 「✅新機能開発」 「✅新機能開発」 「🚀 リリース」 「🚀 リリース」 「🛑アップデート後回し(忙しいから後で …)」
新機能開発が優先され、アップデートなどは後回し 「✅新機能開発」 「✅新機能開発」 「🚀 リリース」 「🚀 リリース」 「🛑アップデート後回し(忙しいから後で …)」 「AWSからメールも来てるし、アップグレードするか
…」
新機能開発が優先され、アップデートなどは後回し 「✅新機能開発」 「✅新機能開発」 「🚀 リリース」 「🚀 リリース」 「🛑アップデート後回し(忙しいから後で …)」 「❌いざ変更変更しようにも、影響範囲がわからない…」
「😨当時を知る人間もいない...」 変更が怖くなり、そのまま放置
アジェンダ 1. 自己紹介 2. サービスは生き物だ 3. レガシー環境が生まれる理由 4. 解決するための3つのアプローチ
解決するための3つのアプローチ 1. テストの導入(ユニット、機能テストなど) 2. コンテナ化 3. 継続的なアップグレード
1. テストの導入(ユニット、機能テストなど) テストが存在しないと... • コードを変更したら、別の場所でエラーが発生 • リファクタリング、バージョンアップの度に確認が大変 • 変更の度に手動テストを頑張ることになる
1. テストの導入(ユニット、機能テストなど) どうやって導入していくのか • テストがない環境で、いきなり理想的なテストを導入するのは難しい • 簡単なところから始める
1. テストの導入(ユニット、機能テストなど) どうやって導入していくのか • テストがない環境で、いきなり理想的なテストを導入するのは難しい • 簡単なところから始める 「小さくはじめる」のが大事
1. テストの導入(ユニット、機能テストなど) 例えば「ログインAPI」のレスポンスの機能テスト
1. テストの導入(ユニット、機能テストなど) 例えば「ログインAPI」のレスポンスの機能テスト • 最初は大味なテストでも良い ◦ 最初から全てのケースを網羅しよう としなくていい ◦ APIのレスポンスが期待通りかどう
かを確認するだけでいい • テストが習慣化されていることが大事 ◦ 最初は「最低限の動作確認」を意識
1. テストの導入(ユニット、機能テストなど) CI/CD に組み込んでテストを継続的に実行する • テストは書くだけでは意味がない => 継続的に実行することが重要 • CI/CDに組み込むことで
◦ コード変更時に自動テストが実行される ◦ テストの陳腐化を防ぐ
1. テストの導入(ユニット、機能テストなど) テストが存在すれば... • コードを変更したら、別の場所でエラーが発生 => 影響範囲が明確になり、エラーがすぐ検知できる • リファクタリング、バージョンアップの度に確認が大変 =>
テストがパスしていれば、既存の機能に大きな影響を与えずに変更できることが 確認できる • 変更の度に手動テストを頑張ることになる => 手動で行う必要はなく、テスト実行に関する負担を軽減
解決するための3つのアプローチ 1. テストの導入(ユニット、機能テストなど) 2. コンテナ化 3. 継続的なアップグレード
2. コンテナ化 • 環境差異によるエラー • デプロイの手間が増えることによるミス • ロールバックによるダウンタイム発生 コンテナ化しないと起こる問題
2. コンテナ化 なぜコンテナ化するのか 1. 環境の一貫性 2. スケーラビリティの向上、リソースの最適化 3. CI/CDパイプラインとの統合が容易
2. コンテナ化 • 環境差異によるエラー => コード管理されたイメージファイルを利用するだけ • デプロイの手間が増えることによるミス => GithubActionsなどのCI/CDパイプラインに統合することで
ビルド 🏭 => テスト✅ => デプロイ🚀 まで自動化(属人化なども排除) • ロールバックによるダウンタイム発生 => 過去のイメージをデプロイするだけ コンテナ化しないと起こる問題
解決するための3つのアプローチ 1. テストの導入(ユニット、機能テストなど) 2. コンテナ化 3. 継続的なアップグレード
3. 継続的なアップグレード 時間とともに通常開発とアップグレード作業の差が開いていく
3. 継続的なアップグレード 時間とともに通常開発とアップグレード作業の差が開いていく
• テスト・検証サイクルの高速化 ◦ CI/CDパイプラインにて自動実行 • ローカル環境での検証が容易 3. 継続的なアップグレード テストの導入とコンテナ化による開発・検証の効率化 通常開発と並行して、バージョンアップ作業もスムーズに実施可能
3. 継続的なアップグレード • データベースをバージョンアップ予定のコンテナイメージを利用する • PHPなども同様、バージョンアップ予定のコンテナイメージを利用する データベースやPHPのバージョンアップがしたい バージョンアップ予定のコンテナイメージを利用しテスト実行する
• PHP7.1 => PHP8.3 • Laravel5.8 => Laravel11 • 同時にMySQL5系
=> 8系 3. 継続的なアップグレード このアプローチを通して、通常の開発と並行しながら、 約3年間かけて… (無事故で)バージョンアップすることに成功🥳
サービスは生き物だ 鮮度を保つことができます
None
あなたはこの3つのアプローチなしで、バージョンアップを無 事故で行える自信がありますか?
とはいえ、やっていることは特別なことではなく...
テストとか、コンテナ化とかって
「やらなきゃならないことをやるだけさ、だからうまくいくんだ よ」 映画「アイデン&ティティ」(みうらじゅん原作)
皆様、ご清聴ありがとうございました!