こちらは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への移行を行う予定です！