Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

Yusuke Katsuki

April 09, 2022
Tweet

More Decks by Yusuke Katsuki

Other Decks in Technology

Transcript

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

    View full-size slide

  2. © Peraichi Inc. All Rights Reserved
    ⽬次
    2
    • ⾃⼰紹介
    • バージョンアップの⼤⽅針
    • 計画策定(PoC)フェーズ
    • 本移⾏フェーズ

    View full-size slide

  3. © Peraichi Inc. All Rights Reserved
    3
    ⾃⼰紹介
    ⾹⽉ 雄介 @katsukii
    • 株式会社ペライチ Co-Founder 取締役CTO
    • 2014年にペライチ社を共同創業
    • 創業時からプロダクト開発全般を管掌
    • プロダクト開発→開発組織づくり→採⽤広報

    View full-size slide

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

    View full-size slide

  5. © Peraichi Inc. All Rights Reserved
    本⽇お話する内容
    5
    • ⾃⼰紹介
    • バージョンアップの⼤⽅針
    • 計画策定(PoC)フェーズ
    • 本移⾏フェーズ
    CakePHP2.xから4.xにバージョン
    アップした背景と、その⽅法について
    お話します

    View full-size slide

  6. © Peraichi Inc. All Rights Reserved
    ⽬次
    6
    • ⾃⼰紹介
    • バージョンアップの⼤⽅針
    • 計画策定(PoC)フェーズ
    • 本移⾏フェーズ

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  9. © Peraichi Inc. All Rights Reserved
    そもそもバージョンアップで対応すべきか(1/2)
    ほぼ作り直しならバージョンアップじゃなくて別FWでリプレイスする選択肢もあるので
    は︖
    改めてバージョンアップかリプレイスか検討する必要がある
    素直に対応するならこれ FWとして⼈気かつ便利らしい 社内に知⾒があり

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  12. © Peraichi Inc. All Rights Reserved
    リソース確保をどうするか
    オフショア会社とのマイグレーションチームを組成
    オフショアベンダー
    現⾏開発チーム
    マイグレーション(移管)チーム
    プロジェクト
    マネージャ
    ラボチーム
    連携
    連携

    View full-size slide

  13. © Peraichi Inc. All Rights Reserved
    進め⽅の⽅針
    プロジェクト全体の進め⽅としては、まずPoCを実施しその後本移⾏という流れで進⾏
    PoCフェーズ 移⾏フェーズ
    本格的な移⾏に⼊る前主要な論点を検証することで
    プロジェクトのフィジビリティおよび⾒積もり精度向上を図る

    View full-size slide

  14. © Peraichi Inc. All Rights Reserved
    ⽬次
    14
    • ⾃⼰紹介
    • バージョンアップの⼤⽅針
    • 計画策定(PoC)フェーズ
    • 本移⾏フェーズ

    View full-size slide

  15. © Peraichi Inc. All Rights Reserved
    バージョンアップにおける主な論点
    • 新規開発を⽌めずに進める構成・移管⽅法は︖
    • 移⾏にどれくらいの期間がかかるのか︖(必要な予算は︖)
    • 移⾏中の品質担保をどのように⾏うか︖
    PoCでは⼤きく3つの論点について検証
    論点1
    論点2
    論点3

    View full-size slide

  16. © Peraichi Inc. All Rights Reserved
    バージョンアップにおける主な論点
    新規開発を⽌めずに進める構成・移管⽅法は︖
    移⾏にどれくらいの期間がかかるのか︖(必要な予算は︖)
    移⾏中の品質担保をどのように⾏うか︖
    PoCでは⼤きく3つの論点について検証
    論点1
    論点2
    論点3

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

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

    - peraichi_v4
    - bin
    - config
    - src

    既存のCakePHP2ディレクトリ
    CakePHP4を配置

    View full-size slide

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

    View full-size slide

  21. © Peraichi Inc. All Rights Reserved
    バージョンアップにおける主な論点
    新規開発を⽌めずに進める構成・移管⽅法は︖
    移⾏にどれくらいの期間がかかるのか︖(必要な予算は︖)
    移⾏中の品質担保をどのように⾏うか︖
    PoCでは⼤きく3つの論点について検証
    論点1
    論点2
    論点3

    View full-size slide

  22. © Peraichi Inc. All Rights Reserved
    移⾏期間の⾒積もりと予算
    移⾏にどれくらいの期間がかかるのか︖(必要な予算は︖)
    論点2
    そもそも、不確実性の⾼いプロジェクトの予算をどうやってとればいいのか︖
    移⾏期間 不確実性

    不確実性を解消しないと、プロジェクト全体で
    どれくらいの⼯数・期間がかかるかわからない

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  26. © Peraichi Inc. All Rights Reserved
    バージョンアップにおける主な論点
    新規開発を⽌めずに進める構成・移管⽅法は︖
    移⾏にどれくらいの期間がかかるのか︖(必要な予算は︖)
    移⾏中の品質担保をどのように⾏うか︖
    PoCでは⼤きく3つの論点について検証
    論点1
    論点3
    論点2

    View full-size slide

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

    View full-size slide

  28. © Peraichi Inc. All Rights Reserved
    ⽬次
    29
    • ⾃⼰紹介
    • バージョンアップの⼤⽅針
    • 計画策定(PoC)フェーズ
    • 本移⾏フェーズ

    View full-size slide

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

    View full-size slide

  30. © Peraichi Inc. All Rights Reserved
    そして
    ついに今⽉移管完了予定(現在進捗98%くらい)
    PoC 移⾏
    2021.06
    環境構築&
    論点検証開始
    2021年8⽉
    移⾏開始
    保守対応
    2022年2⽉
    最終リリース
    2022年4⽉
    完了予定
    準備
    2021.05
    契約&
    キックオフ

    View full-size slide

  31. © Peraichi Inc. All Rights Reserved
    宣伝
    ① エンジニア募集しています ② テックブログやってます
    ペライチ Tech blog
    zenn.dev/peraichi
    コーポレートサイトの「採⽤情報」をご覧ください
    peraichi.co.jp

    View full-size slide

  32. テクノロジーをすべての⼈が使える世界に

    View full-size slide