Recommended
More Related Content
What's hot
What's hot (20)
Similar to Armored core vのオンラインサービスにおけるクラウドサーバー活用事例
Similar to Armored core vのオンラインサービスにおけるクラウドサーバー活用事例 (20)
Recently uploaded
Recently uploaded (14)
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