ARMORED	  CORE	  Vのオンラインサービスにおけるクラウドサーバー活用事例	      株式会社 フロム・ソフトウェア	           技術部  惠良 和隆	   (kazutaka.era@fromso7ware.co.j...
自己紹介	•  2002年 豊橋技術科学大学修士課程修了	  •  2002年 (株)フロム・ソフトウェア入社	•  ゲーム開発効率化のための環境構築や	     ゲーム技術の研究開発に従事	  •  2007年 meet-­‐meの開発を機に...
本セッションの内容について	•  コンシューマゲーム機向けオンラインタイトル   「ARMORED	  CORE	  V」開発での経験がベース	  •  コンシューマ+オンライン	    –  PS3、Xbox360	  •  クラウドサービス...
ご注意(1)	•  オンラインタイトルって?	   –  ここでは、	      	      クライアント・サーバー型	                	  ネットワークシステム	     	      を持つものを指す	   –  プラット...
ご注意(2)	•  セッション内で挙げている解決手法は、あくま   で一例(≠ Best	  PracKce)	  •  タイトルによっては適切でない可能性もある	  •  IaaSに関する話は、Amazon	  EC2のみ	         ...
アジェンダ	•  オンラインタイトル開発の注意点	  •  インフラに関する注意点	  •  問題の整理	  •  具体的な対応方法	  •  考察	  •  まとめ	                           6
コンシューマ機向けオンラインタイトル開発で考慮する点	オンラインタイトル開発の注意点	                               7
コンシューマプラットフォームの特殊性	•  セキュリティ	    –  通信プロトコル	    –  ユーザー認証	  •  QAチェック	    –  プラットフォーマーで実施される	    –  各プラットフォームで規定される要件への対応	...
コンシューマプラットフォームの特殊性(2)	•  ハードウェアスペック	   –  CPUの違い(主にEndianの違い)	   –  メモリ容量	  •  利用できるライブラリの制限	   –  ライセンス的にOKでもポーティング作業が必要	...
サービス運営	•  製品のサポート	    –  オンラインならではのトラブルは必ず起きる	  •  プラットフォーム側オンラインサービスの都合	    –  PlayStaKon	  NetworkやXbox	  Live!のサービスメンテ ...
インフラに関する注意点	                    11
サーバーインフラ	•  クライアント数増加=サーバー負荷増大	   –  CPU負荷、メモリ使用量、帯域使用量	  •  ソフトが急に売れればサーバーを急ぎ増強す   る必要が出てくる	   –  ハードウェアは急に増やせない	  •  タイト...
売れ方	•  パッケージタイトルは売れ方が独特	   –  売れ方も含めてリージョン毎に大きな違い	 販                                     日本	 売        発売直後の急激な上昇	 本       ...
製品寿命	•  内容が変わらなければ当然飽きる	   –  同じユーザーが長期間遊び続けることはない	                                           日本	                         ...
インフラの選択肢	•  オンプレミス	    –  初期コストが大きい	    –  保守コストもそれなりに大きい	    –  自由に設計出来る	    –  インフラ専門の人材が必要	  •  クラウドサービス(IaaS)	    –  従...
Amazon	  EC2(IaaS)の制限	•  サービスレベル	    –  Amazon	  EC2では、年間稼働割合99.95%	    –  SLAの良いIaaSを使えば、オンプレミスよりサービスレベル     を高くできるかも?	  ...
問題の整理	          17
これまでに挙げた問題	•  プラットフォーム毎のセキュリティ対応	  •  QAチェック対応	  •  ハードウェアスペックの差異	  •  利用できるライブラリの制限	  •  サービス運営	  •  サーバー負荷の大きな変動	  •  クラ...
取り扱う問題一覧	•  プラットフォーム毎のセキュリティ対応	  •  QAチェック対応	  •  サーバー負荷の大きな変動	                              19
具体的な対応方法	             20
取り扱う問題一覧	•  プラットフォーム毎のセキュリティ対応	  •  QAチェック対応	  •  サーバー負荷の大きな変動	                              21
プラットフォーム毎のセキュリティ対応	  •  通信プロトコル	    –  Xbox360	       •  XSP(Xbox	  Secure	  Protocol)を使用	                                ...
プラットフォーム毎のセキュリティ対応(2)	•  Xbox360	     –  XSPの利用が必須であり通信プロトコルの選択権      は無いが、XLSPを利用すればセキュリティ面での      負担が下がる	               ...
XLSPの構成	     Xbox Live Server	                           Internet側	     Data Center側	                                   We...
XLSPの構成(2)	      Xbox Live Server	                   通信可能	                                    Web Proxy                   ...
Security	  Gatewayとは?	•  文字通りゲートウェイとしての役割	    –  プロトコル変換(XSP⇔UDP/TCP)	    –  クライアントから接続される(パケットが到達する)     と、Web	  Proxy経由で...
Security	  Gatewayの動き	                                  Internet側	      Data Center側	クライアント①	            From 1.1.1.1:3074...
XLSPの稼働条件	•  2枚のNIC(自由にアドレス設定できるもの)	  •  自由に使えるプライベートアドレス空間	  •  空いているグローバルIP	Amazon	  EC2インスタンスには	     	  ・NICが1つしかない	   ...
どうやってXLSPを動かすのか?	•  【再考】	  XLSPに必要なもの	    –  自由に使えるプライベートアドレス空間	    –  グローバルIPアドレス	    –  自由にアドレスをアサインできるNIC	   要するにネットワーク...
Amazon	  EC2上でVPN	•  Amazon	  EC2のVPNサービス(VPC)	     –  アプリケーションからのIPアドレス設定が出来ない      (グローバル/プライベートどちらも)	  •  OpenVPN	     ...
OpenVPN導入	Amazon EC2上のアドレス設定	                       TAPインタフェースのアドレス	    グローバルIP:3.3.3.3    プライベートIP:10.0.0.1	             ...
OpenVPN導入(2)	•  SGはTAPインタフェースしか見ないので、イン   ターネット側アドレスもVPN上のもの	   –  インターネットとVPNが完全に遮断されている	  •  インターネット側とVPNを繋ぐ必要がある	   –  ...
取り扱う問題一覧	•  プラットフォーム毎のセキュリティ対応	  •  QAチェック対応	  •  サーバー負荷の大きな変動	                              33
QAチェック対応	•  製品リリース前に必ずプラットフォーマーのQA   チェックに通す	  •  QAチェックは製品版仕様のもので行われる	  •  当然、接続先サーバー設定も製品版と同じ	  •  アップデートパッチにもQAチェックは必須	...
QAチェック対応(2)	•  サーバーへの接続情報をどうするか?	  例)	   HTTPでWebサーバーから情報を取得する	   –  アクセス先のURLをどうやって保持するか?	     •  コードにハードコード	     •  何らかの...
QAチェック対応(3)	•  NATでパケット転送する	   –  本番サーバーの入り口にiptablesを設定	   –  QAチェック用の専用サーバーを用意	   –  QAチームのグローバルIPアドレスから本番サー    バーに飛んできた...
取り扱う問題一覧	•  プラットフォーム毎のセキュリティ対応	  •  QAチェック対応	  •  サーバー負荷の大きな変動	                              37
動的IPアドレス割り当て	•  例) EC2インスタンスを作成すると、次の様な   ホスト名が割り当てられ、パブリックDNSと	     プライベートDNSに登録される	   –  Public	  DNS	     ec2-­‐50-­‐18...
動的IPアドレス割り当て(2)	•  DNS参照(nslookup)してみる	         –  Amazon	  EC2外からec2-50-18-12-34.us-          west-1.compute.amazonaws.co...
動的IPアドレス割り当て(3)	•  IPアドレス直指定アクセス	   – プライベートIPアドレス 	  :EC2↔EC2	   – グローバルIPアドレス 	  :外部↔EC2	  •  ホスト名指定アクセス	   – Public	  D...
動的IPアドレス割り当て(4)	•  ARMORED	  CORE	  Vでは、ホスト名ではなくIPア   ドレスを使用	    –  開発中は、EC2以外の環境でも稼働させるため	  •  グローバルIPアドレス、プライベートIPアドレス  ...
負荷分散対応	•  Amazon	  EC2には、ELB(ElasKc	  Load	  Balancing)   がある	  •  要するにロードバランサ―的な機能	  •  ELB用のエンドポイントが設定され、そこに対し   てアクセスする...
ELBの問題点	•  セッションベースのプロトコルのみ対応	   –  UDPは使えない!	  •  iptablesのようにパケット転送ができない	   –  QAチェックへの対応ができない/(^o^)\	   クライアントからの接続を分散す...
自前で負荷分散対応	•  ARMORED	  CORE	  Vでは、クライアントが最初に   接続するサーバー(ログインサーバー)を固定	  •  クライアントは、ログインサーバーに接続後、   本当に繋ぐべきサーバーの接続情報を取得	  • ...
自前で負荷分散対応(2)	                                     LoginSvはDBに記録されている                                     全FrontSvの接続情報を定期チ...
考察	•  実際に運用してみてわかったこと	   –  Amazon	  EC2はとても安定していた	     •  EC2が原因のトラブルは数えるほど	   –  コンシューマ機のタイトルはユーザーがものすごく    集中する	     • ...
考察(2)	•  課題	     –  今回紹介したXLSPを稼働させる方法では、スルー      プットが出ない	        •  大量のデータ送受信が要求される場合には不向き	     –  サーバーインスタンスを大量に使う場合、その上...
まとめ	•  コンシューマ機向けオンラインタイトルでの注   意点は、プラットフォーム毎に異なる	  •  クラウドサービスの制約はあるが、工夫次第   で回避可能	  •  サービス開始後のQAチェックも考慮する	  •  負荷分散を考慮する...
ご清聴ありがとうございました	                   49
Upcoming SlideShare
Loading in...5
×

Armored core vのオンラインサービスにおけるクラウドサーバー活用事例

2,182

Published on

CEDEC2012で使ったスライドです。

http://cedec.cesa.or.jp/2012/program/NW/C12_P0027.html

Published in: Technology
0 Comments
6 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,182
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
6
Embeds 0
No embeds

No notes for slide

Transcript of "Armored core vのオンラインサービスにおけるクラウドサーバー活用事例"

  1. 1. ARMORED  CORE  Vのオンラインサービスにおけるクラウドサーバー活用事例 株式会社 フロム・ソフトウェア   技術部  惠良 和隆 (kazutaka.era@fromso7ware.co.jp) 1
  2. 2. 自己紹介 •  2002年 豊橋技術科学大学修士課程修了  •  2002年 (株)フロム・ソフトウェア入社 •  ゲーム開発効率化のための環境構築や   ゲーム技術の研究開発に従事  •  2007年 meet-­‐meの開発を機にオンライン   サービス開発に携わる  •  ARMORED  CORE  V から本格的にクラウド   サービスを使用開始   2
  3. 3. 本セッションの内容について •  コンシューマゲーム機向けオンラインタイトル 「ARMORED  CORE  V」開発での経験がベース  •  コンシューマ+オンライン   –  PS3、Xbox360  •  クラウドサービス   –  IaaS   3
  4. 4. ご注意(1) •  オンラインタイトルって?   –  ここでは、     クライアント・サーバー型    ネットワークシステム     を持つものを指す   –  プラットフォームのオンラインサービスが提供する マッチングシステムを使ったP2P接続のみのタイト ルは含まない 4
  5. 5. ご注意(2) •  セッション内で挙げている解決手法は、あくま で一例(≠ Best  PracKce)  •  タイトルによっては適切でない可能性もある  •  IaaSに関する話は、Amazon  EC2のみ   5
  6. 6. アジェンダ •  オンラインタイトル開発の注意点  •  インフラに関する注意点  •  問題の整理  •  具体的な対応方法  •  考察  •  まとめ   6
  7. 7. コンシューマ機向けオンラインタイトル開発で考慮する点 オンラインタイトル開発の注意点 7
  8. 8. コンシューマプラットフォームの特殊性 •  セキュリティ   –  通信プロトコル   –  ユーザー認証  •  QAチェック   –  プラットフォーマーで実施される   –  各プラットフォームで規定される要件への対応   –  これをパスして初めてリリースできる 8
  9. 9. コンシューマプラットフォームの特殊性(2) •  ハードウェアスペック   –  CPUの違い(主にEndianの違い)   –  メモリ容量  •  利用できるライブラリの制限   –  ライセンス的にOKでもポーティング作業が必要   –  ハードウェア依存の機能や仕様を活用しているも のは、ポーティング作業も厄介   9
  10. 10. サービス運営 •  製品のサポート   –  オンラインならではのトラブルは必ず起きる  •  プラットフォーム側オンラインサービスの都合   –  PlayStaKon  NetworkやXbox  Live!のサービスメンテ ナンスも発生する  •  サービスの稼働状況の監視   –  インフラの監視   –  プロセスの監視 10
  11. 11. インフラに関する注意点   11
  12. 12. サーバーインフラ •  クライアント数増加=サーバー負荷増大   –  CPU負荷、メモリ使用量、帯域使用量  •  ソフトが急に売れればサーバーを急ぎ増強す る必要が出てくる   –  ハードウェアは急に増やせない  •  タイトル販売数の予測は立てにくい  •  フリーミアムゲームだとなおさら予測困難 12
  13. 13. 売れ方 •  パッケージタイトルは売れ方が独特   –  売れ方も含めてリージョン毎に大きな違い 販 日本 売 発売直後の急激な上昇 本 欧米 数 / 日 同時接続数が急に大きくなる 30 60 90 120 発売してからの経過日数 13
  14. 14. 製品寿命 •  内容が変わらなければ当然飽きる   –  同じユーザーが長期間遊び続けることはない   日本 欧米 ー ー 数 30 60 90 120 発売してからの経過日数 14
  15. 15. インフラの選択肢 •  オンプレミス   –  初期コストが大きい   –  保守コストもそれなりに大きい   –  自由に設計出来る   –  インフラ専門の人材が必要  •  クラウドサービス(IaaS)   –  従量制課金   –  保守は気にしなくて良い   –  IaaSの仕組みに基づいた制限がある 15
  16. 16. Amazon  EC2(IaaS)の制限 •  サービスレベル   –  Amazon  EC2では、年間稼働割合99.95%   –  SLAの良いIaaSを使えば、オンプレミスよりサービスレベル を高くできるかも?  •  仮想マシン上で出来ることに限られる   –  Amazon  EC2ではXen環境なので、XenのゲストOSで出来る ことに制限される   –  1つの仮想NIC   –  IPアドレスは動的割り当て   –  グローバルIPアドレスはNATによるマッピング   •  グローバルIPアドレスは予約可能   16
  17. 17. 問題の整理 17
  18. 18. これまでに挙げた問題 •  プラットフォーム毎のセキュリティ対応  •  QAチェック対応  •  ハードウェアスペックの差異  •  利用できるライブラリの制限  •  サービス運営  •  サーバー負荷の大きな変動  •  クラウドサービスの制限 18
  19. 19. 取り扱う問題一覧 •  プラットフォーム毎のセキュリティ対応  •  QAチェック対応  •  サーバー負荷の大きな変動   19
  20. 20. 具体的な対応方法 20
  21. 21. 取り扱う問題一覧 •  プラットフォーム毎のセキュリティ対応  •  QAチェック対応  •  サーバー負荷の大きな変動   21
  22. 22. プラットフォーム毎のセキュリティ対応  •  通信プロトコル   –  Xbox360   •  XSP(Xbox  Secure  Protocol)を使用   TCP UDP VDP XSP UDP IP Ethernet •  ユーザー認証   –  Xbox360   •  XLSP(Xbox  Live  Server  Plaorm)を使えば保証される 22
  23. 23. プラットフォーム毎のセキュリティ対応(2) •  Xbox360   –  XSPの利用が必須であり通信プロトコルの選択権 は無いが、XLSPを利用すればセキュリティ面での 負担が下がる   非常に素晴らしい! クラウドサービスの制限に引っかかる 23
  24. 24. XLSPの構成 Xbox Live Server Internet側 Data Center側 Web Proxy Internet Security Gateway XLSP 独自サーバー群 Internet側はグローバルIPが割り当てられ、 クライアント Data Center側はプライベートIPが割り当てられる 24
  25. 25. XLSPの構成(2) Xbox Live Server 通信可能 Web Proxy 接続先を取得 Internet Security Gateway クライアント数に応じてスケールアウト 自分自身のグローバルIPアドレスを Web Proxy経由でXbox Live Serverに登録 クライアント クライアントからのパケットを復号化する 25
  26. 26. Security  Gatewayとは? •  文字通りゲートウェイとしての役割   –  プロトコル変換(XSP⇔UDP/TCP)   –  クライアントから接続される(パケットが到達する) と、Web  Proxy経由でユーザー認証を行う   –  認証されていないパケットはすべて破棄される   –  WindowsのIPスタックとは完全に分離されている 26
  27. 27. Security  Gatewayの動き Internet側 Data Center側 クライアント① From 1.1.1.1:3074 To 3.3.3.3:3074 From 192.168.0.1:1000 XSP Packet To 192.168.1.1:12345 IP:1.1.1.1 独自サーバー UDP Packet Port:3074 From 2.2.2.2:3074 IP:192.168.1.1 To 3.3.3.3:3074 UDP Packet Port:12345 XSP Packet From 192.168.0.1:1001クライアント② To 192.168.1.1:12345 SG IP:3.3.3.3 IP:192.168.0.1∼5 IP:2.2.2.2 Port:3074 Port:1000∼10000 Port:3074 SGは、Internet側のグローバルIPアドレスとData Center側の プライベートIPアドレスを要求し、自身でNICに割り当てる。 (それぞれ空いているIPアドレスを提供しなければならない) 27
  28. 28. XLSPの稼働条件 •  2枚のNIC(自由にアドレス設定できるもの)  •  自由に使えるプライベートアドレス空間  •  空いているグローバルIP Amazon  EC2インスタンスには    ・NICが1つしかない    ・IPアドレスを自由にアサインできない  という制限がある!! 28
  29. 29. どうやってXLSPを動かすのか? •  【再考】  XLSPに必要なもの   –  自由に使えるプライベートアドレス空間   –  グローバルIPアドレス   –  自由にアドレスをアサインできるNIC 要するにネットワーク設定を自由に行いたい   という事なので、仮想的なネットワークを構築   すれば良いのでは? 29
  30. 30. Amazon  EC2上でVPN •  Amazon  EC2のVPNサービス(VPC)   –  アプリケーションからのIPアドレス設定が出来ない (グローバル/プライベートどちらも)  •  OpenVPN   –  Amazon  EC2上で動作する   –  仮想インタフェース(TAP)に対して、   アプリケーションからIPアドレスを設定できる   –  ただし、オーバーヘッドは大きい 30
  31. 31. OpenVPN導入 Amazon EC2上のアドレス設定 TAPインタフェースのアドレス グローバルIP:3.3.3.3 プライベートIP:10.0.0.1 192.168.0.1 Web Proxy グローバルIP:3.3.3.4 192.168.1.1 ・・・ プライベートIP:10.0.0.2 Security Gateway 192.168.1.254 グローバルIP:3.3.3.5 プライベートIP:10.0.0.3 192.168.2.1 独自サーバー TAPインタフェースだけをXLSPに使わせることで、 XLSPの要件を充足できる! 31
  32. 32. OpenVPN導入(2) •  SGはTAPインタフェースしか見ないので、イン ターネット側アドレスもVPN上のもの   –  インターネットとVPNが完全に遮断されている  •  インターネット側とVPNを繋ぐ必要がある   –  パケットリピータで中継する(例:stone)   OpenVPN パケット Security 独自サーバー リピータ Gateway SG用インスタンス 独自サーバー用インスタンス 32
  33. 33. 取り扱う問題一覧 •  プラットフォーム毎のセキュリティ対応  •  QAチェック対応  •  サーバー負荷の大きな変動   33
  34. 34. QAチェック対応 •  製品リリース前に必ずプラットフォーマーのQA チェックに通す  •  QAチェックは製品版仕様のもので行われる  •  当然、接続先サーバー設定も製品版と同じ  •  アップデートパッチにもQAチェックは必須 アップデートパッチのチェック中に 本番サービス中のサーバーに接続してしまう 34
  35. 35. QAチェック対応(2) •  サーバーへの接続情報をどうするか?  例)   HTTPでWebサーバーから情報を取得する   –  アクセス先のURLをどうやって保持するか?   •  コードにハードコード   •  何らかの形で動的に取得   –  QA専用のWebサーバーにどうやってアクセスさせ ればよいか?   35
  36. 36. QAチェック対応(3) •  NATでパケット転送する   –  本番サーバーの入り口にiptablesを設定   –  QAチェック用の専用サーバーを用意   –  QAチームのグローバルIPアドレスから本番サー バーに飛んできたパケットを、QAチェック用サー バーに転送する(DNAT)   –  QAチェックサーバーから戻ってきたパケットもきち んとQAチームに転送する(SNAT) 36
  37. 37. 取り扱う問題一覧 •  プラットフォーム毎のセキュリティ対応  •  QAチェック対応  •  サーバー負荷の大きな変動   37
  38. 38. 動的IPアドレス割り当て •  例) EC2インスタンスを作成すると、次の様な ホスト名が割り当てられ、パブリックDNSと   プライベートDNSに登録される   –  Public  DNS   ec2-­‐50-­‐18-­‐12-­‐34.us-­‐west-­‐1.compute.amazonaws.com   –  Private  DNS   ip-­‐10-­‐12-­‐34-­‐56.us-­‐west-­‐1.compute.internal   ※赤字部分がグローバルIPアドレス、     青字部分がプライベートIPアドレスを示す 38
  39. 39. 動的IPアドレス割り当て(2) •  DNS参照(nslookup)してみる   –  Amazon  EC2外からec2-50-18-12-34.us- west-1.compute.amazonaws.com   Name: ec2-50-18-12-34.us-west-1.compute.amazonaws.com   Address: 50.18.12.34 –  Amazon  EC2内から   Name: ec2-50-18-12-34.us-west-1.compute.amazonaws.com Address: 10.12.34.56 Name: ip-10-12-34-56.us-west-1.compute.internal Address: 10.12.34.56 39
  40. 40. 動的IPアドレス割り当て(3) •  IPアドレス直指定アクセス   – プライベートIPアドレス  :EC2↔EC2   – グローバルIPアドレス  :外部↔EC2  •  ホスト名指定アクセス   – Public  DNSのホスト名  :Always   – ただし、Public  DNSのホスト名はEC2インスタ ンス自身は知らない   40
  41. 41. 動的IPアドレス割り当て(4) •  ARMORED  CORE  Vでは、ホスト名ではなくIPア ドレスを使用   –  開発中は、EC2以外の環境でも稼働させるため  •  グローバルIPアドレス、プライベートIPアドレス を各サーバープロセスの設定ファイルに記述  •  サーバープロセスは自身のIPアドレスを設定 ファイルから取得し、それをDBに登録   –  DBを見れば接続先のIPアドレスが分かる   41
  42. 42. 負荷分散対応 •  Amazon  EC2には、ELB(ElasKc  Load  Balancing) がある  •  要するにロードバランサ―的な機能  •  ELB用のエンドポイントが設定され、そこに対し てアクセスする  •  バックエンドのIPアドレスは考慮しなくてよい   –  動的IPアドレス割り当ても無問題   42
  43. 43. ELBの問題点 •  セッションベースのプロトコルのみ対応   –  UDPは使えない!  •  iptablesのようにパケット転送ができない   –  QAチェックへの対応ができない/(^o^)\   クライアントからの接続を分散する目的で 利用できない 43
  44. 44. 自前で負荷分散対応 •  ARMORED  CORE  Vでは、クライアントが最初に 接続するサーバー(ログインサーバー)を固定  •  クライアントは、ログインサーバーに接続後、 本当に繋ぐべきサーバーの接続情報を取得  •  ログインサーバーからの情報を元に、クライア ントは別のサーバーに接続し直す 44
  45. 45. 自前で負荷分散対応(2) LoginSvはDBに記録されている 全FrontSvの接続情報を定期チェック FrontSvの IPリスト ①LoginSvから接続先となるFrontSv #n の情報を取得 LoginSv BackSv #1 BackSvの IPリスト DB FrontSv #1 BackSv #m ②LoginSvから取得した情報 BackSvの IPリスト を使いFrontSv #n に接続 各FrontSvはDBに記録されている FrontSv #n 全BackSvの接続情報を定期チェック 45
  46. 46. 考察 •  実際に運用してみてわかったこと   –  Amazon  EC2はとても安定していた   •  EC2が原因のトラブルは数えるほど   –  コンシューマ機のタイトルはユーザーがものすごく 集中する   •  クラウドによるスケールアウトが効果的に活用できる   •  スケールアップも容易に行える   –  開発用サーバーやQAチェック用サーバーなど、 目的ごとにスポットでサーバーを用意できるのは 非常に便利   46
  47. 47. 考察(2) •  課題   –  今回紹介したXLSPを稼働させる方法では、スルー プットが出ない   •  大量のデータ送受信が要求される場合には不向き   –  サーバーインスタンスを大量に使う場合、その上 で動くプロセスの起動や停止も大変になる   •  簡単な操作で大量のインスタンスやプロセスを制御で きる仕組みが必要   •  クラウドを効率良く扱うためのシステムが必要   47
  48. 48. まとめ •  コンシューマ機向けオンラインタイトルでの注 意点は、プラットフォーム毎に異なる  •  クラウドサービスの制約はあるが、工夫次第 で回避可能  •  サービス開始後のQAチェックも考慮する  •  負荷分散を考慮する  •  【結論】 クラウドサービスは、コンシューマ機 向けオンラインタイトルに最適なインフラの1 つになり得る 48
  49. 49. ご清聴ありがとうございました 49

×