こんにちはドリコムでインフラを担当しているnettyです。
サービスの移行は準備も大変ですし、失敗した場合の事を考えると極力避けたい作業ではありますが、今回は避けて通れない状況でした。
移行先としてAWSを選択した理由は以下になります。
ここではどのようにデータの移行を行ったのかについて説明していきます。
やる事は以下になります。
まずはXtraBackupの2.4をインストールします。
XtraBackupで取ったバックアップファイルをS3にアップロードする必要があるので、AWS CLIもインストールします。S3へのデータ転送のみの利用になるので、インストールが簡単なバンドルされたインストーラを利用しました。
最後にS3のバケット作成と移行元のサーバからS3にアクセスするIAMを作れば完了です。IAMはS3へアップロードするだけなので、以下権限を付けました。
1．XtraBackupでバックアップを取得する。
2．バックアップファイルをS3に転送する。
3．AWSのコンソールでS3のファイルを元にAuroraを起動する。
通常のAurora起動とそれほど差はなく最初に「S3から復元」ボタンをクリックし
以下はテストなのでシングルリージョンでの起動になります。
あとはDNSを変更しアプリ側の動作確認に問題がなければ移行完了ですね．．．．．．．．．．．
1．save or bgsaveをしてdump.rdbのデータ同期をする。
2．バックアップファイルにElastiCacheのパーミッションを付けて転送する。
Aurora移行と違う点として、ElastiCacheがS3のファイルを読込む時に、IAMロールではなくS3のパーミッションが必要になるため、S3オプションのgrantsを使ってパーミッションを付与して転送します。
3．AWSのコンソールでS3のファイルを元にElastiCacheを起動する。
ElastiCacheはAuroraより簡単で、データのインポートに転送したS3とファイルを指定して完了です。
データ容量やサービス停止時間など考慮して最適な手順で移行がスムーズに行えればと思います。
個人的にはXtraBackupを利用した移行方法でファイルの圧縮形式にpbzip2などの形式が利用出来るようになれば移行時間が短縮出来るので是非追加して欲しいなと思いました。
サービス移行の背景
オンプレ環境でのサーバ老朽化やクラウドサービスの終了などでサービスの移行をする事がありますが、今回とあるクラウドの終了に伴い、とあるサービスをAWSに移行することになりました。サービスの移行は準備も大変ですし、失敗した場合の事を考えると極力避けたい作業ではありますが、今回は避けて通れない状況でした。
移行先としてAWSを選択した理由は以下になります。
- 使い慣れた環境
- マネージドサービス利用による運用コスト削減
ここではどのようにデータの移行を行ったのかについて説明していきます。
移行方法の選択
今までの移行は下記図のように移行元と移行先をVPNで繋ぎ、サーバ間でレプリケーションさせる方法をとってきましたが、今回の移行ではマネージドサービスのAmazon Auroraを利用するため、Percona XtraBackupを使ってAurora移行を行いました。- 今までの移行
- XtraBackupでの移行
- 検証項目が少なかった
- 通常のバックアップにXtraBackupを利用しているので、少ない変更で手順を確立出来た
- 移行元のデータ量がそれほど多くない
※バックアップ+転送+Aurora起動で約2時間程度 - 既にXtraBackupでの移行を実施した事がある
- 事前にサーバを起動しないので移行期間中のコストを削減できる
XtraBackupによる移行
XtraBackupを利用したAuroraへの移行は以下の点を気を付ければ問題なく行えます。- Xtrabackupが2.4以上である事
- 圧縮テーブル(Barracuda)を利用していない事
圧縮テーブルの存在確認は
mysql> SELECT * FROM information_schema.TABLES WHERE ROW_FORMAT = 'Compressed';
- 圧縮形式がGzip,tar,xbstreamである事
データ移行準備
実際に準備した内容と移行を行った手順について説明していきます。やる事は以下になります。
- XtraBackupのインストール
- AWS CLIのインストール
- S3のバケット作成とIAMの作成
まずはXtraBackupの2.4をインストールします。
$ sudo yum install https://repo.percona.com/yum/percona-release-latest.noarch.rpm
$ sudo yum install percona-xtrabackup-24
$ curl "https://s3.amazonaws.com/aws-cli/awscli-bundle.zip" -o "awscli-bundle.zip"
$ unzip awscli-bundle.zip
$ sudo ./awscli-bundle/install -i /usr/local/aws -b /usr/local/bin/aws
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:PutObject"
],
"Resource": [
"arn:aws:s3:::netty-test/*"
]
}
]
}
データ移行
準備が出来たら後は以下の順番でバックアップからAuroraの起動までを行います。1．XtraBackupでバックアップを取得する。
$ sudo innobackupex --user=xxxx --password=xxxx --stream=tar /var/backup | gzip > /var/backup/xtrabackup.tar.gz
$ aws s3 cp /var/backup/xtrabackup.tar.gz s3://netty-test/xtrabackup/
通常のAurora起動とそれほど差はなく最初に「S3から復元」ボタンをクリックし
{
"Effect": "Allow",
"Action": [
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::netty-test/xtrabackup/xtrabackup.tar.gz*"
]
}
以下はテストなのでシングルリージョンでの起動になります。
あとはDNSを変更しアプリ側の動作確認に問題がなければ移行完了ですね．．．．．．．．．．．
おまけ
今回の移行したサービスはMySQL以外にもRedisも利用していたので、RedisもマネジメントサービスのElastiCacheに移行しました。こちらについても簡単な纏めになりますが、行った内容について説明していきます。1．save or bgsaveをしてdump.rdbのデータ同期をする。
$ sudo redis-cli bgsave
Aurora移行と違う点として、ElastiCacheがS3のファイルを読込む時に、IAMロールではなくS3のパーミッションが必要になるため、S3オプションのgrantsを使ってパーミッションを付与して転送します。
$ aws s3 cp /var/lib/redis/dump.rdb s3://netty-test/redis/ --grants full=id=バケット所有者の正規ID,id=540804c33a284a299d2547575ce1010f2312ef3da9b3a053c8bc45bf233e4353
ElastiCacheはAuroraより簡単で、データのインポートに転送したS3とファイルを指定して完了です。
最後に
XtraBackupを利用した移行方法について説明しましたが、選択しなかったAWS Database Migration Serviceでもデータの移行は可能です。データ容量やサービス停止時間など考慮して最適な手順で移行がスムーズに行えればと思います。
個人的にはXtraBackupを利用した移行方法でファイルの圧縮形式にpbzip2などの形式が利用出来るようになれば移行時間が短縮出来るので是非追加して欲しいなと思いました。
