グーペ PHP

グーペのPHPバージョンを5.2から7.1にアップグレードしました

グーペ PHP

こんにちは、グーペグループエンジニア @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の両方でユニットテストが実行され通るようにしました。両バージョンでテストを通すことにより、既存システムに影響を与えていないことを確認しつつ、新バージョンでの動作担保を確保しました。

Drone上でPHP5.2, PHP7.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にリアルタイムで通知するようにしました。

Fluentd + Norikraを利用したリアルタイムエラー通知

本基盤により

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

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

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

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

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

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

> Line 123: PHP 4 constructors are now deprecated
    function Hoge()
    {
    }

> Line 123: Removed function "mysql_query" called
    mysql_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%になりました。

Version Req/s Min (ms) 50th pct 75th pct 95th pct 99th pct Max (ms) Mean (ms) Std Dev
PHP 5.2.9 27.823 325 2147 4884 6092 7896 12619 2884 2047
PHP 7.1.1 29.916 132 236 270 367 490 594 249 61

CPU負荷

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

PHP5.2, PHP7.1 CPU使用率の比較図

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

まとめ

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

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

書いた人

  • バーチー

    ホームページ作成サービス「グーペ」のエンジニア。最近Vue.jsに夢中です。

  • okkun

    技術部インフラグループのシニアエンジニア。ほぼ三十路なので「おっくん」とかどうなんだろうと最近感じています。