10月18日に行われたPHP Confarence 2017。本稿では、次の4つの注目セッションをレポートします。

1. 石田健太さん「グラブル流運用術 〜1700万人を満足させるためのシステム構成、PHPプログラムの考え方〜」
2. 市橋立さん「PHPで作るサービスの、これまでの10年とこれからの10年」
3. 吉本将宣さん「PHP Version UpとAWSへの移行」
4. 田中改さん「運用、追加開発しづらいPHPアプリケーションに未来を与える方法」

石田健太さん「グラブル流運用術 〜1700万人を満足させるためのシステム構成、PHPプログラムの考え方〜」

Cygamesの石田健太さんは、ソーシャルゲームであるグランブルファンタジーの運用を通して、システムの改善点の発見手法から実際の改修を行って得た知見について発表しました。

ボトルネック部分の調査・分析

グランブルファンタジーは1,700万人がプレイしており、アクセス数は一人あたり3秒に1回、総アクセス数は1日に10億PVにものぼる巨大なサービスです。石田さんはグランブルファンタジーを「もっと早くする」という目的をもってシステム改修にあたりました。そのシステム改修では、まずは次の2の方法で調査・分析を行いました。

• New Relicを用いた処理負荷が高いAPIの特定
• XHProfを用いたコードベースでの処理負荷の高い部分の特定

New Relicとは、稼働しているシステムについてGUIで負荷状況を確認できるサービスです。New Relic上で、Transaction、Throughput、MostTimeConsumingを確認したところ、バトルの際に利用されるAPIのアクセス頻度が高く、それに伴い処理時間が長いことが判明しました。そのため、バトルの処理に焦点をあてた改修が必要だと判断しました。

XHProfとは、処理時間や関数のcall数、メモリ仕様を数値として算出できるツールです。New Relicでの分析の結果を反映して、バトルの処理に焦点をおいてXHProfで確認したところ、「⁠スキル計算処理」「⁠CSV取得処理」の2点の処理時間が長い頃が判明しました。

分析結果から判明したこの2点を、システム改修の対象とすることに決定しました。

スキル計算処理の改修

グランブルファンタジーでは様々な要素の組み合わせによりスキル計算を行っており、そのため計算処理が膨大なものとなっていました。そこでスキルの計算処理を軽減させるために、計算結果をキャッシュとしてKVSに保存させることで、計算回数の軽減を図りました。その実装で気をつけた点は次の2点です。

• バトルの勝敗に関わるダメージ計算の整合性を担保するため、一意のデータが特定できるようなKeyを設定する。
• 運用障害を未然に防ぐため、データが取得できない場合でも問題なく処理できるようにする。

これらに気をつけた実装することで、システム障害を考慮しつつ、スキル計算処理のパフォーマンス改善を達成しました。

CSV取得処理の改修

グランブルファンタジーでは、キャラクターや武器のパラメータ情報をマスタデータとしてCSV形式で保存しています。これらのマスタデータは、Webサーバー上でKVS（Redis）に保存していました。

CSV取得処理が遅い原因は、マスタデータを取得するタイミングで検索対象となるCSVファイルが多かったことが要因の一つでした。そのため、一旦取得されたマスタデータをWeb上で別のKVS（memcashed）にキャッシュとして保存することで、処理の効率化を図りました。その実装で気をつけた点は次の2点です。

• キャッシュとマスタデータを同じWebサーバー上に置く。
• データの整合性を保つため、マスタデータが更新された際にキャッシュを削除する。

これらに気をつけた実装することで、バッチ更新を考慮しつつCSV取得処理のパフォーマンスを改善しました。

システム改修の成果

システム改修の結果として、「⁠バトルAPIの速度が42.5%改善」「⁠メモリ使用量が40%減少」「⁠CALL関数の数が50%減少」といった成果を得ました。

石田さんは改修を通じて、「⁠常に改善の意識を持つ必要性」を認識したと述べていました。また今回の改修に共通した「データは最小限にまとめて再利用する」「⁠同じデータを何度も取得しいで再利用」というプログラムを書く上での基本ついて、改めて重要性を認識したと結論付けていました。

市橋立さん「PHPで作るサービスの、これまでの10年とこれからの10年」

弁護士ドットコムの市橋立さんは、自社のWeb開発の10年前と現在と開発体制の変遷について紹介し、また今後10年間の動向としてマイクロサービス化の推進について発表しました。

2005年と2017年におけるWeb開発環境について比較

2005年と2017年では、Web開発に用いられる技術に大きな違いがあります。弁護士ドットコムにおいても、次の表ように10年前と現在とでは開発環境に大きな隔たりがありました。

弁護士ドットコムは2013年まで赤字であり、その際には「いかに良いサービスを生み出すか」を重点的に開発をおこなっていました。そのためレガシー改善の優先度は高くありませんでした。

しかし2014年になり黒字化したことで、「⁠いかに現行のサービスをスケールさせるか」に焦点を合わせて開発できるようになりました。結果、レガシー改善に着手できるようになりました。

レガシー改善をする上でで問題となっていたことの一つは、開発体制の「カウボーイスタイル」でした。カウボーイスタイルとは、次の問題点がある開発体制のことを指します。

1. 開発ルールの不在
   • masterにcommitしてpush
   • Redmine、Jenkinsを利用してない
2. 優先度付けの不在
   • 依頼開発がエンジニア個人間で行われる
   • すべてのタスクが最優先
3. 貧弱な開発環境
   • テストサーバーが一台しかない

このカウボーイスタイルを解消するための方法の一つとして、開発プロセスの整備を進めました。その内容は、スクラムの実践やスプリント毎の優先順位判断、vagrant/docker/Ansibleの整備です。

レガシーコードと向きあうとは

市橋さんにとってレガシー改善とは、「⁠技術的負債を0にする」ことではありませんでした。

レガシー改善においては、その会社のステージによって改善の対象となる領域が異なります。例えばアーリーではアーキテクチャや開発プロセスの刷新に重点をおくべきであり、レイターとなれば社外調整として技術広報の見直しやエンジニア文化の相互理解に重点をおくべきです。つまり、レガシーと向き合うとはその会社のフェーズに合った適切な手法を取ることを指します。

これからの10年におけるマイクロサービス化

市橋さんはこれまでの10年の振り返りとしてレガシー改善について話した後に、これからの10年に関する話としてマイクロサービス化を取り上げました。

市橋さん曰く、これまでのサービスはモノリシックであり、大きな変更もしやすいものでしたが複雑化しがちでした。そのようなサービスを複雑化しないものへと移行させるためにマイクロサービスに着目しました。

市橋さんがマイクロサービス化を実現させる上での優先順位は「疎結合化 >> 運用 >> 内部設計」です。例えば、運用のために疎結合化を妥協することは認めず、疎結合化を優先させることでマイクロサービス化を実現させます。

またマイクロサービス化を設計する上で重視したポイントは次の3点です。

1. どう分けるか
   • 600ほどのクラスを分析して分割する。
2. どう連携するか
   • APIのインターフェースをしっかりと定義することで、後のAPIの提供内容の変更に対応できるようにする。
3. どう運用するか
   • Linkerd等のインフラサービスを利用する。

この3点を重点としてマイクロサービス化が実現できた場合には、PHPに限らず適切な言語によってサービスが構築されると述べていました。

今後のサービス開発を取り巻く3つの流れ

市橋さんは今後のサービス開発を取り巻く流れとして、次の3点を挙げました。

1. 計算資源仮想化
   • AWS/Heroku/Dokcer
   • サービスに合わせてスケールする
2. サービス化
   • 必要に応じてCircleCI/NewRelic等のサービスを組み合わせる
3. アジャイル化
   • 問題の定義から解決まで一気通貫で達成する

この3点を前提として、マイクロサービスをマイクロチームで開発を進めることになるだろうと話しました。

最後に市橋さんは、これからの10年に求められることは「最適化し続けること」であると述べていました。またその最適化はサービス面／技術面の双方から行う必要があり、終わりがないものとし、PHP Conferene 2017のスローガンであるChallngeと同じであると結論付けていました。

吉本将宣さん「PHP Version UpとAWSへの移行」

グリーの吉本将宣さんは、グリーのシステムをPHP5.2からPHP5.5にバージョンアップする過程とその成果、さらにその成果に元にしてAWS移行を実現したことにについて発表しました。

2年前のグリーのシステム構成

グリーのシステムは、次の3つの分野に分けられます。

1. SNS＆ゲームプラットフォーム
2. 広告＆メディア
3. ブラウザゲーム＆ネイティブゲーム

2年前の時点では、これらのシステムのほとんどはPHP5.2かつオンプレミスであり、広告＆メディアの一部や新規のネイティブゲームのみがAWSに置かれていました。

レガシー環境から脱却できていなかった理由として、次の理由を挙げました。

1. 新規OSへの対応が遅れたため
   • 数千台規模のサーバ入れ替えには長期の必要であった。
2. 古くからあったサービスは密結合であったため
   • プラットフォームとゲームが同じサーバー上で動いていた。
3. メンテナンスが難しいため
   • パートナー企業への影響があった。

これらの理由より、新しい環境への刷新が実現が困難でありました。しかしレスポンス速度の限界、メンテナンスコストの増大といった理由から、PHP5.2からPHP5.5へのバージョンアップを決定しました。

PHPのバージョンアップ

次の3点を意識することで、PHPのバージョンアップを実現しました。

1. 少人数によるプロトタイピング

• ゲーム／SNSが最低限動くところまで完成させた。

2. ノウハウの共有

• 部署をまたがった情報共有の仕様を策定した。

3. 修正方針／QAスケジューリングの明確化
   • 修正方針：PHP5.2とPHP5.5両方で動くようにする。
   • QAスケジュール：先行して1つのゲームでQAを実施した。

またPHPのバージョンアップを実現したことで、システム負荷の改善（load averageを50%改善）や、組織を超えて一つの目標に一丸となって進む信頼関係を得ました。

AWSへの移行

特に信頼関係が成果として大きなものであり、それによってAWSへの移行が実現しました。具体的には、20を超えるサービスと数千代規模のサーバーをオンプレミスからAWSへ移行しました。

AWS移行によってサーバー費用の削減（40%近い削減を達成⁠）⁠、完全なPHPバージョンアップの成功（オンプレミスに残っていたネイティブゲームをPHP5.5にした）を達成しました。

AWS移行に際してはテスト不足／準備不足のためにいくつかの問題はありましたが、全体を通して大きなトラブルなく移行を完了できました。その理由として、移行ミスの原因／対策を次回の移行に反映させたPDCAの実施と、PHPのバージョンアップで培った信頼関係を挙げていました。

吉本さんは、PHPのバージョンアップとAWSへの移行に共通した成功要因は「強靭な意思／チームワークである」と述べていました。また勝ち得たチームワークによって、次のチャレンジへのモチベーションにも繋がると結論付けていました。

田中改さん「運用、追加開発しづらいPHPアプリケーションに未来を与える方法」

VOYAGE GROUPの田中改さんは、運用／追加開発がしやすいプロダクトの条件について、また「サポーターズ」のシステム改修を例に挙げて、いかにして運用／追加しやすいプロダクトを構築したのかについて発表しました。

運用／追加開発がしやすい条件とは

田中さんはこれまで所属したチームを比較し、運用／追加開発がしやすい条件に次の3点を挙げました。

1. アプリケーションモニタリングがある
   • デプロイ後にエラーに気がつける。
2. テストコードがある
   • デプロイ前にエラーに気がつける。
3. デプロイが容易である
   • デプロイ後にエラーが発生しても、その修正が容易である。

そして、運用／追加開発がしづらい条件は上記の反対であると定義し、改修前のサポーターズは「アプリケーションモニタリングがない」「⁠テストコードがない」という問題点があったと指摘しました。そこでサポーターズの改修にあたり、New Relicの導入とテストコードの追加によってこの問題を改善しました。

アプリケーションモニタリングの追加

アプリケーションモニタリングのツールとしてNew Relicを利用しました。New Relicはエンドポイント毎の処理時間や404エラーの発生を分析できるため、どこを改修すべきかを決定できました。

実際に改善前のサポーターズを分析した結果、「⁠Error Rate 30%」「⁠Response Time 761sec」という結果が判明しました。この調査結果を指針してシステム改修を実施できました。

テストコードの追加

既存のアプリケーションにはテストコードが網羅的に存在しておらず、かつ既存の処理が膨大であるためにテストコードの追加が難しいという課題が存在しました。そこで問題の切り分けを行い、まず新規機能については新しく別アプリケーションを立ち上げ、そこにシステム処理とテストコードを実装していく方針を取りました。

その際に有用であったツールはAWSのALBでした。ALBによってURLごとにアプリケーションを振り分けることで、既存アプリケーションと新規アプリケーションの並列が可能になりました。

ALB実装の際に気をつけた点は、session管理です。片方のアプリケーションのsession情報が、もう片方のアプリケーションのsession情報として維持される必要がありました。この課題を解決するために、ログイン時に双方のアプリケーションのsession用のテーブルに書き込むことで、session情報を維持しました。

また既存機能に対するテストコードの追加は、新しい別アプリケーションに既存機能の移植を段階的に行い、それに合わせてテストコードを新しく記述することで対応しました。段階的に機能移植とテストコード記述を行うことで、既存機能を保持した上でテストコードの追加を実現しました。

システム改修をしてみて

このサポーターズのシステム改修によって、田中さんは「運用／追加開発がしづらいシステム改善方法」「⁠システム改修の第一歩をどう見つければよいか」について気づきを得たと述べていました。またALBを用いて別アプリケーション立ち上げることで、既存機能に触れず移行する可能性が見えたと結論付けていました。

レポートの終わりに

本稿では、注目のセッションとして4つのセッションについてレポートを紹介しました。私が面白いと感じた点は、どのセッションについてもシステム改修について触れているものの、改修対象であるサービスの性質やスピーカーの視点がそれぞれのセッション毎に異なっていたために、トークの焦点が異なっていたことです。ぜひ読者のみなさんもこれらのセッションのスライドや動画を確認して、それぞれの違いを見つけて楽しんでみてください。