この記事は公開されてから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分割をサービスイン後に行うことを更に決断する必要があったなど、様々な苦労がわかります。
予測できるならそれに越したことはないですが、予測できない事態に対応できるアーキテクチャ設計を行いたいですね。
14
