できるphp7アップグレード...•pearを利用した独自フレームワーク...

バーチー / GMO PEPABO inc. 2017.10.08 / PHPカンファレンス2017

できるPHP7アップグレード

http://blog.hypermkt.jp

ソフトウェアエンジニアバーチー @hypermkt

SH事業部グーペチーム 兼 アニメ部部長

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万 ４万

admin shop stats

① PHP 7.0.0 MySQL関数削除 アプリケーション全体でMySQL関数を使用 約260箇所のPDO切り替え

② PHP 5.4.0 マジッククォート削除 SQLを文字列結合している。SQLインジェクション対策のため、約230箇所のプレースホルダー化

当初から分かっていた課題は３つ

11

③ PHP5.2 から 7.1間の仕様変更、 下位互換性のない変更点の全容 を知らない

当初から分かっていた課題は３つ

12

もう一つ困難があります

13

作業許可をもらうこと

14

•現状でも「開発は」出来る

•開発リソースが足りない

•KPI改善や機能開発優先

理解されにくいアップグレード業務

15

•ユーザーメリット •タイミング

説得のポイント

16

ユーザーメリット

17http://php.net/releases/7_0_0.php

•PHP 7.0.0で２倍高速化！ •開発効率改善で開発スピード向上！ •安定サービス提供

•2016年前期にお申し込み数２倍に！ •更なる成長のためエンジニア数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開発経験２年以上のエンジニア２名

24

インフラ @hfm

アップグレード対象は4ロール

25

top

機能 サービス紹介ユーザー申し込み

ホームページ作成契約 ホームページ閲覧 バッチ処理

メール配信

PHPバージョン 5.2 5.2 5.2 5.2

PHPコード行数 4万 25万 6万 ４万

admin shop stats

どこから着手すべきか？

26

簡単かつ短期間で完了出来るものから着手しよう！

27

結論

•我々はPHPアップグレード未経験者

•特定バージョンの課題解決法や効率的な作業手順を知らない

•まずは1回PHPアップグレードを経験することで、 一通りの課題解決方法を学び、非効率な方法も経験する

•次からは作業の効率化と作業時間軽減も出来る！

なぜか

28

ぴーえいちぴー

MySQL関数の削除ならお任せください！

ereg系関数は一発置換で仕留めるぜ

どうやって難易度を測るか？

30

•ユーザー影響度(= リスク）が小さいもの

•PHPコード行数が少ない

•検証が楽なもの（バッチ処理は手間）

難易度の決め方

31

難易度top

機能 サービス紹介ユーザー申し込み ホームページ閲覧 ホームページ作成

決済

ユーザー管理バッチ処理メール配信

PHPコード行数 4万 6万 25万 ４万

ユーザー影響度 小 中 大 大

検証 楽 楽 普通 難

難易度 楽 普通 難 難

adminshop stats

•作業に入ってみないと分からないのでざっくりと。

•目安程度

•目安とはいえ数値として提示することが大切

見積もり

33

作業見積もりtop

機能 サービス紹介ユーザー申し込み ホームページ閲覧 ホームページ作成

決済

ユーザー管理バッチ処理メール配信

PHPコード行数 4万 6万 25万 ４万

ユーザー影響度 小 中 大 大

検証 楽 楽 普通 難

難易度 楽 普通 難 難

作業見積もり 1.5ヶ月 1ヶ月 2ヶ月 1ヶ月

adminshop stats

作業順序とリリース目安

35

top

機能 サービス紹介ユーザー申し込み ホームページ閲覧 ホームページ作成

決済ユーザー管理バッチ処理メール配信

PHPコード行数 4万 6万 25万 ４万

ユーザー影響度 小 中 大 大

検証 楽 楽 普通 難

難易度 楽 普通 難 難

作業見積もり 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. チームメンバー全員検証

動作検証は２段階

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