pfm (PaaS for MMOG) back ground of this development and technical details (overall image of implementation)

1. オンラインゲーム向けPaaS～ 提案の背景と技術的詳細について 株式会社コーエー 弥富 豪宏

3. S國志Online

5. 解決方法の提案（再）

6. 解決方法が実現した場合の社会への影響（再）

7. 実装の概要について

8. 実装の詳細について

9. まとめ

12. 開発自体の難しさによる人件費の高さ

13. MMOGも基本は分散コンピューティングシステム（以下分散システム）

14. 分散システムのプログラムは誰でもすぐできるというものではない

15. 結果的に人材の数が限られ、高コストとなる

21. 開発の難易度も大きく下がる

28. 物理系を構成するオブジェクトとそのオブジェクト間の相互作用を決定する物理法則が存在し、物理法則に従って系の時間的発展を計算していくことでMMOGは進行していく

29. オブジェクトには「自由意思」をもつもの(一般的にはプレイヤーやNPC)ともたないもの(一般的にはアイテムや建造物)がある

33. 仮想空間の開発・運営のビジネスモデルが根本的に変わる

35. 物理系を構成するオブジェクトとそのオブジェクト間の相互作用を決定する物理法則が存在し、物理法則に従って系の時間的発展を計算していくことでMMOGは進行していく

36. オブジェクトには「自由意思」をもつもの(一般的にはプレイヤーやNPC)ともたないもの(一般的にはアイテムや建造物)がある

38. 自由意思をもつオブジェクトはさらに「行動」の決定を系の外部からの入力によって行うもの（プレイヤーやBOT)と、系の状態をもとにした内部計算によって行うもの(NPC)に分けられる

41. 典型的MMOGは数千のプレイヤーと数百の置物、１万のNPCを処理する

42. 現時点でのハードウェアのパフォーマンスでは基本的に１台の機材で上記を処理することはできないため、分散システムを利用することになる

43. どのように上記の要素を分散して処理するか、がMMOGのシステムの要所

45. 系全体を物理的に相互作用しない副系に分割し、それぞれを別の機材が担当する手法

46. MMOGの実装としては一般的で多くのタイトルに採用されている

47. 株式会社コーエーの「三国志Online」では中国の州１つが１つの副系として定義されており、荊州がコンピューター１、益州がコンピューター２といった形で分散する

49. pfmでは物理系に所属するオブジェクト単位で担当する機材を分散する application server cluster

51. RPCの詳細はpfmのユーザーが記述するプログラムからは隠蔽される

52. したがってユーザープログラムからはオブジェクトがどの機材に所属しているかは一切意識せず扱うことができる

53. この条件を満たすユーザーのプログラム環境を以降ユーザーモードと呼ぶ

54. 例)enemy_player.decrease_hp(my_player.attack_point) decrease_hp RPC call reply decrease_hp RPC call Frontend B local cache modified backend A, B master data modified

56. 障害発生時には、その機材が担当していたオブジェクトを他の機材に割り振って処理を続行する

59. 例えば、ゾーンシステムでは、ゲーム内での物理的位置によって処理する機材が決定されてしまうためゲーム内におけるプレイヤーやNPCの集中がある程度を超えると単一の機材では処理しきれないという問題が発生してしまう。開発経験上はプレイヤーなら1500程度で限界

62. ユーザーモードでのプログラミングではこの困難さは下位のシステムによって完全に隠蔽されるため、分散システムではないゲームアプリケーションを記述するのと同程度の単純さになると考えられる

72. 通常のMMOGの場合、ゲームの更新のリリースごとにユーザーにパッチファイルと呼ばれる巨大なファイル（数百MB～1GB)をダウンロードさせて、そこに含まれるすべての更新を一気に適用する

75. ダウンロード先として、任意のサイトが使えるようにしたい(UGCの取り込みなどを容易にするため）

76. リソースの配信・非配信を容易にしたい（一旦配信したものでも問題があれば表示されないようにできる）

77. パッチ配信について(3) resource IDを通知 キャッシュのmd5が登録されているものと一致していなければ新しいダウンロード先を通知。 Resource IDとキャッシュファイルのmd5をペアにして問い合わせ(キャッシュがない場合はmd5は空) resource IDをキーにしてキャッシュを検索 URLが通知された場合には、そこから新しくリソースをダウンロードしてキャッシュを更新する。通知されなかった場合はローカルのキャッシュでそのまま表示

84. メモリ上のキャッシュを使うにしてもその読み書きの頻度が通常のwebアプリとは比較にならない。常時接続で非同期クエリを行うことが必要。

86. クエリを送信したコンテクスト（送信者など）をmsgidとペアにして記録しておく

87. サーバー側はクエリに含まれるmsgidをそのまま送り返す

89. PfM architecture Master server cluster application server cluster 太い矢印の接続はすべてpingでtimeoutを検出

91. frontendの制御をするfe_masterとbackendの制御をするbe_masterの２種類がある

92. fe_master : どのホストにどのゲームのユーザーがどのくらい接続しているかの管理とユーザーが接続するノードの決定

93. be_master : ゲーム中の各オブジェクトを保存するノードの管理

94. frontendはfe_masterとbe_master両方と、backendはbe_masterとやり取りをする

96. 最初に見つかった master server node(accept node と呼ぶ ) に接続し master server node のリストと master server として動作することが必要なデータ全部をそこから取得する

97. 取得中にそのデータに変更があった場合には accept node がその都度通知を送る

98. 取得完了後、 master server node のリストにあるすべてのホストと接続し、 accept node に準備完了の通知を送る

101. multicast を受け取った fe_master は fe_master node list を frontend に返信する (host address と接続 node 数を含む )

102. Frontend は list を接続 node 数でソートし、 list の先頭 (primary) と２番目 (secondary) と TCP 接続する。

103. 基本的に primary と通信する。障害が発生した場合は即座に secondary が primary に昇格し、 list の次の要素が secondary になる

104. master が追加された場合には frontend に通知され、 secondary より後ろの list が再度ソートされる

105. master の削除は ping で検出する

107. frontend は fe_master に client が接続すべき primary と secondary の frontend のアドレスを問い合わせる

108. primary のアドレスが問い合わせをした frontend 自身ならログイン完了。 client に primary と secondary の接続情報を送る。

109. client は今接続している frontend と primary が異なれば、 primary に対して最初から同じ処理を行う

110. ログイン後、接続先 frontend に障害が発生した場合、 client は secondary に対して同じ処理を行う。

111. 最初の接続 (game Id送信) fe_masterにこのclientの接続先を問い合わせ 接続先と障害発生時の接続先を通知 接続先がFrontend Aでなければ再接続 (game ID送信）->最初のフローに戻る

113. frontend は、その上で走っているプログラムが、オブジェクトを参照する必要がでると、 be_master に問い合わせを行い、そのオブジェクトを保持している backend のどれかからデータを取得し、自分のメモリ上にキャッシュする。この際 backend 側でも同様にキャッシュする

114. オブジェクトは複数の frontend から参照される可能性があるが、最初にデータを参照しようとした frontend だけがキャッシュを保持する。他の frontend はすでにキャッシュをしている frontend のアドレスだけを保持して、参照や更新はそのホストに対する RPC を介して行う。

115. データの更新はまずデータを保持しているすべての backend に送信され、その後 frontend のキャッシュが更新される。