Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Nice to meet you Aurora!!

C61c4df7cb3f2da2b4a7e7fe08bca7e1?s=47 guitarrapc
November 10, 2015

Nice to meet you Aurora!!

Amazon Aurora 東京ローンチイベント 10/Nov/2015 発表資料

- RDS for MySQL から Aurora への移行に関する共有

事前に読んでおくべき資料
- Amazon re:Invent (DAT405) Amazon Aurora Deep Dive
http://www.slideshare.net/AmazonWebServices/dat405-amazon-aurora-deep-dive

- AWS Black Belt Tech Webinar シリーズ 2015 - Amazon Aurora
http://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-tech-2015-amazon-aurora

- RDS for AuroraとRDS for MySQL5.6のParameter Groupsの違いをみてみた
http://qiita.com/con_mame/items/1d10c87554920a71f501

- Amazon Aurora DB クラスターへのデータの移行
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Aurora.Migrate.html

- わずかなダウンタイムでの Amazon RDS MySQL または MariaDB DB インスタンスへのデータのインポート
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/MySQL.Procedural.Importing.NonRDSRepl.html

C61c4df7cb3f2da2b4a7e7fe08bca7e1?s=128

guitarrapc

November 10, 2015
Tweet

Transcript

  1. Nov-10/2015 Aurora Tokyo Launch Event @guitarrapc_tech

  2. @Job @Private http://tech.guitarrapc.com @guitarrapc_tech

  3. 目的 ゴール

  4. https://speakerdeck.com/guitarrapc/nice-to-meet-you-aurora

  5. None
  6. Environment Before RDS for MySQL MultiAZ + Read Replica r3.4xlarge

    After Amazon Aurora 2 node (1 writer / 1 reader) r3.4xlarge
  7. Measure Response Time New Relic Application, Database, Redis, External の監視、通知

    > データベース処理の所要時間が一目瞭然 BigQuery アプリケーションが発行したクエリを全て計測 > 同一クエリのAurora による変化を調査可能
  8. Before : RDS for MySQL Total Database Response : 15

    ~ 22 ms (時間帯によって前後)
  9. After : Amazon Aurora Total Database Response : 5.5 ms

    (Very Stable)
  10. Aurora 3x faster than MySQL (Total)

  11. Cheese became thinned!

  12. Improve UPDATE query (3-5x faster)

  13. What kind of Database operation has changed?

  14. Query Average duration

  15. Select : 1x about same

  16. Update : 5x+ faster

  17. Insert : 2x+ faster

  18. Delete : 0.8x slower

  19. What could be affected to query result?

  20. Architecture Improvement : MultiAZ RDS for MySQL w/ MultiAZ 同期待ち遅延の解消

    MultiAZ のスタンバイ側とAZ間の同期待ち時間がAuroraで改善
  21. Architecture Improvement : Commit 非同期グループコミットの採用 コミットキューを非同期に書き込み 4 / 6 のストレージノードACK応答で成功判定

  22. Architecture Improvement : Other スレッドプールの改善、ロックハンドリングの改善 多くの要素が改善されて、特にUPDATE / INSERT に大きく寄与している

  23. None
  24. First of all, must read 移行のすべてはここに Amazon Aurora DB クラスターへのデータの移行

    http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Aurora.Migrate.html Amazon Aurora とのレプリケーション http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Aurora.Replication.html
  25. 2 scenario for Aurora Migration Snapshot Migration 考慮点が圧倒的に少ないのでオススメ Replication Migration

    DBサイズ > 500GB ~ 1TB の場合の現実案はコレ 移行方法 AWS 推奨 移行ダウンタイムの極小化 手間 スナップショット O △ O レプリケーション △ O X
  26. Confirm before Migration Aurora only supports InnoDB - SQL_Mode は

    0に(レプリケーション移行のみ / スナップショットでは不要) 以下の条件が満たされるとDBエンジンの自動変換ができず、Create T able時に問題が起こる 条件1. sql_mode にNO_ENGINE_SUBSTITUTION が設定されている 条件2. InnoDB 以外のストレージエンジンを使用している - InnoDB しかないことを確認(事前にInnoDB への変換がオススメ) Check Usage Size (MyISAM形式のテーブルがあると注意) MyISAM無 : 移行前ディスクで 6TBまでok MyISAM有 : マイグレーションを行うテーブルに3TB超がないように!
  27. Snapshot Migration Actual : 120GB : db.r3.4xlarge マイグレーション所要時間: 01:37h レプリカ作成所要時間

    : 00:06h 時間 作業 00:00 サービスの停止(DBアクセス停止) 00:00 SnapShot 開始 00:11 SnapShot 完了 / Aurora 作成開始 01:37 Aurora作成完了 01:38 ReadReaplica作成開始 01:44 ReadReaplica作成完了
  28. Snapshot Migration is depend on size 時間 作業 00:00 サービスの停止(DBアクセス停止)

    00:00 SnapShot 開始 00:39 SnapShot 完了 / Aurora 作成開始 10:42 Aurora作成完了 10:43 ReadReaplica作成開始 10:49 ReadReaplica作成完了 Actual : 1100GB : db.r3.8xlarge マイグレーション所要時間: 10:42h レプリカ作成所要時間 : 00:06h
  29. Required Short downtime migration? Use “Replication Migration”

  30. Replication Migration Summary Master(MySQL) / Replica(MySQL) / Replica(Aurora)の関係性 RDS Master

    RDS Replica (MySQL) (A) RDS Replica (Aurora) (B) 1. MySQLレプリカ(A) RDS Master Aurora (B) 3. Aurora(B) Replica(A)
  31. Replication Migration : Minimize downtime 実測値 : 1100GB : db.r3.8xlarge

    マイグレーション所要時間 : 10:42h レプリケーションの完了 : 00:30h 時間 作業 00:00 SnapShot 開始 00:39 SnapShot 完了 / Aurora 作成開始 10:42 Aurora作成完了 11:00 サービスの停止(DBアクセス停止) 11:30 レプリカラグの解消、アプリ動作確認 11:30 ReadReaplica作成開始 11:36 ReadReaplica作成完了
  32. Attention while Replication migration Read Replica のレプリケーション停止中のMaster Freeable Memory bin

    log が溜まる分だけ、Master の Freeable Memory が消費 時々、Replicaを繋いで bin log を自動削除させる or 移行タイミングを調整
  33. Replication Migration SQL rds_set_external_master プロシージャの設定 - bin logの名前と場所 : 同期停止しているReadReplicaから取得

    - set_external_master先のRDS : Master インスタンス (多段構成ではない) CALL mysql.rds_set_external_master (‘マイグレーション対象のMySQLマスターインスタンス', 3306, ‘replユーザー名’, ‘replパスワード', 'mysql-bin-changelog.xxxx', 400, 0); CALL mysql.rds_start_replication;
  34. None
  35. Cluster & DB Parameters Aurora Default を使うのが AWS 推奨 Cloud

    Formationの適用は時間がかかるので注意 デフォルトの接続周りのパラメータが小さく設定されている Query Cache は Write heavy な環境 なら 0 (OFF) にしたほうがいい? max_connections や thread_cache_size が小さくなってるので注意 inno_db_io_capacity | max は、Aurora 任せのため変更できない 2015/11 Query Cache を全台有効に。 有効でも遅延がないことを確認
  36. Security Group apply to Cluster DBインスタンス単位からクラスター単位に変更 弊社ではDBインスタンス毎の接続制御に使っていたため制御方法変更 やりたいこと オフィスから本番レプリカへのアクセスを接続可能に 外部サービスは本番レプリカは接続許可(本番マスターは拒否)

    開発環境から本番マスターはつなげさせたくない フェイルオーバーしても状態を維持できるようにしたい ⇒ Public Accessible + Route Table による制御に変更 開発効率化 分析 事故の防止 可用性維持
  37. VPC contents Account B (10.x.0.0/16) Internet VPN connection VPC contents

    route table Aurora Writer Aurora Reader ap-north-east1a ap-north-east1c DB Cluster Account A (10.x.0.0/16) Internet gateway ADDNS Security Group cannot be apply individual
  38. Route table approach Route Table による外部接続可否の制御 本番マスター : IGW とつながらない

    Private Route Table にAZアサイン 本番レプリカ : IGW とつながった Public Route Table にAZアサイン ルーティング時点で接続を制御することでマスター接続を遮断 フェールオーバーを検知してRouteTable をオンラインで自動切替 Security Group によるアクセス制御 接続元が同一VPCなら、Private IP でのアクセス制御が適用 接続元がVPC外なら、Public IP でのアクセス制御が適用
  39. VPC contents Account B (10.x.0.0/16) Internet VPN connection VPC contents

    route table Aurora Writer Aurora Reader ap-north-east1a ap-north-east1c DB Cluster Account A (10.x.0.0/16) Internet gateway ADDNS route table route table Handle connection with Route Table
  40. High CPU / Memory / QueueDepth RDS for MySQL :

    60%超えから著しい性能劣化 Connection 拒否 や サービスの停止 へのコンボになったことも :( Aurora : 100% 近くになっても性能劣化も小さく動作し続ける 同程度のクエリを十分に捌く + 応答速度改善 これまでMySQL で性能劣化が著しかった60%を超えても堅調に動作 CPU が高めの理由の一つは、6コピーを常に作成していることにもある
  41. tmp_dir depends on Instance Size tmp_dirが指定できない + 容量はインスタンスサイズに依存 大きなデータベースに対して、大きなtemporary tableを作成するような処理

    を行う場合に tmp_dir の容量がボトルネックになる可能性が。 http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/InstanceStorage.html#instance-store-volumes
  42. None
  43. Primary Failover Order Failover 先のレプリカ指定はまだ未実装 (2016/3/15 にリリース済) http://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-tech-2015-amazon-aurora https://aws.amazon.com/jp/blogs/aws/additional-failover-control-for-amazon-aurora/

  44. Cache Purge 任意でキャッシュのパージを実行することはできない

  45. Connection Handling RDS for MySQL 5.6 に比べて、同時に4000 conn~8000 conn 張った

    時の耐久性は弱い CPU が 100% から落ちてこない (コネクションが詰まってしまっている) Failover でインスタンスを強制的に切り替えざるを得なくなる Aurora Team には報告済み ~2000 conn なら問題ない コネクションの張り方をソフトになるようにしている
  46. None
  47. Aurora will help your business 特にMultiAZ を利用している場合にパフォーマンス効果発揮 MultiAZ でのノード構成数が2/3 に!

    (MultiAZ + ReadReplica の場合) 処理性能向上によるDBインスタンスの統合も視野に! レプリケーションのほぼリアルタイム化によって処理分散が容易に 耐障害性の向上による機会損失の低減 ストレージレイヤの改善によるストレージ障害減少 フェールオーバーの高速化、ストレージ障害復旧も高速化
  48. Don’t miss cost reduction! 性能向上によるDB 統合でノード削減も期待できる 弊社の場合、DB統合も行い 年間 2200万円超 のコスト削減効果

    RDS (db.r3.4xlarge / gp2 / OnDemand) Hourly Daily Yearly RDS for MySQL(MultiAZ + 1 ReadReplica) $4.54 + $2.27 = $6.81 $163.44 $59,655.60 Aurora (+ 1 Replica) $2.8 * 2 = $5.6 $134.40 $49,056.00 削減効果 ▲$1.21 ▲$29.04 ▲$10599.6
  49. Aurora makes you happy :)