JAWS-UG首都圏勉強会レポート 第9回

「ぼくらの甲子園」のDBをRDS for MySQLからAuroraへ

カヤックでのAurora移行は「今のところいいことしかない」

11月2日に開催されたJAWS-UG横浜Rebootにおいて、RDS for MySQLからAuroraへの移行についてLTを披露したのが、面白法人カヤックの藤原俊一郎さん。Auroraの移行により、RDS for MySQLのたまにデータが詰まる問題やリードレプリカの難点が解消されたという。

マルチAZのMySQLがたまにつまる、リードレプリカの暖気がつらい

　ゲームや広告、Webサービスなど、ともかくバズるモノを作るのが得意な面白法人カヤック。古都鎌倉に本社を構えていることでも知られているが、最近は支社として“ヨコハマ展望台”オフィスができたこともあり、今回のJAWS-UG横浜の登壇につながったようだ。そんなカヤックの藤原俊一郎さんがLTで披露したのは、ソーシャルゲーム「ぼくらの甲子園」でのAurora移行話だ。

面白法人カヤック 技術部 藤原俊一郎さん

　2014年9月にリリースされたぼくらの甲子園はプラットフォームとしてAWSを全面採用しており、ストレージとしてRDS for MySQLを使っている。「9人のプレイヤーが2チーム、合計18人が1つの試合を操作する。試合進行は背後にバッチ処理が動いていて、複雑なデータの書き換え処理をするため、トランザクションをきっちりやらないと厳しい」（藤原さん）という理由でNoSQL DBは採用しなかったという。

　では、なぜAuroraに移行したのか？　1つ目の理由は、マルチAZ構成のMySQLがたまに詰まるという現象だ。「数週間に1度の頻度ですが、十数秒反応がなくなって、その後スロットに溜まり出すという現象が起こる」（藤原さん）とのこと。サポートに電話しても、「そのとき調子が悪くて現象は解消しています」という話だが、仕組み上しようがないと考えた。しかし、Auroraだとこの現象の解消が見込める。「Auroraだと3つのAZのすべて書き込み、2つのAZで書き終えたら、レスポンスが戻ってくる。なので、原理的には2つのAZが同時につまらない限りは、こういう事態は起こりにくいはず」と藤原さんは見通しを語る。

　2つ目は「リードレプリカの暖気がつらい」という話だ。リードレプリカはEBSのスナップショットから復元できるが、立ち上げ時だけアクセスが遅いという「ファーストタッチペナルティ」がある。そのため、いったん全データをコマンド等で読み出す作業が必要になるが、イベントの前にインスタンスを立てる際につらくなる。しかし、Auroraの場合だと、最初からストレージが用意されており、それらをインスタンスで共用する形になるので、こうした問題が起こらないという。

リードレプリカの暖機運転がつらい

アプリケーションの互換性があるので、移行を検討すべき

　こうした事情からAuroraへの移行を始めたカヤック。事前検証でMySQLとの違いを意識することもなく、一部の導入でも問題なく利用できた。ただ、テストした限り、カヤックの環境では性能面での向上はなかった。「下がるわけでも、上がるわけでもなく。限界が変わるわけでも、同じくらい」（藤原氏）という。

　本番への移行はダウンタイムを少なくするため、MySQLでリードレプリカを作成し、いったん停止したリードレプリカからスナップショットを取得。そこからAuroraを復元し、アプリケーションの参照先を変えることで10月には無事に移行できたという。

　移行の効果としては、課題となっていたデータの詰まりが完全になくなったほか、暖気の必要もなくなった。また、同社では障害対応のためにスナップショットをまめにとっているが、EBSのようにスナップショット取得時の負荷がかからなくなったという点もメリットだった。さらにクエリのレイテンシが取得できるようになったので、性能や遅延の監視に便利だという。

　コスト面に関してはAurora自体はMySQLに比べて若干高価にはなるが、I/O性能を保証してくれるEBSのProvisioned IOPSのコストが減るほか、IOPSを稼ぐために大きめの容量を確保する必要がなくなった。インスタンス費用が上がり、ストレージとIOPSの費用が下がったので、トータルではあまり変わらないという。

　まとめとして藤原氏は、「結局、悪いところは今のところない。アプリケーションの互換性が確保されているので、現状でひっかかるところがあれば、移行する価値はあると思う。特にIOPSの安定性が上がったのでうれしい。いまのところいいところしかない」とアピールした。

■関連サイト

• JAWS-UG横浜－Reboot！