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

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

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

動画

セッションスピーカー

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

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あるある話には大いにうなずけました。