PHP Version Up と AWS への移行

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Copyright © GREE, Inc. All Rights Reserved. 自己紹介 ● 吉本将宣 ● 2014年グリー Join ● インフラ/リードエンジニア ○ 本職は NoSQL のはずだが、、、 ○ 何でもやるスタイル ■ PM、フロント開発・コードレビュー... ■ 一時は Manager も ... ● 10月からメディア事業へ ○ iOS/Android アプリの開発メイン

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Copyright © GREE, Inc. All Rights Reserved. なぜオンプレがレガシー化したのか ● 新規 OS への対応遅れ ○ 数千台規模のサーバの入替はそれだけで長期に渡る ● 息の長いサービスは密結合化 ○ 古くからあるサービス ■ GREE SNS やガラケー時代からの内製ブラウザゲーム ○ プラットフォームやゲーム間で require ■ プラットフォームが出来る前のコード ■ API 化されていない部分 ■ 同じサーバで動いていた ● API 呼び出しより MySQL 直アクセスの方が速かった ● メンテナンスが入れづらい ○ ゲームプラットフォームの修正はパートナー様にも影響する ● 肥大化したコード

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Copyright © GREE, Inc. All Rights Reserved. しかし限界はある ● レスポンス速度の改善も限界 ○ ２年前の時点でも周回遅れの PHP 5.2 ● OS が古いことによるミドルウェアのメンテナンスコスト増大 ○ セキュリティパッチは独自で対応 ○ AWS は ubuntu trusty なので、同じミドルウェアで複数バージョンをメンテナンスしないといけない意を決して内製のブラウザゲームからバージョンアップを始めた

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Copyright © GREE, Inc. All Rights Reserved. 少人数によるプロトタイピング ● インフラチームを中心に各ゲーム・プラットフォームから数名で対応 ● ゲームや SNS 機能が最低限動くところまで一気にやった ○ 各サービス共通のコードを完成させる ○ よくある syntax error の修正方法を決める ■ 引数の変更など (regex_replace, etc… ● ミドルウェア・インフラ面の問題も先取り ○ 画像ライブラリ・Apache などの設定や問題の確認 ● 開発環境を統一 ○ chef を使って本番と共通の cookbook を作成 ○

Slide 16

Slide 16 text

Copyright © GREE, Inc. All Rights Reserved. ノウハウ共有 ● 全サービスで共通のエラーレポートフローを定義 ○ ゲーム内で閉じない不具合は全員に共有 ○ どのように対応したかも一覧で分かるように ● チームや領域によらずに修正 ○ インフラ・ゲーム・プラットフォームのチームに関係なく pull request ○ レビューやテストは各サービスのエンジニアが対応することで品質を担保 ● インフラチームが舵を取って積極的にノウハウを共有 ○ 全社で共通となっているインフラチームが中心になることで情報を集約

Slide 17

Slide 17 text

Copyright © GREE, Inc. All Rights Reserved. 修正方針と QA のスケジューリング ● 修正方針 ○ PHP5.2 と PHP5.5 両方で必ず動くように修正する ● QA とリリースまでのスケジュール調整 ○ 先行して一つのゲームで QA を実施 ■ 密結合なので、プラットフォームなどの不具合も見つることができた ■ 画像合成といったセンシティブで時間が掛かる問題も早めに検知できた ○ 共通の不具合を修正後は並行して QA を実施 ■ 定常的に実施しているイベント等の QA と同時に実施 ● PHP5.2 と PHP5.5 の両方の環境で QA すると時間が掛かりすぎる ■ 事前に発生しやすい問題は把握・対応できているので不具合は少なめ ○ プラットフォームは定常 QA で確認しつつ徐々にリリース ○ リリースは一台に投入して2週間以上様子を見てから ■ 負荷に問題がないか

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Copyright © GREE, Inc. All Rights Reserved. レガシーからの脱却 ● バージョンアップ前 (2015年時点) ○ Trusty & PHP5.5：全体の 20% ● バージョンアップ後 (2016年時点) ○ Trusty & PHP5.5：全体の 90% ■ Lenny & PHP5.2 で残ったもの ● サーバ管理システム等 ● オンプレのネイティブゲーム

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Copyright © GREE, Inc. All Rights Reserved. 移行したサービス ● ブラウザゲーム ○ 密結合なものも含めて全て ● スマホ向けネイティブゲーム ○ ブラウザゲームで得たノウハウを活かして PHP Version Up も同時に ○ ネイティブ向けのゲームプラットフォームも ● ゲーム以外も ○ コーポレート、広告・メディア事業系のサイト 2０を超えるサービス、数千台規模のサーバを AWS に移行

Slide 32

Slide 32 text

Copyright © GREE, Inc. All Rights Reserved. どうやって移行したか？ ● Direct Connect 使った ○ 事前に MySQL のレプリカを AWS 上に作る ■ AWS 側のレプリカを一台、オンプレのサービスに入れてクエリ検証やレスポンス速度等を確認 ● 密結合な内製ブラウザゲームの場合、プラットフォームがオンプレに残るので AWS からオンプレへのレスポンス速度も重要 ○ テスト用の別ドメインを AWS 側につけてテスト実施 ■ AWS からオンプレの本番 DB にアクセスして確認 ● 移行日の深夜メンテで切替 ○ MySQL マスタ切替＆ DNS 切替 ○ 最終的な動作チェック

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Copyright © GREE, Inc. All Rights Reserved. なぜ一年で数千台規模を移行できたのか ● 普通に PDCA 回した ○ 最初の移行ミスでプロジェクト並行する問題が把握できた ○ 事前にやる作業や修正を次の移行プロダクトに共有した ○ 負荷予測の精度も移行を経るごとに高くなった ● 円滑なコミュニケーション ○ PHPバージョンアップした時からの信頼関係 ○ 相互に仕組みを理解しているため話が早く問題を早く検知しやすい ■ 認識齟齬などに問題も少なかった