[レポート] FINAL FANTASY BRAVE EXVIUS における Amazon Aurora、Amazon Kinesis の利用事例 #AWSSummit

FINAL FANTASY BRAVE EXVIUS における Amazon Aurora、Amazon Kinesis の利用事例

6/1 (水) ~ 6/3 (金) に開催された AWS Summit Tokyo 2016 の General Confrence 6/2 16:20 ～ 17:00 のセッション「FINAL FANTASY BRAVE EXVIUS における Amazon Aurora、Amazon Kinesis の利用事例」を聴講しました。本記事はそのレポートです。

セッション情報

セッション紹介文

弊社にて運営しているゲームコンテンツにおける AWS 利用事例 (主に Amazon Aurora・Amazon Kinesis) についてご紹介します。

セッション資料・動画

セッション資料

http://media.amazonwebservices.com/jp/summit2016/2B-04.pdf

動画

セッションスピーカー

• 宇津木 豊（株式会社スクウェア・エニックス　第８ビジネス・ディビジョン ディレクター)
• 関根 雅文（株式会社エイリム　開発部システムグループ グループマネージャー）

FINAL FANTASY BRAVE EXVIUS(FFBE)について

http://www.jp.square-enix.com/FFBE/

• 2015年10月のリリースされたスマホ向け RPG ゲーム
• 5日間で100万ダウンロードを突破
• 現時点で600万ダウンロードを突破
• グロスではコンスタントにトップ10以内にランクイン

システム構成

以下のサービスを利用

• Amazon OpsWorks
• Amazon AutoScaling
• Amazon RDS Aurora
• Amazon ElastiCache Redis
• Amazon Redshift
• Amazon S3
• Akamai CDN

Amazon Aurora について

用途

• メインRDBとして利用
• プライマリーキーのみでテーブルをスキャンできるようにテーブル設計
• SQLのJOINは禁止
• 水平分割している

ログデータの管理

• Auroraはシーケンシャルスキャンが遅い
• 当初はログデータをAuroraに保存し、DWH的に使っていたが、現在Redshiftに移行

Auroraのメリット

• ストレージの自動拡張
  • 10GB単位で勝手に増える
  • サイジング不要
• パフォーマンス
  • Aurora利用前はMySQLを使用しており、WRITEが要求レベルに到達していなかった
  • Auroraに切り替えると、WRITEを捌ききれた。
  • MySQL+PIOPSよりもAuroraのほうが安く管理しやすい
• 耐障害性
  • リリース直後はMySQLとAuroraが混在
  • MySQLインスタンスのディスク障害が原因でサービスが一時停止した
  • AWSサポートから、Auroraはディスク障害に対するデータベースの耐障害性が向上しており、Auroraだと同じことは起きないはずだから試して、と言われた。 カチンときたが、Aurora移行後、インスタンスの障害はおきていない

不満な点

一部の処理が遅い

• mysqldup -> スナップショットがあるので問題にはならない
• ALTER TABLE -> Auroraに備わる online schema change があるので問題にはならない
• テーブルスキャン -> DWH 的な使い方をしない

メンテナンス通知

• EC2のように前もってメンテナンス予告メールが届かない
• APIを叩いたり、フォーラムを見ていないと、見逃す。

インスタンスサイズ

• medium サイズ以下でインスタンスをたてられない。
• テスト環境もAuroraで構築すると維持費がかかる

コストのサイジングをしにくい

• ストレージが自動拡張するので、ランニングコストのサイジングが難しい

ioDrive+Percona と Auroraのベンチマーク

あくまで参考情報

• READはそれほど違いがない
• WRITEはioDriveの性能がまさる。

ゲームサービスはREADが多いことや、Auroraはマネージド・サービスであることも考慮すると、AuroraはioDriveに戦えるレベル。

Aurora まとめ

Auroraじゃなきゃいけない理由はない。

Auroraを選ばない理由もない。

Amazon Kinesis Streams について

用途

高機能なメッセージキューとして利用

SQS/RabbitQMのようなメッセージキューと以下が異なる

• メッセージの順番保証
• 同じメッセージを複数回処理可能
• 利用したキューの消しこみ不要

アーキテクチャー

EC2内のfluentがプロデューサーになってKinesis Streamsにメッセージ送信 Kinesis Streamsのコンシューマーは以下の3種類

• Kinesis Client Library(KCL) : ログ確認
• Lambda -> S3 -> Lambda -> Redshift (KPI分析)
• Lambda -> S3 -> EMR(ファイルのマージ) -> S3 (ログ保存用)

Kinesisの不満点

特に無し

強いているならば、Web管理画面からシャード内のメッセージを参照したい(SQSには同様の機能あり)

Kinesisの利用で気をつけるべきこと

• メッセージの取りこぼしを回避するため、予め多めのシャード数を確保し、サービスイン後にサイジングする
• シャード数は2のべき乗にする
  • シャード数が2のべき乗だと、シャードのマージ・スプリットが簡単。
  • メンテナンス時に、シャード数を変えてストリームを作り直すのもあり。
• Lambdaの並列数はシャード数と同じ

Kinesisまとめ

• 高性能なメッセージキューとして利用する分には非常に満足できる
• Kinesis固有のメッセージ処理の作法を心得ること
• Kinesis Firehoseが東京リージョンに来ると、シームレスにS3/Redshift連携できるので、Kinesisをより使いやすくなるのではないか

まとめ

今年の頭頃から、似たようなシステム構成の案件を担当しており、他社の知見を知りたくて参加しました。 Kinesisあるある話には大いにうなずけました。