[レポート] Fate/Grand Orderにおける、ディライトワークス流AWS導入＆活用術 #AWSSummit

AWS Summit Tokyo 2016

#イベントレポート

#レポート

#AWS

大村貴俊

2016.06.07

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

はじめに

2016/6/1(水) ~ 6/3(金)に開催された「AWS Summit Tokyo 2016」のDay2、General Conference SMB Track「【ディライトワークス様登壇】Fate/Grand Order における、ディライトワークス流 AWS 導入＆活用術」を聴講しましたので、レポートとしてまとめます。弊社でもソーシャルゲームのバックエンドを構築することがあり、こういったテーマは非常に関心があります。

Fate/Grand Orderとは

Fate/Grand Orderは、TYPE-MOON原作のFateシリーズ「Fate/stay night」を元にして製作されたスマートフォン専用オンラインロールプレイングゲームで、iOS版とAndroid版がリリースされています。Android版が2015年7月30日に、iOS版が2015年8月12日にそれぞれリリースされ、ディライトワークス社が開発し、アニプレックス社が運営を行っています。

セッションの開始ではトレーラー映像が流れました。

Android版：https://play.google.com/store/apps/details?id=com.aniplex.fategrandorder
iOS版：https://itunes.apple.com/jp/app/fate-grand-order/id1015521325?mt=8

セッション紹介文

セッションの紹介文を以下に転載します。

Fate/Grand Order における他クラウドからの AWS への移行、および大規模アクセスを捌く運用技術に関してお話します。

スピーカー紹介

今井守生氏

ディライトワークス株式会社プログラマー

田村祐樹氏

ピアレス株式会社代表取締役　Fate/Grand Orderでは安定化を担当

Fate/Grand Orderのリリースと課題点

サーバー選定

Fate/Grand Order アプリケーションはUnity C#で作られていたため、サーバーもC#が使いたかった。
そのためAzureを選択した。
IIS+MySQL+Redis

ASP.Net WebアプリケーションをAzure App Serviceのウェブアプリへデプロイ。

インフラの専任者がいない状態でサービスイン。

海外からのアカウントが増えた。

課題として見えてきた点

AWS移行前の課題 1.性能

Redisがボトルネックにあったことは殆ど無い
最もボトルネックになるのはデータベースで、容易に台数を増やすことができない

データベースのCOMMIT時に0.5秒前後のslow queryが数秒おきに発生。
性能検証の結果、ストレージへの書き込み性能が数秒おきに瞬間的に劣化していることが判明した。
Azure Premium Storage(P30)をつかうことで解決しようとした。

データベースのmasterからslaveへのレプリケーションで数千秒単位での遅延が発生

slaveをRAID 0 構成に変更
効果はあまりない
slaveのI/Oバリア(I/O barrier)を無効化
ディスクへの書き込み完了を待たない
効果はあまりない
slaveのI/Oスケジューラをcfqからnoopに変更
スケジューリングの負荷が減ることを期待したが効果ない
slaveを参照していた一部SQLをmaster参照に切り替え
アイテムの消失はなくなったがmasterの負荷が増えた

メモリ枯渇によるSwapが発生
処理性能の限界
DBサーバーのメモリが枯渇
当時の最高スペックStandard Dシリーズ D14を使用(※現在はGシリーズが存在します)
永続化が必要でないデータはRedisに保存するように変更

AWS移行前の課題 2.可用性

前触れのないサーバーダウンが1ヶ月に計3回（Redis2回、データベース1回）
クラウドサービス上のメンテナンスが数ヶ月に1回
メンテナンスでは約2日の何処かで15分前後の突発的な再起動が発生
リージョン切り替えることで対応していたが、切り替えること自体が高コスト

クラウドサービスの2015年ダウンタイムを比較、AWSが圧倒的に短い

課題まとめ

大規模アクセスを処理するには性能が物足りない
全体的にインフラ周りにかかる手間が多く、開発に専念できない

AWS移行の理由

抱えていた課題が、AWSであれば解決できるだろうという結論

データベース性能処理の向上、メモリ増大（112GB→244GB）

まとめ

開発時はAzureはC#やVisualStudioとの相性がよく使いやすいクラウドだった。
運用開始後、想定以上のアクセスが有り、Azureでの性能の限界に達した。
AWSなら解決できると思い移行を決断した

AWS移行計画

スペック

AWS+C#5.0
WindowsServer 2012 R2
EBを利用

上記構成で問題ない

30サーバー
3000-5000リクエスト/秒
20000クエリ/秒 (リード
8000クエリ/秒 (ライト

使用しているもの

IIS
MySQL
Redis
memcache
ELB
EC2
S3
RDS
EC
EB

ゲームインフラの特徴

当初の想定が難しい

そのゲームがどのくらいヒットするかわからない。
エンジニアには完璧に予測ができない。

動き始めたら止められない。
数日単位の停止はできない。
停止している間は負荷がよみきれない。
動いているインフラの変更や調整は非常に手間がかかる。

常に更新される

一般的なサービスと異なりInsert/Update/Deleteが膨大。
負荷が頻繁に変動する。
メンテナンス開け、イベント開始時などには通常の数倍のアクセスがある。
ユーザーさんの期待度や熱量が、そのまま負荷に直結するため、最大負荷と必要な性能を予測することが難しい。

なぜAWSを使うのか

インフラ管理の難しさ

大規模を経験したインフラエンジニアは常に足りない
マネージドサービス

データベースの性能

マネージドデータベースには便利な機能が満載
自動バックアップ、スナップショット、ポイント・イン・タイム・リカバリ(PITR)、MultiAZ
構成変更が用意
性能が必要になった時にすぐにインスタンス性能を上げることもできるしデータベース分散も出来る

AzureからAWSへ移行

移行と更新を両立する
インフラ作業に専念できる人が居ない
インフラ作業に専念できる人が居なかった
信頼できるサーバ管理会社の選定
スカイアーチネットワークスさんに移管をお願いした

データをどう移すべきか

AWS Database Migration Serviceの検討からレプリケーションまで。
データサイズが既に多くなっていたこともあり、検証がうまくいかず、基本に帰ってレプリケーションすることにした。
レプリケーション遅延の回避。

実装の修正

AzureSDKとAzureに依存していたコードの置換
AWS ELBが送ってくるX-Forwarded-Forへの対応

どちらも小規模な対応ですんだ

周辺環境の修正

Linuxサーバーの移行
fluentdやnxlogなど

データ検証及び動作検証

RDS試験環境を構築してQAを行う
リリース済みアプリに対してプロキシを使用してのプレイ

移行作業

深夜メンテナンスによる移行
AzureからAWSにしたとき、AWSからAzureにもどせるように作業した
IISの時間がずれるトラブルあり
IISはGMT、JSTに切り替えていたけど勝手にGMTに戻ることがあった

AWS移行が無事完了

2015年10月に移行決定し、12月頭に移行完了。
年末は安心して過ごせた。
徐々にスパイクが発生し、明らかに重い状況になった。
AWSに移行するだけでは増加に対応できない。

サーバートラブルの理由

AWSであろうとも突然の死。
SLAは100%ではない。
データベースの性能限界は突然来る
10ms常時処理が2000msかかって死ぬ
海外からの容赦無いDoS攻撃が来る
特にアジア圏内の国からの容赦無い不正アクセス

チューニングの道のり

サーバー台数を増やす？
データベースの性能上げる？
水平分割とか垂直分割すればいい？

ボトルネックはどこか

スロークエリを解決する？
キャッシュに逃がす？
テーブルスキーマーを見直す？

Innodbのチューニング

innnodb_buffer_pool_sizeがなにより重要
innnodb_log_file_sizeとinnodb_log_files_in_groupも重要
thread重要

公式ドキュメントを読もう

MySQLのチューニングに関しては必ず公式ドキュメントを熟読する
「〜〜はNで十分です」という文言には注意する
なぜそれをするのかを確実に
必ず切り分けをして効果の有無を確認する

必ず計測しよう

最適値はサービスやゲームの特性に左右される
ロブ・パイクの古い古い格言
「計測すべし。早過ぎる最適化は諸悪の根源である」

データベースを分割する

DBを分割しよう

チューニングにも限界がある
水平分割と垂直分割
Fate/Grand Orderでは垂直分割を採用
ユーザー情報、サーヴァント情報、アイテム情報などは4分割した。
制限として外部キーが使えなくなった。
JOINも使えなくなった。

水平分割 vs 垂直分割

得手不得手がある
水平分割は分散トランザクションを適切に要いることが必要

移行の心構え

仮説と検証をつみかさねよう
大規模を経験したエンジニアというのはほとんど世の中には居ません
仮説をたてるにはその根拠となる知識と経験が必要になります
MySQLというデータベースをチューニングするのに、お手本となる教科書も虎の巻もありません
強い心臓を持とう
Twitterとかみてるよ

開発

まとめ

AWSを使うのは一つの最適解
AWSを使うだけではいけない
AWSは銀の弾丸ではない
魔法ではないが非常に強力な武器である

スライド

(6/9追記) スライドが公開されましたので追記します。

感想

非常に中身の濃いセッションでした。最後までひたすら早口でしゃべり通した感じで、詰め込むだけ詰め込んで、それだけ伝えたい事が多かったのだとお見受けしました。

ローンチ初期からいろいろと話が絶えないFate/Grand Orderですが、2015年12月14日にサーバー増強をするというメンテナンスは、AWSへの移行だったことがわかりました。

ただそれだけでは現状のアクセス（正規も非正規も）に耐えられず、DB分割をサービスイン後に行うことを更に決断する必要があったなど、様々な苦労がわかります。

予測できるならそれに越したことはないですが、予測できない事態に対応できるアーキテクチャ設計を行いたいですね。