Fate/Grand Order における、ディライトワークス流AWS 導入＆ … · 開発用の周辺ツールやフレームワークから作る必要がありました。また、定期的なゲーム内イベントや、機能拡張などを行っていく必要がありました。

Copyright2016DELiGHTWORKSInc.AllRightsReserved.

DELiGHTWORKS Inc.

Fate/Grand Order における、ディライトワークス流 AWS 導入＆活用術 (前編)2016/06/02


自己紹介今井守生l 大学卒業後、システムエンジニアとして就職l 2012年にゲーム会社に転職し、スマートフォン向けゲームを開発l 2014年からディライトワークスにてFate/Grand Orderのサーバ側プログラムを担当


Fate/Grand Orderのご紹介l 人気シリーズ｢Fate｣のスマートフォン向け新作RPGl 2015年7月にリリースl 現在までに500万DLを突破


アジェンダl AWS移行の経緯l AWS移行前のサーバ構成/設計l AWS移行前の課題l AWS移行の理由


AWS移行の経緯


AWS移行の経緯l Fate/Grand Orderは当初、 Microsoft Azureを使用l 2015年7月のリリース以降、様々な課題が発生l 同年10月にAWSへの移行を決め、12月に実施


クラウドサービスを選択した理由インフラエンジニアが不在立ち上げ直後の会社で、インフラ専任のメンバーがいませんでした。

開発に専念したい開発用の周辺ツールやフレームワークから作る必要がありました。また、定期的なゲーム内イベントや、機能拡張などを行っていく必要がありました。

クラウドサービスなら…新規インスタンスの作成やスケールアップ･ダウンが手軽にできるので、インフラの管理コストが減り、開発に専念できる想定でした。


Microsoft Azureを選択した理由クライアントアプリの開発にUnity(C#)を選択→サーバサイドの開発にもC#を選択└ソースコードの共通化└クライアント/サーバ両方に跨った開発の学習コストの低減└スクリプト言語よりも高速└コンパイル言語(型安全)、強力なIDEの存在(Visual Studio)→.NET Framework(Windows Server)を選択→Micorosft Azureを選択


AWS移行前のサーバ構成/設計


リリース直後の規模感環境C# (Visual Studio 2013)ASP.NET

リリース当初の規模20~30サーバ2,000-3,000 Requests/sec10,000 Query/sec (Reads)4,000 Query/sec (Writes)


AWS移行前の構成IIS 8.0 (Windows Server 2012).NET Framework 4.5ゲームサーバ： Standard A4 × 20~30管理ツールサーバ： Standard A4 × 1

MySQL 5.6 (CentOS 6.5)Standard DS14 × 2

Redis 2.8 (CentOS 6.5)Standard DS12 × 1


AWS移行前の構成図

GameServer(PaaS)×20~30

MySQL(IaaS)master×1

Redis (IaaS)×1

AdminServer(IaaS)×1

AzureLoadBalancer

User

Internet

AzureCloud

MySQL(IaaS)slave×1


ゲームシステム設計方針ゲームサーバとの通信頻度を少なくする通信頻度を少なくすることで、ゲームサーバへの同時アクセス数を抑えられる想定でした。


ゲームシステム設計例１マスタデータのみで表示できる画面については通信を行わない例えばクエストを選択する画面やショップ画面を開く際は、通信せずに情報を表示しています。また、クエストの進行中についても極力通信を行わない設計にしています。

※別途、画像データなどのダウンロードは行っていますが、こちらはCDNで配信していますので、ゲームサーバのアクセス数には影響ありません。


ゲームシステム設計例２ユーザデータはログイン時に最新の状態をクライアントアプリと同期ログイン以降は、ユーザが能動的に更新を行う場合にのみ、更新後の結果を同期しています。ユーザが所有しているサーヴァントやアイテムについては、上記にて同期されたデータを表示しています。

※ゲーム内のフレンド情報は、例外的に一定間隔ごとに同期しています。


しかし…l 想定を遥かに上回るユーザ数l 海外からの大量のアカウント作成や、正規のアプリを使用していないと見られる高速かつ大量のアクセス

その結果、イベント開始直後はアクセスを処理しきれず、サーバのレスポンスが悪くなる状況が続きました。


AWS移行前の課題


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


AWS移行前の課題 1.性能l Redisがボトルネックになったことはほとんどなしl ゲームサーバの処理性能が足りない場合は増台 or スケールアップで対応l ゲームサーバのCPU使用率が跳ね上がる場合は、プログラム側に問題がある可能性が高いため原因を修正して解決

l 最もボトルネックになるのはデータベースで、容易に台数を増やすことができず、スケールアップにも限界


AWS移行前の課題 1.性能DBのCOMMIT時に0.5秒前後のslow queryが数秒置きに発生性能検証の結果、ストレージへの書き込み性能が数秒置きに瞬間的に劣化していることが判明しました。Premium Storage(P30)を使用することで解決しました。

▼実際のslow query# Query_time: 0.462707 Lock_time: 0.000000 Rows_sent: 0 Rows_examined: 0COMMIT;# Query_time: 0.497831 Lock_time: 0.000000 Rows_sent: 0 Rows_examined: 0COMMIT;


AWS移行前の課題 1.性能DBのmasterからslaveへのレプリケーションで数千秒単位の遅延が発生slaveから参照してもmasterにあるデータが存在しないため、獲得した直後のアイテム等が消失しているように見えることがありました。

l slaveをRAID 0構成に変更2つのストレージを使用し、並行して書き込みを行うことによって高速化を期待しましたが、効果はありませんでした。

l slaveのI/Oバリアを無効化ディスクへの書き込みの完了を待たない方式にすることで、書き込み速度の向上を期待しましたが、効果はありませんでした。


AWS移行前の課題 1.性能l slaveのI/Oスケジューラをcfqからnoopに変更cfqはプロセスごとにI/O要求のキューを持ち、公平に処理されていきます。noopはシンプルにI/O要求が処理され、スケジューリング負荷が小さいため、書き込み速度が向上することを期待しましたが、効果はありませんでした。

l slaveを参照していた一部のSQLをmaster参照に切り替えアイテムが消失したりということはなくなりましたが、アクセスが集中するため、master側の処理性能が劣化しました。


AWS移行前の課題 1.性能メモリの枯渇によるswapの発生、処理性能の限界DBサーバのメモリが枯渇してswapが発生したり、そもそもの処理性能が足りない状態でした。

l 当時の最高スペックであるStandard DS14を使用l 永続化が必須でないデータはRedisに保存するように変更これにより一時的に改善されましたが、ユーザ数が増加していくに連れて、イベント開始直後に高負荷になることが増えていきました。

▼実際のslow query# Query_time: 27.485704 Lock_time: 0.000046 Rows_sent: 0 Rows_examined: 1update XXX# Query_time: 31.603121 Lock_time: 0.000061 Rows_sent: 0 Rows_examined: 1update XXX


AWS移行前の課題 2.可用性前触れのないサーバダウンが1ヶ月に計3回 (Redisで2回、DBで1回)冗長構成は自前で行う必要があり、インフラ専任のメンバーがおらず現実的ではありませんでした。

クラウドサービス上のメンテナンスが数か月に1回メンテナンスでは、約2日間のどこかで15分後前後の突発的な再起動が発生します。メンテナンスはリージョンごとに行われていたため、メンテナンスが行われないリージョンに移行して回避しましたが、リージョンの変更を行うこと自体がかなり高コストでした。


AWS移行前の課題 2.可用性クラウドサービスの2015年のダウンタイムを比較http://www.networkworld.com/article/3020235/cloud-computing/and-the-cloud-provider-with-the-best-uptime-in-2015-is.html


AWS移行前の課題まとめl 大規模アクセスを処理するには性能が物足りないl 全体的にインフラ周りにかかる手間が多く、開発に専念できない


AWS移行の理由


AWS移行の理由サーバが抱える課題について相談するうち、AWSであれば前述の課題が解決できるだろうという結論になりました。

l DBの処理性能の向上、メモリの増大 (112GB -> 244GB)l 前触れのないサーバダウンはほぼ無し(フェイルオーバーの導入も比較的容易)

l クラウドサービス上の突発的なメンテナンスも無し


まとめl 開発時は、AzureはC#やVisual Studioとの相性が良く使いやすいクラウドでした。

l しかし運用開始後、想定以上のアクセスがあり、考えうる対策は行いましたが、Azureでの性能の限界に達しました。

l AWSであれば解決できる見込みがあり、AWSへの移行を決めました。


そしてAWSへ…


DELiGHTWORKS Inc.

Fate/Grand Order におけるディライトワークス流 AWS 導入&活用術（後編）2016/06/02


自己紹介お仕事田村祐樹（ピアレス株式会社代表取締役社長）Fate/Grand Orderでは、リリース後のサーバ安定化などを担当。

経験値某コンソールゲーム会社から、某ソーシャルゲーム会社まで、色々とやってます。

メインプログラマから、プロジェクトリーダ、事業責任者まで。

スキルセットクライアント、サーバ、インフラとある程度の範囲ができる感じです。

C++、Lua、Java、Objective-C、PHP、Python、Golang、などなど。


アジェンダAWS+C#でのネットワークゲーム開発ディライトワークスでのサーバサイド開発についてお話します。

AzureからAWSへの移行について紆余曲折あってAzureからAWSへ移行したお話をします。

AWSの構成変更とチューニングAWSにしても発生したトラブルとチューニング、スケールアウトについてお話します。


AWS+C#でのネットワークゲーム開発


現在の規模感現在の環境AWS + C# 5.0WindowsServer 2012 R2デプロイはAWS Elastic Beanstalk上記構成で問題無く利用可能

現在の規模30サーバー3,000-5,000 Requests/sec20,000 Query/sec (Reads)8,000 Query/sec (Writes)


基本構成IIS 8.0(Amazon EC2 Windows Server 2012 RC2).NET Framework 4.5 + ASP.NET 5c4.2xlarge x 30

MySQL 5.6(Amazon RDS)db.r3.8xlarge x 4

Redis 2.8(Amazon ElastiCache)cache.r3.4xlarge x 2

memcached(Amazon ElastiCache)cache.r3.2xlarge


AWS利用サービスElastic Load Balancing（高スケールなロードバランス）Amazon EC2（クラウド内の仮想サーバ）Amazon S3（クラウド内のスケーラブルなストレージ）Amazon RDS（マネージド型リレーショナルデータベースサービス）Amazon ElastiCache（メモリ内キャッシュサービス）AWS Elastic Beanstalk（ウェブアプリを実行および管理）


Architecture:Fate/Grand Order


ゲームインフラの特徴


当初の想定が難しいそのゲームがどれくらいヒットするかわからない普通のヒットであれば処理できるように設計はするものの、始まってみるまでどれくらいのヒットするのかはエンジニアには完璧には予測ができません。今までに見たことがないくらいヒットする事もあります。

動き始めたら止められない一度ゲームが始まってしまうと短時間のメンテは出来ても、なかなか数日単位の停止はできません。また、停止している間は負荷が読み切れません。動いているインフラの変更や調整は非常に手間がかかります。


常に更新される一般的なサービスと異なりINSERT/UPDATE/DELETEが膨大多くのユーザさんに「見て貰う」のではなく「遊んで貰う」必要があるため、膨大な量のWRITE(READも)が常に発生します。

負荷が頻繁に変動するメンテナンス開け、イベント開始時などには通常の数倍のアクセスがあることも普通です。ユーザさんの期待度や熱量がそのまま負荷に直結するため、最大負荷と必要な性能を予測することが難しくなっています。


なぜAWSを利用するのか？


インフラ管理の難しさ大規模を経験したインフラエンジニアは常に足りない優秀なインフラエンジニアは採用が難しく、大規模アクセスが来てから探していても間に合いません。

マネージドサービスの利便性アプリのデプロイ構成、DBなどのバックアップ、冗長構成、試験環境の用意、などなど、時間をかけて準備しなければならないものは沢山あります。

これらを一手に引き受けてくれるのが、AWSだと言えます。


データベースの性能マネージドDBには便利な機能が満載自動バックアップ、スナップショット、ポイントインタイムリカバリ、Multi-AZといった便利でユーザさんのデータを守る機能があります。

構成変更（スケールアウト、スケールアップ）が容易性能が必要になった時にすぐにインスタンス性能をあげることもできますし、幾つかのDBに分散させることもできます。

オンプレだとなかなかこうは行きません。


AzureからAWSへの移行


移行と更新を両立するインフラ作業に専念できる人がいない当初、非常に大きな問題として、インフラ作業に専念できる人が居ませんでした。特にゲームの更新を止める訳にもいかず、インフラエンジニアを必要としていました。

信頼できるサーバ管理会社の選定既にゲームが動いてしまっている状況で幾つかのサーバ管理会社さんへお声がけさせていただき、最終的に株式会社スカイアーチネットワークスさんに移管作業に関してご助力頂きました。現在でも、引き続きサーバ管理をお願いし、メンテナンスなどにもお付き合い頂きお世話になっております。


データをどう移すべきかAWS Database Migration Serviceの検討からレプリケーションまで簡単にデータを移行できる手段を探すべくデータマイグレーションサービスも検討しましたが、データサイズが既に多くなっていたこともあり、検証がうまくいかず基本に返ってレプリケーションにする事にしました。

レプリケーション遅延の回避スレーブが処理できる量を超えた更新がマスタから発行されるとスレーブが遅れていきます。これだといつまで経ってもデータが追いつきません。innodb_flush_log_at_trx_commit=2などを設定し、スレーブのI/Oを改善し速度を向上させました。（CPU、メモリ、I/Oの問題で対処が異なります）


実装の修正AzureSDKとAzureに依存したコードの置換C#のプロジェクトにはAzureに依存したコードが幾つかありました。こちらに関しては、設定ファイルによるON/OFFで、Azureに依存しないコードへ置き換えました。例えばAzure CacheからMemory Cacheへ変更などです。

ELBが送ってくるX-Forwarded-Forへの対応Azureでは生のIPがサーバに届いていたのをX-Forwarded-Forに対応する必要などがありましたが、かなり小規模な変更で対応できました。


周辺環境の修正Linux（CentOS）サーバの移行ユーザーアクティビティ記録のためや、エラーの管理などにLinuxを使っていましたがこちらも移行する必要がありました。

fluentdやnxlogなどログ周りの設定変更KPI解析の為にログ解析基盤に対してログを送信しており、fluentdやnxlogを使っていましたが、こちらの設定を変更する必要がありました。


データ検証および動作検証RDS試験環境を構築してQAを行う同期したDBをスナップショットから別途作成し、QA環境を構築しました。こちらに対応したクライアントバイナリを作成しデバッガーチェックをしました。

リリース済みアプリに対してプロキシを使用してのプレイ既にリリースされているアプリでも問題なく動作ができるように、iPhoneのプロキシ機能を利用し、本番サーバではなく検証サーバにアクセスするようにし、動作を検証しました。


移行時の構成図:Fate/Grand Order


移行作業深夜メンテナンスによる移行レプリケーションしていたDBに切替、逆に何か問題があったときの為にAzure->AWSのレプリケーションをAWS->Azureに切り替えました。

IISの時間がずれるトラブルありIISではGMT（グリニッジ標準時間）で管理されているため、JST（日本標準時）に切り替えていたのですが、勝手にGMTに戻ってしまう事がありました。結果としてIISのレジストリを調整し、修正を行いました。


AWSの構成変更とチューニング


AWSへの移行後2015年10月に移行決定し2015年12月頭に移行が完了負荷は安定し、年始年末は非常に安心して過ごすことができました。

だがしかし……！徐々にスパイクが発生し、明らかに「重い」という状況になりました。

単にAWSへ移行するだけではユーザさんの増加に耐えられませんでした。


サーバートラブルの理由AWSであろうとも突然の死はあるSLAが100%でない以上、どんなサービスにも突然の死があります。落ちたときにどうするのかをきちんと設計しておく必要しないといけません。

データベースの性能限界が突然くるユーザーさんが増え続ける限り、データは増え続けますし、10msで処理していたSQLが突然2,000msでしか処理できなくなり、プロセスリストがみるみる詰まります。

海外からの容赦ないDoS攻撃がくる時にはアジア圏内の国から容赦ない不正アクセスがきて負荷とデータ量を急上昇させます。楽しんで戴いているユーザさんの妨げになるので対処しなければなりません。


チューニングへの道のりサーバーの台数を増やせば良いのでは？DBが限界の状態で安易にサーバの台数を増やすと、DBへのアクセス数が一気に増大してDBが詰まってゲームが応答しなくなります。

データベースの性能をあげれば良いのでは？DBはその時点で既に最高のインスタンスを使っていました。Amazonさんが更に高性能なデータベースを用意してくれるのを待つわけにはいきませんでした。

水平分割とか垂直分割をすれば良いのでは？作業の見積もりを行いましたが、短時間のメンテで終わる作業ではない事が一目瞭然でした。ユーザさんが再開を待っているため、今すぐ解決をするべくチューニングを行う事にしました。


ボトルネックはどこかスロークエリを解決する？まずは定石であるスロークエリを解決するのが鉄板です。しかし、データベースが限界に達している場合、何でも無いようなＳＱＬがスロークエリになってしまいます。

キャッシュに逃がす？Redisやmemcachedに関しては揮発性を考慮し、万が一無くなっても大丈夫なものを優先して配置しています。結果として、問題が解決するまで性能が向上しませんでした。

テーブルのスキーマを見直す？データベースのテーブルを再設計することで高速化が期待できる可能性はありました。しかし、運用中の既に大量のデータが追加されたテーブルを最適化するのはリスクが高くなります。


Innodbのチューニング基礎inndb_buffer_pool_sizeが何より重要！ここさえあれば基本は性能がでます。ただし、FGOではデータサイズおよびインデックスサイズが、既に500GBを超えているため、インデックスサイズ相当だけをメモリにのせるのがやっとでした。

innodb_log_file_sizeとinnodb_log_files_in_groupも重要バッファプールデータは直接テーブルへ書き出されるのではなく、一旦ログファイルに書き出されます。故に、テーブルへフラッシュする前のデータを保持するログファイルサイズも重要です。thread重要(innodb_read_io_threads/innodb_write_io_threads)I/Oが問題になるとき、いかにR/Wを向上させるかになるため、threadの数を増やすのが有効でした。しかし、並列thread数を制御するinnodb_thread_concurrencyを0（制限なし）にすると耐えられませんでした。あっと言う間にプロセスが詰まり応答できなくなる状況でした。


公式ドキュメントを読もうMySQLのチューニングに関しては必ず公式ドキュメントを熟読する１つ１つのパラメータの動作、最適化について非常に細かく書いてあります。ボトルネックに応じて調整するパラメータが変わりますので、必ず仮説を持って対応することが大事です。ボトルネックになっているのが、CPUかメモリか、ディスクI/Oかで対応が変わります。

「HogeはNで十分です」という文言には注意するGoogleで調べれば様々なMySQLチューニング例が引っかかると思います。しかし、多くのサイトには「なぜそれをするのか」が書いてありません。見知らぬ人の見知らぬ環境を丸写しにしてはいけません。

必ず切り分けをして効果の有無を確認するMySQLには非常に多くのパラメータがあります。これらを一気に変更するとどれが効果があったのかが解りづらくなります。場合によってはdynamic（再起動無し）で変更できる値もありますので根気よく１つ１つ試しましょう。


必ず計測しよう最適値はサービスやゲームの特性に左右されるFGOでは、1台のMySQLでかなりの数をさばいていましたが、やがてそれも限界が来ました。サービスやゲームによってはもっとアクセスが多い事もあり得ますし、MySQLの使われ方（ConnectionStringやConnectionPoolingなども含め）によっても挙動が変わってきます。

ロブ・パイクの古い古い格言（プログラミング作法の人、Goの人）プログラムがどこで時間を消費することになるか知ることはできない。ボトルネックは驚くべき箇所で起こるものである。したがって、どこがボトルネックなのかをはっきりさせるまでは、推測を行ったり、スピードハックをしてはならない。

計測すべし（＝早すぎる最適化は諸悪の根源である）計測すべし。計測するまでは速度のための調整をしてはならない。


データベースを分割する


DBを分割しようチューニングにもやはり限界があるFGOでは、チューニングを繰り返すことで性能を限界まで出していましたが、それでもやはり分割をしなければならない時がやって来ます。（来ました）

水平分割と垂直分割DBを水平（ユーザID等で別DBに振りわける）と垂直（機能単位で別DBに振りわける）に分割する方法が一般的です。

FGOでは垂直分割を採用しましたユーザ情報、サーヴァント情報、アイテム情報などで４分割しています。制限として、外部キーが使えなくなります。また、DBをまたがったJOINができないなど、クエリへの制約があります。


水平分割VS垂直分割得手不得手がある一概にどちらが優れているというものではありません。（どちらも経験済みとしての意見として）

水平分割水平分割は無限にスケールすると言われますが、分散トランザクションを適切に用いる必要があるのと、ユーザ毎にデータが分散してしまうため、ユーザ間での整合性を保つための設計が非常に難しくなります。

かつ、特定のDBに負荷がかかった場合でも全体の個数を増やして分散する必要があります。

垂直分割（FGOで採用）無限にスケールする訳では無く、かつ幾つかスキーマやクエリに制限がかかりますが、設計はシンプルになります。機能単位の分割であるため、特定の機能に負荷がかかる場合は個別最適化が必要になります。


大規模と向き合う心構え


仮説と検証を積み重ねよう大規模を経験したエンジニアというのは殆ど世の中にいません大規模を経験した、というエンジニアでも10万DAUなどが殆どです。（サービス／ゲーム内容によるので一例とお考え下さい）殆どのエンジニアにとっては未知数の大規模アクセス＝未知との遭遇です。大規模アクセスの運用に正解はありません。故に、仮説と検証を積み重ねて実証する必要があります。誰も正解を教えてはくれません。

仮説を立てるにはその根拠となる知識と経験が必要になりますMySQLというデータベースをチューニングするのに、お手本となる教科書も虎の巻もありません。結局は、CPU、メモリ、ストレージI/O、スレッド、に集約されます。公式ドキュメントには「なぜ効果があるのか」は書いてありますが、理解できなければ意味がありません。「コンピュータの構成と設計第5版」などを読んでコンピュータをアーキテクチャとして理解しておくことが非常に役に立ちます。

強心臓を持とうサーバトラブルに遭遇したとき、Twitterなどでもお客様から様々な意見が届きます。時にココロが痛いこともあると思います。しかし、黙って待っていてもトラブルは解決しません。トラブルが起きている時こそココロを強く持ちましょう。


開発を取り巻く環境


開発環境BitBucket(Git)大事なところはPullRequestベースで開発を行ってます。

Sentryエラーログツール。何かエラーが起きるとエラーレポートが届きます。

Jenkins様々な通知や作業の自動化に役立ってます。

New Relic最強のモニタリングツールです。これがないと負荷を計測することが難しいです。


New Relicによる計測普段はMySQLは8ms～10ms


New Relicによる計測突然のスパイクが発生すると4,000ms


まとめ


まとめAWSを使うことは１つの最適解ですインフラエンジニアがいないような会社でも大規模ゲームを運用することができます。

AWSを使う「だけ」ではいけないデータは日々積み重なり、状況は刻一刻と変化します。AWSを活用するためには仮説と検証を繰り返し実証することが必要です。

AWSは銀の弾丸ではありませんすべての問題を解決する魔法はありませんが、非常に強力な武器ではあります。

Documents

Fate/Grand Order における、 ディライトワークス流AWS 導入＆ … · 開発用の周辺ツールやフレームワークから作る必要がありました。 また、定期的なゲーム内イベントや、機能拡張などを行っていく必要がありました。

Fate/Grand Order における、ディライトワークス流AWS 導入＆ … · 開発用の周辺ツールやフレームワークから作る必要がありました。また、定期的なゲーム内イベントや、機能拡張などを行っていく必要がありました。