人気ゲームアプリ「クラッシュフィーバー」におけるaws活用

人気ゲームアプリ「クラッシュフィーバー」における AWS活用

～Amazon Aurora と AWS Lambda の事例～

ワンダープラネット株式会社執行役員CTO 村田知常

© 2016 WonderPlanet Inc.

自己紹介

村田知常（むらたともつね）• ワンダープラネット株式会社執行役員CTO（R&D事業部管掌）• 大学院を修了後、10年間名古屋のSIerにて業務システムを開発• ワンダープラネット株式会社の創業メンバー• 著書「SpriteKitではじめる2Dゲームプログラミング Swift対応」• 好きなAWS


AWS Lambda

ワンダープラネット株式会社

2012年9月3日設立スマートデバイス向けフルネイティブアプリ・ゲームの企画・開発・運営・販売

名古屋本社（栄）東京オフィス（新宿）

従業員数 63名

楽しいね！を、世界中の日常へ



https://youtu.be/tmbq-_PbVt4

クラッシュフィーバー公式PV

クラッシュフィーバー

仮想世界をモチーフとした世界観を舞台に、画面をタップするだけの簡単操作でパネルをブッ壊す爽快感やサウンドが魅力のゲーム


クラッシュフィーバー

• 2015年7月にリリース• 世界累計600万ダウンロード突破• 日本App StoreセールスランクにてTOP10入り• 2016年5月より台湾・香港・マカオ版をリリース• 台湾と香港のApp Storeセールスランクにて第1位を獲得• 2016年5月と8月に全国テレビCMを実施


アジェンダ

• クラッシュフィーバーのサーバー構成• AWSを採用して良かった点• AWSを採用して苦労した点• クラッシュフィーバーにおけるAWS事例紹介• Amazon Auroraへの移行事例• AWS Lambdaの利用事例


クラッシュフィーバーのサーバー構成


APIサーバーの規模感


• クライアントからのリクエストに対して• 600,000 req / min まで処理することが可能• 現在のレイテンシーは 50 ms 前後

※ ELB上の数値です。

APIサーバーを中心とした構成


Elastic Load Balancing

Amazon Route 53

AmazonDynamoDB

AmazonRDS

Amazon ElastiCache

Internetmobile client EC2 Instances

Auto Scaling group

Amazon Route 53

APIサーバーの中身


• Amazon Linux• nginx• PHP• FuelPHP• PHP-FPM• APCu• Mackerel

利用しているAWSサービス• Amazon EC2• Amazon Aurora• Amazon DynamoDB• Amazon ElastiCache（Redis）• Amazon Route 53 ・・・ Private DNSとしても利用• Elastic Load Balancing• Amazon S3• Amazon SQS ・・・ SQSを経由して非同期で処理• Amazon SNS ・・・ CloudWatchと組み合わせてLambdaを実行• AWS CloudWatch• AWS Lambda


AWSを採用して良かった点


AWSを採用して良かった点

• いつでも好きな時に素早くリソースを増減できる• グローバル展開が自分たちでできる• ビジネスサポートで何でも相談できる• エンジニアが楽しんで開発できる


いつでも好きな時に素早くリソースを増減できる

• 開発時は最小限のスペック、サーバー台数で良い• リリース時は想定アクセス数に対して待ち構える• その後はどう増える/減るかは、読めない


スペック(インスタンスタイプ)の変更、サーバーの増減がいつでも出来るのが良いところ。

グローバル展開が自分たちでできる

© 2016 WonderPlanet Inc.https://aws.amazon.com/jp/about-aws/global-infrastructure/

グローバル展開が自分たちでできる

• 日本にいながら、シンガポールや米国などにリソースを配置できる• 主要なサービスは、どこのリージョンでも使うことができる


自社で海外展開することでノウハウの蓄積と運営もやりやすい

ビジネスサポートで何でも相談できる

• 何かが起こってからでは遅い（ユーザーは待ってくれない）• ビジネスサポートは、とにかくレスポンスが早い！• サーバーに関する技術的な相談にも対応


メンバーがビジネスサポートへ相談リーダーの負荷軽減

AWSは触っていて楽しい！

• AWSを扱えることが1つの武器となる• サービスの追加、機能追加が激しい• AWSを使っていることが採用のウリにもなる


エンジニア自身が楽しんで開発できるのは大切

AWSを採用して苦労した点


AWSを採用して苦労した点

•クラウドとは言えリソースは有限•容易にスケールアップできるが故に、過去のプロダクトで使いすぎた


クラウドとは言えリソースは有限

•リソースを確保したくても在庫がなくて確保できない場合もある• 一時的であればspotインスタンスで対応も良い•デフォルトのAWSサービス制限• 必要に応じて制限引き上げのリクエストをしましょう


http://docs.aws.amazon.com/ja_jp/general/latest/gr/aws_service_limits.html

容易にスケールアップできるが故に、、、

• パフォーマンス障害に対して一時的な対応としてスペックや台数を増やして対応• 根本原因を改修し、戻さなければならない• 戻さないと請求金額を見たときに…真っ青


請求に関する監視

• アラートと通知で請求額をモニタリングCloudWatch を使用して AWS のコストをモニタリング• Billing and Cost Management• 特に「Cost Explorer」がオススメ• 細かく利用料金を確認することが可能• 未来の予測も出すことが可能


目標金額の設定と利用状況の把握

• 金額をここまでに抑えようと目標を設定• 今どれだけ使い、このリソース変更を行うことでどれだけ請求が増えるのかを把握させる


結果、メンバーがコストを意識し自発的にコストダウンを考える

事例紹介①Amazon Auroraへの移行事例


AmazonAurora移行前のデータベース

• Amazon RDS for MySQL を利用• Multi-AZを有効• リードレプリカを使い Master-Slave の構成• 変更の少ないデータはキャッシュに持たせて負荷対策• 空き容量が少なくなるとメンテナンスで容量を追加• ユーザーの増減により増加ペースが変わるので

常に確認が必要• 容量追加の終了時間が読みにくい


AmazonAuroraへの移行を考えたきっかけ

• テレビCMに向けてのパフォーマンス• DBのインスタンスタイプを上げて検証• db.r3.8xlarge で負荷テスト• 想定DAUに耐えるリクエスト数は捌けない• 対策期間が短く、チューニングやDB分割は時間的に厳しい


Amazon Auroraに置き換えるだけで倍以上の性能が出るらしいぞ？

移行にあたって検証したこと

• まずはAuroraのパフォーマンスを確認• MySQL互換の互換性を確認• MySQLとAuroraの両方に全SQLを発行し結果を確認• AWS Summit Tokyo 2016があったので情報収集• サービス提供2週間前に切り換えた。とか普通に聞いた• 移行時のメンテナンス時間を短くするコツが聞けた


AmazonAuroraへの移行手順-メンテナンスの前準備：簡略説明 -


レプリケーション

最新のデータと常に等しい状態に

MySQLDBinstance

Aurora

AmazonAuroraへの移行手順-メンテナンスの前準備 -

1. MySQLにリードレプリカを追加2. リードレプリカへのレプリケーションを停止3. レプリカ情報(バイナリログのポジションをメモ)を取得、

snapshotを作成4. snapshotからレプリカ遅延が発生しないサイズの

Auroraインスタンスを起動5. MySQLからAuroraへのレプリケーションを開始

（先ほど作成したリードレプリカは削除）© 2016 WonderPlanet Inc.

AmazonAuroraへの移行手順-メンテナンス -

1. Auroraのレプリカラグがゼロなのを確認2. MySQLからAuroraへのレプリケーションを停止3. あとはAPIからの向き先を変え、Auroraにレプリカを

追加したり、運用に必要なものを設定4. 最後にAuroraをウォームアップと、RDSをお片付け


AmazonAuroraへ移行したことで…

• パフォーマンスが上がった分、スペックを下げることでコストダウン• 空き容量が足らなくなったら自動で追加されるので空き容量を気にしなくて良くなった！！→ 開発へ集中できる• 特に問題は発生していません。


事例紹介②AWS Lambdaの利用事例


突然のスパイク

• 突然リクエストが数倍に増えることがある• イベント開始時は開始とともに増加• 稀によく分からないタイミングで増えることも• 増えても大丈夫なように構築• ただ何が起こるか分からないのが現実


耐えきれないアクセスが来ると、どうなるか…

• すでにログインしてプレイしているユーザーのサーバーからのレスポンスが徐々に遅くなる

• お構いなしにユーザーはログインしてくる• そのうちログインが失敗するように…• ログイン連打により、サーバーへのリクエストが激増


↓最悪、システム全体のダウン

システム全体がダウンする前に…

• すでにログインしているユーザーは守りたい• 新規のログインを抑えれば負荷が増えることはない


↓ログイン制限の仕組み

ログイン制限システム


AmazonSNS

AmazonCloudWatch

AmazonDynamoDB

AWSLambda

監視対象

ElasticLoadBalancing

AmazonRDS

通知起動

書込

通知

フラグが立つ

ログイン制限システム-監視対象を増やす場合-


AmazonSNS

AmazonCloudWatch

AmazonDynamoDB

AWSLambda

監視対象

ElasticLoadBalancing

AmazonRDS

通知起動

書込

通知

AmazonElastiCache

CloudWatchの設定のみで完了

ログイン制限システムのポイント

• 低コストで実現• いつでも柔軟に監視対象を追加できる• 閾値の変更もCloudWatchで済む


AWSを上手く活用する面白さ

まとめ


まとめ

• マネージドサービスの素晴らしさ• AWS側で管理されるのでインフラエンジニアが

いなくても運営することができる• AWSサービスを上手く活用する楽しさ• 新しいサービスや機能の追加が楽しみ• ワクワク開発することも大切


名古屋・東京で仲間を募集中！！

• サーバーエンジニア• AWS、PHP/Python/Golang• ユーザーとの距離の近さ• 高負荷への挑戦• サーバーエンジニア以外も募集中


http://wonderpla.net/jobs/


ご清聴ありがとうございました

人気ゲームアプリ「クラッシュフィーバー」におけるaws活用

Technology