Tweet
Tweet

Slide 1

Slide 1 text

世界で展開する新しいネットワークサービス 任天堂 竹本 賢一 はてな 渡辺 起 JAWS Days 2014 0315

Slide 2

Slide 2 text

任天堂 ネットワーク開発運用部 竹本 賢一 これまで関わってきた仕事 ネットワーク試遊台（DS/Wii) Wiiの間（VODサービス） ニンテンドー3DS/Wii U プレゼンス・マッチングサーバ 好きなAWSサービス Amazon S3 Route53

Slide 3

Slide 3 text

はてな システムプラットフォーム部 渡辺 起（わたなべたつる） これまで関わってきた仕事 好きなAWSサービス Amazon S3 id:wtatsuru

Slide 4

Slide 4 text

任天堂とはてなの関わり

Slide 5

Slide 5 text

任天堂とはてなの関わり • 2008年 「うごくメモ帳」 – ニンテンドーDSi DSiウェアとして配信 – サーバーサイドを開発

Slide 6

Slide 6 text

• 「うごメモシアター」「うごメモはてな」 としてネットワークサービスを展開 ※2013年5月31日をもってサービス終了 任天堂とはてなの関わり

Slide 7

Slide 7 text

任天堂とはてなの関わり のサーバーサイド開発を担当 ディレクター デザイナー アプリケーションエンジニア インフラエンジニア ディレクター アプリケーションエンジニア インフラエンジニア スムーズなコミュニケーションを重視し、 はてな京都オフィスで一緒に取り組んでいます

Slide 8

Slide 8 text

皆さんは Miiverseをご存知ですか？

Slide 9

Slide 9 text

Miiverseとは • Wii Uやニンテンドー3DSをお使いの世界中のお客様が、 それぞれのMiiを通じてつながることができる ゲームを話題の中心としたコミュニケーションサービス

Slide 10

Slide 10 text

思いのままに思いを共有 • テキストベースの投稿と、タッチスクリーンを生かした 手書き投稿が大きな特徴

Slide 11

Slide 11 text

みんなの反応を楽しむ • プレイ中のゲームのスクリーンショットを共有したり、 「そうだね」と表現された共感や、それぞれの投稿に対 して「コメント」を残すことができる

Slide 12

Slide 12 text

ゲームの中でもコミュニケーション • ゲームに対してもAPIを提供しており、ゲーム中から直 接Miiverseの機能を活用することができる • ゲーム開発者に専用ライブラリを提供

Slide 13

Slide 13 text

PCやスマホでもご覧いただけます • ウェブブラウザやお手持ちの スマートデバイスからも閲覧、 投稿が可能 • レスポンシブデザイン に対応

Slide 14

Slide 14 text

ウェブベースの実装 • Wii Uやニンテンドー3DSのMiiverseアプリケーション はウェブベースの通信を行います Aamzon EC2 Aamzon S3 / CloudFront HTTP/HTTPS

Slide 15

Slide 15 text

ウェブベースの実装 • Wii Uやニンテンドー3DSのMiiverseアプリケーション はウェブベースの通信を行います JS HTML5 CSS3

Slide 16

Slide 16 text

開発からリリースまで

Slide 17

Slide 17 text

開発の経緯 • 2011年末に、新ハードにおいて新しいコミュニ ケーションサービスの展開を計画 • 2012年から実際に開発に着手 – システムロンチのターゲットは2012年11月 • Wii U発売と同時にサービス公開 • 構築まで1年未満の短納期 – クライアントはWii U、PC/スマートデバイス、その 後にニンテンドー3DSを想定して検討

Slide 18

Slide 18 text

インフラ要求とIDC選定 • 世界中からのアクセス – 大陸ごとにいくつかのDCを契約するか もしくは AWS を利用するかを検討 – 早いうちにPC/スマートデバイス、世界中の ニンテンドー3DSもMiiverseに対応する

Slide 19

Slide 19 text

インフラ要求とIDC選定 • トラフィック増減に柔軟に対応できるインフラ – ウェブサービスの成長に合わせて • ユーザーの増加にあわせた設備拡張 • アクセスピークの変動に強い基盤 – 新しいサービスなのでアクセスピークが読みにくい – ピーク時以外のコストロスを抑えられる – スケーラビリティの高いシステムの必要性 • 十分なスケール能力のある巨大なストレージ • ハイIOを受け止められる高性能なデータベースの必要性 • 柔軟なネットワーク

Slide 20

Slide 20 text

インフラ要求とIDC選定 • AWSのみで構築することに – DB性能との兼ね合いも考慮すると、AWSとオンプレの ハイブリッド構成も視野 • オンプレの場合はFusionIOの利用も想定していたが… • hi1 or PIOPS 利用を前提にEC2でチャレンジ – ロンチ時点から大がかりな構成 • 短期間での構築にAWSは圧倒的に有利 • 海外でのDC契約に時間がかかる可能性があり時間的にも厳しい

Slide 21

Slide 21 text

リリースまでの歩み 2011年 年末 Wii U ロンチに向けたプロジェクトスタート 2012年 春 IDCをAWSに確定し開発を開始 開発、テスト、デバッグ環境を構築 夏 AWSのサポートに加入 SA/TAMから直接、定期的なアドバイスを受ける 駆け足で開発を進める 秋 フィールドテスト実施、最終の詰め作業 11月 Wii U 北米リリース (11/18) Wii U 欧州リリース (11/30) 12月 Wii U 日本リリース (12/8)

Slide 22

Slide 22 text

リリースまでの歩み 2013年 年始 PC・スマートデバイス向け開発開始 春 PC・スマートデバイス版リリース (4/25) ニンテンドー3DS版の開発を開始 12月 ニンテンドー3DS版リリース(12/10)

Slide 23

Slide 23 text

システム概要と構成

Slide 24

Slide 24 text

• EC2インスタンス1000台規模 • マルチリージョン（日本、北米、欧州） – 全て Multi-AZ 冗長構成 – VPNでフラットに結ぶ • Miiverse本体と3つのサブシステムを構築 – タイムライン、共感、通知 – REST API で通信 • 画像等静的データ配信 – S3 + CloudFront システム概要

Slide 25

Slide 25 text

活躍しているミドルウェア • 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

Slide 26

Slide 26 text

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活用のポイント

Slide 27

Slide 27 text

• 直近のリージョンにアクセス • 同期的な処理はほぼリージョン内で完結 3リージョン構成

Slide 28

Slide 28 text

• リージョン構成の考え方 – 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

Slide 29

Slide 29 text

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 システム構成 – 全体図

Slide 30

Slide 30 text

• 「普通の」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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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 – 遅延などはあまり問題になっていない

Slide 35

Slide 35 text

• 非同期ジョブ：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

Slide 36

Slide 36 text

• 画像ストレージには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

Slide 37

Slide 37 text

• 3つのサブシステム – REST API で通信 • タイムライン – ユーザ投稿データ – Pull型のタイムライン • 共感 – 「そうだね」 • 通知 – ユーザへの通知 • 全てマルチリージョン展開 Timeline Empathy Notification システム構成 – サブシステム

Slide 38

Slide 38 text

構築・デプロイ・監視 • 構築 – Chef Server • サービスインできるサーバをすぐに作成 • DB は EBS snapshot から • サーバ管理 – Mackerel • はてな製サーバ管理ツール • メトリクス収集・監視項目作成・デプロイ管理 • 監視 – Nagios • 稼働中のサーバの監視を自動作成 • Nagios 自体の監視に CloudWatch

Slide 39

Slide 39 text

日々のサーバー運用 • 24時間365日のサーバー監視チームと連携 – システム障害のアラート • Nagiosアラートや実機での確認 – IRCもしくは電話連絡での連携 • 迅速なエンジニアコールで対応 – 管理ツール不具合 • システムに連動したツール類のサポート • AWS Supportの活用 – AWSに依存した障害はSupportに連絡 – 必要に応じて電話等も活用し迅速に解決

Slide 40

Slide 40 text

いろいろありました ～ 苦労話 ～

Slide 41

Slide 41 text

苦労話 – リリース当日 • 北米リリース （2012年11月18日） – ロンチ以来、最大規模のパフォーマンス障害 • クライアントから接続できなくなる • フロントエンド、バックエンドどちらともパ フォーマンス劣化 • EC2インスタンスの増強 • ELBからHAProxyへの置き換え • アプリケーションのロジック変更 – ネットワークに優しく – 12時間程度で完調に。

Slide 42

Slide 42 text

苦労話 – 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投入により レスポンス大幅改善

Slide 43

Slide 43 text

苦労話 – 急なアクセス増加 • ユーザーの急増に伴うトラフィックの変化 – アクセスピークに対して • インスタンスやネットワークの状況 • アラート、エラーログのチェック – 例えばI/O不足 • タイムラインのキャッシュ部分等 • 頻繁にキャッシュクリア = truncate table • 継続性があれば hi1/c3/i2インスタンスへ切り替え

Slide 44

Slide 44 text

苦労話 - 定常的に抱える悩み • 疎通障害の問題 – AZ間疎通障害への対処が難しい – AZ間通信を行っているところの切り離し、戻し • インスタンス障害 – インスタンス障害・メンテに遭遇することが多い – マスターDBでもMHAを活用してすぐに対処できる • EBS I/O詰まりなどでいつの間にか切り替わっていることも • EBS障害への対応 – I/Oが全くできなくなることがある – サービスアウトされるようにケア

Slide 45

Slide 45 text

AWSを活用して...

Slide 46

Slide 46 text

AWSを活用して • リソース不足に短期間で対応 – 急激なアクセス増加 • 仮想マシンはリードタイムゼロで調達可能 • オンプレに比べ、スケールアウト・スケールアップが容易 – SDKの活用 • ツールの作り込みでなるべく自動化しフットワークを高める。 柔軟性をもたせ、運用コストも低減。 • ストレージ開発/運用負荷の軽減 – 膨大な手書き投稿やスクリーンショットなど多量のオブジェクト • S3やCloudFrontの連携でシームレスにデータ運用 – オンプレと比べ、ストレージ運用の負担がとても軽い • 強力なAPIを使ってロジックに落とし込める

Slide 47

Slide 47 text

• IO不足や演算能力不足への対処 – データベースでPIOPS EBSでもIOが足りない • Hi1やi2などのSSD搭載インスタンスを活用 – アプリサーバやプロキシインスタンスのCPU • 高速なECUが利用できるc3/m3インスタンスで強化 • セキュアでかつスケーラブルなネットワークの構築 – メッシュで結んだVPC , Multi-AZで強いシステムを構成 – ACLやSecurityGroupの活用で柔軟なオペレーション • 有事の際にAWS基盤で困った時には – Enterpriseサポート – 専属のSAやTAMと迅速にコンタクト AWSを活用して

Slide 48

Slide 48 text

Thank you for listening!!!