[レポート]【アカツキ様ご登壇事例】大規模環境における Ruby on Rails on AWS での最適化事例 ～ 200ms → 100ms への歩み ～ #AWSSummit

こんにちは、城岸です。今回は、AWS Summit Tokyo 2018の6/1(金) 「【アカツキ様ご登壇事例】大規模環境における Ruby on Rails on AWS での最適化事例 ～ 200ms → 100ms への歩み ～」セッションのレポートです。

セッション情報

• セッション名：【アカツキ様ご登壇事例】大規模環境における Ruby on Rails on AWS での最適化事例 ～ 200ms → 100ms への歩み ～
• スピーカー：長井 昭裕氏　（株式会社アカツキ サーバーサイドエンジニア）

ソーシャルゲームにおいて、レスポンスタイムの短縮は UX の向上に大きな役割を果たします。しかしながら Ruby on Rails は一般に、大規模環境で高速に動作するフレームワークではないと認識されています。本講演では AWS 上で大規模に分散して稼働する、Ruby on Rails を採用したソーシャルゲームのバックエンドシステムにおいて、どのようにレスポンスタイムの半減を実現したのか、その手法についてご紹介します。

セッション内容

• 高速化の意義
• 高速化の対象となるゲーム
• インフラ構成
• 高速化の実践
• 効果
• まとめ

高速化の意義

言わずもがなですが高速化は正義です。高速化を実現することで、以下のメリットを享受することができます。

• UXの向上
  • ユーザーのストレス減
  • 定着率の改善
• インフラの高集約化
  • キャパシティの増加
  • 低コスト化

高速化を実現することは、ゲームの利用者、提供者、双方にメリットがあります。

高速化の対象となるゲーム

今回高速化の対象となったゲームは、以下のような特性/状態を持っています。

• モバイルゲームのサーバーサイド
• アプリケーションは Ruby on Rails で実装されている
• スパイクが起こりやすい（ゲームのキャンペーン時など）
• 一般的な最適化は実施済
  • N＋１クエリの撲滅など

アプリケーションはAPIサーバーとして動作しており、「クライアントへのゲームデーターの返却」、「ゲームロジックの計算」、「ユーザデータの管理」を担っている。また、モバイルゲームの特性としてユーザがアクションするたびにサーバーサイドとの通信が発生する仕組みとなっている。

インフラ構成

ELB + EC2(auto scaling) + DataStore の構成。DataStoreはデータの特性に応じて、Amazon Aurora、RDS（MySQL)、ElastiCache(memcached、Redis)を使い分けている。 また、それらのDataStoreは、データの読み込み特性に応じて、水平分割/垂直分割/リードレプリカの追加を既に実施済みである。

高速化の実践

実践した内容は以下の3つ。これら3つを実施することでアプリケーションに対するレスポンスタイムを200ms → 100msに短縮した。

• ActiveRecordの実行時間短縮
• Middleware部分の実行時間短縮
• アプリケーション最適化

ActiveRecordの実行時間短縮

ActiveRecordでは1トランザクション内で複数のクエリを実行しており、そのクエリはAZを跨いで実行されている。→同一AZへ優先的なクエリ発行するよう調整

上記の対策を実施することで、15ms改善。ただし、縮退時は同一AZへの優先的な接続をやめ、ランダムでインスタンスを選方式としている。

Middleware部分の実行時間短縮

アプリケーションではDBコネクションの管理が行われており、アプリケーションはDBへ接続時にプーリングされている接続済のコネクションをチェックアウトし利用する。また、接続済のコネクションは事前にpingによる疎通確認を実施している。

また、ライブラリとしてoctopusを利用しているため、実装の関係上チェックアウト時に全てのDBにpingを送ってしまう。→コネクションの死活監視といったミドルウェアレベルでの挙動最適化

これで、50ms改善。

発生している事象↓
Do not ping MySQL on connection checkout

アプリケーション最適化

フレンド機能を実現するために、アプリケーションはユーザデータを管理する数十台に分割されたDBにアクセスする必要がある。→キャッシュの積極的活用

フレンドの読み込みはキャッシュから、また、キャラのレベルアップなどフレンド機能に必要な変更はキャッシュにも即時反映する方針とする。 これで、35ms改善。

効果

UX向上に加え、以下の効果もあった。

• EC2の台数が2/3に・・・年間数千万円のコスト削減
• リージョン間の通信減・・・年間数百万円のコスト削減

まとめ

以下の3つ施策を実施することで、レスポンスタイムの改善、UXの向上、コスト削減が実現できた。

• 耐障害性を犠牲にせず同一のAZ内の通信を優先的に行う
• コネクションの死活監視といったミドルウェアレベルでの挙動最適化
• インフラの特性を生かしたアプリケーションの最適化

まとめ

Ruby on Rails on AWS の最適化ポイント満載の面白いセッションでした。また、日々のモニタリングの大切さも改めて感じました。どこに時間がかかっているかわからないと対策の打ちようがないですからね。

あとで資料が公開されるそうなのでアップされたらブログ更新します！！