Aurora MySQLが2系になりました 🎉 - あしたのチーム Tech Blog

どうも。先週やっと「コードギアス　復活のルルーシュ」を観たエンジニアの大庭です。

今回は、~~C.C.(CV. ゆかな)の魅力をたっぷりと語る~~コンピテンシークラウドで利用しているAurora MySQLを2系にアップグレードしたので、そこで得たちょっとした知見や失敗談をお話しできればなと思います。

Aurora1から2へはインプレースではアップデートできない
TerraformでのAurora MySQL 2.xの指定
【失敗】スナップショットからの復元にかかる時間は一定ではない
Terraformのタイムアウト
最後に

Aurora1から2へはインプレースではアップデートできない

Aurora MySQL データベースエンジンの更新 (2019-01-09) - Amazon Auroraより

Aurora MySQL 1. クラスターを Aurora MySQL 2.03.2 にインプレースアップグレードしたり、Amazon S3 バックアップから Aurora MySQL 2.03.2 に復元したりすることはできません。これらの制限は、今後の Aurora MySQL 2. リリースで削除する予定です。

なので、Aurora1から2へするには新規にAuroraクラスターを作り直す必要があります。
コンピテンシークラウドはサービスの性質上、無停止稼働が求められるものではないので(もちろん停止時間がないなら嬉しいですが)、今回はメンテナンス日を設けて作業を行いました。

停止が出来ない場合はDMS(Database Migration Service)の利用などを考える必要がありそうです。

TerraformでのAurora MySQL 2.xの指定

結論から言うとTerraformでのAurora MySQL 2.xの指定の仕方は下記です。

resource "aws_rds_cluster" "aurora_mysql" {
  ・・・
  engine                              = "aurora-mysql"
  engine_version                      = "5.7.mysql_aurora.2.03.4"
  ・・・
}

しかし、当時は下記の記事が見つけられず、結局一度AWSコンソールで2系を作ってTerraformで差分を確認して調べました。

docs.aws.amazon.com

Aurora MySQL 2.03.2 以降、Aurora エンジンバージョンの構文は次のとおりです。

<mysql-major-version>.mysql_aurora.<aurora-mysql-version>

たとえば、Aurora MySQL 2.03.2 のエンジンバージョンは次のとおりです。

5.7.mysql_aurora.2.03.2

Aurora MySQL 1.xが5.6.10a、2.02が5.7.12、2.03が5.7.mysql_aurora.2.03.2となるので、とても分かりづらい。

【失敗】スナップショットからの復元にかかる時間は一定ではない

スナップショットの取得は数分でできるのですが、スナップショットから復元はかなり時間がかかります。
自分たちのスナップショットが75GBほどなので、当日どれくらいかかるか目安を知るために本番とほぼ同じ構成のステージングで何度か試しました。
結果、だいたい1時間くらいで完了したので当日もそのくらいであろうと思っていました。
※心配だったので、実際のメンテナンスと同じ時間帯でも1度試しました

しかし、当日実際に行うと結果2.5時間ほどかかりました。。。（インスタンスタイプなども同じなのになぜ？）

dump→importの時間も合わせて計測してスナップショットからの復元の方が早いし、確実だろうと言うことで今回の選択をしましたが、リハーサルよりもかなり時間がかかってしまいました。
これならdump→importの方が早かったですし、import時だけインスタンスタイプをdb.r4.2xlargのような大きいものを利用して時間の短縮を図る（少しのお金はかかりますが）など工夫ができたのでこの判断は失敗でした。。。