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