PHPからJavaへ乗り換えた。そんな昔話をしよう
•
2 recomendaciones•7,026 vistas
ゲームサーバ勉強会第七回(SIG-NetworkSystem)での発表資料です
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a PHPからJavaへ乗り換えた。そんな昔話をしよう
Similar a PHPからJavaへ乗り換えた。そんな昔話をしよう (20)
Más de 優介 黒河
Último
Último (10)
PHPからJavaへ乗り換えた。そんな昔話をしよう
- 2. 今回の講演について • 2012年ごろに開発していたモバイルタイトルでの話になります。 • プロトタイプまでは PHP 5系で作成し、本制作をJava(Tomcat 6)で 行ったため、PHPでは最後まで作成しきれていません。 • そのタイトルでは初期のプロトタイプ時からサービスクローズ まで関わっていました。
- 4. モバイルのゲーム通信ざっくりおさらい クライアント APIサーバー DBサーバー クライアントから受け取ったデータを 処理して返す部分 PHP / Tomcat / node.js 等
- 5. モバイルのゲーム通信ざっくりおさらい クライアント APIサーバー DBサーバー ゲームの設定に関するマスターデータの格納及び、 各プレイヤーのセーブデータの格納先 MySQL / DB2 / MongoDB等
- 6. モバイルゲームでの通信処理の流れ１ クライアント APIサーバー DBサーバー 1. 「ログインする」「ガチャを引いた」「ダンジョンに入る」「ダンジョンクリア」等の アクション時にサーバーに送信。 アクションに紐づくデータをHTTP経由で送信
- 7. モバイルゲームでの通信処理の流れ２ クライアント APIサーバー DBサーバー 2. APIサーバーがクライアントから受け取ったアクション・データを元に処理。 APIサーバーがDBサーバー上のデータを読み書きして処理を行う。
- 8. モバイルゲームでの通信処理の流れ３ クライアント APIサーバー DBサーバー 3.最後に処理した結果を APIサーバーから クライアントへ返す
- 9. 今回の話 クライアント APIサーバー DBサーバー 今回の講演は、 ここを PHP実装→Java実装へ乗り換えた話
- 11. なんでJavaに変えたの？ • ボス(偉いプログラマ)からの提案でした • プロトタイプ開発中にゲーム仕様も膨らみ、予定より規模が大きく なったので PHPだと厳しそうだった • PHPよりはJavaのプログラマーの方が多い部署だった • ログイン機能と、ゲームプレイに入るときのデータ取得通信位までし か作っていなかったので、そこまで未練はなかった • Java自体は フィーチャーフォン時代とAndroid周りのクライアント コード書いてたので、何とかなるだろうという算段があった
- 12. というか、何でPHPを選択したの？ • 何となくです • PHPでWebサービスのアップデート/メンテナンスの経験があった • 勉強会等の資料等を見ていても当時はPHPが多かったように見えた
- 13. で、結局Javaに変えてよかったと思う？ • 変えて本当に良かった。 • このタイトルだけでなく、次のプロジェクトでもJavaを採用した • 後日PHP実装のAPIサーバーを少し見る事になりますが…。 やっぱりあの時Javaにしてよかったと思った
- 14. Javaに変えてよかった点 • 「コンパイル時に怒られる」って素晴らしい！ • 静的解析によるコード品質の担保 • 「キャッシュサーバー」なしで運用出来た
- 15. Javaに変えて面倒だった点 • DBへのアクセスで、オブジェクト変数への適応は自前で行う 必要があった → Reflectionを使って回避 • リソースリークが発生しうる → ちゃんと組めば問題ない.
- 18. コンパイルについて • PHP → サーバーにエラーとなるプログラムがアップされてしまい、 サーバーが全く動かない状態が起こりえる。 開発中でも他スタッフの手が止まってしまうのでヨロシクない • Java → 少なくともコンパイルが通ったプログラムなので、最低限の 保証はされている(実行時エラーが起きないとは言っていない)
- 19. 変数・型宣言 • PHP 型付け、変数宣言なしでも いきなり変数が使える • Java 変数を型とセットで宣言しないとソモソモ使えない
- 20. 変数・型宣言 • PHP → 変数名のスペルミス等で実行時に未初期化変数等のエラー等が 定期的に発生する。 int型のつもりが気付くとstring型になっててトラブル • Java → 変数名をスペルしたら、コンパイル通らないし、別の型で宣言された 変数には別の型の値は入れられない
- 21. PHPでありがちなエラー(極端にした例) for( $counter = 0 ; $counter < 10; $count++ ){ // 何かを処理する… } 変数名が間違っているので、ループ条件である 「$counter」がインクリメントされず別変数が インクリメントされてしまう。 その結果、無限ループしてしまう。 問題なのは、実行して この処理を通るまではエラーがわからない事
- 23. 静的解析によるコード品質の担保
- 25. CheckStyleについて • ソース本体(.javaファイル)に対して行う静的解析ツール • 主な目的は、コーディング規約が守られているかチェックする ツール • 特定のパスだけは例外等の細かい指定をxmlで出来る • 実際のプロジェクトでもいくつか部分的にチェック対象から外すよう にしていた
- 26. CheckStyleで出来ること • 変数やクラス名の命名規則チェック • 変数やメソッドは小文字スタートになっているか？等 • 行数の多いメソッドチェック • コメントをちゃんと書いているかチェック
- 27. FindBugsについて • コンパイル結果(.classファイル)に対して行う静的解析ツール • 主な目的は、バグになりそうな箇所のチェック • null ポインタアクセスのチェック等が出来る
- 30. しかし、Javaでは違う！！！
- 37. キャッシュサーバー？？？ APIサーバー DBサーバー キャッシュサーバー (memcached等) DBサーバーから得た結果を キャッシュサーバーに入れて、 そちらから優先的に読むようにする
- 38. 何故キャッシュサーバーなしで出来た？ • PHPでは、プロセスベース • 1アクセス毎にプログラム自体がリセットされてしまうので、次のアク セスがあった時も再びデータを取り直すところからスタート • 対して、Java(tomcat)はスレッドベース • 1アクセス毎にスレッドを割り当てて実行するので、アクセス毎にデー タはリセットされない • 次回以降のアクセスのためのデータを何らかの形で保持してあげれば 再びデータを取り直す必要がない
- 42. どういうデータにどう使った？ • static変数にキャッシュしたのはマスターデータ • DBのテーブル(種類)毎にそれぞれキャッシュの有効時間があり、一定 時間を過ぎると強制的に取り直していた • データ更新があった場合は、キャッシュをクリアするために開発者し か叩けないキャッシュクリア専用のAPIを用意した • ユーザーのデータは、アクセス毎にDBへアクセスしていた ※マスターデータとは、ゲームのカード設定等のデータ。 運営以外が書き換えることはない
- 43. その他にスレッドベースでのテクニック • static変数に アクセスしたユーザーIDの履歴を100件程用意し て、フレンド以外のパートナーユーザー紹介に使った • 外部サーバーにチュートリアル突破率等を渡す必要があったが、 別スレッドを立てて裏で外部サーバーへの通信を行う事でレス ポンスの向上を測った
- 48. PHPでのDBの取得周りについて id name lv 1 セイバー 10 2 アーチャー 9 3 ランサー 8 DBテーブル 「servant」$dbObj = GetFromDB(“SELECT * FROM servant”); $data = array(); for( $i = 0 ; $i < $dbObj->count ; ++$i ){ $data[i] = $dbObj->GetRow($i); } // データへのアクセスは下記のようになる // $data[0] で一件目のデータにヒット // $data[0][‘id’] <= ここには1 // $data[0][‘name’] <= ここには”セイバー” // $data[0][‘lv’] <= ここには10 // $data[1] で2件目のデータにヒット // $data[1][‘id’] <= ここには2 // $data[1][‘name’] <= ここには”アーチャー” // … DB上に上記のようなテーブルがあったと 仮定して、それを処理するPHPプログラム は左のような仮コードになる
- 49. JavaでのDBの取得周りについて id name lv 1 セイバー 10 2 アーチャー 9 3 ランサー 8 DBテーブル 「servant」 dbObj = GetFromDB(“SELECT * FROM servant”); Servant[] data = new Servant[dbObj.GetCount()]; for( int i = 0; i < dbObj.GetCount(); ++i ){ data[i] = new Servant(); data[i].id = dbObj.GetInt( i , “id” ); data[i].name = dbObj.GetString( i , “name” ); data[i].lv = dbObj.GetInt( i , “lv” ); } // 各カラムごとに個別に取ってくる必要があり面倒 DB上に上記のようなテーブルがあったと 仮定して、それを処理するJavaプログラム は左のような仮コードになる // どこかでクラス定義している class Servant{ public int id; public string name; public int lv; }
- 50. JavaでのDBの取得周りについて id name lv 1 セイバー 10 2 アーチャー 9 3 ランサー 8 DBテーブル 「servant」 dbObj = GetFromDB(“SELECT * FROM servant”); Servant[] data = new Servant[dbObj.GetCount()]; for( int i = 0; i < dbObj.GetCount(); ++i ){ data[i] = new Servant(); data[i].id = dbObj.GetInt( i , “id” ); data[i].name = dbObj.GetString( i , “name” ); data[i].lv = dbObj.GetInt( i , “lv” ); } // 各カラムごとに個別に取ってくる必要があり面倒 カラムが増えれば増えるほど、ここを書く 量が増えてきて面倒だし、ミスも増える // どこかでクラス定義している class Servant{ public int id; public string name; public int lv; }
- 54. Reflectionについて id name lv 1 セイバー 10 2 アーチャー 9 3 ランサー 8 DBテーブル 「servant」 // DBからデータを引くとき、各public変数の名前に勝手に代入させる class Servant{ public int id; public string name; public int lv; } DB名と変数名で紐づけして、 勝手に値が入るようにする
- 55. JavaでのDBの取得周りについて id name lv 1 セイバー 10 2 アーチャー 9 3 ランサー 8 DBテーブル 「servant」 dbObj = GetFromDB(“SELECT * FROM servant”); Servant[] data = dbObj.GetCount(); for( int i = 0 ; i < dbObj.GetCount();++i){ data[i] = new Servant(); dbObj.Read<Servant>( i , data[i] ); } // どこかでクラス定義している class Servant{ public int id; public string name; public int lv; }
- 57. まとめ • PHPからJavaに乗り換え時に、静的解析ツールを導入したので コードの品質を保った状態で開発できた • Java(tomcat)環境下では、スレッドベースだったのを利用して static変数(global領域)にデータをキャッシュする事が出来た • PHPでは連想配列という便利な奴がいたので、DBへのデータ アクセスが楽だったが、JavaではReflectionを使って楽にした