密着 24時！ MySQL 5.1 から Aurora への移行100日間〜 Backlog 編

by matsuura

2016/05/20

Backlog / Development

Photo via Visual hunt

Backlog の一部のスペースにて Amazon Aurora へと移行しました。ここでは、その経緯と実際に実施した作業を簡単にご紹介させていただきます。

移行の経緯

昨年末データベース障害が発生しユーザー様には多大なご迷惑をお掛けしてしまいました。
Backlog には Terraform をどう使っているかを紹介したブログにあるように複数の運用環境があります。
その各々の環境の構築時期によって EC2 上で自前運用していた MySQL もあれば、RDS for MySQL もある、といった統一されていない状況でした。また EC2 上ではまだ MySQL 5.1 も稼働していました。
移行を検討するにあたり、優先したのは障害時の復旧が素早く出来ることと、少しでも運用の管理コストを下げることでした。Backlog のサーバは 100 台以上で運用されており管理コストが上がってきてます。
そういった経緯もあり EC2 上で自前運用するアンマネージドなものからマネージドサービスである RDS for MySQL へ移行することとし検証を開始しました。
最初は RDS for MySQL に切り替えることを検証をしていたのですが、簡単に RDS for MySQL から Amazon Aurora に移行できます。アプリケーションが動くかのテストを実施し、問題なく動くことを確認したので Amazon Aurora に移行することになりました。

Amazon Aurora に決めた理由としては、アベイラビリティ(可用性)とスケーラビリティ(拡張性)です。また、先行して移行したヌーラボアカウントで安定稼働していること。それに、新しい Backlog 環境では Amazon RDS for MySQL 5.6 での稼働実績があり移行の後押しとなりました。

また公式で互換性があることが記載されています。( Amazon Aurora データベースエンジンは InnoDB ストレージエンジンを使用することで MySQL 5.6 と強い互換性を持っています。 )

主観ではありますが運用の視点で見た場合に Amazon Aurora にして何が一番嬉しいかというとスケーラビリティ(拡張性)でした。 Amazon Aurora ストレージは 10 GB 単位で最大 64 TB まで、データベースのパフォーマンスに影響を与えずに拡張されます。
Backlog は複数の運用環境があり、ユーザー数をコントロール可能です。 64 TB 以上データが増えないようにすることが可能でディスク拡張のためのメンテナンスを実施しなくてよくなります。RDS for MySQL のディスク拡張を行った際には待機を行っておりましたが、いつ完了するか、いつ切り替わるかのコントロールが実施できず、夜実施し、朝終了することもありました。回数は少ないとはいえこういったメンテナンスから開放されるのは嬉しいものです。

ユーザー様視点でみるとマネージドなサービスを利用することになってデータベースが原因となるメンテナンス時間が減ることになります。

移行手順の検討

ここでは EC2 上の MySQL 5.1 から Amazon Aurora に移行する手順を検討します。
重要視したのは通常のメンテナンス時間でデータを確実に移行することでした。
MySQL バージョン間のレプリケーション互換性を参考に段階的に MySQL のバージョンアップを行いレプリケーションのチェーンをさせてデータベースを切り替えていくことにしました。

データ容量は 5TB ほどで一気に Amazon Aurora に移行するのではなく大きく3ステップ、さらにそれをブレークダウンして実質は 14 ステップに分解し少しずつアップデートしていきました。

大きくは以下の 3 つのステップになります。

MySQL 5.1 から MySQL 5.6 へのアップグレード
MySQL 5.6 から RDS for MySQL 5.6 への切り替え
RDS for MySQL 5.6 から Amazon Aurora への切り替え

それぞれの手順を詳しく見ていきます。移行前は下図の状態でした。

移行の手順

手順 1 MySQL 5.5 のスレーブを作成してレプリケーションを開始する。

新規スレーブを MySQL 5.1 で立て、mysql_upgrade を行い MySQL 5.5 にアップグレードしています。データのスナップショットは、すでに稼働しているスレーブから xtrabackup を使用して移行しています。

手順 2 MySQL 5.6 のスレーブを作成してレプリケーションを開始する。

さらにスレーブを MySQL 5.5 で立てて、mysql_upgrade にて MySQL 5.6 にアップグレードしています。データのスナップショットは手順 2 で作成したスレーブから xtrabackup を使用して移行しています。

手順 3 MySQL 5.6 をマスターに切り替えてアプリケーションを稼働させる。

メンテナンス時間を設けて MySQL 5.6 をマスターとしてアプリケーションを稼働させました。

手順 4 Amazon RDS for MySQL 5.6 を立てて、移行用に MySQL 5.6 のスレーブを作成する。

アプリケーションに影響が出ないよう新しいスレーブを立てて、Amazon RDS for MySQL 5.6 を立てます。

手順 5 MySQL 5.6 のスレーブのレプリケーションを停止し、テーブル単位で mysqldump を実施する。

手順 4 で作成したスレーブのレプリケーションを停止し、テーブル単位でバックアップをとっていきました。テーブル単位でバックアップをとった理由としては、テーブル数が多いこととテーブル単位でデータ量が違うため書出しが終わったものを把握しやすいような粒度にしました。
実は何度もフルバックアップを取りリストアを試していました、ですが毎回件数があわず原因を追いづらい状況でした。そういった経緯もありどれだけレプリケーションが遅延しても追いつくまで待つこととし、レプリケーションを止めてテーブル単位で確実に移行を行っていった経緯があります。

話は脱線しますが移行の過程で AWS Database Migration Service でデータを移行することを検討していました。テスト環境での移行はうまくいっており、簡単な操作でデータがレプリケーションされることを確認しています。ですが移行を試した時期がプレビューリリース時期というのもあり、本番データを移行しようとした時に上手く行かず、今回紹介させて頂いた方式でデータの移行を実施しております。AWS Database Migration Service が GAになったときにはすでに移行完了していたので次移行する機会があった場合には使用したいと思っています。そのときにはまたレポートさせて頂きます。