Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

[db tech showcase Tokyo 2015] C27:楽天MySQL Backup Structure by 楽天株式会社 粟田啓介

8.414 Aufrufe

Veröffentlicht am

Database の Backup は運用をする上で最もクリティカルな要素となります。過去、現在の Database Backup方法、そして今後のPlatform構想について楽天のMySQL Database の規模感を交えてお話させていただきます。

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

[db tech showcase Tokyo 2015] C27:楽天MySQL Backup Structure by 楽天株式会社 粟田啓介

  1. 1. 楽天MySQL Backup Structure ~ 過去、現在、そして未来へ~ Keisuke.Awata (keisuke.awata@rakuten.com) Data Store Administration Group Infrastructure Administration Section Global Infrastructure Development Department
  2. 2. 2 Self Introduction
  3. 3. 3 自己紹介  職歴  2007年4月 楽天株式会社へ新卒入社 • 2007年8月 - 2012年6月 AD Platform を開発/運用するアプリケーションエンジニア • 2011年5月 - 2012年5月 サーバー設計エンジニアを兼務 • 2012年6月 - 現在 DBA - Review・Bookmarkなどの ソーシャルプラットフォーム - 広告、アフィリエイトなどのマーケティングプラットフォーム - Oracle以外のID、Point、Coupon などの会員情報プラットフォーム - 社内ツール系
  4. 4. 4 楽天のDatabase
  5. 5. 5 RDBMS 会員データ、ポイントデータ、商品データといった特 にミッションクリティカルなデータが格納 巨大DBMS環境。非常に昔から使用している。 購買データなどクリティカルなデータが格納。 古くから有るが故複雑な依存 楽天のメインRDBMS。 ミッションクリティカルなデータから、 社内サービスまで幅広く使用 Informix Oracle Clustrix PostgreSQL
  6. 6. 6 楽天のデータベースの規模感 71.90% 7.54% 7.36% 11.56% 1.64% # of Server (%) MySQL Clustrix Informix Oracle PostgreSQL # of MySQL DB Total Size 3500 + 100TB +
  7. 7. 7 楽天のDatabase Architecture  時代とともに構成は変わってきた  VCS 構成(Active-Standby on SAN)  VCS + Replication  VCS + Shard  IA Server + SSD  Private Cloud  詳細は前回の db tech showcase の資料をご覧ください [楽天] 詳説 楽天のデータベースアーキテクチャ史 -シングルノードから仮想化フラッシュストレージへ
  8. 8. 8 VCS 時代 ~ IA+SSD 時代初期  サービスの安定稼動  コンポーネントを共用  職人的DBAの全盛期  サービスの基盤を支えていた実績  細かなレビューとチェック項目
  9. 9. 9  スピードや柔軟性  古典的なチケットシステム  膨大な量のレビューとチェック項目 VCS 時代 ~ IA+SSD 時代初期 迅速かつ多様な要望に応える必要性  追い討ちをかけるように  アジャイルプロジェクトの増加  MongoDB/Redis 等の NoSQL の台頭  クラウドサービスの多様化  増強  増強 = HW購入  EOSLタイミングが同じサーバ達
  10. 10. 10 ターニングポイント  DC 移設プロジェクト  DCの移設に伴い 250以上のDBを9ヶ月で Private Cloud へ移設  主に既存DBに新DBをレプリケーションさせて切り替え  BackupからのRestoreする方式  アーカイブからのリストア  時間がかかる  あるある失敗談  レプリケーション元サーバに binlogなかった  binlog転送によりネットワークを逼迫  SJIS Database の存在  新しいDCに建てるサーバはグローバル化に伴い UTF8 に統一  レプリケーション方式は使えない
  11. 11. 11 Migration Tool  CLI Base の Migration Tool  dump → import → Change Master  dump → import のパラレル実行  thread を分けてdump 実行  encode (SJISの場合)  import 期限内に全てのDB移設を完了!
  12. 12. 12 # of VMs in Private Cloud
  13. 13. 13 楽天 MySQL DB Tools
  14. 14. 14 Private Cloudの急激な成長  管理するDatabase数も比例して増加  現在の私たちのグループのDBAは5人  担当するサーバーは本番だけで600台弱  毎月30台ペースでDBサーバが構築されていく
  15. 15. 15 DBA の仕事の変化  DB管理の責任範囲  全てのサービスを同じレベルで見ることはもはや不可能に近い状況  だからエンジニアが  知りたい  やりたい ことを自分たちで出来るようなWeb インターフェースを隙間時間で自作 本当にサポートが必要なサービスに目を向けるための基盤作り
  16. 16. 16 Status Monitoring
  17. 17. 17 Deploy
  18. 18. 18 Operation
  19. 19. 19 FAQ Portal
  20. 20. 20 Cloud化による仕事の変化
  21. 21. 21 楽天DBAを取り巻く環境は年々変わってきている  仕事の仕方も変化せざるを得ない  トップダウンの決定だけで変化しているわけではない!  現場のDBAのアクションで  自分たちが主導になり  新しいことを取り入れることが出来る環境はある  失敗してもいい、という気持ちが大切 やるかやらないかは自分次第!
  22. 22. 22 楽天の MySQL Database の Backup/Restore 方式
  23. 23. 23 DB Restore タイミング  Point in time recovery  年に一度、あるかないか  実際は障害訓練でやる程度  移設増強タイミング  restore したデータを利用してレプリケーション設定  検証/調査  定期メンテナンス  DBAタスク時間見積もり  オペレーション確認  アプリエンジニアからの過去データ調査依頼  前日トラブルがあり、データを確認したい  本番データを用いたアプリケーションテストのため  結合テスト  負荷テスト
  24. 24. 24 楽天 の Database Backup方法 Database Architecture 主なBackup 方法 VCS 構成 SAN SnapshotVCS + Replication VCS + Shard IA Server + SSD mylvmbackup Private Cloud Veeam その他 mysqldump mysqlhotcopy file copy
  25. 25. 25 SAN Snapshot によるBackup DB Server1 DB Active Mirror DB Volume DB Volume Backup NFS NAS Compress Backup Server 1.Mirror Volume へ Backup Serverから mount 2.DB Lock mysql>FLUSH TABLE WITH READ LOCK 3.Active から Mirror へ 再同期 4.Active と Mirrorを切り離し 5.DB Unlock mysql>UNLOCK TABLES 6.Mirror Volumeをマウント 7.BackupNFSをマウント 8.バックアップ領域へtar archive作成 9.Mirror Volumeをアンマウント DB Server2 DB
  26. 26. 26 mylvmbackup による Backup DB Server DB OS Volume DB Volume Backup Volume Backup NFS NASCompress File 1.DBロック取得 mysql>FLUSH TABLE WITH READ LOCK 2.バックアップ時のポジション取得 mysql>SHOW SLAVE STATUS mysql>SHOW MASTER STATUS 3.スナップショット取得 lvcreate -s -l 100%FREE --name=#{db_backup} #{Volname} 4.DBロック開放 mysql>UNLOCK TABLES 5.スナップショット領域をマウント 6.バックアップ領域へtar archive作成 7.スナップショット領域をアンマウント 8.スナップショット領域の使用サイズ確認 lvdisplay #{LVName} 9.スナップショット領域を開放 lvremove -f #{LVName}
  27. 27. 27 SAN Snapshot / mylvmbackup の Restore Backup NFS NAS DB Server DB Local disk に余裕がある場合 1.Backup NFS を mount 2.tar archive ファイルを Local へ Copy 3.tar archive ファイルの 展開 Local disk に余裕がない場合 1.Backup NFS を mount 2.tar archive ファイルをNAS上で展開 Compress File DB  Restore 先は 共有環境 or NFS  tar 展開に非常に時間がかかる  特に定期メンテナンスの前になるとリソースの取り合い  ディスクだけでなくメモリ含め  性能は本番環境に比べて著しく低い
  28. 28. 28 Veeam によるBackup VirtualAPP Veeam Management Server 1.DBロック取得 mysql>FLUSH TABLE WITH READ LOCK 2.バックアップ時のポジション取得 mysql>SHOW SLAVE STATUS mysql>SHOW MASTER STATUS 3.VMスナップショット取得 4.DBロック開放 mysql>UNLOCK TABLES 5.Backupファイル作成 Backup NFS NAS  VMWareに特化した仮想バックアップソフト  フル/増分(差分)バックアップ、重複排除により効率的なバックアップ  現在の楽天のバックアップの主流  本番への影響はSnapshotを取得する数秒のみ
  29. 29. 29 Veeam Restore  Windows GUI ベースのオペレーション  Restoreしたい日付を選んでいくつかの項目を選択  VM 設定全て引き継いでいる  Restore 後 Network 設定等 OS オペレーション Traget DB Server DB Restored DB Server DB
  30. 30. 30 Restore の改善  Backup Restore の過去、現在  SAN Snapshot / mylvmbackup  Restore 先は 共有環境 or NFS  tar 展開に非常に時間がかかる  特に定期メンテナンスの前になるとリソースの取り合い  ディスクだけでなくメモリ含め  性能は本番環境に比べて著しく低い  Veeam  Restore 先は Private Cloud 環境  用途によって性能環境を分けられる  負荷試験環境 => 本番と同じストレージ(FC/SSD)  データ確認用 => 性能を求めない安いストレージ  Restore にやや時間がかかる  展開先のストレージによる  SSDなら30分、FCなら2時間 など
  31. 31. 31 Next Backup Platform
  32. 32. 32 Veeam Backup  VeeamによるBackupの問題点  License Fee  日に日にDBサーバが増えていく現状ではコストが上がる一方  VMware 依存  Platform は時代とともに変わってくる  VCS → IA + SSD → VMware → Next!  運用管理  台数が多くなるにつれてGUI処理が重くなっている  Restore Operation の危険性  既存で動いているサーバにバックアップを上書き  既存で動いているIPアドレスをそのまま別のサーバで使用 など危険な操作が出来てしまう → VMと社内ネットワークに対する最低限の理解が必要
  33. 33. 33 新しいBackup システムの導入検討  要件  Platformとして提供  数百台のサーバのBackup管理  アプリケーションエンジニアでも  「いつでも」  「かんたんに」 リストアできるサービス  中央管理が出来ること  Backup Script は DBサーバ自体に配置  インストールが簡単であること  Jobをコントロールするのは別のアプリケーション  履歴管理ができること  スケジュールの登録/変更が簡単であること  候補  Xtrabackup  MySQL Enterprise Backup
  34. 34. 34 構成図イメージ ? ?
  35. 35. 35 Xtrabackup VS MySQL Enterprise Backup  検証方法  tpcc を利用した ベンチマークにより検証  様々なトランザクションを並列実行した結果を見るため  3回ずつ実行し中間の値を取得
  36. 36. 36 base command Test Scenario Command Full Backup Only Xtra innobackupex --defaults-file=${my.cnf Path} --user=${USER} -- password=${PASSWORD} ${Backup Path} EP mysqlbackup --defaults-file=${my.cnf Path} --user=${USER} -- password=${PASSWORD} --backup-dir=${Backup Path} backup Full Backup + Compress Xtra innobackupex --defaults-file=${my.cnf Path} --user=${USER} -- password=${PASSWORD} --compress ${Backup Path} EP mysqlbackup --defaults-file=${my.cnf Path} --user=${USER} -- password=${PASSWORD} --compress --backup-dir=${Backup Path} backup Compress + process thread 2 + Full Backup Xtra innobackupex --defaults-file=${my.cnf Path} --user=${USER} -- password=${PASSWORD} --compress --parallel=2 ${Backup Path} EP mysqlbackup --defaults-file=${my.cnf Path} --user=${USER} -- password=${PASSWORD} --compress --process-threads=2 --backup- dir=${Backup Path} backup
  37. 37. 37 結果 Category TPCC Backup Time(min) Lock Time Backup Size (GB) tpmC(Only Backup Time) Load (Only Backup Time) Max tpmC Min tpmC Average tpmC Max Load Average Load T10(105) 0:35:00 N/A N/A N/A 14340 5256 11829.6 3.03 2.830 T10(106) 0:35:00 N/A N/A N/A 14544 10356 13091.4 2.92 2.562 XB N/A 0:19:24 0:00:04 38 N/A N/A N/A 2.99 1.842 EB N/A 0:18:43 0:00:03 38 N/A N/A N/A 2.26 1.607 T10 + XB 0:20:10 0:16:49 0:00:52 39 13380 0 10418.198 4.37 3.162 T10 + EB 0:20:10 0:16:02 0:00:53 38 14232 0 3622.135 3.46 2.510 XB + C + T10 0:20:10 0:14:23 0:00:03 23 12876 0 10594.058 3.19 2.479 EB + C + T10 0:20:10 0:08:31 0:00:03 22 11916 0 7154.796 2.65 1.999 XB + C + Th2 + T10 0:20:10 0:14:28 0:00:53 23 12504 0 9800.483 3.87 3.359 EB + C + Th2 + T10 0:20:10 0:09:03 0:00:04 22 11556 0 7765.982 3.42 2.915 * 弊社実行環境による検証結果 (4vCPU-16GB Memory)
  38. 38. 38 Running Time  Enterprise Backupに軍配  どのパターンでも EBの方が早く終わった  Compress を使ったほうが早い!
  39. 39. 39 Backup Size  ほぼ同じ
  40. 40. 40 Lock Time  ほぼ同じ  FLUSH TABLES WITH READ LOCK  流れてくるクエリの Transaction タイミングによる  MyISAM DBに対しては必ずLockがかかる  mysql db ・・・
  41. 41. 41 Load Average  Enterprise Backupに軍配も誤差の範囲  どのパターンでも EBの方がXBに比べてLoadは低めだった Category Load (Only Backup Time) Max Load Average Load T10(105) 3.03 2.830 T10(106) 2.92 2.562 XB 2.99 1.842 EB 2.26 1.607 T10 + XB 4.37 3.162 T10 + EB 3.46 2.510 XB + C + T10 3.19 2.479 EB + C + T10 2.65 1.999 XB + C + Th2 + T10 3.87 3.359 EB + C + Th2 + T10 3.42 2.915  Compress を使ったほうが 負荷が低い
  42. 42. 42 tpmC Category tpmC (Only Backup Time) Average tpmC T10(105) 11829.6 T10(106) 13091.4 T10 + XB 10418.198 T10 + EB 3622.135 XB + C + T10 10594.058 EB + C + T10 7154.796  Xtrabackup の圧勝!?  XB vs EB → 2.87倍  Compress → 1.48倍
  43. 43. 43 EB のデフォルト値  EBではprocess-threads のデフォルトは 6  何も考えずに叩くと process-threads が6で設定される http://dev.mysql.com/doc/mysql-enterprise-backup/3.11/en/backup-capacity-options.html  差は縮まったが Xtrabackup に軍配
  44. 44. 44 Summary  今回は Xtrabackup を採用  いずれもBackup Platformを作る、という観点で言えば同じことが出来る  Backup取得中のDBへのパフォーマンス影響が小さい  ライセンスを気にしなくていい Xtrabackup Enterprise Backup Running Time △ ○ Load Average △ ○ Lock Time ほぼ同じ tpmC ○ △ Backup Size ほぼ同じ Cost ◎ ○
  45. 45. 45 Backup and Restore System
  46. 46. 46 Option の決定  前提  様々なサイズ、リソース、トランザクション数を持つDBがある  個別最適を行わない  自動で判断できないことはしない  Compress オプションは必須  Options  vCPU/2 が最も効率的だった  Compress Thread 数は1で固定
  47. 47. 47 Restore  decompress  Backupのタイミングで Compressをしているため1step 必要  Backupファイルを tar.gz するかどうか  するとしたらそのタイミングは?  tar.gz してしまうと 増分/差分backupをするためにtar展開しな ければならない  1週間後?  copy-back or move-back?  Restore 先のサーバは基本的にはサービス停止している  memory や CPU は使える限り使う  Memory => mem * 0.75  Parallel
  48. 48. 48 Restore に必要な Disk Size Compressed Directory Size Decompressed Directory size Max Usage Size 23GB 69GB 78GB  必要なDisk Size  最大のテーブルサイズ分を考慮したdisk設計をする  backupファイルをどこで展開するかを決める  NFS or Local
  49. 49. 49 Backup and Restore System
  50. 50. 50 絶賛開発中  Restore のしやすさ  Veeam で Restore するよりも安全性は上げられるか  Serviceとしてどこまで展開できるか  アプリケーションエンジニアでも Restoreできる様にする  Server をあらかじめ用意しておく必要がある  Cost  Veeam の Cost を超えない運用Costに抑えられるか  本番への影響  Veeamは Snapshotをとる数秒だけ  Xtrabackup は backup 処理中ずっと どこまで優位性を出せるか?
  51. 51. 51

×