大規模サービスのCakePHP2.xを4.xにジャンプアップした話

https://fortee.jp/phperkaigi-2022/proposal/400cae97-9c03-4faa-948f-4bfa651b42b9

2022.04.10 PHPerKaigi 2022 #phperkaigi

Transcript

1. 株式会社ペライチ Peraichi Inc. ⼤規模サービスのCakePHP2.xを 4.xにジャンプアップした話 🎉 おかげさまで創業7周年︕ PHPer Kaigi 2022 ⾹⽉ 雄介
2. © Peraichi Inc. All Rights Reserved ⽬次 2 • ⾃⼰紹介 • バージョンアップの⼤⽅針 • 計画策定（PoC）フェーズ • 本移⾏フェーズ
3. © Peraichi Inc. All Rights Reserved 3 ⾃⼰紹介 ⾹⽉ 雄介 @katsukii • 株式会社ペライチ Co-Founder 取締役CTO • 2014年にペライチ社を共同創業 • 創業時からプロダクト開発全般を管掌 • プロダクト開発→開発組織づくり→採⽤広報
4. © Peraichi Inc. All Rights Reserved 4 ペライチについて 誰でも簡単にホームページを作れるサービス「ペライチ」を展開しています。 スマホ・ タブレット対応 検索エンジン 最適化 ニーズに応える オプション 安⼼の サポート ペライチで作られたホームページは スマ ホ・タブレットでの表⽰に対応しています 専⾨知識がなくても SEOに最適化した ページの作成ができます オプション形式の料⾦プランで 必要に応じた最適な形で ご利⽤いただけます ペライチはお客様からの お問い合わせに 迅速に対応します
5. © Peraichi Inc. All Rights Reserved 本⽇お話する内容 5 • ⾃⼰紹介 • バージョンアップの⼤⽅針 • 計画策定（PoC）フェーズ • 本移⾏フェーズ CakePHP2.xから4.xにバージョン アップした背景と、その⽅法について お話します
6. © Peraichi Inc. All Rights Reserved ⽬次 6 • ⾃⼰紹介 • バージョンアップの⼤⽅針 • 計画策定（PoC）フェーズ • 本移⾏フェーズ
7. © Peraichi Inc. All Rights Reserved バージョンアップの背景 これまでの背景 ▪ 創業初期からCakePHP2.xを使⽤。新機能開発を優先してきたため保 守の優先順位が低かった ▪ また、CakePHP2からCakePHP3への変更差分が⼤きすぎてなかなか ⼿をつけられずにいた 当時の課題 ▪ ⼀⽅でバージョンアップ対応しないことによる課題も⼤きくなってきた • Cake2.xのセキュリティサポート切れによるセキュリティリスクの上昇 • レガシーな技術だとエンジニア採⽤ができない 課題解消のためにバージョンアップをすることに
8. © Peraichi Inc. All Rights Reserved CakePHP2バージョンアップの難所 CakePHP2系以降⼤きな変更点が発⽣。すんなりバージョンアップさせることが難しい バージョンアップというより、ほぼ作り直しになりそう ▪ CakePHP2.x→3.xにおける差分が特に⼤きく、⼤幅な書き直しが必要に • ORMの連想配列がオブジェクトに • Model周りが⼤幅にリニューアル（QueryBuilder, Table, Entity） • ディレクトリ構造が⼤きく変更
9. © Peraichi Inc. All Rights Reserved そもそもバージョンアップで対応すべきか（1/2） ほぼ作り直しならバージョンアップじゃなくて別FWでリプレイスする選択肢もあるので は︖ 改めてバージョンアップかリプレイスか検討する必要がある 素直に対応するならこれ FWとして⼈気かつ便利らしい 社内に知⾒があり
10. © Peraichi Inc. All Rights Reserved そもそもバージョンアップで対応すべきか（2/2） CakePHPの他にLaravel, Ruby on Railsを候補として検討した結果、CakePHP を選択 Pros Cons CakePHP • バージョンアップによる変更を差し引いて も社内に知⾒があり使い慣れている • 認証基盤など再利⽤できる機能が多い ため、移管コストがもっともかからない • 2.xと4.xの共存環境での並⾏稼動 がしやすい • ⼀応、OSSコミュニティは根強くサポート は存在する • 他の候補と⽐較して、相対的に利便性が弱い • FWとして以前ほど⼈気がないため、今後のエンジニア採⽤⼒がジリ貧に なる可能性 Laravel • PHPのMVCフレームワークとしては絶⼤ な⼈気のため今後採⽤に有利 • FWとしての利便性は⾼そう • 社内に知⾒がないため、キャッチアップが必要かつ品質の評価 • FW⾃体が別物となるため Ruby on Rails • 社内での開発経験あるためキャッチアッ プは不要 • CakePHPよりgemが豊富であり、利便 性は⾼い • 移管コストが最も⼤きい • リポジトリ⾃体を分ける必要があるため移管中の運⽤管理が複雑に • インフラをPHP⽤とRuby⽤で⽤意して並⾏稼動させるコストが⼤きい • 別⾔語となるため、並⾏稼動における運⽤⾯でのリスクが⼤きい。 ★
11. © Peraichi Inc. All Rights Reserved プロジェクトのリソース確保をどうするか リソース確保は、内製ではなく外部ベンダーに 社内リソース による内製の 悩ましさ 外部ベンダー への委託の メリット オフショアベンダーとのラボ契約によりチーム組成することに • 新規の機能開発をストップすることは できない • 仮にやるとしたら新たな⼈材採⽤が 必要だが、それには時間がかかる • ⼈材リソースを早く調達できる • 既にバージョンアップの知⾒がある • オフショア開発であれば⽐較的コスト をかけずに開発が可能
12. © Peraichi Inc. All Rights Reserved リソース確保をどうするか オフショア会社とのマイグレーションチームを組成 オフショアベンダー 現⾏開発チーム マイグレーション(移管)チーム プロジェクト マネージャ ラボチーム 連携 連携
13. © Peraichi Inc. All Rights Reserved 進め⽅の⽅針 プロジェクト全体の進め⽅としては、まずPoCを実施しその後本移⾏という流れで進⾏ PoCフェーズ 移⾏フェーズ 本格的な移⾏に⼊る前主要な論点を検証することで プロジェクトのフィジビリティおよび⾒積もり精度向上を図る
14. © Peraichi Inc. All Rights Reserved ⽬次 14 • ⾃⼰紹介 • バージョンアップの⼤⽅針 • 計画策定（PoC）フェーズ • 本移⾏フェーズ
15. © Peraichi Inc. All Rights Reserved バージョンアップにおける主な論点 • 新規開発を⽌めずに進める構成・移管⽅法は︖ • 移⾏にどれくらいの期間がかかるのか︖（必要な予算は︖） • 移⾏中の品質担保をどのように⾏うか︖ PoCでは⼤きく3つの論点について検証 論点1 論点2 論点3
16. © Peraichi Inc. All Rights Reserved バージョンアップにおける主な論点 新規開発を⽌めずに進める構成・移管⽅法は︖ 移⾏にどれくらいの期間がかかるのか︖（必要な予算は︖） 移⾏中の品質担保をどのように⾏うか︖ PoCでは⼤きく3つの論点について検証 論点1 論点2 論点3
17. © Peraichi Inc. All Rights Reserved Cake4リポジトリ peraichiリポジトリ 移⾏の際のシステム構成をどうするか 新規開発を⽌めずに進める構成・移管⽅法は︖ 論点1 移⾏中のシステム構成について2案を検討 CakePHP2 CakePHP4 nginx .conf 案1. 同⼀リポジトリ内での管理 案2. リポジトリを分けサーバーごと分離 • 同⼀サーバーに共存環境を構築しroutingに て振り分け ユーザー DB • 移管元, 移管先それぞれ別のEC2を⽤意し ALBにて振り分けを管理 Cake2リポジトリ CakePHP2⽤ EC2 CakePHP4⽤ EC2 ALB ユーザー Session DB Session
18. © Peraichi Inc. All Rights Reserved peraichiリポジトリ 移⾏の際のシステム構成をどうするか 新規開発を⽌めずに進める構成・移管⽅法は︖ 論点1 移⾏中のシステム構成について2案を検討 CakePHP2 CakePHP4 nginx .conf 案1. 同⼀リポジトリ内での管理 案2. リポジトリを分けサーバーごと分離 • 同⼀サーバーに共存環境を構築しroutingに て振り分け ユーザー DB • 移管元, 移管先それぞれ別のEC2を⽤意し ALBにて振り分けを管理 振り分けの管理が容易。切り戻しも githubのPRをrevertするだけ ◯ 今回はこちらを選択 Session DB Session Cake4リポジトリ Cake2リポジトリ CakePHP2⽤ EC2 CakePHP4⽤ EC2 ALB ユーザー 移管するごとにALBに振り分けを登 録する必要がある ✖ 今回は選択せず
19. © Peraichi Inc. All Rights Reserved 移⾏の際のディレクトリ構成をどうするか 新規開発を⽌めずに進める構成・移管⽅法は︖ 論点1 既存リポジトリのディレクトリの配下にCakePHP4.x⽤のサブディレクトリを配置し共存 peraichi - app - Config - Console - Controller … - peraichi_v4 - bin - config - src … 既存のCakePHP2ディレクトリ CakePHP4を配置
20. © Peraichi Inc. All Rights Reserved 移管⽅法をどうするか 新規開発を⽌めずに進める構成・移管⽅法は︖ 論点1 2.xから4.xへの移管はControllerごとに実施。また、移管中は他チームにおける開 発と移管対象にかぶりが⽣じないような運⽤を策定 移管中の運⽤⽅針 ▪ 基本的にController単位で移管する⽅針に • Controller単位だと移管完了ごとに機能テストが 可能なため移管管理がしやすい • 運⽤としては、1ヶ⽉のスプリント単位で移管対象の Controllerを決め、社内の他チームに周知 • すべてのControllerをリストアップし、スプレッドシート で随時移管進捗を管理 • デグレ防⽌のため、他チームの開発予定と移管対 象がかぶらないように随時調整 他チームの開発 マイグレーションチームの開発 他チームの開発 内容の取り込み 移管対象がかぶった場合は マイグレーションチーム主導で随時取り込み 他チームの機能開発と 移管対象のかぶりを確認
21. © Peraichi Inc. All Rights Reserved バージョンアップにおける主な論点 新規開発を⽌めずに進める構成・移管⽅法は︖ 移⾏にどれくらいの期間がかかるのか︖（必要な予算は︖） 移⾏中の品質担保をどのように⾏うか︖ PoCでは⼤きく3つの論点について検証 論点1 論点2 論点3
22. © Peraichi Inc. All Rights Reserved 移⾏期間の⾒積もりと予算 移⾏にどれくらいの期間がかかるのか︖（必要な予算は︖） 論点2 そもそも、不確実性の⾼いプロジェクトの予算をどうやってとればいいのか︖ 移⾏期間 不確実性 ︖ 不確実性を解消しないと、プロジェクト全体で どれくらいの⼯数・期間がかかるかわからない
23. © Peraichi Inc. All Rights Reserved PoCによる段階的詳細化 移⾏にどれくらいの期間がかかるのか︖（必要な予算は︖） 論点2 • プロジェクトの進⾏に応じて得られる情報 が増え、より正確な⾒積りが可能に • PoCによりプロジェクトの論点を検証した 上で移⾏フェーズに⼊る プロジェクト全体の⾒積もりはPoC完了後に実施 引⽤︓プロジェクトマネジャーのための「プロセス設計 術」 - プロジェクトの本質とはなにか︓ITpro （参考）不確実性コーン PoCによる段階的詳細化 プロジェクトの初期段階の⾒積もりは、 4倍くらいの誤差が出る可能性がある PoC 移⾏フェーズ
24. © Peraichi Inc. All Rights Reserved ①全体コード量の計測 ⾒積もりの進め⽅ 移⾏にどれくらいの期間がかかるのか︖（必要な予算は︖） 論点2 PoCでどのように⾒積もりを進めたか︖ ②プロジェクトチーム の⽣産性の計測 ③全体コード量にかかる 期間を計算 ▪ 移管対象のコード量を計測 • コード⾏数計測ツール「cloc」 を使って解析 • 移管対象のコードは約26万 LOC ※ LOC…空⾏、コメント、括弧のみの⾏などを除外 した⾏数
25. © Peraichi Inc. All Rights Reserved ②プロジェクトチーム の⽣産性の計測 ①全体コード量の計測 ⾒積もりの進め⽅ 移⾏にどれくらいの期間がかかるのか︖（必要な予算は︖） 論点2 PoCでどのように⾒積もりを進めたか︖ ③全体コード量にかかる 期間を計算 ▪ PoCの中で影響範囲の少ない⼀部機能を実際に移管 • ⼩規模かつ社内管理者向けの機能を実際に移管するこ とでチームの⽣産性を計算 • 例) 約500LOC/⼈⽇ ▪ ⽣産性をもとに全体の⼯数を計算する • ②で計測した⽣産性をもとに、コード全体の移管にかかる ⼯数を算出 • 例) 260,000 / 500 = 520⼈⽇ → 約26⼈⽉
26. © Peraichi Inc. All Rights Reserved バージョンアップにおける主な論点 新規開発を⽌めずに進める構成・移管⽅法は︖ 移⾏にどれくらいの期間がかかるのか︖（必要な予算は︖） 移⾏中の品質担保をどのように⾏うか︖ PoCでは⼤きく3つの論点について検証 論点1 論点3 論点2
27. © Peraichi Inc. All Rights Reserved 品質担保の⽅法 移管の品質担保をどのように⾏うか︖ 論点3 移⾏中はスプリントごとに⼿動テストと⾃動テスト両⾯で品質担保を実施 ▪ ⼿動テスト • 移管機能ごとにテスト仕様書起こしから対応 • プロジェクト専⽤のステージング環境を設置し、仕 様書をもとにテスト ▪ ⾃動テスト • もともとCake2で書いていたUnitTestを全て移管 • Seleniumによるリグレッションテストを⽇次で実⾏ テスト仕様書の⼀例
28. © Peraichi Inc. All Rights Reserved ⽬次 29 • ⾃⼰紹介 • バージョンアップの⼤⽅針 • 計画策定（PoC）フェーズ • 本移⾏フェーズ
29. © Peraichi Inc. All Rights Reserved 実⾏フェーズで意識したこと ▪ 他チームにおけるCakePHP4系のキャッチアップ • 移管済のControllerに対する機能開発はCakePHP4系で実施するため、他チームも 含めてCakePHP4系のキャッチアップをしてもらう必要があった • そのためにマイグレーションチーム主導での社内勉強会を実施 • また、他チームからのQAには都度応えるなど、既存チームの機能開発がスムーズにいく ことを意識 ▪ 後⽅互換性のない関数や、バージョンで動作が異なる機能はリストに都度追加してチ ーム内で横展開 • 事前に100%不具合を防⽌することは現実的でないため、不具合発⽣することを前提 に発覚時に素早く切り戻しができる体制を意識 • 不具合発⽣後は再発防⽌のために、原因となった⾮互換機能の⼀覧化、横展開を 随時実施
30. © Peraichi Inc. All Rights Reserved そして ついに今⽉移管完了予定（現在進捗98％くらい） PoC 移⾏ 2021.06 環境構築& 論点検証開始 2021年8⽉ 移⾏開始 保守対応 2022年2⽉ 最終リリース 2022年4⽉ 完了予定 準備 2021.05 契約& キックオフ
31. © Peraichi Inc. All Rights Reserved 宣伝 ① エンジニア募集しています ② テックブログやってます ペライチ Tech blog zenn.dev/peraichi コーポレートサイトの「採⽤情報」をご覧ください peraichi.co.jp
32. テクノロジーをすべての⼈が使える世界に