RDS MySQL から Aurora への移行

AWS にて RDS MySQL から Aurora への移行した際の流れと注意点について

Transcript

1. JAWS-UG名古屋 RDS MySQL から Aurora への移行 2018.10.17 JAWS-UG 名古屋 / 小林 一樹
2. 自己紹介 氏名 小林 一樹 (こばやし かずしげ) JAWS-UG 名古屋 2018.08 JAWS-UGナイト in AWSome Day 名古屋 から参加。 その日の懇親会で プリン 食べました 🍮 普段の仕事 株式会社スタメン CTO = Ruby on Rails + AWS + (Swift) 好きなAWSサービス CloudWatch、Aurora は 10/14(日) から 😁
3. 発表の内容 • 対象となるシステムの要件 • RDS MySQL を選択した理由 • Aurora 移行を決めた理由 • 移行前後のシステム構成 • リードレプリカを利用した Aurora への移行 • 感想＆まとめ
4. 対象となるシステム • 【TUNAG】エンゲージメント経営コンサルティング • タイムライン、プロフィール、チャット を備えた、フル機能のSNS。株式会社スタメンで自社開発。 • 任意の制度(投稿フォーム)を作ることができる (Google フォーム の高機能版)。
5. システム構成 (概略) • ELB → EC2 (Rails) → RDS MySQL • S3, CloudFront 等のよくある構成 • 事業成長により三ヶ月で倍のトラフィック • BtoBチャットの通知によるクエリが多い • DB がボトルネックになりつつあった
6. 創業時に RDS MySQL を選択した理由 • 2016年6月 のはなし • 開発環境 と 同じ構成に したかった • 慣れている MySQL の安心感があった • 費用をできる限り安く抑えたかった • 周囲から Aurora の 動作実績が少なかった • RDS の フルマネージド な恩恵は本当に嬉しかった • 暗号化、スナップショット、マルチAZ、モニタリング、ログのエクスポート
7. 20180425 AWS Black Belt Online Seminar Amazon Relational Database Service (Amazon RDS) P11 から引用 https://www.slideshare.net/AmazonWebServicesJapan/20180425-aws-black-belt-online-seminar-amazon-relational-database-service-amazon-rds-96509889
8. Amazon Aurora の 特徴 • re:Invent 2014 で 発表された RDS の新しいエンジン。 Amazon が クラウド時代 に 最適化して作った RDBMS。 [Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス https://www.slideshare.net/AmazonWebServicesJapan/auroraamazon-aurora
9. Aurora 移行を決めた理由 • • パフォーマンス要件の向上 運用面の利点 • DB が ボトルネック になりつつあった • フェイルオーバーの短縮 • パフォーマンスとスケーラビリティの両立 • ストレージの自動拡張 Multi-AZ 時の コスト効率 • • • リードアクセス可能なレプリカ 高い互換性と利用実績 • 多くの移行事例 と ドキュメント • Aurora の便利な機能 と 将来性 • クローン作成、Serverless • パフォーマンスインサイト (2018.08 から MySQL に対応)
10. Aurora 移行 と コスト • Aurora クラスターは、コスト効率が良い。 • MySQL Multi-AZ は、スタンバイレプリカは、読み込み (service-in) できない。 • Aurora は、クラスター内の レプリカ に対して、読み込み 可能。 • リードレプリカ が必要な 規模 になると Aurora は コスト効率が良い。 MySQL インスタンス 役割 月間 db.r4.2xlarge Multi-AZ $2.282 $1,698 db.r4.2xlarge レプリカ $1.141 $849 USD $2,547 Aurora インスタンス 役割 月間 db.r4.2xlarge Read/Write $1.400 $1,042 db.r4.2xlarge Read $1.400 $1,042 USD $2,083 ※1: Amazon RDS DB インスタンス » 高可用性 (マルチ AZ) https://docs.aws.amazon.com/ja̲jp/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html ※2: Amazon Aurora のよくある質問 https://aws.amazon.com/jp/rds/aurora/faqs/
11. Aurora DB Cluster • • 最大15個 の Aurora レプリカ を DB クラスター 内に作成可能。 • ストレージが共有されているため、レイテンシが非常に低い • 読み書き と 読み取り専用 の エンドポイントが設定される。 プライマリインスタンス に 障害発生すると 1-2分で レプリカ が昇格する。 • MySQL Multi-AZ より 復旧が 速い。 • 昇格の優先順位を設定可能。 • プライマリインスタンスのみ の場合 復旧に15分程度。 • クエリで耐故性のテストが可能 Amazon Aurora DB クラスターの管理 https://docs.aws.amazon.com/ja̲jp/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html
12. 移行前後の構成 • RDS MySQL Multi-AZ から Aurora Cluster へ。
13. リードレプリカを利用した移行手順 ① RDS MySQL に Aurora レプリカ を作成 Application • MySQL Aurora レプリカ を マルチAZ 配置 で作成し、 Aurora DB クラスター を作成する。 ② Aurora レプリカ を Master へ昇格する • マネジメントコンソールから操作。 • 数分間のダウンタイム。 ③ ① replication ② Aurora DB Cluster ③ アプリケーションの 接続先 を Aurora へ切り替え 参考: Aurora リードレプリカを使用した、MySQL DB インスタンスから Amazon Aurora MySQL DB クラスターへのデータの移行 https://docs.aws.amazon.com/ja̲jp/AmazonRDS/latest/UserGuide/AuroraMySQL.Migrating.RDSMySQL.Replica.html
14. 事前検証 • アプリケーション Application • MySQL からの Replication での Write の検証。 • 検証環境での一通りの機能を用いた Read/Write の検証。 MySQL replication • 移行作業 • 同じ構成の 検証環境で 移行作業を実施して検証。 • 日曜日の未明に移行し、想定外の事態へのリスクヘッジを行う。 Aurora DB Cluster 結果的に、RDS MySQL 5.7 から Aurora 移行に際して、アプリの修正はゼロ
15. 実際の移行: RDS MySQL に Aurora レプリカ を作成 • 移行対象の MySQL インスタンスを選択して、Aurora リードレプリカを作成 • マルチ AZ 配置 にして、Aurora DB Cluster を構成する。
16. 実際の移行: RDS MySQL に Aurora レプリカ を作成 • 異なる AZ に Aurora インスタンス が作成される • Aurora DB Cluster に、Write/Read と Read Only の エンドポイント が設定される
17. 実際の移行: Aurora レプリカ を Master へ昇格する • アプリケーションを終了し、接続先が無くなることを確認。 • Aurora インスタンス の どちらか を 昇格 させる。 数分で マスター に昇格する (本番移行時は3分でした)。 • 昇格後、アプリケーションを再開すれば、Aurora 移行は完了。
18. 移行後の感想 • 非常に高い MySQL 互換性 • • 移行に際してアプリの修正はゼロだった。 レプリカラグが 非常に低いのは嬉しい • • • 平均 15ミリ秒 程度。 Aurora の運用は順調 • Aurora MySQL 5.7互換に 非対応の機能 • パフォーマンスインサイト 😭 • Aurora Serverless 😢 Rails での Read/Write の 分離 は延期 • gem octopus の導入を検討したが、互換性の検証で躓く。 • アプリケーションのDBボトルネックは完全に解消。 • Aurora レプリカの段階的な投入による検証ができなかった。 • Aurora による性能向上の検証はまだしてない。 • レプリカインスタンスを有効活用すべく今後対応予定
19. まとめ • 思ったよりも楽に移行できました。 • • パフォーマンスも良好。 • • Aurora の 高い MySQL 互換性 と フルマネージドな管理機能 のおかげ。 インスタンスをグレードアップしたのも大きい。 今後やりたいこと • Aurora に対応した 最適化 [Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス https://www.slideshare.net/AmazonWebServicesJapan/auroraamazon-aurora • Aurora 向けに先行してリリースされる便利な機能を使っていきたい。 例：現在: Aurora クローン を利用した 検証環境 の 構築 • 任意の時間を指定して、クラスターのクローンを作成できる。 • Copy-On-Write で 高速。 高いコスト効率。