kasei_sanのブログ

かせいさんのIT系のおぼえがきです。胡乱の方はnoteとtwitterへ

Amazon Auroraへの移行事例をまとめて知見を抽出してみた

AWS Aurora

先に知見まとめ

急いでる人はここだけ読めば良いと思う

移行方法

以下の3つの方法のどれかで移行している

  1. RDSの場合、Auroraリードレプリカを作成して、同期完了後、昇格
  2. Amazon DMSでAuroraにデータを移行。同期完了後、切替
    • DMSにはいくつか制限があるので、単純に移行はできない
  3. 自前でAuroraのmasterにレプリケーションを貼る。同期完了後、切替
    • 切替は設定ファイルのエンドポイントを書き換える or DNSのレコード変更

レプリケーションやDMSを使う場合、ついでにテーブルのリファクタリングをしている会社も多い

RDSなら、リードレプリカで移行するのがシンプル
それ以外からの移行 or テーブルのリファクタリングもしたいならば、DMSを使うのがベターか

やったほうが良さそうなこと

  • 段階的な移行として、旧DBとAuroraの同期が完了後、読み込みだけAuroraにする
    • 確かにその方が安全性が高そう
  • stageだけ先にAuroraに移行して検証する
    • その際に移行にかかる時間を計測しておくと、ダウンタイムが予測しやすくなる
  • 失敗時の切り戻しプランを用意する
  • 書き込みの切替時には、旧masterからの書き込みトラフィックを遮断する
    • セキュリティグループで対象のボートを閉じるのが簡単そう
  • カスタムエンドポイントで、バッチや検証用DBなど高負荷のreadが発生するトラフィックと、webサービスが使用するリードレプリカを分ける
  • 旧DBとAuroraのタイムゾーンをあわせる
  • Auroraのフェイルオーバー時のコネクションプーリング対策

その他

  • 現在は、Aurora(MySQL5.7)があり、Performance Insightsもサポートされている

各社の移行事例

BASEのメインDBをAurora(MySQL)に移行しました - BASE開発チームブログ

  • 一番最新っぽい事例

記事執筆時期

2018/11月

移行内容

  • RDS(MySQL5.6) -> Aurora(MySQL5.6)

移行理由

  • 運用負荷の削減
    • MySQL on EC2の方が多機能だがスキルのあるエンジニアを貼り付ける必要がある
    • MySQLの新機能と、RDSのスループットのトレードオフ
    • ベンダーロックインというリスク
  • 速度
    • レプリカラグが発生しない
    • クエリキャッシュが有用
    • スループットの向上
  • 費用(分析、集計用DBをリードレプリカに移行できたため
  • その他Auroraの機能
    • カスタムエンドポイント(分析用レプリカを運用していた
    • 無停止パッチ(運用コスト削減
    • Performance Insights
    • 監査ログ
    • 高速クローン

移行方法

  • 既存環境からAuroraのMasterにレプリケーション
    • テンポラリの書き込み可能MySQLレプリカを間に挟んでいる

サービスに影響しない書き込み可能レプリカを入れることで、「mysql.rds_stop_replication」と「mysql.rds_start_replication」コマンドにてレプリケーションを操作し、レプリケーションを止めている間にテンポラリに対して巨大テーブルへのALTER文等を実施して事前にAuroraのテーブル定義をカスタマイズできます。弊社で言えば大きめのテーブルへのインデックス追加はこのやり方で実施しておきました。row_formatをDynamicに書き換えておきたい場合などはこの方法で実施すれば夜間メンテなどで長い時間サービスを停止する必要なく実施できます。

  • CNAME内のエンドポイント情報を全てAurora側に向けることで移行

移行結果

  • リードレプリカのタイムラグが減った

特記事項

  • Aurora Serverlessの検討
    • インスタンス用パラメータグループにあるinnodb_file_formatでbarracuda指定ができないので見送り
    • barracudaはファイルを圧縮して、IOスループットを上げるオプション
  • MySQLのバージョン
  • テーブル圧縮はコマンドが通るけど実際には圧縮されないので気付きにくいらしい

MySQLからPostgreSQLへの移行とDBリファクタリング/postgresqlJapan2018 - Speaker Deck

記事執筆時期

2018/11月

移行内容

Aurora(MySQL) -> Aurora(PostgreSQL)

移行理由

RDBのリファクタリング

  • PostgreSQLへの移行理由
    • トリガーを柔軟に定義できる
    • トリガーに指定するユーザー定義関数の言語が複数選択できる

移行方法

  • Amazon DMSを使用
    • レプリケーションのタイミングでDBトリガーを発動し、リファクタリングしたテーブルに合わせた内容にデータを加工している
  • APIサービスを新たに立ててDBへのアクセスをAPIにwrap
    • API内で、徐々に新DBに移行

特記事項

  • 移行失敗の監視
    • Mackerelのチェックプラグインを使用
    • エラーログを監視して何かあったら通知
    • CloudWatchでできそうな...?

RDS for MySQLからAuroraへの移行 〜Auroraリードレプリカを利用した低コスト移行方式〜 - コネヒト開発者ブログ

記事執筆時期

2018/8月

移行内容

  • RDS(MySQL5.6) -> Aurora(MySQL5.6)

移行理由

  • 可用性を担保しながら、コストメリットが享受できる
  • 運用面のメリットを享受したかった

移行方法

Aurora リードレプリカ -> masterへ昇格

  • Auroraリードレプリカを本番の読み取りトラフィックにカナリアリリース
  • ステージング環境を、Aurora構成に切替
  • 本番の読み取りトラフィックを100%Aurora化
  • サービス用途以外のレプリカDBを、Auroraをマスターとするbinlogレプリにて作成
  • 書込トラフィックのAuroraへの切替
    • 書き込みトラフィックを遮断

      切替時の書込データロストを防ぐ為の書込トラフィック遮断 RDSマスタをリードオンリーモードにするのが正攻法なところですが、SecurityGroupを使い、L4レイヤでMySQLへの通信を遮断する方法を選択しました。

    • 最終書込のAuroraへのレプリケーション確認
    • Auroraマスター昇格
    • 書込トラフィックをAuroraへ切替

特記事項

  • 書き込み切替のダウンタイムは3分強
  • 「複数のリーダエンドポイントを設けたい」と書かれているが、現在はカスタムエンドポイントで対応可能

Aurora リードレプリカを使用した PostgreSQL から Aurora への移行 - TerraSkyBase

記事執筆時期

2018/8月

移行内容

RDS(PostgreSQL) -> Aurora(PostgreSQL)

移行理由

なし。検証

移行方法

Aurora リードレプリカ -> masterへ昇格

  • Aurora リードレプリカの作成
    • RDSのリードレプリカとして設定する
  • 同期完了後に昇格
    • ドキュメントでは Aurora リードレプリカのレプリカラグを"0" にするとあるが、実質不可能なので、トランザクションを停止させてから昇格した
  • DB クラスターロールが、「レプリカ」から「マスターになる」

雑感

EC2上のMySQLからAuroraへの移行作業で失敗・想定外だったこと - シンクロ・フード エンジニアブログ

記事執筆時期

2018/5月

移行内容

EC2上の MySQL -> Aurora(MySQL)

移行理由

不明

移行方法

自前でAuroraのmasterにレプリケーションを貼る。同期完了後、切替

特記事項

  • Aurora→外側のMySQLサーバという向きではレプリケーションがSSL通信できない
    • 別リージョンのMySQLサーバにバックアップを取っていた
    • 結局クロスリージョンレプリカを使用
  • 移行前のMySQLサーバと、移行予定のAuroraサーバのTimezoneがズレていることにより、移行当日のデータ差分チェックで差分が発生
  • フェイルオーバー後、クライアント側のコネクションプーリングが、新リードレプリカをmasterと誤認する
    • rails側でコネクションプーリングを定期的にリセットするように設定したらしい

RDS for MySQL5.7 から Aurora（MySQL 5.6 互換）へ移行しました - Feedforce Developer Blog

  • へいしゃblog

記事執筆時期

2017/10月

移行内容

RDS(MySQL5.7) -> Aurora(MySQL5.6)

  • 当時はMySQL5.7未サポート

移行理由

ストレージの自動スケーリング 、耐障害性 という主に運用目線で見たときの強みを評価し、採用しました。

移行方法

既存 DB を RDS へ最小限のダウンタイムで移行することができる AWS Database Migration Service (以下 DMS) を利用して、データ移行を行いました。

  • Auroraを参照する環境を新しく作成して、BuleGreenDeploymentで移行

特記事項

  • MySQL5.6 -> 5.7へのダウングレード
    • 影響範囲の調査が必要だった
    • ROW_FORMAT が変わるので、migrationを用意して、db:migrate した
    • mysql-devel のバージョンを 5.7 から 5.6 にダウンさせる必要があった
  • DMS
    • Terraformでコード化しなかったけど、コード化した方が安全だった
    • null 制約 や AUTO_INCREMENT 属性といった情報は移行されないので、mysqldump でテーブル定義だけ先にdumpした
    • 外部キーが設定されたテーブルのデータ移行が失敗することがあるので、追加の接続属性 に initstmt=SET FOREIGN_KEY_CHECKS=0 を追加
  • 所要時間の把握が不足していた。事前にリハーサルを行って把握しておくべき

【ヒカラボ】RDS for MySQL → Aurora

記事執筆時期

2016年1月

  • AmazonDMSリリース前

移行内容

RDS(MySQL5.6) -> Aurora

移行理由

  • パフォーマンスの向上
  • メンテナンスの削減
  • 負荷対策(リードレプリカ15台)
  • コスト削減

移行方法

RDSのリードレプリカからスナップショットを作成後、RDS->Auroraにレプリケーションを貼る

  • その後、参照系、更新系と、Auroraに移行
  • 移行後、切り戻しができるように、逆方向にレプリケーションを貼り直した

移行結果

  • パフォーマンスは目立つほど向上していない
  • インスタンス作成時間が短縮された

特記事項

  • writerインスタンスを再起動すると、フェイルオーバーが発生することがある
  • 昇格を前提にした設計に変更した
    • インスタンス名を昇格を前提にした名前に変更した
      • db-master db-slave01.. を instance001, instance002... )
    • readerとwriterのセキュリティグループを統一

その他の移行事例