Jaws Days 2014 Miiverse

世界で展開する新しいネットワークサービス「Miiverse 」のAWS活用事例
Jaws Days 2014 発表資料

Transcript

1. 世界で展開する新しいネットワークサービス 任天堂 竹本 賢一 はてな 渡辺 起 JAWS Days 2014 0315
2. 任天堂 ネットワーク開発運用部 竹本 賢一 これまで関わってきた仕事 ネットワーク試遊台（DS/Wii) Wiiの間（VODサービス） ニンテンドー3DS/Wii U プレゼンス・マッチングサーバ 好きなAWSサービス Amazon S3 Route53
3. はてな システムプラットフォーム部 渡辺 起（わたなべたつる） これまで関わってきた仕事 好きなAWSサービス Amazon S3 id:wtatsuru
4. 任天堂とはてなの関わり
5. 任天堂とはてなの関わり • 2008年 「うごくメモ帳」 – ニンテンドーDSi DSiウェアとして配信 – サーバーサイドを開発
6. • 「うごメモシアター」「うごメモはてな」 としてネットワークサービスを展開 ※2013年5月31日をもってサービス終了 任天堂とはてなの関わり
7. 任天堂とはてなの関わり のサーバーサイド開発を担当 ディレクター デザイナー アプリケーションエンジニア インフラエンジニア ディレクター アプリケーションエンジニア インフラエンジニア スムーズなコミュニケーションを重視し、 はてな京都オフィスで一緒に取り組んでいます
8. 皆さんは Miiverseをご存知ですか？
9. Miiverseとは • Wii Uやニンテンドー3DSをお使いの世界中のお客様が、 それぞれのMiiを通じてつながることができる ゲームを話題の中心としたコミュニケーションサービス
10. 思いのままに思いを共有 • テキストベースの投稿と、タッチスクリーンを生かした 手書き投稿が大きな特徴
11. みんなの反応を楽しむ • プレイ中のゲームのスクリーンショットを共有したり、 「そうだね」と表現された共感や、それぞれの投稿に対 して「コメント」を残すことができる
12. ゲームの中でもコミュニケーション • ゲームに対してもAPIを提供しており、ゲーム中から直 接Miiverseの機能を活用することができる • ゲーム開発者に専用ライブラリを提供
13. PCやスマホでもご覧いただけます • ウェブブラウザやお手持ちの スマートデバイスからも閲覧、 投稿が可能 • レスポンシブデザイン に対応
14. ウェブベースの実装 • Wii Uやニンテンドー3DSのMiiverseアプリケーション はウェブベースの通信を行います Aamzon EC2 Aamzon S3 / CloudFront HTTP/HTTPS
15. ウェブベースの実装 • Wii Uやニンテンドー3DSのMiiverseアプリケーション はウェブベースの通信を行います JS HTML5 CSS3
16. 開発からリリースまで
17. 開発の経緯 • 2011年末に、新ハードにおいて新しいコミュニ ケーションサービスの展開を計画 • 2012年から実際に開発に着手 – システムロンチのターゲットは2012年11月 • Wii U発売と同時にサービス公開 • 構築まで1年未満の短納期 – クライアントはWii U、PC/スマートデバイス、その 後にニンテンドー3DSを想定して検討
18. インフラ要求とIDC選定 • 世界中からのアクセス – 大陸ごとにいくつかのDCを契約するか もしくは AWS を利用するかを検討 – 早いうちにPC/スマートデバイス、世界中の ニンテンドー3DSもMiiverseに対応する
19. インフラ要求とIDC選定 • トラフィック増減に柔軟に対応できるインフラ – ウェブサービスの成長に合わせて • ユーザーの増加にあわせた設備拡張 • アクセスピークの変動に強い基盤 – 新しいサービスなのでアクセスピークが読みにくい – ピーク時以外のコストロスを抑えられる – スケーラビリティの高いシステムの必要性 • 十分なスケール能力のある巨大なストレージ • ハイIOを受け止められる高性能なデータベースの必要性 • 柔軟なネットワーク
20. インフラ要求とIDC選定 • AWSのみで構築することに – DB性能との兼ね合いも考慮すると、AWSとオンプレの ハイブリッド構成も視野 • オンプレの場合はFusionIOの利用も想定していたが… • hi1 or PIOPS 利用を前提にEC2でチャレンジ – ロンチ時点から大がかりな構成 • 短期間での構築にAWSは圧倒的に有利 • 海外でのDC契約に時間がかかる可能性があり時間的にも厳しい
21. リリースまでの歩み 2011年 年末 Wii U ロンチに向けたプロジェクトスタート 2012年 春 IDCをAWSに確定し開発を開始 開発、テスト、デバッグ環境を構築 夏 AWSのサポートに加入 SA/TAMから直接、定期的なアドバイスを受ける 駆け足で開発を進める 秋 フィールドテスト実施、最終の詰め作業 11月 Wii U 北米リリース (11/18) Wii U 欧州リリース (11/30) 12月 Wii U 日本リリース (12/8)
22. リリースまでの歩み 2013年 年始 PC・スマートデバイス向け開発開始 春 PC・スマートデバイス版リリース (4/25) ニンテンドー3DS版の開発を開始 12月 ニンテンドー3DS版リリース(12/10)
23. システム概要と構成
24. • EC2インスタンス1000台規模 • マルチリージョン（日本、北米、欧州） – 全て Multi-AZ 冗長構成 – VPNでフラットに結ぶ • Miiverse本体と3つのサブシステムを構築 – タイムライン、共感、通知 – REST API で通信 • 画像等静的データ配信 – S3 + CloudFront システム概要
25. 活躍しているミドルウェア • OS – CentOS６ • Development – Perl – Javascript, HTML5, CSS3 • Database – MySQL • Cache – Redis, Memcached • LB/Proxy – Nginx, HAProxy, Squid • Network – Quagga, Openswan, OpenVPN • Monitoring – Nagios, CloudWatch – Mackerel, Graphite – fluentd, MongoDB • Deployment – Git, Chef – Capistrano, Cinamon
26. Route 53 Hosted Zone Route Table Elastic Load Balancing VPC Router Internet Gateway VPN Gateway VPN Connection Elastic IP Instances Amazon S3 Elastic Block Store Network CDN Cloud Front bucket EBS/PIOPS S3 EC2 SDK Ruby AWS活用のポイント
27. • 直近のリージョンにアクセス • 同期的な処理はほぼリージョン内で完結 3リージョン構成
28. • リージョン構成の考え方 – Multi Region – Multi-AZ – Cross replication • リージョン間をVPNでフラットに結ぶ – IPSec VPN + IPIP tunnel + OSPF – AZ単位でフルメッシュに 3リージョン構成 AZ #1 AZ #2 AZ #3 AZ #1 AZ #2 AZ #3 AZ #1 AZ #2 AZ #3 VPN Network
29. Multi-Region Multi-AZ 構成 VPN Connection VPN Connection Availability Zone #1 Region #Tokyo Amazon EC2 Amazon S3 Amazon CloudFront EC2 DB Instances Elastic Load Balancing VPN Instance VPN Connection Internet Gateway Availability Zone #2 VPN Instance Availability Zone #3 Amazon EC2 Amazon EC2 EC2 DB Instances EC2 DB Instances Region #US VPN Instance Region #EU システム構成 – 全体図
30. • 「普通の」Webスタック • ELB, Reverse Proxy, App, Cache, DB Elastic Load Balancing Reverse Proxy (Nginx) ELB/HAProxy App servers DB (MySQL) Cache (memcached) Job Queue + Worker システム構成 HAProxy Route 53 Amazon S3 CloudFront
31. ELB/HAProxy • ELB + Route53 Alias Record • Nginx: SSL Termination システム構成 - Proxy Elastic Load Balancing Reverse Proxy (Nginx) App servers DB (MySQL) Cache (memcached) Job Queue + Worker HAProxy Route 53 Amazon S3 CloudFront
32. Reverse Proxy (Nginx) • 内部では ELB, HAProxy で振り分け システム構成 – ELB/HAProxy Elastic Load Balancing ELB/HAProxy App servers DB (MySQL) Cache (memcached) Job Queue + Worker HAProxy Route 53 Amazon S3 CloudFront
33. ELB/HAProxy • App server: Perl PSGI/Plack • Memcached でキャッシュ システム構成 - Cache Elastic Load Balancing Reverse Proxy (Nginx) App servers DB (MySQL) Cache (memcached) Job Queue + Worker HAProxy Route 53 Amazon S3 CloudFront
34. HAProxy Cache (memcached) • データベースの選択 – MySQL 5.5を採用 – MHA for MySQL でフェイルオーバ システム構成 - DB Elastic Load Balancing Reverse Proxy (Nginx) ELB/HAProxy App servers DB (MySQL) Amazon S3 CloudFront Job Queue + Worker Route 53 • Cross region replication – 遅延などはあまり問題になっていない
35. • 非同期ジョブ：TheSchwartz or 独自実装worker – システムごとに MySQL や Redis を活用 • リージョン間でのジョブ転送は MySQL Replication で システム構成 - jobs Elastic Load Balancing Reverse Proxy (Nginx) ELB/HAProxy App servers DB (MySQL) Amazon S3 CloudFront Cache (memcached) Job Queue + Worker HAProxy Route 53
36. • 画像ストレージにはS3を使用 • CloudFront 経由で配信 システム構成 – ストレージ HAProxy Cache (memcached) Elastic Load Balancing Reverse Proxy (Nginx) ELB/HAProxy App servers DB (MySQL) Amazon S3 CloudFront Job Queue + Worker Route 53
37. • 3つのサブシステム – REST API で通信 • タイムライン – ユーザ投稿データ – Pull型のタイムライン • 共感 – 「そうだね」 • 通知 – ユーザへの通知 • 全てマルチリージョン展開 Timeline Empathy Notification システム構成 – サブシステム
38. 構築・デプロイ・監視 • 構築 – Chef Server • サービスインできるサーバをすぐに作成 • DB は EBS snapshot から • サーバ管理 – Mackerel • はてな製サーバ管理ツール • メトリクス収集・監視項目作成・デプロイ管理 • 監視 – Nagios • 稼働中のサーバの監視を自動作成 • Nagios 自体の監視に CloudWatch
39. 日々のサーバー運用 • 24時間365日のサーバー監視チームと連携 – システム障害のアラート • Nagiosアラートや実機での確認 – IRCもしくは電話連絡での連携 • 迅速なエンジニアコールで対応 – 管理ツール不具合 • システムに連動したツール類のサポート • AWS Supportの活用 – AWSに依存した障害はSupportに連絡 – 必要に応じて電話等も活用し迅速に解決
40. いろいろありました ～ 苦労話 ～
41. 苦労話 – リリース当日 • 北米リリース （2012年11月18日） – ロンチ以来、最大規模のパフォーマンス障害 • クライアントから接続できなくなる • フロントエンド、バックエンドどちらともパ フォーマンス劣化 • EC2インスタンスの増強 • ELBからHAProxyへの置き換え • アプリケーションのロジック変更 – ネットワークに優しく – 12時間程度で完調に。
42. 苦労話 – Wii U リリース当日 00:00 Release 03:00 ELBの切替が頻発する フロントエンドのNginx負荷増大 03:30 03:40 06:45 フロントに設置したELBへの接続が断続的に切れる状態 アプリロジックを変更しDB負荷を減らす方向で調整 08:30 AM: 午前 PM: 午後 共感・タイムラインサーバー性能低下 DBサーバの大量追加で少し緩和する 11:00 11:30 タイムラインサーバの不調継続中 DBサーバの追加で緩和する RP(リバースプロキシ)で接続が詰まる 設定ミスが発覚 12:00 DBの追加を継続 アプリサーバーの再起動を断続的に行う アプリプロセス(Plack)の調整 12:30 タイムラインサーバの不調継続中 DBサーバの追加で緩和する 13:00 ゲームAPIの応答は回復し始める 14:40 タイムラインサーバーのレスポンス低下が続く ELBを介さずに直接DB接続する処置でレスポンスが 大幅に改善 15:00 16:00 高負荷部分のELB代替としてHAProxyを投入 HAProxy投入により レスポンス大幅改善
43. 苦労話 – 急なアクセス増加 • ユーザーの急増に伴うトラフィックの変化 – アクセスピークに対して • インスタンスやネットワークの状況 • アラート、エラーログのチェック – 例えばI/O不足 • タイムラインのキャッシュ部分等 • 頻繁にキャッシュクリア = truncate table • 継続性があれば hi1/c3/i2インスタンスへ切り替え
44. 苦労話 - 定常的に抱える悩み • 疎通障害の問題 – AZ間疎通障害への対処が難しい – AZ間通信を行っているところの切り離し、戻し • インスタンス障害 – インスタンス障害・メンテに遭遇することが多い – マスターDBでもMHAを活用してすぐに対処できる • EBS I/O詰まりなどでいつの間にか切り替わっていることも • EBS障害への対応 – I/Oが全くできなくなることがある – サービスアウトされるようにケア
45. AWSを活用して...
46. AWSを活用して • リソース不足に短期間で対応 – 急激なアクセス増加 • 仮想マシンはリードタイムゼロで調達可能 • オンプレに比べ、スケールアウト・スケールアップが容易 – SDKの活用 • ツールの作り込みでなるべく自動化しフットワークを高める。 柔軟性をもたせ、運用コストも低減。 • ストレージ開発/運用負荷の軽減 – 膨大な手書き投稿やスクリーンショットなど多量のオブジェクト • S3やCloudFrontの連携でシームレスにデータ運用 – オンプレと比べ、ストレージ運用の負担がとても軽い • 強力なAPIを使ってロジックに落とし込める
47. • IO不足や演算能力不足への対処 – データベースでPIOPS EBSでもIOが足りない • Hi1やi2などのSSD搭載インスタンスを活用 – アプリサーバやプロキシインスタンスのCPU • 高速なECUが利用できるc3/m3インスタンスで強化 • セキュアでかつスケーラブルなネットワークの構築 – メッシュで結んだVPC , Multi-AZで強いシステムを構成 – ACLやSecurityGroupの活用で柔軟なオペレーション • 有事の際にAWS基盤で困った時には – Enterpriseサポート – 専属のSAやTAMと迅速にコンタクト AWSを活用して
48. Thank you for listening!!!