PHP+MySQLを使ったスケーラブルなソーシャルゲーム開発
•
34 recomendaciones•43,310 vistas
OSC 2013 Hokkaidoで発表された「PHP+MySQLを使ったスケーラブルなソーシャルゲーム開発」のスライド資料です。
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a PHP+MySQLを使ったスケーラブルなソーシャルゲーム開発
Similar a PHP+MySQLを使ったスケーラブルなソーシャルゲーム開発 (20)
Más de infinite_loop
Más de infinite_loop (20)
PHP+MySQLを使ったスケーラブルなソーシャルゲーム開発
- 1. PHP+MySQL を使った スケーラブルなソーシャルゲーム開発 株式会社インフィニットループ 佐々木 亨基 2013/09/14 OSC Hokkaido 2013
- 2. 自己紹介 ・佐々木 亨基 ・ゆきこ yukicon ・ Twitter:@yukiconEx ・株式会社インフィニットループ所属 ・札幌 MySQL 勉強会代表 ・ゲームと戦車とお人形さんが好き ・隠居して一日中 MMORPG をして過ごすのが夢 ・超適当 ・のんびりゆったりまいぺーす
- 4. インフィニットループについて ・北海道札幌市にあるシステム開発会社 約 90 名（契約スタッフ・アルバイト含む）で活動中 社長も含め、ほぼ全員がエンジニア ・主な開発実績（主にサーバサイドを担当） ブラウザ三国志 (2009) 英雄クエスト (2010) Lord of Knights(2012) フォトバトラー (2012) Vim 検定 (2012) PHP 検定 (2013) その他いろいろ
- 6. ■ はじめに ・ソーシャルゲーム案件 ・スケーラブル？ ■ 架空戦記 ・ [Ⅰ] の時代 サービス開始 ・ [Ⅱ] の時代 Web サーバ追加 ・ [Ⅲ] の時代 DB スレーブ追加 ・ [Ⅳ] の時代 垂直分割 ・ [Ⅴ] の時代 水平分割 お題目
- 7. ■ 実際のところ ・アプリのチューニング ・負荷状況の洗い出し ・スケールアップとスケールアウト ・ DB 分割アレコレ お題目
- 11. 架空戦記
- 14. スモールスタート！
- 15. ひとまず最小の構成 Web DB Web 1 台 DB 2 台 DB [Ⅰ] の時代
- 16. ・ DB サーバはデータ損失を防ぐため ホットスタンバイ状態のスレーブサーバを用意 ・ホットスタンバイさせているサーバは参照しない ・ Web サーバが落ちたらごめんなさい とりあえず動く！ [Ⅰ] の時代
- 17. ユーザ数が想定外の増加！
- 19. ■ 現状 Web サーバの性能が限界 ピークタイムでは CPU 使用率が常に 100% に近い 1 台では耐え切れない Web サーバの増強が急務！ [Ⅱ] の時代への遷移
- 20. -- Web サーバを増やすには ・ LB( ロードバランサ ) の導入 複数の Web サーバに振り分けを行う ・セッションを管理するキャッシュサーバを設ける サーバ間を跨いでログインセッションを管理 memcached を使用 ・必須ではないがログサーバも用意 アプリのログを一元管理 syslog を使用 [Ⅱ] の時代への遷移
- 21. Web サーバ他を追加 Web Web 3 台 DB 2 台 Cache 1 台 Log 1 台 WebWeb Cache Log LB DB DB [Ⅱ] の時代
- 22. ・ Web サーバはどんどん追加可能 ・ Web サーバが 1 台くらい落ちても平気 ただし LB から切り離す対応は必要 ・ Cache サーバはセッション以外もキャッシュ可 ・ Cache サーバはバッチサーバとしても使用可 CPU を使う PHP のバッチ処理と メモリを使う memcached は同居しやすい ・ Cache サーバも増やせる ・ Log サーバを立てた事でアプリログは今まで通り これで一安心！ [Ⅱ] の時代
- 23. そんな訳なかった！
- 24. 今度は DB サーバが高負荷に！ Web WebWeb LB DB DB Cache Log [Ⅱ] の時代
- 25. ■ 現状 DB サーバの性能が限界 参照クエリも更新クエリも全て 1 台へ発行している しかし 1 台だけ参照していたのでは耐え切れない DB サーバの増強が急務！ [Ⅲ] の時代への遷移
- 26. -- DB サーバを増やすには ・複数のスレーブサーバを用意 ・マスタ、スレーブの参照先切り替えを実装 トランザクションや更新クエリはマスタに 参照クエリはスレーブに ・なんらかのスレーブ参照先振り分け方式を用意 アプリレベルで実装 DNS サーバを立てて振り分け LB の使用 など [Ⅲ] の時代への遷移
- 27. DB スレーブを追加 Web Web 3 台 DB 4 台 Cache 1 台 Log 1 台 WebWeb LB DB DB DBDB Cache Log [Ⅲ] の時代
- 29. Web WebWeb LB DB DB DBDB Cache Log [Ⅲ] の時代
- 30. スケールアウト！
- 31. Web と DB スレーブを追加 Web Web 5 台 DB 6 台 Cache 1 台 Log 1 台 WebWeb LB DB DB DBDB Web Web DB DB Cache Log [Ⅲ] の時代
- 32. ・ Web サーバや DB スレーブを追加して耐えられる ・単一 DB としての完成形 ・この先は DB 分割が必須 ・この方式のサーバ群を増やしていくという手もある ブラウザ三国志がその方式 ( 通称ワールド分け方式 ) ワールド間で関わりは持てない ユーザ数増加には新規ワールドをオープンする事で対応 アクティブユーザが減少したらワールドを統合 今度こそ安心？ しかしこの案件にワールド分けは許されなかった… [Ⅲ] の時代
- 33. 順調に増え続けるユーザ
- 34. 遂に恐れていた時が！
- 35. DB マスタが限界を迎える Web WebWeb LB DB DB DBDB Web Web DB DB Cache Log [Ⅲ] の時代
- 36. マスタサーバは 1 台きりで増やせない 更新性能がネックとなりいずれ限界が来る Master Slave Slave Slave ・・・ ×n SELECT UPDATE SELECT SELECT [Ⅲ] の時代
- 37. ■ 現状 DB マスタの更新性能が限界 案件的にワールド分けも許されない 意を決して DB 分割をするしかない！ [Ⅳ] の時代への遷移
- 38. DB 分割 (DB Sharding) [Ⅳ] の時代への遷移 A テーブル B テーブル E テーブル F テーブル E テーブル F テーブル E テーブル F テーブル … 垂直分割 ( テーブル単位での分割 ) 水平分割 ( 同テーブルの ID 単位による分割 ) C テーブル D テーブル
- 39. 難易度の低い垂直分割を採用！ [Ⅳ] の時代への遷移 A テーブル B テーブル E テーブル F テーブル E テーブル F テーブル E テーブル F テーブル … 垂直分割 ( テーブル単位での分割 ) 水平分割 ( 同テーブルの ID 単位による分割 ) C テーブル D テーブル
- 40. -- 垂直分割するには ・分離するテーブルを選択 イベント時のみ重くなるため イベント用のテーブルを分離する など、アプリによって様々 ・アプリを複数 DB への問い合わせに対応 対象 DB の切り替え 複数 DB 間でのトランザクションの管理 [Ⅳ] の時代への遷移
- 41. DB を垂直分割 Web Web 5 台 DB 8 台 Cache 1 台 Log 1 台 WebWeb LB DB DB DBDB Web Web Cache Log DB DB DBDB DB1 DB2 [Ⅳ] の時代
- 43. 止まらないユーザ増加
- 44. DB1 をこれ以上垂直分割するのが難しい！ Web WebWeb LB DB DB DBDB Web Web Cache Log DB DB DBDB DB1 DB2 [Ⅳ] の時代
- 45. 知ってた！
- 47. やるしかない！ [Ⅴ] の時代への遷移 A テーブル B テーブル E テーブル F テーブル E テーブル F テーブル E テーブル F テーブル … 垂直分割 ( テーブル単位での分割 ) 水平分割 ( 同テーブルの ID 単位による分割 ) C テーブル D テーブル
- 48. -- 水平分割するには ・分割するテーブルを選択 ユーザに紐付いたデータを水平分割 更新の激しいイベントデータを水平分割 など、垂直分割とは思想が違うため再設計 ・共通データ Global + User × n が王道 ・アプリを水平分割に対応 各 DB へのデータ振り分け DB 間を跨いだ串刺し検索 [Ⅴ] の時代への遷移
- 49. ユーザデータを水平分割 Web 5 台 DB 12 台 Cache 1 台 Log 1 台LBCache Log DB DB DBDB Global [Ⅴ] の時代 DB DB DB DB User1 DB DB DB DB User2 Web WebWebWeb Web
- 50. ・増え続けるデータ、更新の多いデータは水平分割 データが増えるならサーバも増やす 更新ネックになりそうならサーバを増やす ・もちろん今までの手法と合わせて対応可能 Web サーバの追加 スレーブ DB の追加 垂直分割 今度こそ安心！ [Ⅴ] の時代
- 51. スケールアウト Web 9 台 DB 16 台 Cache 1 台 Log 1 台LBCache Log DB DB DBDB Global [Ⅴ] の時代 DB DB DB DB User1 DB DB DB DB User2 DB DB DB DB User3 Web Web Web Web Web WebWeb Web Web
- 52. もっとスケールアウト！ Web 16 台 DB 20 台 Cache 1 台 Log 1 台LBCache Log [Ⅴ] の時代 DB DB DB DB User1 DB DB DB DB User2 DB DB DB DB User3 Web DB DB DB DB Global DB DB DB DB Event Web Web Web Web Web Web Web Web Web Web Web Web Web Web Web
- 53. 最初はこんなのだったのに・・・ Web DB Web 1 台 DB 2 台 DB 思い出
- 55. 架空戦記 完
- 56. こんにちわ現実
- 60. ・グラフで負荷状況を監視 サーバリソースを確認 munin cacti ・スロークエリログを確認 特に重いクエリを発見 mk-query-digest との組み合わせも効果的 ・ tcpdump + mk-query-digest 実行時間は短いが実行回数の多いクエリを発見 ・ MySQL の binlog を解析 更新の多いテーブルを特定 負荷状況の洗い出し
- 61. ・デッドロック検出時にログに残す 頻繁にデッドロックが起こる箇所の特定 MySQL5.6, MySQL5.5.30 以降 アプリレベルで実装もあり ・アプリレベルでサンプリングツールを用意 リクエスト時に 1/10000 の確率で情報を記録 実行時間、ページ・ API ごとの実行回数を調査 重いページ・ API を特定 リリース前の社内テストレベルでも有効 負荷状況の洗い出し
- 62. ・ xhprof の活用 本番に近いデータ量を開発環境に用意して実行 クエリキャッシュは無効にして行う 具体的に重い処理をメソッドレベルで特定 ・ DB ライブラリで実行時にクエリ数をカウント どのテーブルに何が何クエリ流れたかを計測 1 リクエスト辺りのクエリ数を明確にする 1 リクエスト単位で問題となっているクエリを特定 負荷状況の洗い出し
- 63. ・高負荷は 9 割方 DB 操作に起因 クエリ数の削減 クエリの見直し インデックスの見直し ロック範囲の見直し デッドロック時はリトライ やむを得ず重いクエリを流すならキャッシュする といった対策を 負荷状況の洗い出し
- 64. ・スケールアップとスケールアウトは上手く行う 月額 10 万円のサーバ 8 台で運用していたが 実は月額 20 万円のサーバを使えば 3 台で運用できるなんて事もある ・サーバ台数を試算 性能の差をテスト 現状の負荷状況と照らし合わせる ・実際の導入は段階的に行うと安全 月額 20 万円のサーバ 3 台で賄えそうであっても ひとまず 4 台用意しておいて 負荷状況を確認しながら減らしていく スケールアップとスケールアウト
- 66. ・単一 DB の場合 // DB から SELECT $dba->select('user_tbl'); ・ DB 分割対応後 // グローバル DB から SELECT $dba->gb()->select('user_id_tbl'); // 対象ユーザ ID のデータがある DB から SELECT $dba->user($user_id)->select('user_tbl'); // 複数のユーザ DB から SELECT $dba->user_multi($user_id_arr)->select('user_tbl'); コードの一例
- 67. ■DB 間を跨いだ JOIN ができない ・基本はアプリレベルで結合する事になる ・敢えて冗長なデータの持ち方をするのもあり Global と User で同じデータを持ってしまう 更新時には必ず両方とも更新する ・特にマスタデータは顕著なので全 DB に持つ マスタデータは Global なデータだが ユーザデータと JOIN したい事が多い 直に SQL を叩いて更新するのは禁止 必ず管理画面、専用スクリプトなどで更新 DB 分割アレコレ
- 68. ■ ランキング集計が大変 ・データが各サーバに分散している ・ FEDERATED ストレージエンジンを活用 別サーバのデータが参照できる 遅いが集計バッチでの利用なら使えるレベル INSERT SELECT で Global にデータを集める ロックがかかるため必ずスレーブを参照する DB 分割アレコレ
- 69. ■ ちょっとした抽出作業が大変 「レベル上位者 100 人を抽出して」 という感じの依頼に対して SQL で抽出する場合 全 UserDB に対して逐次実行 テキストや Excel 表などに手でまとめる というのを毎回やるのは辛い ・専用の管理画面を用意 SQL を投げると SELECT して結果をマージ テーブル表示してくれるだけの画面 DB 分割アレコレ
- 70. ■ 串刺し検索が大変 ・ライブラリの実装で吸収 複数 DB でも簡単に扱えるように ・水平分割すればする程コストが増大する 分割数は最低限にとどめておく ・検索結果をキャッシュする 串刺し検索のコストは大きい 同盟員のリストのような何度も参照する情報は 検索結果そのものをキャッシュしてしまう DB 分割アレコレ
- 71. ■ トランザクションの管理が煩雑 ・ライブラリの実装で吸収 可能な限り単純化する ・データ不整合発生時には必ずログを残す データ不整合の発生頻度は低い ログを頼りに手で対応 DB 分割アレコレ
- 72. ■ 分割数を増やすタイミング ・基本的にはグラフを監視して対応 DB サーバの負荷状況 ユーザ増加傾向を照らしあわせて先手を打つ ・大型プロモーションなどがあるなら試算して対応 ○○ 万人のユーザ数増加を見込み 同時接続数が ×× になるので対応 など DB 分割アレコレ
- 73. ■ 逆に縮小する場合 ・サーバリソースが余っているなら縮小を検討 ・サーバのスペックを落とす ・複数 DB を 1 つのサーバに同居させる サーバ A に User1 と User2 サーバ B に User3 と User4 のように配置するとアプリの改修が不用 DB 分割アレコレ
- 74. 弊社技術ブログでスライドを公開 サンプルコードを交えて紹介しています インフィニットループ技術ブログ PHPMatsuri2013 で発表した資料を公開しました「ソーシャルゲーム案件における DB 分割の PHP 実装～とにかく分割ですよ。 10 回じゃ足りない。 20 回くらい分 割。～」 http://www.infiniteloop.co.jp/blog/2013/07/phpmatsuri-db-partition/ 実装について詳しくは
- 76. インフィニットループでは、エンジニアを募集しています ・社長も含めほぼ全員がプログラマで技術者に優しい環境 ・勤務地は北海道札幌市、他社出向などは無し ・おいしい食べ物、自然いっぱい、花粉少ない、涼しい ・短い通勤時間、徒歩や自転車で通勤が可能 ・ U ターン、 I ターン大歓迎 ・ PHP 開発エンジニア ・スマホ開発エンジニア ・ MySQL エンジニア ・インフラエンジニア 求人募集
- 77. ご清聴ありがとうございました