php version up と aws への移行

Copyright © GREE, Inc. All Rights Reserved.Copyright © GREE, Inc. All Rights Reserved.

PHP Version Up とAWS に移行した話

グリー株式会社

吉本将宣

Copyright © GREE, Inc. All Rights Reserved.

自己紹介

● 吉本将宣

● 2014年グリー Join

● インフラ/リードエンジニア○ 本職は NoSQL のはずだが、、、

○ 何でもやるスタイル

■ PM、フロント開発・コードレビュー...

■ 一時は Manager も ...

● 10月からメディア事業へ○ iOS/Android アプリの開発メイン


今日お話しすること

● PHP Version Up した話● AWS に移行した話


今日お話しすること

● PHP Version Up した話● レガシーと戦って僕たちが手に入れた武器

● AWS に移行した話● 僕たちが手に入れた武器で次にやったこと


グリーのサービス

SNS＆

ゲームプラットフォーム

ブラウザゲーム＆

ネイティブゲーム

広告メディア事業など


Memcached/ Redis / Flare

MySQL

Apache + PHP

基本システム構成

アプライアンスロードバランサ

＋Apache Proxy

ロードバランサ層アプリケーション層データベース層


２年前の僕たちの環境

SNS＆





オンプレ

AWS



SNS＆





オンプレ

AWS

OS : Ubuntu TrustyPHP : 5.5 以上MySQL : 5.6 以上



SNS＆





オンプレ

AWS

OS : Debian LennyPHP : 5.2MySQL : 5.5


なぜオンプレがレガシー化したのか

● 新規 OS への対応遅れ

○ 数千台規模のサーバの入替はそれだけで長期に渡る

● 息の長いサービスは密結合化

○ 古くからあるサービス

■ GREE SNS やガラケー時代からの内製ブラウザゲーム

○ プラットフォームやゲーム間で require

■ プラットフォームが出来る前のコード

■ API 化されていない部分

■ 同じサーバで動いていた

● API 呼び出しより MySQL 直アクセスの方が速かった

● メンテナンスが入れづらい

○ ゲームプラットフォームの修正はパートナー様にも影響する

● 肥大化したコード


抜け出せないレガシーの沼


しかし限界はある

● レスポンス速度の改善も限界

○ ２年前の時点でも周回遅れの PHP 5.2

● OS が古いことによるミドルウェアのメンテナンスコスト増大

○ セキュリティパッチは独自で対応

○ AWS は ubuntu trusty なので、同じミドルウェアで複数バージョンを

メンテナンスしないといけない

意を決して内製のブラウザゲームからバージョンアップを始めた


効率よく＆スピード重視で進めないといけない


どうしたのか

● 少人数によるプロトタイピング● ノウハウの共有● 修正方針と QA のスケジューリング


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

● インフラチームを中心に各ゲーム・プラットフォームから数名で対応

● ゲームや SNS 機能が最低限動くところまで一気にやった

○ 各サービス共通のコードを完成させる

○ よくある syntax error の修正方法を決める

■ 引数の変更など (regex_replace, etc…

● ミドルウェア・インフラ面の問題も先取り

○ 画像ライブラリ・Apache などの設定や問題の確認

● 開発環境を統一

○ chef を使って本番と共通の cookbook を作成

○


ノウハウ共有

● 全サービスで共通のエラーレポートフローを定義

○ ゲーム内で閉じない不具合は全員に共有

○ どのように対応したかも一覧で分かるように

● チームや領域によらずに修正

○ インフラ・ゲーム・プラットフォームのチームに関係なく pull request

○ レビューやテストは各サービスのエンジニアが対応することで品質を担保

● インフラチームが舵を取って積極的にノウハウを共有

○ 全社で共通となっているインフラチームが中心になることで情報を集約


修正方針と QA のスケジューリング

● 修正方針○ PHP5.2 と PHP5.5 両方で必ず動くように修正する

● QA とリリースまでのスケジュール調整○ 先行して一つのゲームで QA を実施

■ 密結合なので、プラットフォームなどの不具合も見つることができた

■ 画像合成といったセンシティブで時間が掛かる問題も早めに検知できた

○ 共通の不具合を修正後は並行して QA を実施

■ 定常的に実施しているイベント等の QA と同時に実施

● PHP5.2 と PHP5.5 の両方の環境で QA すると時間が掛かりすぎる

■ 事前に発生しやすい問題は把握・対応できているので不具合は少なめ

○ プラットフォームは定常 QA で確認しつつ徐々にリリース

○ リリースは一台に投入して2週間以上様子を見てから

■ 負荷に問題がないか


決してスマートとは言えないやり方だが...


どうにか難題を乗り越えて僕たちが勝ち得たものとは


負荷の改善

● 50%ほど load avergae が改善された○ Web サーバを 40% 削減

PHP 5.2PHP 5.5


レガシーからの脱却

● バージョンアップ前 (2015年時点)

○ Trusty & PHP5.5：全体の 20%

● バージョンアップ後 (2016年時点)

○ Trusty & PHP5.5：全体の 90%■ Lenny & PHP5.2 で残ったもの

● サーバ管理システム等

● オンプレのネイティブゲーム


そんな数字よりも。。。


僕たちが真に勝ち得たもの

● 互いのシステムへの相互理解○ サーバサイドエンジニアのインフラへの理解

○ インフラエンジニアのアプリケーションへの理解

● 組織を超えた強力なチームワーク○ 一つの目標に向かって一丸となって進む力

○ 自分の領域に囚われずに協力し合う信頼関係


AWS に行こう


AWS 移行したモチベーション

システム観点では。。。

● オンプレサーバの老朽化○ 2017年には EOSL を迎えてしまう○ HDDおよびメモリの故障率の増加○ パフォーマンスの限界


でも、それだけじゃない



● 一丸となってやれば何でもできる自信○ 10年来の超大規模レガシーから抜け出した自信

● 次のチャレンジへの意欲向上○ PHP7○ 疎結合化○ etc...



● やりたいことは非常に多い

● でも、さすがに一気に全部やるのは怖いので

● AWS 移行しつつ、並行して PHP7 の準備をしました


1年でゲームを全部 AWS に移行した

● 2016年

SNS＆





オンプレ

AWS


1年でゲームを全部 AWS に移行した

SNS＆



スマホゲーム


オンプレ

AWS

● 2017年


移行したサービス

● ブラウザゲーム

○ 密結合なものも含めて全て

● スマホ向けネイティブゲーム

○ ブラウザゲームで得たノウハウを活かして PHP Version Up も同時に

○ ネイティブ向けのゲームプラットフォームも

● ゲーム以外も

○ コーポレート、広告・メディア事業系のサイト

2０を超えるサービス、数千台規模のサーバを AWS に移行


どうやって移行したか？

● Direct Connect 使った

○ 事前に MySQL のレプリカを AWS 上に作る

■ AWS 側のレプリカを一台、オンプレのサービスに入れて

クエリ検証やレスポンス速度等を確認

● 密結合な内製ブラウザゲームの場合、プラットフォームがオンプレに残るので

AWS からオンプレへのレスポンス速度も重要

○ テスト用の別ドメインを AWS 側につけてテスト実施

■ AWS からオンプレの本番 DB にアクセスして確認

● 移行日の深夜メンテで切替

○ MySQL マスタ切替＆ DNS 切替

○ 最終的な動作チェック


移行して良かったこと

● サーバ費用の削減○ 40% 近い削減を達成

■ ハードウェア性能向上による負荷低減

● サーバリソースの在庫調整が不要に○ オンプレではサーバ増加における調達のために在庫が必要だった

● PHP5.5 に出来ていなかったサービスも完全移行○ オンプレに残っていたネイティブゲーム等


AWS 移行で起きた問題

● 深夜メンテを入れて移行できなかったのは最初の一回だけ○ 原因は疎結合化を同時にやろうとしたことによるテスト不足

● メンテ当日の準備不足○ テスト用端末がログインできないプロダクトがあり

当日慌てて対応した

大きなトラブルはほとんどなかった


なぜ一年で数千台規模を移行できたのか

● 普通に PDCA 回した○ 最初の移行ミスでプロジェクト並行する問題が把握できた

○ 事前にやる作業や修正を次の移行プロダクトに共有した

○ 負荷予測の精度も移行を経るごとに高くなった

● 円滑なコミュニケーション○ PHPバージョンアップした時からの信頼関係

○ 相互に仕組みを理解しているため話が早く

問題を早く検知しやすい

■ 認識齟齬などに問題も少なかった


今後のチャレンジ

● PHP7 on Xenial○ 一部サービスでは導入を開始

■ memcached への connection 数が改善

■ cpu 負荷も半分程度に

● HTTP2 を使った通信の高速化

● オンプレに残ったサービスのハイブリッドクラウド


まとめ

● 強靭な意志でレガシーから抜け出せる

● 勝ち得たチームワークは次のチャレンジの大きな財産！

● パフォーマンスの改善はその副産物


技術負債は人的資源に変える大きなチャンス！

php version up と aws への移行

Engineering