読者です 読者をやめる 読者になる 読者になる

DELiGHTWORKS

DELiGHTWORKS株式会社の開発に関する情報を発信していきます。

48時間後…

こちらは48時間後に突然サービスが瞬断される状況が頻発し、生きた心地がしなかった、という備忘録です。

AWS Summitでお話しさせて戴いたAWSへの移行ですが、その中にAuroraは出てきませんでした。しかし、実際にはFate/Grand Orderは一度Auroraへ移行をしていました。そして、再度RDSに切り戻しています。

こちらに関して既に問題は解決してはいるのですが、こんなこともあったということで知見を共有させていただきます。

4月末、私たちはRDS(MySQL)をAuroraへ移行しておりました。これはDBの分割前に行った対策になり、暫くは問題無く稼働していました。

しかし、稼働から48時間後突然のスパイク(アクセス障害)が訪れました。これに関してはまさに「この瞬間には何もしていない」のに発生したスパイクで、アクセス数が急増した訳でもなかったため、解決には非常に困難を極めました。

原因はAuroraにあることは明らかですが、原因が思い至りません。

こちらに関してあらゆるパラメータの精査、MySQLコネクター周りの実装確認、かつ自社側のプログラム側の確認、を行いましたが解決出来ず結果としてRDS(MySQL)への切り戻しを行いました。

 

その後、調査を進め私たちは問題を突き止めることができました。

問題は何だったのでしょうか?

答えはRDS(MySQL)への切り戻しのために設定したbinlog(バイナリログ)でした。

この時期のAuroraはbinlogをPurgeする際に「Init DB」という高負荷のクエリが頻発し、サービスが瞬断される症状があり、Purgeが走り始める48時間後に突然性能が低下し、問題が発生したのです。

(Fate/Grand Orderではbinlogの保持期間を48時間に設定していたため)

なお、この問題に関してはEfficient Storage of Binary Logsという変更が入り、解消されていますが、この時点ではこの変更はlab mode(実験中)でしか提供されておらず、問題となったのでした。

 

Auroraの使い方につきましては、

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.Replication.CrossRegion.html

の “Before You Begin”に”you must be running the most recent version of the Aurora database engine"

とあるように、最新のバージョンを利用することが推奨されています。

なので、皆さんは是非最新をご利用下さい。

 

既に問題は発生しませんが、リリースされているEfficient Storage of Binary Logsの変更に関してはこちらをご覧下さい。

https://forums.aws.amazon.com/ann.jspa?annID=3793

 

ということで、48時間後に突然の障害に見舞われたお話でした。

このような障害も時にはありますので、いつでもインフラは気を抜けません。

このときは直ぐには原因が思い至らず、本当に冷や汗が出ました。

元々切り戻しのためのbinlogに対する障害なので本末転倒感がありますが、切り戻しで解決したときは胸をなで下ろしたものです。

やはり何事にも準備が必要ですね。

……が、より快適に遊べるゲームを目指し再度Auroraへの移行を行う予定です!