• ツイート
• 

こんにちは、グーペグループエンジニア@hypermkt と技術部インフラグループ・シニアエンジニア@hfm です。半年に及ぶグーペのPHPアップグレード作業が2017年5月中旬に全て完了し、PHPバージョンは5.2から7.1になりました。今回の記事ではアップグレードの過程と効果について、ご紹介させていただきます。

1. はじめに
   1. 8年目のホームページ作成サービス「グーペ」
   2. なぜ8年目のタイミングでアップグレードをしたのか
2. アップグレード基本方針
   1. PHP5.2との後方互換性を維持する
   2. deprecatedの対応は優先度低め
3. 事前準備
   1. 新旧両バージョンで継続的テスト
   2. より広範囲をカバーできるE2Eテストを重視
   3. リアルタイムエラー検知
4. 下位互換性のない変更点の修正
   1. php7ccによる互換性の自動検知
   2. MySQL関数の削除
   3. preg_replaceへの置き換え
   4. PHP7.1用php.iniの作成
5. リリース
   1. アプリケーションの応答速度の向上
   2. CPU負荷
6. まとめ

はじめに

8年目のホームページ作成サービス「グーペ」

グーペは初心者向けのホームページ作成サービスです。ホームページ作成から運営まで強力にサポートする各種機能を幅広く取り揃えており、中小企業のお客様を中心に50,000人以上の方にご利用いただいております。

2009年5月にサービス開始以来、PHP5.2とPEARライブラリを組み合わせた独自フレームワークで開発が進められてきました。ユニットテストを導入したのが2015年7月と遅かったこともあり、広範囲に渡ってレガシーコード(「レガシーコード改善ガイド※」の定義通り、テストのないコードのこと)が増えていました。

※ マイケル・C・フェザーズ.(2009) レガシーコード改善ガイド, 翔泳社

なぜ8年目のタイミングでアップグレードをしたのか

グーペは今までKPI改善・機能開発を優先していたため、PHPのアップグレードは先送りにしていました。2015年10月に、2020年に向けた大きな目標が策定され、その目標達成のため、チーム全員でお申込み数のみを伸ばす方針を立てました。機能開発の優先度を下げ、Google AnalyticsやA/Bテストツールを利用し、コンバージョン率の改善に全力で取り組みました。その結果、お申込み数は2016年末に昨対比で2倍を達成しました。この活動については、「チーム全員でお申し込み数を2倍にした話」で詳しく解説しておりますのでご参照ください。

新規のお申込み数が増える一方で、既存ユーザーのご要望にお応えできていないという現状もありました。そこで次に顧客満足度を上げ、契約率を伸ばす方針を立てました。既存機能を改修し競合他社に負けないスピードで、新規機能を高速に開発していく必要があります。長期的な視点で、開発効率を改善し、開発スピードをあげるため、このタイミングでアップグレードをすべきだと判断しました。

アップグレード基本方針

PHP5.2との後方互換性を維持する

本プロジェクトは当初より、長期になることは予想していました。理由としては

1. PHP5.2からPHP7.1にアップグレードするため、下位互換性のない変更点の影響箇所が多数あった
2. ユニットテスト、E2Eテストでカバーされていないコードが大量にあった
3. 決済・バッチ処理など正常に動作しないとサービスの継続に致命的な影響がある処理が多数あった
4. PHPアップグレードの経験がない

などの状況があり、エンジニア2名で約半年と見積もりました。一方でサービス改善のプロジェクトは多数進行しており、我々はこれらと並行してPHPアップグレード作業を進める必要がありました。そこで執った方針は以下です。

• 新旧両バージョンで動作するアプリケーションにする
• バージョン別で処理を分ける必要がある場合は、PHP_VERSION_IDで処理を分岐

この方式によりPHP5.2と後方互換性を維持したアプリケーション環境を構築でき、既存プロジェクトと並行しながらアップグレード作業を進めることが出来ました。

deprecatedの対応は優先度低め

アップグレード作業ではdeprecated警告に何度も遭遇しました。deprecated警告とは、 将来的にサポートされない関数や仕様の警告です。動作上は問題ないと判断し、今回は「優先度低めとし余裕があれば対応する・なければ対応しない」という方針としました。

但し今回問題なくても、次回アップグレード時に廃止になる可能性は高いです。そのためPHP7.1化が完了してから、順次deprecated警告を対応する予定です。

事前準備

新旧両バージョンで継続的テスト

CI上でPHP5.2、7.1の両方でユニットテストが実行され通るようにしました。両バージョンでテストを通すことにより、既存システムに影響を与えていないことを確認しつつ、新バージョンでの動作担保を確保しました。

ペパボでは社内統一CI基盤として、OSS版Droneを全社的に利用しています。Droneについては、カラーミー EC基盤チーム@ravelllが去年発表しました「ペパボを支える大統一CI基盤と人々」で詳しく解説されておりますので、こちらをご参照ください。

より広範囲をカバーできるE2Eテストを重視

E2Eテストはユニットテストよりも重要であると考えています。PHPアップグレードでは、下位互換性のない変更点のため、同じソースファイルを複数回修正する機会があります。その都度手動により検証を繰り返すのは生産的ではありません。

また一口にE2Eテストと言いましても、何をどこまで検証すべきかが悩みどころでした。今回下位互換性のない変更点の中で、一番影響があったのはereg、MySQL関数の削除でした。サービスの特性上、ほぼ全画面でDB処理を行っており、その状況を踏まえまして

1. 画面表示時にステータスコードが200 OKか。PHP Warning/Fatal Errorが表示されていないか。
2. 画面上からDBのCRUD処理に関する操作ができるか。

を検証する方針で実装しました(詳しくはこちらのグーペのE2Eテスト運用事情をご参照ください)。またユニットテスト同様に、E2EテストもCI上で実行することで、アプリケーション全体の動作担保、検証時間の大幅な軽減をすることが出来ました。

リアルタイムエラー検知

Fluentd +Norikra を利用したログの集約・解析基盤を構築し、アプリケーションサーバーのPHPエラーログをSlackにリアルタイムで通知するようにしました。

本基盤により

• 既存バグの早期発見につながる
• アップグレード時の障害にすぐに気づける

というメリットがあります。

下位互換性のない変更点の修正

アップグレード作業の肝は下位互換性のない変更点の修正です。特に、バージョン差異が大きいほど作業コストが増します。そこで下位互換性のない変更の対応で工夫した事、対応に苦労したものをご紹介します。

php7ccによる互換性の自動検知

グーペではphp7ccという互換性検知ツールの導入をし、必要な箇所のみを修正する方針としました。下記はphp7ccに指摘された例です。PHP4形式のコンストラクター記述はdeprecated、PHP7で削除されたmysql_query関数が呼ばれていると指摘されています。アップグレードという点では、deprecatedでも動作しますので今回は保留とし、必須である後者のみを修正しました。

>Line123:PHP4constructorsarenowdeprecatedfunctionHoge(){}>Line123:Removedfunction"mysql_query"calledmysql_query($query);

またCIでphp7ccを都度実行し、指摘された箇所は片っ端から修正していきます。この方針により1ファイルずつ手作業で調査する必要がなくなりました。

MySQL関数の削除

PHPにはMySQLへの接続用のAPIが、PDO_MySQL, ext/mysqli, ext/mysqlの三種類ありますが、PHP7.0でext/mysql(MySQL関数)が削除されました。機能比較・性能については、php.netのどのAPIを使うかに詳しくまとまっていますのでご参照ください。

グーペは歴史的経緯で

1. PDO
2. PEAR::DB(mysql APIを利用)
3. MySQL関数

の3つのDB接続方法が存在しており、対応方法を検討しました。機能差・性能差に大きな差はない、著名フレームワークであるLaravelでPDOが利用されており、将来性がある点からPDOに切り替える方針としました。既存のMySQL関数の利用箇所は、全てPDOに変更しました。

対応方法に悩んだのはPEAR:DBです。PEAR::DBが対応しているMySQL APIは、mysql, mysqliの2つです。mysqliに切り替えれば、問題なく利用できます。しかし現状は、パッケージの置き換えが推奨されており、バグ・セキュリティ修正のみの状態です。今回はリリースを優先するため、PEAR::DBではmysqliを利用する方針としました。PHP7.1化が完了してから、徐々にPDOに置き換えていく予定です。

preg_replaceへの置き換え

ereg関数がPHP7.0で削除されました。対策としてpreg_replace に置き換えることで対応することが出来ます。例えばereg_replaceですと下記のようにpreg_replaceに変更することで対応できます。

$replaced=ereg_replace('hoge','fuga','hoge hoge');↓$replaced=preg_replace('/hoge/','fuga','hoge hoge');

sedなどの一括文字列置換コマンドを利用して、一発置換することも可能です。勇気と気合が必要ですが、まとめてやってしまった方が効率的です。

PHP7.1用php.iniの作成

新しいバージョンのPHPがリリースされると、下位互換性のない変更点・新機能・仕様変更の都合で、php.iniの追加・削除・初期値の変更が行われます。php.netに「削除されたINI項目」という案内がありますが、MySQL関数のような拡張モジュールの削除によるphp.iniの影響まで記載されていないので、全容の把握は困難でした。そこで我々が執った手順は以下です。

1. 旧バージョン、新バージョンのオリジナルのphp.iniファイルを用意
2. diff -u php5-php.ini php71-php.ini で差分を検出
3. 変更点を精査
   1. 削除された項目は無視(去るものは追わず)
   2. 追加された項目を調査。大抵は新機能に伴う追加なので、深くは追わない。
   3. 値の変更があった項目は入念に調査。全ての項目の意味を調べ、旧バージョンと同じ値にするか、サービスの特性に合わせて再調整。
4. 調査結果を踏まえて新バージョンのphp.iniファイルに反映

地道ですが、変更点を理解しながら反映することが出来るので安心です。これにより新バージョンを基準とした、サービスの設定を含んだphp.iniファイルが完成します。

リリース

リリースは複数台に冗長化されたアプリケーションサーバを1台ずつ置き換えて行いました。PHP5.2とPHP7.1でアプリケーションを動かしつつ、プロダクション環境でもエラーが出ないことを確かめながら徐々に移行していきました。PHP7.1化の方針として、PHP5.2との互換性を維持しながら修正していったので、PHP5.2とPHP7.1の並行運用期間中に大きな障害を生むことはありませんでした。

アプリケーションの応答速度の向上

PHP 7は PHP 5.6の倍のパフォーマンスとアナウンスされている通り、アプリケーションの応答速度も大幅に向上しました。HTTPレスポンスタイムのグラフ（Mackerelの外形監視）を見たところ、平均30ms〜40msほど改善していました。

また、高負荷時のパフォーマンスを測定するために、本番と同じスペックのインフラ環境を準備し、Gatlingを用いてベンチマークを行いました。

サービスのピークタイムでは、1台あたり秒間30リクエストほど受け付けていたので、Gatlingによるベンチマークでも同様のパフォーマンス測定を行いました。その結果、最小のレスポンスタイム同士でPHP5.2.9では325msに対し、PHP7.1.1では132msと40%になりました。

CPU負荷

また、CPUリソースの使用率にも変化がありました。アプリケーションをPHP5.2, PHP7.1.1それぞれで動かしてみたところ、約半分程度のCPU使用率で動作しました。Tumblr Engineering — PHP 7 at Tumblrでも同様の結果が報告されていましたが、それとほぼ同じ結果を得られました。

この結果を受けて、CPUサイズを半分にしたインスタンスに切り替え、インフラコストも抑えることが出来ました。

まとめ

目立ったエラーや障害も発生せずに、無事にPHP7.1にアップグレードを行うことが出来ました。アプリケーション応答速度も大幅に向上し、ユーザー体験の向上、SEOに好影響であると考えます。

しかし本当の意味でのアップグレード作業はこれからです。本プロジェクトで得られた知見・経験を活かし、今後も継続的にアップグレードしていくことが大切です。できるだけ最新のバージョンを利用し、ユーザー・開発者双方に恩恵が受けられるようにしていきたいと思います。

募集中の職種や、詳しい社内の環境や制度に関してはGMOペパボ株式会社 採用サイト をご覧ください。エンジニア新卒採用に関する情報をまとめたページも公開中！

• ツイート
•