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

by Yusuke Katsuki

Slide 1

Slide 1 text

株式会社ペライチ Peraichi Inc. ⼤規模サービスのCakePHP2.xを 4.xにジャンプアップした話 🎉 おかげさまで創業7周年︕ PHPer Kaigi 2022 ⾹⽉雄介

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

© Peraichi Inc. All Rights Reserved 4 ペライチについて誰でも簡単にホームページを作れるサービス「ペライチ」を展開しています。スマホ・タブレット対応検索エンジン最適化ニーズに応えるオプション安⼼のサポートペライチで作られたホームページはスマホ・タブレットでの表⽰に対応しています専⾨知識がなくても SEOに最適化したページの作成ができますオプション形式の料⾦プランで必要に応じた最適な形でご利⽤いただけますペライチはお客様からのお問い合わせに迅速に対応します

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

© Peraichi Inc. All Rights Reserved バージョンアップの背景これまでの背景 ■ 創業初期からCakePHP2.xを使⽤。新機能開発を優先してきたため保守の優先順位が低かった ■ また、CakePHP2からCakePHP3への変更差分が⼤きすぎてなかなか⼿をつけられずにいた当時の課題 ■ ⼀⽅でバージョンアップ対応しないことによる課題も⼤きくなってきた • Cake2.xのセキュリティサポート切れによるセキュリティリスクの上昇 • レガシーな技術だとエンジニア採⽤ができない課題解消のためにバージョンアップをすることに

Slide 8

Slide 8 text

© Peraichi Inc. All Rights Reserved CakePHP2バージョンアップの難所 CakePHP2系以降⼤きな変更点が発⽣。すんなりバージョンアップさせることが難しいバージョンアップというより、ほぼ作り直しになりそう ■ CakePHP2.x→3.xにおける差分が特に⼤きく、⼤幅な書き直しが必要に • ORMの連想配列がオブジェクトに • Model周りが⼤幅にリニューアル（QueryBuilder, Table, Entity） • ディレクトリ構造が⼤きく変更

Slide 9

Slide 9 text

Slide 10

Slide 10 text

© 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⽤で⽤意して並⾏稼動させるコストが⼤きい • 別⾔語となるため、並⾏稼動における運⽤⾯でのリスクが⼤きい。 ★

Slide 11

Slide 11 text

© Peraichi Inc. All Rights Reserved プロジェクトのリソース確保をどうするかリソース確保は、内製ではなく外部ベンダーに社内リソースによる内製の悩ましさ外部ベンダーへの委託のメリットオフショアベンダーとのラボ契約によりチーム組成することに • 新規の機能開発をストップすることはできない • 仮にやるとしたら新たな⼈材採⽤が必要だが、それには時間がかかる • ⼈材リソースを早く調達できる • 既にバージョンアップの知⾒がある • オフショア開発であれば⽐較的コストをかけずに開発が可能

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

© 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

Slide 18

Slide 18 text

© 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に振り分けを登録する必要がある ✖ 今回は選択せず

Slide 19

Slide 19 text

© Peraichi Inc. All Rights Reserved 移⾏の際のディレクトリ構成をどうするか新規開発を⽌めずに進める構成・移管⽅法は︖ 論点1 既存リポジトリのディレクトリの配下にCakePHP4.x⽤のサブディレクトリを配置し共存 peraichi - app - Config - Console - Controller … - peraichi_v4 - bin - config - src … 既存のCakePHP2ディレクトリ CakePHP4を配置

Slide 20

Slide 20 text

© Peraichi Inc. All Rights Reserved 移管⽅法をどうするか新規開発を⽌めずに進める構成・移管⽅法は︖ 論点1 2.xから4.xへの移管はControllerごとに実施。また、移管中は他チームにおける開発と移管対象にかぶりが⽣じないような運⽤を策定移管中の運⽤⽅針 ■ 基本的にController単位で移管する⽅針に • Controller単位だと移管完了ごとに機能テストが可能なため移管管理がしやすい • 運⽤としては、1ヶ⽉のスプリント単位で移管対象の Controllerを決め、社内の他チームに周知 • すべてのControllerをリストアップし、スプレッドシートで随時移管進捗を管理 • デグレ防⽌のため、他チームの開発予定と移管対象がかぶらないように随時調整他チームの開発マイグレーションチームの開発他チームの開発内容の取り込み移管対象がかぶった場合はマイグレーションチーム主導で随時取り込み他チームの機能開発と移管対象のかぶりを確認

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

© Peraichi Inc. All Rights Reserved PoCによる段階的詳細化移⾏にどれくらいの期間がかかるのか︖（必要な予算は︖）論点2 • プロジェクトの進⾏に応じて得られる情報が増え、より正確な⾒積りが可能に • PoCによりプロジェクトの論点を検証した上で移⾏フェーズに⼊るプロジェクト全体の⾒積もりはPoC完了後に実施引⽤︓プロジェクトマネジャーのための「プロセス設計術」 - プロジェクトの本質とはなにか︓ITpro （参考）不確実性コーン PoCによる段階的詳細化プロジェクトの初期段階の⾒積もりは、 4倍くらいの誤差が出る可能性がある PoC 移⾏フェーズ

Slide 24

Slide 24 text

© Peraichi Inc. All Rights Reserved ①全体コード量の計測⾒積もりの進め⽅移⾏にどれくらいの期間がかかるのか︖（必要な予算は︖）論点2 PoCでどのように⾒積もりを進めたか︖ ②プロジェクトチームの⽣産性の計測 ③全体コード量にかかる期間を計算 ■ 移管対象のコード量を計測 • コード⾏数計測ツール「cloc」を使って解析 • 移管対象のコードは約26万 LOC ※ LOC…空⾏、コメント、括弧のみの⾏などを除外した⾏数

Slide 25

Slide 25 text

© Peraichi Inc. All Rights Reserved ②プロジェクトチームの⽣産性の計測 ①全体コード量の計測⾒積もりの進め⽅移⾏にどれくらいの期間がかかるのか︖（必要な予算は︖）論点2 PoCでどのように⾒積もりを進めたか︖ ③全体コード量にかかる期間を計算 ■ PoCの中で影響範囲の少ない⼀部機能を実際に移管 • ⼩規模かつ社内管理者向けの機能を実際に移管することでチームの⽣産性を計算 • 例) 約500LOC/⼈⽇ ■ ⽣産性をもとに全体の⼯数を計算する • ②で計測した⽣産性をもとに、コード全体の移管にかかる⼯数を算出 • 例) 260,000 / 500 = 520⼈⽇ → 約26⼈⽉

Slide 26

Slide 26 text

Slide 27

Slide 27 text

© Peraichi Inc. All Rights Reserved 品質担保の⽅法移管の品質担保をどのように⾏うか︖ 論点3 移⾏中はスプリントごとに⼿動テストと⾃動テスト両⾯で品質担保を実施 ■ ⼿動テスト • 移管機能ごとにテスト仕様書起こしから対応 • プロジェクト専⽤のステージング環境を設置し、仕様書をもとにテスト ■ ⾃動テスト • もともとCake2で書いていたUnitTestを全て移管 • Seleniumによるリグレッションテストを⽇次で実⾏テスト仕様書の⼀例

Slide 28

Slide 28 text

Slide 29

Slide 29 text

© Peraichi Inc. All Rights Reserved 実⾏フェーズで意識したこと ■ 他チームにおけるCakePHP4系のキャッチアップ • 移管済のControllerに対する機能開発はCakePHP4系で実施するため、他チームも含めてCakePHP4系のキャッチアップをしてもらう必要があった • そのためにマイグレーションチーム主導での社内勉強会を実施 • また、他チームからのQAには都度応えるなど、既存チームの機能開発がスムーズにいくことを意識 ■ 後⽅互換性のない関数や、バージョンで動作が異なる機能はリストに都度追加してチーム内で横展開 • 事前に100%不具合を防⽌することは現実的でないため、不具合発⽣することを前提に発覚時に素早く切り戻しができる体制を意識 • 不具合発⽣後は再発防⽌のために、原因となった⾮互換機能の⼀覧化、横展開を随時実施