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

Amazon RDS移行のための 性能検証でわかった2つのこと

Amazon RDS移行のための 性能検証でわかった2つのこと

日本MySQLユーザ会(MyNA会) 2021年07月 -下位レイヤ勉強会- での発表資料です。

676954675cda206b7baae939a82a8ef4?s=128

Kenichi Takahashi

July 09, 2021
Tweet

Transcript

  1. Amazon RDS移行のための 性能検証でわかった2つのこと 髙橋 健一 @kenchan / GMO PEPABO inc.

    2021.07.09 MyNA会 2021年07月 1
  2. 2 自己紹介 GMOペパボ EC事業部 シニアエンジニアリングリード 髙橋 健一 @kenchan • RubyとAgileなソフトウェア開発が好きなソフト

    ウェアエンジニア • https://twitter.com/kenchan • https://diary.shu-cream.net • 最近はGUILTY GEAR -STRIVE-で9層と10層 を行ったり来たりしてます
  3. 3 今日のお品書き GMOペパボが運営するとあるサービスのMySQLをAmazon RDSに移行するために行った性能検証を通してわかったことや気 になった点を紹介する事例発表です。 トピックは2つでAmazon RDS for MySQLでのファーストタッチペ ナルティの解除方法と、Multi-AZ環境でのシングルスレッドの書

    き込み性能限界についてです。 ※本発表に登場するMySQLは全て5.6系です
  4. 4 今日のお品書き 1. 移行対象のデータベースの規模やスペック 2. 今回の移行計画のさわり 3. わかったこと1: ファーストタッチペナルティの解除方法は2つ 4.

    わかったこと2: Multi-AZではシングルスレッドのIO性能に限界がありそう 5. まとめ
  5. 5 移行対象のデータベースの規模やスペック • Primary * 1 • Intel Xeon 24コア

    • SSD 1.4TB • memory 240GB • Replica * 4 • Intel Core Processor 24~48コア • NVMe 1.4TB • memory 240~365GB • 用途によってスペックの差異有り GMOペパボが運営するとあるWebサービスのメインDB
  6. 6 今回の移行計画のさわり • 現行のDBから多段レプリケーションを組んで段階的に移行する • レプリケーション遅延を計測することで書き込み性能を確認できる • Read Replicaを独立して切り替えることができるので読み込み性能を確認できる •

    サービス停止をPrimary切り替えの時間だけにすることができる AWS Direct Connectを利用した多段レプリケーションを利用した移行
  7. 7 今日のお品書き 1. 移行対象のデータベースの規模やスペック 2. 今回の移行計画のさわり 3. わかったこと1: ファーストタッチペナルティの解除方法は2つ 4.

    わかったこと2: Multi-AZではシングルスレッドのIO性能に限界がありそう 5. まとめ
  8. 8 わかったこと1: ファーストタッチペナルティの解除方法は 2つ • Amazon RDSのデータボリュームはEBSの技術を使っているため、バックアップから復元し たときに発生する • EBSのバックアップはS3に行われていて、S3から復元されたEBSは初回のデータアクセスで

    初めてS3からデータがロードされる挙動になる • 性能検証前に必ず解除しなければ意味のあるデータがとれない 皆さんご存知ファーストタッチペナルティ
  9. 9 わかったこと1: ファーストタッチペナルティの解除方法は 2つ • ディスクの全ての領域に一度触ることが必要 • EC2ではddで書き込むなどの方法がある • 「全て」

    is 何 • RDS for MySQLではプライマリインデックスと セカンダリインデックス ファーストタッチペナルティを解除するためには(1) mysql -sse "SELECT distinct table_name, index_name FROM information_schema.statistics WHERE table_schema = 'YOUR_DATABASE_NAME'" | while read table index ; do mysql -sse "SELECT count(*) FROM $table FORCE INDEX($index)" YOUR_DATABASE_NAME > /dev/null & done https://diary.shu-cream.net/2021/04/02/RDS%20for%20MySQLのファーストタッチペナルティを解除する 3ライナー.html
  10. 10 わかったこと1: ファーストタッチペナルティの解除方法は 2つ • ディスクの全ての領域に一度触ることが必要 • ストレージタイプの変更は強制的にディスク全体を読み込むことになる • io1で運用するなら、まずは

    gp2で復元してからストレージタイプを変更することで全てのデータ を読み込むことになり、ファーストタッチペナルティを解除できる • クエリでの解除とストレージタイプの変更、両方の時間を計測するとよいかも ファーストタッチペナルティを解除するためには(2)
  11. 11 わかったこと1: ファーストタッチペナルティの解除方法は 2つ • Amazon RDSではEBSの技術を使っているためにバックアップから復元した直後は十分な IO性能が出ない • ファーストタッチペナルティを解除するには全てのデータ領域を触ることが必要

    • RDS for MySQLではプライマリとセカンダリ両方のインデックスを触る必要がある • ストレージタイプの変更でもファーストタッチペナルティの解除ができる ファーストタッチペナルティについてわかったこと
  12. 12 今日のお品書き 1. 移行対象のデータベースの規模やスペック 2. 今回の移行計画のさわり 3. わかったこと1: ファーストタッチペナルティの解除方法は2つ 4.

    わかったこと2: Multi-AZではシングルスレッドのIO性能に限界がありそう 5. まとめ
  13. 13 わかったこと2: Multi-AZではシングルスレッドのIO性能に限界がありそう • 現行Primary -> 現行Replica -> RDS Primary

    -> RDS Replicaという多段レプリケーショ ンを組んでいる • RDS Primaryは可用性確保のためにMulti-AZにしたい 今回の移行計画をあらためて確認 Multi-AZに なりたい!
  14. 14 わかったこと2: Multi-AZではシングルスレッドのIO性能に限界がありそう • RDSのPrimaryをMulti-AZにするとレプリケーション遅延が増加し続ける • Single-AZでは期待するIO性能がでてレプリケーション遅延は発生しない • 書き込みIOPSのグラフをみると明らかに頭打ちしている •

    ストレージタイプを変えても同じことがおきる Multi-AZにしたRDS PrimaryのWrite IOPSが頭打ちする問題(1)
  15. 15 わかったこと2: Multi-AZではシングルスレッドのIO性能に限界がありそう Multi-AZにしたRDS PrimaryのWrite IOPSが頭打ちする問題(2) Single-AZ Single-AZ Multi-AZ

  16. 16 わかったこと2: Multi-AZではシングルスレッドのIO性能に限界がありそう • 監査用に取得しているクエリログを使った負荷試験では 問題が起きなかった Multi-AZにしたRDS PrimaryのWrite IOPSが頭打ちする問題(3)

  17. 17 わかったこと2: Multi-AZではシングルスレッドのIO性能に限界がありそう • 起きている現象のまとめ • Multi-AZのRDS Primaryに多段レプリケーションを組むと IO性能が出ずにレプリケーション遅 延が起きる

    • Single-AZのRDS Primaryでは期待するIO性能がでる • Multi-AZでも負荷試験では性能が出ているように見える • レプリケーションと負荷検証の違いは MySQLの書き込みスレッド数 • レプリケーションの書き込みは 1スレッドで行われる • 負荷試験は並列にクエリを流すので複数スレッドで書き込みが行われる • Multi-AZ環境では1スレッドあたりの書き込み性能に限界がある? なぜMulti-AZにしたRDS PrimaryのWrite IOPSが頭打ちするのかの仮説
  18. 18 わかったこと2: Multi-AZではシングルスレッドのIO性能に限界がありそう • AWSサポートにも協力してもらったが、検証期間中に原因を解明できなかった • メンテ時間前はSingle-AZにして、メンテ中にMulti-AZへの変換を行うように計画を変更し た Multi-AZにしたRDS PrimaryのWrite

    IOPSが頭打ちする問題をどう解決したか
  19. 19 今日のお品書き 1. 移行対象のデータベースの規模やスペック 2. 今回の移行計画のさわり 3. わかったこと1: ファーストタッチペナルティの解除方法は2つ 4.

    わかったこと2: Multi-AZではシングルスレッドのIO性能に限界がありそう 5. まとめ
  20. 20 まとめ • ファーストタッチペナルティを解除するには全ての領域に触る必要がある • プライマリインデックスとセカンダリインデックスの両方を読み込むこと • ストレージタイプを変更して解除することもできる • Multi-AZではシングルスレッドでの書き込み性能限界があるようにみえる

    • RDS外からレプリケーションを組むときに注意しよう • ストレージタイプに関係なく 500 IOPS前後に限界があるようにみえる • AWSのサポートにも問い合わせたが、検証期間中には原因究明に至らなかった • 具体的な移行プロセスなどの今回紹介できなかった内容はペパボテックブログで公開予定 です!!1 RDS移行のための性能検証でわかったこと・気づいたこと
  21. 21 Thank You! Thank You! 今回の検証は @yoku0825 さんとGMOグローバルサイン ホールディングスの CloudCREWさんに協力いただきました。

    本当にありがとうございました。