こんにちはドリコムでインフラを担当しているnettyです。

サービス移行の背景

オンプレ環境でのサーバ老朽化やクラウドサービスの終了などでサービスの移行をする事がありますが、今回とあるクラウドの終了に伴い、とあるサービスをAWSに移行することになりました。
サービスの移行は準備も大変ですし、失敗した場合の事を考えると極力避けたい作業ではありますが、今回は避けて通れない状況でした。
移行先としてAWSを選択した理由は以下になります。
  • 使い慣れた環境
  • マネージドサービス利用による運用コスト削減

ここではどのようにデータの移行を行ったのかについて説明していきます。

移行方法の選択

今までの移行は下記図のように移行元と移行先をVPNで繋ぎ、サーバ間でレプリケーションさせる方法をとってきましたが、今回の移行ではマネージドサービスのAmazon Auroraを利用するため、Percona XtraBackupを使ってAurora移行を行いました。
  • 今までの移行
  • XtraBackupでの移行
XtraBackup以外にもAWS Database Migration Serviceもありますが、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
XtraBackupで取ったバックアップファイルをS3にアップロードする必要があるので、AWS CLIもインストールします。S3へのデータ転送のみの利用になるので、インストールが簡単なバンドルされたインストーラを利用しました。
 $ 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
最後にS3のバケット作成と移行元のサーバからS3にアクセスするIAMを作れば完了です。IAMはS3へアップロードするだけなので、以下権限を付けました。
  {
    "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
2.バックアップファイルをS3に転送する。
$ aws s3 cp /var/backup/xtrabackup.tar.gz s3://netty-test/xtrabackup/
3.AWSのコンソールでS3のファイルを元にAuroraを起動する。

通常のAurora起動とそれほど差はなく最初に「S3から復元」ボタンをクリックし
Auroraのバージョンを選択したら移行元のMySQLのバージョンを選択し、バックアップファイルを転送したS3の入力をします。
次にS3にアクセスするためのIAMロールを選択するのですが、こちらは「新規ロールの作成」にすれば正しく設定されます。
※作成されたロールはファイル名まで指定されているので、ファイル名を変更した場合は「新規ロールの作成」で再作成するかロールを直接編集する必要があります。
  {
    "Effect": "Allow",
    "Action": [
      "s3:GetObject"
    ],
    "Resource": [
      "arn:aws:s3:::netty-test/xtrabackup/xtrabackup.tar.gz*"
    ]
  }
後は通常通りのAurora起動の指定になります。
以下はテストなのでシングルリージョンでの起動になります。

あとはDNSを変更しアプリ側の動作確認に問題がなければ移行完了ですね...........

おまけ

今回の移行したサービスはMySQL以外にもRedisも利用していたので、RedisもマネジメントサービスのElastiCacheに移行しました。こちらについても簡単な纏めになりますが、行った内容について説明していきます。

1.save or bgsaveをしてdump.rdbのデータ同期をする。
$ sudo redis-cli bgsave
2.バックアップファイルにElastiCacheのパーミッションを付けて転送する。
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
3.AWSのコンソールでS3のファイルを元にElastiCacheを起動する。
ElastiCacheはAuroraより簡単で、データのインポートに転送したS3とファイルを指定して完了です。

最後に

XtraBackupを利用した移行方法について説明しましたが、選択しなかったAWS Database Migration Serviceでもデータの移行は可能です。
データ容量やサービス停止時間など考慮して最適な手順で移行がスムーズに行えればと思います。
個人的にはXtraBackupを利用した移行方法でファイルの圧縮形式にpbzip2などの形式が利用出来るようになれば移行時間が短縮出来るので是非追加して欲しいなと思いました。

参考リンク