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