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

楽天MySQL Backup Structure
~ 過去、現在、そして未来へ~
Keisuke.Awata (keisuke.awata@rakuten.com)
Data Store Administration Group
Infrastructure Administration Section
Global Infrastructure Development Department

3
自己紹介
 職歴
 2007年4月楽天株式会社へ新卒入社
• 2007年8月 - 2012年6月
AD Platform を開発/運用するアプリケーションエンジニア
• 2011年5月 - 2012年5月
サーバー設計エンジニアを兼務
• 2012年6月 - 現在
DBA
- Review・Bookmarkなどのソーシャルプラットフォーム
- 広告、アフィリエイトなどのマーケティングプラットフォーム
- Oracle以外のID、Point、Coupon などの会員情報プラットフォーム
- 社内ツール系

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移設を完了！

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

15
DBA の仕事の変化
 DB管理の責任範囲
 全てのサービスを同じレベルで見ることはもはや不可能に近い状況
 だからエンジニアが
 知りたい
 やりたい
ことを自分たちで出来るようなWeb インターフェースを隙間時間で自作
本当にサポートが必要なサービスに目を向けるための基盤作り

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ロック取得
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 Management
Server
1.DBロック取得
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時間など

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}
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}
password=${PASSWORD} --compress --process-threads=2 --backup-
dir=${Backup Path} backup

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
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 ◎ ○

46
Option の決定
 前提
 様々なサイズ、リソース、トランザクション数を持つDBがある
 個別最適を行わない
 自動で判断できないことはしない
 Compress オプションは必須
 Options
 vCPU/2 が最も効率的だった
 Compress Thread 数は1で固定

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
Restore に必要な Disk Size
Compressed
Directory Size
Decompressed
Directory size
Max Usage Size
23GB 69GB 78GB
 必要なDisk Size
 最大のテーブルサイズ分を考慮したdisk設計をする
 backupファイルをどこで展開するかを決める
 NFS or Local

50
絶賛開発中
 Restore のしやすさ
 Veeam で Restore するよりも安全性は上げられるか
 Serviceとしてどこまで展開できるか
 アプリケーションエンジニアでも Restoreできる様にする
 Server をあらかじめ用意しておく必要がある
 Cost
 Veeam の Cost を超えない運用Costに抑えられるか
 本番への影響
 Veeamは Snapshotをとる数秒だけ
 Xtrabackup は backup 処理中ずっと
どこまで優位性を出せるか?

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

More Related Content

What's hot (20)

Viewers also liked (20)

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

More from Insight Technology, Inc. (20)

Recently uploaded (12)