楽天MySQL Backup Structure~ 過去、現在、そして未来へ~

Keisuke.Awata (keisuke.awata@rakuten.com)

Data Store Administration Group

Infrastructure Administration Section

Global Infrastructure Development Department

2

Self Introduction

3

自己紹介

職歴 2007年4月 楽天株式会社へ新卒入社

• 2007年8月 - 2012年6月AD Platform を開発/運用するアプリケーションエンジニア

• 2011年5月 - 2012年5月サーバー設計エンジニアを兼務

• 2012年6月 - 現在DBA- Review・Bookmarkなどの ソーシャルプラットフォーム- 広告、アフィリエイトなどのマーケティングプラットフォーム- Oracle以外のID、Point、Coupon などの会員情報プラットフォーム- 社内ツール系

4

楽天のDatabase

5

RDBMS

会員データ、ポイントデータ、商品データといった特にミッションクリティカルなデータが格納

巨大DBMS環境。非常に昔から使用している。購買データなどクリティカルなデータが格納。古くから有るが故複雑な依存

楽天のメインRDBMS。ミッションクリティカルなデータから、社内サービスまで幅広く使用

Informix

Oracle

Clustrix PostgreSQL

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

楽天のDatabase Architecture

時代とともに構成は変わってきた VCS 構成(Active-Standby on SAN)

VCS ＋ Replication VCS ＋ Shard

IA Server + SSD Private Cloud

詳細は前回の db tech showcase の資料をご覧ください[楽天] 詳説 楽天のデータベースアーキテクチャ史 -シングルノードから仮想化フラッシュストレージへ

8

VCS 時代 ～ IA+SSD 時代初期

サービスの安定稼動 コンポーネントを共用

職人的DBAの全盛期 サービスの基盤を支えていた実績 細かなレビューとチェック項目

9

スピードや柔軟性 古典的なチケットシステム 膨大な量のレビューとチェック項目

VCS 時代 ～ IA+SSD 時代初期

迅速かつ多様な要望に応える必要性

追い討ちをかけるように アジャイルプロジェクトの増加 MongoDB/Redis 等の NoSQL の台頭 クラウドサービスの多様化

増強 増強 = HW購入 EOSLタイミングが同じサーバ達

10

ターニングポイント

DC 移設プロジェクト DCの移設に伴い 250以上のDBを9ヶ月で Private Cloud へ移設

主に既存DBに新DBをレプリケーションさせて切り替え

BackupからのRestoreする方式 アーカイブからのリストア

時間がかかる あるある失敗談

レプリケーション元サーバに binlogなかった binlog転送によりネットワークを逼迫

SJIS Database の存在 新しいDCに建てるサーバはグローバル化に伴い UTF8 に統一

レプリケーション方式は使えない

11

Migration Tool

CLI Base の Migration Tool dump → import → Change Master

dump → import のパラレル実行 thread を分けてdump 実行 encode (SJISの場合) import

期限内に全てのDB移設を完了！

12

# of VMs in Private Cloud

13

楽天 MySQL DB Tools

14

Private Cloudの急激な成長

管理するDatabase数も比例して増加 現在の私たちのグループのDBAは5人 担当するサーバーは本番だけで600台弱 毎月30台ペースでDBサーバが構築されていく

15

DBA の仕事の変化

DB管理の責任範囲 全てのサービスを同じレベルで見ることはもはや不可能に近い状況

だからエンジニアが 知りたい やりたい

ことを自分たちで出来るようなWeb インターフェースを隙間時間で自作

本当にサポートが必要なサービスに目を向けるための基盤作り

16

Status Monitoring

17

Deploy

18

Operation

19

FAQ Portal

20

Cloud化による仕事の変化

21

楽天DBAを取り巻く環境は年々変わってきている

仕事の仕方も変化せざるを得ない トップダウンの決定だけで変化しているわけではない！

現場のDBAのアクションで 自分たちが主導になり 新しいことを取り入れることが出来る環境はある 失敗してもいい、という気持ちが大切

やるかやらないかは自分次第！

22

楽天の MySQL Database のBackup/Restore 方式

23

DB Restore タイミング

Point in time recovery 年に一度、あるかないか 実際は障害訓練でやる程度

移設増強タイミング restore したデータを利用してレプリケーション設定

検証/調査 定期メンテナンス

DBAタスク時間見積もり オペレーション確認

アプリエンジニアからの過去データ調査依頼 前日トラブルがあり、データを確認したい

本番データを用いたアプリケーションテストのため 結合テスト 負荷テスト

24

楽天 の Database Backup方法

Database Architecture 主なBackup 方法

VCS 構成

SAN SnapshotVCS ＋ Replication

VCS ＋ Shard

IA Server + SSD mylvmbackup

Private Cloud Veeam

その他mysqldump

mysqlhotcopy

file copy

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

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

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

Veeam によるBackup

VirtualAPP

Veeam ManagementServer

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

Veeam Restore

Windows GUI ベースのオペレーション Restoreしたい日付を選んでいくつかの項目を選択 VM 設定全て引き継いでいる Restore 後 Network 設定等 OS オペレーション

Traget DB Server

DB

Restored DB Server

DB

30

Restore の改善

Backup Restore の過去、現在 SAN Snapshot / mylvmbackup

Restore 先は 共有環境 or NFS tar 展開に非常に時間がかかる 特に定期メンテナンスの前になるとリソースの取り合い

ディスクだけでなくメモリ含め 性能は本番環境に比べて著しく低い

Veeam Restore 先は Private Cloud 環境

用途によって性能環境を分けられる 負荷試験環境 => 本番と同じストレージ(FC/SSD) データ確認用 => 性能を求めない安いストレージ

Restore にやや時間がかかる 展開先のストレージによる

SSDなら30分、FCなら2時間 など

31

Next Backup Platform

32

Veeam Backup

VeeamによるBackupの問題点 License Fee

日に日にDBサーバが増えていく現状ではコストが上がる一方

VMware 依存 Platform は時代とともに変わってくる

VCS → IA + SSD → VMware → Next!

運用管理 台数が多くなるにつれてGUI処理が重くなっている

Restore Operation の危険性 既存で動いているサーバにバックアップを上書き 既存で動いているIPアドレスをそのまま別のサーバで使用など危険な操作が出来てしまう

→ VMと社内ネットワークに対する最低限の理解が必要

33

新しいBackup システムの導入検討

要件 Platformとして提供

数百台のサーバのBackup管理 アプリケーションエンジニアでも

「いつでも」 「かんたんに」リストアできるサービス

中央管理が出来ること Backup Script は DBサーバ自体に配置

インストールが簡単であること

Jobをコントロールするのは別のアプリケーション 履歴管理ができること スケジュールの登録/変更が簡単であること

候補 Xtrabackup MySQL Enterprise Backup

34

構成図イメージ

？

？

35

Xtrabackup VS MySQL Enterprise Backup

検証方法 tpcc を利用した ベンチマークにより検証

様々なトランザクションを並列実行した結果を見るため 3回ずつ実行し中間の値を取得

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

結果

Category TPCCBackup

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

Running Time

Enterprise Backupに軍配 どのパターンでも EBの方が早く終わった

Compress を使ったほうが早い！

39

Backup Size

ほぼ同じ

40

Lock Time

ほぼ同じ FLUSH TABLES WITH READ LOCK 流れてくるクエリの Transaction タイミングによる MyISAM DBに対しては必ずLockがかかる

mysql db ・・・

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

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

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

Summary

今回は Xtrabackup を採用 いずれもBackup Platformを作る、という観点で言えば同じことが出来る Backup取得中のDBへのパフォーマンス影響が小さい ライセンスを気にしなくていい

Xtrabackup Enterprise Backup

Running Time △ ○

Load Average △ ○

Lock Time ほぼ同じ

tpmC ○ △

Backup Size ほぼ同じ

Cost ◎ ○

45

Backup and Restore System

46

Option の決定

前提 様々なサイズ、リソース、トランザクション数を持つDBがある

個別最適を行わない 自動で判断できないことはしない Compress オプションは必須

Options vCPU/2 が最も効率的だった Compress Thread 数は1で固定

47

Restoredecompress

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

Restore に必要な Disk Size

CompressedDirectory Size

DecompressedDirectory size

Max Usage Size

23GB 69GB 78GB

必要なDisk Size 最大のテーブルサイズ分を考慮したdisk設計をする backupファイルをどこで展開するかを決める

NFS or Local

49

Backup and Restore System

50

絶賛開発中

Restore のしやすさ Veeam で Restore するよりも安全性は上げられるか Serviceとしてどこまで展開できるか

アプリケーションエンジニアでも Restoreできる様にする Server をあらかじめ用意しておく必要がある

Cost Veeam の Cost を超えない運用Costに抑えられるか

本番への影響 Veeamは Snapshotをとる数秒だけ Xtrabackup は backup 処理中ずっと

どこまで優位性を出せるか?

51