Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
バーチー / GMO PEPABO inc. 2017.10.08 / PHPカンファレンス2017
できるPHP7アップグレード
PHP5.2からPHP7.1にアップグレード!
4
•PHP5.2から7.1へアップグレードする困難
•PHPアップグレードを安全かつ短期間で遂行するための計画と戦略 •PHPアップグレードのその後
今日お話すること
5
•特定バージョンにおける課題の解決方法
話さないこと
6
•PHPアップグレードの流れを理解してイメージが湧く
•PHPアップグレード検討中の方の後押しをする
ゴール
7
PHP5.2から7.1へアップグレードする困難
•サービス開始から8年目 •PHP 5.2
•Composerが使えない
•PEARを利用した独自フレームワーク
•ユニットテスト カバレッジ率 1%未満(感覚値)
PHPアプリケーション
9
(2016年10月当時)
アップグレード対象は4ロール
10
top
機能 サービス紹介ユーザー申し込み
ホームページ作成契約 ホームページ閲覧 バッチ処理
メール配信
PHPバージョン 5.2 5.2 5.2 5.2
PHPコード行数 4万 25万 6万 4万
admin shop stats
① PHP 7.0.0 MySQL関数削除 アプリケーション全体でMySQL関数を使用 約260箇所のPDO切り替え
② PHP 5.4.0 マジッククォート削除 SQLを文字列結合している。SQLインジェクション対策のため、約230箇所のプレースホルダー化
当初から分かっていた課題は3つ
11
③ PHP5.2 から 7.1間の仕様変更、 下位互換性のない変更点の全容 を知らない
当初から分かっていた課題は3つ
12
もう一つ困難があります
13
作業許可をもらうこと
14
•現状でも「開発は」出来る
•開発リソースが足りない
•KPI改善や機能開発優先
理解されにくいアップグレード業務
15
•ユーザーメリット •タイミング
説得のポイント
16
ユーザーメリット
17http://php.net/releases/7_0_0.php
•PHP 7.0.0で2倍高速化! •開発効率改善で開発スピード向上! •安定サービス提供
•2016年前期にお申し込み数2倍に! •更なる成長のためエンジニア数2.5倍に!
タイミング:いい波が来た
18https://speakerdeck.com/hypermkt/timuquan-yuan-deoshen-siip-mishu-wo2bei-nisitahua
サービスの更なる発展、安定・安全・高速なサービス提供、そして開発スピード改善のため、
PHPのアップグレードをさせてください!
いいよ!
PHP7.1化が決定
20
•アップグレード対象の4ロールをPHP5.2からPHP7.1にする
ゴール
21
スケジュールを立てよう
•スケジュール
•担当者
•見積もり
•着手順序
•リリース目安
決めること
23
開発 @hypermkt
Goope開発経験2年以上のエンジニア2名
24
インフラ @hfm
アップグレード対象は4ロール
25
top
機能 サービス紹介ユーザー申し込み
ホームページ作成契約 ホームページ閲覧 バッチ処理
メール配信
PHPバージョン 5.2 5.2 5.2 5.2
PHPコード行数 4万 25万 6万 4万
admin shop stats
どこから着手すべきか?
26
簡単かつ短期間で完了出来るものから着手しよう!
27
結論
•我々はPHPアップグレード未経験者
•特定バージョンの課題解決法や効率的な作業手順を知らない
•まずは1回PHPアップグレードを経験することで、 一通りの課題解決方法を学び、非効率な方法も経験する
•次からは作業の効率化と作業時間軽減も出来る!
なぜか
28
ぴーえいちぴー
MySQL関数の削除ならお任せください!
ereg系関数は一発置換で仕留めるぜ
どうやって難易度を測るか?
30
•ユーザー影響度(= リスク)が小さいもの
•PHPコード行数が少ない
•検証が楽なもの(バッチ処理は手間)
難易度の決め方
31
難易度top
機能 サービス紹介ユーザー申し込み ホームページ閲覧 ホームページ作成
決済
ユーザー管理バッチ処理メール配信
PHPコード行数 4万 6万 25万 4万
ユーザー影響度 小 中 大 大
検証 楽 楽 普通 難
難易度 楽 普通 難 難
adminshop stats
•作業に入ってみないと分からないのでざっくりと。
•目安程度
•目安とはいえ数値として提示することが大切
見積もり
33
作業見積もりtop
機能 サービス紹介ユーザー申し込み ホームページ閲覧 ホームページ作成
決済
ユーザー管理バッチ処理メール配信
PHPコード行数 4万 6万 25万 4万
ユーザー影響度 小 中 大 大
検証 楽 楽 普通 難
難易度 楽 普通 難 難
作業見積もり 1.5ヶ月 1ヶ月 2ヶ月 1ヶ月
adminshop stats
作業順序とリリース目安
35
top
機能 サービス紹介ユーザー申し込み ホームページ閲覧 ホームページ作成
決済ユーザー管理バッチ処理メール配信
PHPコード行数 4万 6万 25万 4万
ユーザー影響度 小 中 大 大
検証 楽 楽 普通 難
難易度 楽 普通 難 難
作業見積もり 1.5ヶ月 1ヶ月 2ヶ月 1ヶ月
作業順序 ① ② ③ ④リリース目安 2016/12末 2017/01末 2017/03末 2017/04末
adminshop stats
時系列2016/11
2016/12
2017/01
2017/02
2017/03
2017/04
2017/05
top PHP7.1化完了
PHP7化プロジェクトスタート!
shop PHP7.1化完了
stats PHP7.1化完了
admin PHP7.1化完了
🎍
🌸
🎅
時系列2016/11
2016/12
2017/01
2017/02
2017/03
2017/04
2017/05
top PHP7.1化完了
PHP7化プロジェクトスタート!
stats PHP7.1化完了
admin PHP7.1化完了
🎍
🌸
🎅top PHP7.1化完了12/18-25 新婚旅行 ✈
shop PHP7.1化完了
アップグレード基本方針
•長期間の作業になる
•👉 早く終わらしたい
•既存プロジェクトと並行して作業を進めたい
•👉 安全に進めたい
前提
39
•PHP5.2との後方互換性を維持する •= PHP5.2/7.1 両方で動くアプリケーションにする
•deprecated警告の対応は優先度低め
アップグレード基本方針
40
•課題 •PHP5.2 : システムワイドなPEARライブラリを多数利用
• PHP7.1 : autoload経由で読み込みたい
•懸念 • PHP5.2, 7.1の両方でPEARライブラリを読み込むにはどうすれば?
なぜPHP5.2との後方互換性を維持するのか
41
// システムワイドなPEAR::DB
require_once(‘DB.php’);
PHP_VERSION_ID
42
$ php -v | head -n 1 PHP 7.1.5 (cli) (built: May 15 2017 11:18:10) ( NTS )$ cat php_version_id.php <?php var_dump(PHP_VERSION_ID);
$ php php_version_id.php int(70105)
•解決策 • PHP_VERSION_IDで分岐
• PHP5.2との後方互換性を維持して細かくリリース
•効果 • 既存プロジェクトと並行作業
• Composer有り無し環境との並行運用
PHP_VERSION_IDで分岐
43
if (PHP_VERSION_ID >= 70000) { require_once __DIR__ . '/../../vendor/composer/autoload.php'; } else { require_once ‘DB.php’; // システムワイドなPEAR::DB
}
deprecated警告の対応は優先度低め
44
•将来的にサポートされない関数や仕様の警告
•動作上は問題ない
•次回バージョンアップ時に廃止になる可能性は高い
deprecated警告とは
45
•余裕があれば対応する・なければ対応しない
•PHP7.1化が完了してから順次deprecated警告を対応
•PHP7.1化をなるはやで終わらせることを優先
deprecated警告の対応は優先度低め
46
いざPHPアップグレード作業へ
•下位互換性のない変更点の修正
•MySQL関数の削除
•ereg系関数の削除
•マジッククォート廃止
•関数・文法の仕様変更の修正
•php.iniの調整
•などなど
PHPアップグレード作業
48
•影響範囲はアプリケーション全体
•単調作業
•同じ修正を多数ファイルで行う
•同じファイルを何度も修正する
PHPアップグレード作業の特徴
49
•ケアレスミスやデグレしやすい
•どこに地雷があるか分からない 💣
注意点
50
•安全 • リアルタイムPHPエラー検知
• 新旧両バージョンで継続的テスト
•作業時間短縮 • 未使用ファイルの削除
• php7ccによる互換性の自動検知
• E2Eテスト
長期に渡るPHPアップグレード作業のポイント
51
リアルタイムPHPエラー検知• Fluentd + Norikraを利用したログの集積・解析基盤を構築
•アプリケーションのPHPエラーログをSlackにリアルタイム通知
メリット
53
•既存バグの早期発見につながる
•動作検証時、アップグレード時の障害にすぐ気づける
新旧両バージョンで継続的テスト
54
•CI上でPHP5.2, 7.1の両方でユニットテスト
•既存システムに影響を与えていないことを確認しつつ、 新バージョンでの動作担保を確保
未使用ファイルの削除
55
•他サービスからコピペされたファイル
•廃止になった機能
•リニューアル時に残された旧機能
•キャンペーン用一時コード
未使用ファイルは思っている以上にある
56
•PHPアップグレード対象の範囲縮小 •検証時間軽減 •依存関係の軽減
未使用ファイルを削除するメリット
57
•ルール
•調査期間を決める
•優先度
1.ライブラリ
2.ルーティング、コントローラー
•方法
•対象ファイル名、クラス名でgit grep
•同僚に聞く = 削除したかったが後回しにしてたのを掘り出す
未使用ファイルの削除の仕方
58
php7ccによる互換性の自動検知
60
•必須ライブラリ
• https://github.com/sstalle/php7cc
• PHP 5.3-5.6からPHP7の互換性チェッカー
• CIで都度実行し、指摘された箇所を片っ端から修正
• 1ファイルずつ手作業で調査する必要が無い> Line 123: PHP 4 constructors are now deprecated function Hoge() { }
> Line 123: Removed function "mysql_query" called mysql_query($query);
より広範囲をカバーできる E2Eテストを重視
61
•同じ箇所を同じ手順で検証するのは時間の無駄 • 今後も継続的にアップグレードできる環境構築
E2Eテストを重視した理由
62
•アプリケーションの特徴
•全体でCRUD処理
•PHPアップグレード
•PHP Warning/Fatalエラーが発生する懸念あり
前提
63
•簡易的なCRUD処理チェック
•HTTPステータス、PHPエラーのチェック
•全画面で実装
•PHP5.2 / 7.1両方で実行を確認
実装方針
64
E2Eテスト環境
65
Ruby製テストフレームワーク
Webアプリケーションの テストフレームワーク
Capybara用PhantomJSドライバー
Headless Webkitベースブラウザ
全体図
php:7.1-apacheコンテナ環境
社内PHP5.2環境
Push
Deploy
E2Eテスト
E2Eテスト
PHP5.2
PHP7.1
全ページのHTTPステータスチェック、PHPエラーをチェック
require 'spec_helper'shared_examples_for 'correct response' do |uri| before { visit uri } it "#{uri}が200 OKで正常に閲覧できる" do expect(page.status_code).to be(200) end it "#{uri}にPHPの警告が無い" do expect(page).to have_no_content('Warning:') end it "#{uri}にPHPのエラーが無い" do expect(page).to have_no_content('Fatal error:') end end
require 'spec_helper'describe '正常閲覧テスト'do %w( /info/information /info/maintenance /info/obstacle ).each do |page| it_behaves_like 'correct response', page endend
HTTPステータスチェック features/info_spec.rb
簡易的なCRUD処理チェックdescribe 'お知らせが投稿できる', :js => true do before do visit '/info/' fill_in 'title', with: '件名テスト' fill_in 'body', with: ‘本文テスト' click_button '登録' end it { expect(page).to have_content 'お知らせを投稿しました' } end
動作検証
69
1. 自己テスト
2. チームメンバー全員検証
動作検証は2段階
70
•Issueでテスト項目書を用意
準備
71
## お申し込み
- [ ] お申し込みが出来る
- [ ] お申込した内容がDBに登録される
•用意したテスト項目書ベースに可能な限り全機能・ページを確認
•テスト項目書の漏れや間違いは随時加筆修正
•検証 → バグ修正 → 検証を繰り返す
自己テスト
72
•ルール
• チームメンバー全員で行う
• 朝会で告知、スケジュールを確保
• 全員同時に行う
• 時間は1時間
• 回数は1回~2回
• 自分は検証しない、チームメンバーの検証のサポート
チームメンバー全員検証
73
•職種別で視点が変わるので検証範囲が広がる
•思いもよらぬバグが見つかる
•テスター/QAがいないチームにオススメ
チームメンバー全員検証のメリット
74
地味に大変なバッチ処理の検証
75
•23本
•毎分、毎日、毎月、月末月初
•機能
•一斉メール配信
•契約の自動更新(DB, API呼び出し, メール送信)
•SSL証明書の自動更新
•などなど
バッチ処理状況
76
動作検証が大変!
•PHP 7.1 ローカル開発環境で全て手動実行
•PHP 7.1 ステージング環境でユーザー・DBに影響がない範囲で手動実行
検証の仕方
77
•一ヶ月は様子見
•大抵のバッチ処理は一ヶ月で全て完走する(と思います)
•月末月初のバッチ処理もありますよね?
本番リリース後の重要なポイント
78
PHPアップグレードのその後
•本番と同じスペックのインフラ環境に対して実施
•サービスのピークタイムは1台あたり秒間約30リクエスト
•Gatlingによるベンチマークで同様のパフォーマンス測定
アプリケーション応答速度の向上!
80
•CPUサイズを半分にしたインスタンスに切り替え、インフラコスト減に。
CPU負荷が半分に!
81
•VagrantからDocker開発環境へ
•起動が高速
•開発環境の構築/調整が簡単
•Composerが使えるようになった
開発環境
82
• PHPリリースのRSSを確認
• パッチバージョン(7.1.x)は数日以内にアップグレード
• ChangeLogを確認
• CI上でユニットテスト、E2Eテストが通る
最新バージョンを追従
83
$ php -v PHP 7.1.9 (cli) (built: Aug 30 2017 20:06:08) ( NTS ) Copyright (c) 1997-2017 The PHP Group Zend Engine v3.1.0, Copyright (c) 1998-2017 Zend Technologies
まとめ
84
•PHP5.2から7.1へアップグレードする困難
•スケジュールの立て方、複数ロール時の着手順序
•アップグレード基本方針
•安全かつ作業時間短縮するための施策
•バグや作業漏れを逃さない動作検証
•今後のアップグレード方針
今日話したこと
85
•今後も継続的にアップグレードしていくことが大切
•できるだけ最新のバージョンを利用し、ユーザー・開発者双方に恩恵が受けられるようにしていきたい
本当のPHPアップグレードはこれから
86
ぜひPHP7アップグレードのChallengeを!
87
君もペパボで働かないか?最新の採用情報をチェック→ @pb_recruit