AWS上の本番DBから通信コストを抑えて大量データを開発DBに入れる

こんにちは。エキサイト株式会社のエンジニアのAです

今回はAWS上で本番稼働中のRDSから開発用DBクラスター内に新しく作成したスキーマにデータを入れる必要があったため、その際に通信料金をできる限り最小限で抑える方法をご紹介します

料金について

  • インターネット経由で外からDBにアクセスすると料金がかかるので極力VPC内の同一リージョン間で行う

  • 異なるAZ間で通信した場合でも通信料金がかかるので同一AZから通信を行う(料金は微々たるものなので、大量のデータをやり取りする場合のみ考える必要があります)

aws.amazon.com

同一の AWS リージョンでのデータ転送 Amazon EC2Amazon RDS、Amazon Redshift、Amazon DynamoDB Accelerator (DAX)、Amazon ElastiCache インスタンス、Elastic Network Interface、または同じ AWS リージョン内のアベイラビリティーゾーンをまたいだ VPC ピアリング接続間で「受信 (イン)」/「送信 (アウト)」されるデータの転送料金は、各方向 0.01 USD/GB です。

使用構成

  • 本番環境RDS master1台 Read3台+オートスケール

  • 開発環境RDS master1台 Read1台

一時的な移行用DBを作成する

dumpの際はRDSに負荷がかかるため、本番DBのスナップショットから移行用の一時的なDBクラスターを作成しています

RDS → インスタンスを選択 → [スナップショット作成]

スナップショット→[スナップショットを復元]

※この方法だとスナップショット作成以降、本番DBに入ったデータは入らないので注意

Dumpを実行する開発サーバーを用意する

  • 本番環境DBからデータをDumpする際は、本番DBの対象インスタンスと同一のAZにする

  • Dumpしてきたデータを開発DBに入れる際は、対象インスタンスが実行環境と同一AZか確認する

※本番と開発DBの対象インスタンスのAZ異なった場合、DumpデータをS3に置いて開発DBと同じAZの実行環境でS3からDumpデータを取得してデータを入れるなどで対応

データの移行

1.本番DBからデータをDumpする

mysqldump -u [user] -h [本番DBのホスト名] -p [DB名]
  1. 開発DBにデータを入れる
cat [Dumpデータ.gz] | mysql -u [user] -h [開発DBのホスト名] -p -D [DB名]

片付け

  • 一時的に作った移行用DBをクラスターごと削除する

  • 開発環境からDumpデータを削除(S3に保存しておくのもアリかもしません)

終わりに

今回のように既存のDBクラスターを使う必要がない場合は、そのままスナップショットから作ったクラスターのサイズを調整するだけでよいです

また、最初に述べたように大量のデータを通信したり、頻繁にデータ通信が発生するなどの要件がなければAZを合わせる必要はなさそうなため、要件に合わせて変えていくと良いでしょう