PowerPoint プレゼンテーション

Size: px

Start display at page:

Download "PowerPoint プレゼンテーション"

みひなふじした
5 years ago
Views:

1 大規模環境における Ruby on Rails on AWS での最適化事例 ~ 200ms 100ms への歩み ~ 2018/06/01 AWS Summit 2018 株式会社アカツキエンジニア長井昭裕 1

2 自己紹介長井昭裕 (Akihiro Nagai) 経歴: 2016年にアカツキに入社モバイルゲームのインフラ構築運用(AWS, GCP), サーバサイドアプリケーション開発(Rails), 開発環境整備, 分析基盤構築, その他諸々を担当趣味は (2017年実績 318食/年) 2

3 とある日のバージョンアップバージョンアップ平均レスポンスタイム 200ms 100ms! 3

4 4

5 モバイルゲームのサーバサイドにおいていかにしてこのような高速化を実現しその結果どのようなメリットがあったかご紹介いたします 5

6 アジェンダ高速化の意義モバイルゲームにおけるサーバサイドの役割インフラ構成大規模環境下でのRuby on Rails 高速化事例まとめ 6

7 高速化の意義 7

8 我々はなぜ高速化するのかレスポンスタイムの高速化はいかなる場合も正義 UXの向上ストレス低減定着率の改善インフラの高集約化キャパシティの増加低コスト化高速化はユーザプロバイダともにメリットがある 8

9 モバイルゲーム運用中頻出のアクセススパイク requests/min キャンペーン & イベント開始新しいイベントのオープンやキャンペーン開始とともにユーザが急増するといった現象は日常茶飯事高速化によるキャパシティ担保は使命 9

10 今回の高速化のターゲット運用開始して数年経つモバイルゲームのサーバサイドアプリケーション Webフレームワークとして Ruby on Rails を採用 AWS 上で動作 (EC2 + RDS + Elasticache 等を利用 ) 一般的な高速化はやりつくされている N+1クエリの撲滅 DBからの大量レコード取得回避 DBへの適切なindex 設計...etc 10

11 Ruby on Rails 非常に有名な Web フレームワーク高い生産性と柔軟性を持つスモールスタートできるためスタートアップでの採用が多い反面一般に大規模環境向けではない高速ではないと言われている Ruby on Rails を用いたシステムが AWS 上で大規模にスケールアウトしかつ高速に動作することが可能であることをお伝えします 11

12 モバイルゲームにおけるサーバサイドの役割 12

ログインボーナスやミッションの達成条件判定ユーザデータの管理 - イベントの達成状況管理 -

13 モバイルゲームにおけるサーバサイドの役割 APIサーバとして動作クライアントへのゲームデータ返却 - 現在チャレンジ可能なイベント一覧 & イベントの内容ゲームロジックの計算 - ログインボーナスやミッションの達成条件判定ユーザデータの管理 - イベントの達成状況管理 - ユーザの所持アイテム管理 etc ユーザが何かアクションをする度にサーバサイドとの通信が必要レスポンスタイムの長短はUXに大きく関わる 13

14 モバイルゲームのサーバサイド高速化における技術的課題ユーザデータが大量である - ユーザが持つキャラクタ数百体 & キャラクタの育成状態 - イベント数百個のクリア状況...etc ゲームロジックが複雑である - このイベントは別のイベントA,Bをクリアしていないと挑戦不可 - このミッションは特定のキャラクタを編成しかつ特定のアイテムを使用した場合にのみ達成...etc Write intensive な特性である - アイテムの取得経験値の獲得...etc 逐一書き込みが発生 - キャッシュを並べてスケールアウトといった戦略は採りづらい高速化は一筋縄ではいかない 14

15 インフラ構成 15

16 インフラ構成 Load Balancer Auto Scaling group EC2 RDS (Aurora) RDS (MySQL) Elasticache Elasticache Master Read Replicas Shard01 ShardXX Master DB User DB Memcached Redis 16

17 インフラ構成: 各データストアの役割 Load Balancer EC2 Auto Scaling group イベント情報等のゲームデータを格納ユーザが所持しているアイテム等のユーザ資産を格納 RDS (Aurora) Master セッションやレスポンスキャッシュ等揮発して問題ないデータ RDS (MySQL) Read Replicas Master DB Shard01 ランキングや永続化したいキャッシュ等 Elasticache Elasticache ShardXX User DB Memcached Redis 17

18 インフラ構成: スケールアウト戦略 Master DB (RDS Aurora MySQL) Load Balancer Read Replica を増やすことでスケールアウト Read intensive な特性 EC2 Auto Scaling group RDS (Aurora) Master RDS (MySQL) Read Replicas Master DB Shard01 Elasticache Elasticache ShardXX User DB Memcached Redis 18

19 インフラ構成: スケールアウト戦略 User DB (RDS MySQL Multi-AZ) 水平分割 Load Balancer Write intensive な特性異なる種類のユーザ情報間でJoin したいため 1ユーザの情報は EC2 Auto Scaling group 1shard内に収める RDS (Aurora) Master RDS (MySQL) Read Replicas Master DB Shard01 Elasticache Elasticache ShardXX User DB Memcached Redis 19

20 インフラ構成: スケールアウト戦略 Cache (Elasticache Memcached / Redis) 垂直水平分割 Load Balancer 用途別キャッシュクラスタコンシステントハッシュ法での EC2 Auto Scaling group RDS (Aurora) Master key分散キャパシティを担保 RDS (MySQL) Read Replicas Master DB Shard01 Elasticache Elasticache ShardXX User DB Memcached Redis 20

21 インフラ構成 : 規模数十万 ~ 百数十万 rpm Load Balancer Auto Scaling group EC2 c4.8xlarge * 数十台 r4.8xlarge * 数台 r4.4xlarge * 数十台 m4.2xlarge, r3.xlarge 混在数十台 RDS (Aurora) RDS (MySQL) Elasticache Elasticache Master Read Replicas Shard01 ShardXX Master DB User DB Memcached Redis 21

22 高速化の実践 22

23 今回の高速化のターゲット ( 再掲 ) 運用開始して数年経つモバイルゲームのサーバサイドアプリケーション Webフレームワークとして Ruby on Rails を採用 AWS 上で動作 (EC2 + RDS + Elasticache 等を利用 ) 一般的な高速化はやりつくされている N+1クエリの撲滅 DBからの大量レコード取得回避 DBへの適切なindex 設計...etc 23

24 高速化①: ActiveRecordの実行時間短縮 ActiveRecord は Rails が採用しているRuby製ORM ~30ms AZ間の通信オーバヘッドでした ~15ms 24

25 EC2 RDS 間の通信距離 Load Balancer Auto Scaling group EC2 RDS (Aurora) RDS (MySQL) Elasticache Elasticache Master Read Replicas Shard01 ShardXX Master DB User DB Memcached Redis 25

26 異なるAZ間の通信距離 AWSデザインパターンとして対障害性担保のため複数AZにインスタンスを配置することが推奨されているしかし異なるAZ間のRTTは同一AZ内のものより数倍大きい約0.2ms 十数回約2.5ms 十数回 ActiveRecordを使っていると 1トランザクション内で複数のクエリを発行することになるためこの差は無視できないものとなる Read Replicas AZ ap-northeast-1a AZ ap-northeast-1c 26

27 同一AZへの優先的なクエリ発行 AWSデザインパターンとして対障害性担保のため複数AZにインスタンスを配置することを推奨しているしかし異なるAZ間のRTTは同一AZ内のものより数倍大きい約0.2ms 十数回約0.2ms 十数回 Read Replicas AZ ap-northeast-1a AZ ap-northeast-1c ActiveRecordを使っていると 1トランザクション内で複数のクエリを発行することになるためこの差は無視できないものとなる可能な限り同一AZにあるDBへクエリ発行を行うことでレスポンスタイムの高速化を実現 27

28 同一AZへの優先的なクエリ発行(縮退時) DBの障害が発生した際の再接続先も同一AZ内のインスタンスにすると負荷の偏りが生じ連鎖的な障害を起こす可能性がある Read Replicas AZ ap-northeast-1a AZ ap-northeast-1c 28

29 同一AZへの優先的なクエリ発行(縮退時) DBの障害が発生した際の再接続先も同一AZ内のインスタンスにすると負荷の偏りが生じ連鎖的な障害を起こす可能性がある負荷の偏りが発生同一AZのDBへ再接続 Read Replicas AZ ap-northeast-1a AZ ap-northeast-1c 29

30 同一AZへの優先的なクエリ発行(縮退時) DBの障害が発生した際の再接続先も同一AZ内のインスタンスにすると負荷の偏りが生じ連鎖的な障害を起こす可能性がある縮退時は同一AZへの優先的な接続をやめランダムでインスタンスを選ぶことで負荷分散をする縮退時は負荷分散を優先 Read Replicas AZ ap-northeast-1a AZ ap-northeast-1c 高速化だけでなくシステムの信頼性を維持することも忘れてはならない 30

31 同一 AZ への優先的なクエリ発行の結果平均レスポンスタイム 15ms 短縮! 信頼性も犠牲にしない! ~30ms ~15ms 31

32 高速化②: Middleware部分の実行時間短縮 Middlewareで妙に時間がかかっている... DBコネクションの死活監視が原因でした 32

33 Rails における DB のコネクション管理 Rails Application logic Request Rails では DB のコネクションをプーリングしており必要に応じてプールからコネクションが返却される Connection pool 33

34 RailsにおけるDBのコネクション管理 Request Rails Application logic process check out Rails ではDBのコネクションをプーリングしており必要に応じてプールからコネクションが返却される check in Connection pool 34

RailsにおけるDBのコネクション管理 Request Rails Application logic process check in check out Connection pool Rails ではDBのコネクションをプーリングしており必要に応じてプールから

35 RailsにおけるDBのコネクション管理 Request Rails Application logic process check in check out Connection pool Rails ではDBのコネクションをプーリングしており必要に応じてプールからコネクションが返却されるプールからは生きたコネクションを返却するため事前に ping が疎通することを確認しているコネクションが切れる要因 Failover WaitTimeout どれもレアケース疎通確認 ping 全リクエスト疎通確認する必要は無い 35

36 RailsにおけるDBのコネクション管理 Request Rails Application logic process check in check out Connection pool 最後の疎通確認から30秒間は ping を抑止する Rails ではDBのコネクションをプーリングしており必要に応じてプールからコネクションが返却されるプールからは生きたコネクションを返却するため事前に ping が疎通することを確認しているコネクションが切れる要因 Failover WaitTimeout どれもレアケース ping 全リクエスト疎通確認する必要は無い 36

37 RailsにおけるDBのコネクション管理 Rails デフォルトでは Rails は複数の DBを扱うことができないため Octopusというライブラリを利用している Application logic process check in check out 実装の関係上 check out 時すべてのDBに ping を送ってしまう Octopus Connection pool ping Connection pool ping... ping 数十台 37

38 RailsにおけるDBのコネクション管理 Rails Application logic process check in check out 今回の対策で不要な ping が抑止され Octopus Connection pool Connection pool 数ms 数十台のオーバヘッドの削減に成功 ping ping... ping 数十台 38

39 DBの死活監視抑制の結果平均レスポンスタイム 50ms短縮 39

40 ちなみに... この問題は Rails upstream でも議論されていて SpotifyやGroupon でも課題になっているようです 40

41 ここまでの高速化の効果変更内容同一 AZへの優先的なクエリ発行 DBへの過剰な死活監視抑止計効果 15ms 50ms 65ms 100ms 削減までの残りは地道なアプリケーションの最適化 41

42 アプリケーション最適化 ~100ms ~65ms 42

43 アプリケーションの最適化 Load Balancer EC2 Auto Scaling group RDS (Aurora) Master キャッシュを積極的に活用する RDS (MySQL) Read Replicas Master DB Shard01 Elasticache Elasticache ShardXX User DB Memcached Redis 43

44 高速化事例: フレンド機能の高速化フレンド機能とは他ユーザの一部キャラクタを自分のキャラクタのようにイベントに連れ出せる機能モバイルゲームではよく見られる技術的な課題キャラクタデータを保持しているUserDBは水平分割されているキャラクタ1体あたりのデータ量が多い候補としてリストアップするフレンドが多いキャッシュを活用 44

45 フレンド機能の高速化 Load Balancer 全shardに分散した他ユーザのキャラクタ情報にアクセスが必要 EC2 Auto Scaling group RDS (Aurora) Master RDS (MySQL) Read Replicas Master DB Shard01 数十台 User DB Elasticache Elasticache ShardXX Memcached Redis 45

46 フレンド機能の高速化 Load Balancer フレンド機能として必要になる情報のみキャッシュにコピー EC2 Auto Scaling group copy RDS (Aurora) Master RDS (MySQL) Read Replicas Master DB Shard01 数十台 User DB Elasticache Elasticache ShardXX Memcached Redis 46

47 フレンド機能の高速化 Load Balancer フレンド情報の読み込みはキャッシュから EC2 Auto Scaling group RDS (Aurora) Master RDS (MySQL) Read Replicas Master DB Shard01 数十台 User DB Elasticache Elasticache ShardXX Memcached Redis 47

48 フレンド機能の高速化 Load Balancer キャラのレベルアップ等フレンド機能に必要な変更はキャッシュにも随時反映 EC2 Auto Scaling group RDS (Aurora) Master RDS (MySQL) Read Replicas Master DB Shard01 数十台 Elasticache Elasticache ShardXX 900ms 300ms へ高速化 User DB Memcached Redis 48

49 高速化の結果変更内容同一 AZへの優先的なクエリ発行 DBへの過剰な死活監視抑止アプリケーションの最適化計効果 15ms 50ms 35ms 100ms 約 100ms の平均レスポンスタイム短縮に成功! EC2 の台数が約 2/3 へ年間数千万円の削減リージョン間の通信費も約 2/3 に年間数百万円の削減より良い UX を提供しながらコスト削減にも成功これこそが高速化の効果 AWSエンタープライズサポートのおかげです 49

50 まとめ AWS 上で大規模にスケールアウトした Ruby on Rails アプリケーションの高速化事例について紹介しました対障害性を犠牲にせず同一 AZ 内の通信を優先的に行うコネクションの死活監視といったミドルウェアレベルでの挙動最適化インフラの特性を活かしたアプリケーションの最適化このような最適化を継続していくことで Ruby on Rails の高い生産性柔軟性を活かしながらも大規模かつ高品質なサービスをコストを抑えながら提供することができます 50

51 備考 : 使用しているソフトウェアサービスの詳細種別 Webフレームワーク Ruby on Rails 言語 Ruby アプリケーションサーバ Unicorn RDB Sharding ライブラリ Octopus RDBMS キャッシュ APM Aurora MySQL a MySQL (RDS) Memcached (Elasticache) Redis (Elasticache) NewRelic 51

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

10年オンプレで運用したmixiをAWSに移行した10の理由

10年オンプレで運用したmixiをAWSに移行した10の理由 10 年オンプレで運用した mixi を AWS に移行した 10 の理由 AWS Summit Tokyo 2016 株式会社ミクシィオレンジスタジオ mixi システム部北村聖児自己紹介 2 名前北村聖児所属株式会社ミクシィオレンジスタジオ mixiシステム部担当サービス SNS mixi 今日話すこと 3 mixi を AWS に移行した話 mixi 2004 年 3 月 3 日にオフィシャルオープンした