本スライドは、数ヶ月に1度実施される一大イベント「楽天スーパーセール」にて発生した基幹系DBの性能課題を受け、 最新機種へDB移設を超短期間で実施したプロジェクトについて、異機種、異バージョン、異アーキテクチャのDB移行をどのように実施したか、 国内初実績となるAttunityを活用したレプリケーション、その他関連する移行ノウハウについての資料です。

1. 楽天プロジェクトX：
基幹DB移設 編
Vol.01 2013/05/31
楽天株式会社
上加世田 暁
http://www.rakuten.co.jp/

2. 2
自己紹介
 氏名： 上加世田 暁 （かみかせだ さとる）
 性別： 男
 年齢： 29
 経歴： 2009年3月 東京電機大学 大学院情報メディア学科 修了
2009年4月 新卒として楽天株式会社へ入社
2009年7月 DBAとして配属
Oracle/MySQL/Teradata/Informix/Clustrixなど
多くのRDBMSの管理
 Linkdin： http://www.linkedin.com/pub/satoru-kamikaseda/72/97b/381

3. 3
アジェンダ
１ 背景
２ 性能課題・原因調査
３ 増強・移行検討
４ 移行要件・検証
５ 実施と結果
６ まとめ

4. 4
2012年6月 楽天スーパーセール

5. 5
会員情報管理DB
会員情報
 楽天会員8000万人以上の会員情報を管理

6. 6
システム構成
環 境
 Oracle 10g
 3 ノード RAC
 Weblogic 接続
 アプリケーション・パーティショニング制御
Node 2 Node 3
Node 1

7. 7
スーパーセール時の負荷
ピ ー ク 時 の 負 荷
CPU使用率
Load Average
ピーク

8. 8
性能課題
性 能 課 題
 DBがセッションを捌き切れない
 会員がログインできない
→ 楽天スーパーポイントが利用できない
→ イベント参加情報が連携できない
※ イメージです

9. 9
この時点でのスケジュール
6月
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
7月
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31
8月
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
9月
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30
10月
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31
11月
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30
12月
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31
Super Sale
原因調査開始！
Next
Super Sale
メンテナンス
残り6ヶ月！
・ 原因調査
・ 課題解決
・ 増強
・ パフォーマンス検証
・ などなど・・・

10. 10
原因調査
O r a c l e
 Oracleの設定？
 Weblogicの設定？
 セッション数・コネクションプール不足？
H / W
 S/Wの高負荷？
 Disk I/O？
 CPU不足？
 メモリ不足？
⇒ 対応！
⇒ 対応！
⇒ 対応！
⇒ 対応！

11. 11
Evnents Waits Total
Wait
Time(s)
Waits
/txn
Executions
cursor: pin S 2,515,782 1,136 32.5 235,2701
Weblogicの設定
問 題 点
 Weblogic 死活監視
 都度 “SELECT 1 FROM DUAL;” を発行
Select
1
Select
1
Select
1
Select
1
Select
1
Select
1
Select
1
Select
1
Select
1
Select
1
Select
1
Select
1
Select
1
Select
1
Select
1
Select
1
Select
1
Select
1
Select
1
Select
1
Select
1
Select
1
Select
1
Select
1
Select
1
Select
1
Select
1
Select
1
Select
1
Select
1
Select
1
Select
1
Select
1
Select
1
Select
1
Select
1
Select
1
Select
1
Select
1
Select
1
Select
1
Select
1
Select
1
Select
1
Select
1
Select
1
Select
1
Select
1
Select
1
Select
1
Select
1 Node 2 Node 3
Node 1

12. 12
Weblogicの設定
対 応
 死活監視実行頻度を１秒毎に変更
Select
1
Select
1
Select
1
Select
1
Node 2 Node 3
Node 1

13. 13
ここまでの結果として
負 荷 試 験 結 果
 対応前の1.5倍まで耐えられる！
Before After

14. 14
まだ足りない・・・
さ ら な る 増 強
 3倍のパフォーマンスが必須！
Before After Next

15. 15
この時点でのスケジュール
6月
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
7月
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31
8月
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
9月
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30
10月
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31
11月
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30
12月
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31
Super Sale
メモリ追加
S/W交換
Weblogic設定変更
増強検討開始！
Next
Super Sale
メンテナンス
残り3ヶ月！
・ 増強・移行検討
・ パフォーマンス検証
・ 実施方法の確立
・ などなど・・・

16. 16
増強
増 強 案
Node 1
Node 2
Node 3
Node 4
Node 5
Node 6
Node 1
Node 2
Node 3
スケールアウト？ スケールアップ？
New 1
New 2
New 3
Oracle11g
Node 1
Node 2
Node 3
Oracle10g

17. 17
スケールアウト（ノード追加）検討
デ メ リ ッ ト
 機種が古い
 購入コスト・RACKコストなど必要
 Node追加作業の検証が必要
 Node数増に伴うアプリケーション改修
 調達に時間が必要
Node 1
Node 2
Node 3
Node 4
Node 5
Node 6
Node 1
Node 2
Node 3
メ リ ッ ト
 実績あるサーバ
 DB自体の移行が不要

18. 18
スケールアップ（最新IA機へ移行）検討
デ メ リ ッ ト
 実績の無いサーバ
 Oracle11g にVersion UPが必要
 パフォーマンス以外に障害試験等が必要
 監視やバックアップ等の運用整備が必要
 DBのデータ移行が必要
メ リ ッ ト
 既存環境と同様の3Node RAC
 機種自体が既に購入済みのため購入フローが不要
 事前のパフォーマンス試験など可能
Node 1
Node 2
Node 3
New 1
New 2
New 3
Oracle11gOracle10g

19. 19
方針決定
増 強 方 針
 メインプラン ：スケールアップ（最新IA機へ移行）
 バックアッププラン ：スケールアウト（ノード追加）
Node 1
Node 2
Node 3
Node 4
Node 5
Node 6
Oracle10g
Node 1
Node 2
Node 3
Oracle11g
New 1
New 2
New 3
Node 1
Node 2
Node 3
スケールアウト スケールアップ

20. 20
移行要件
要 件
 メンテナンス時間の最短化
 移行後の有事の際に戻せる仕組み
会員情報DB特性
 テーブル数 ：約90個
 データサイズ：約300GB
 特記事項 ：楽天の全サービスが使う
Node 2 Node 3
Node 1

21. 21
移行方法
一 括 デ ー タ 移 行 差 分 同 期 移 行
 準備が楽
 データ整合性信頼度高
 停止時間が4時間以上必要
 停止時間短縮可能
 差分同期の仕組みが必要
 データ担保が必要
Node 2Node 3
Node 1
Node 2Node 3
Node 1
NOW NEW
Node 2Node 3
Node 1
Node 2Node 3
Node 1
NOW NEW
Oracle10g Oracle11g Oracle10g Oracle11g

22. 22
レプリケーション・ソリューション
Logical DataGuard自 前 ス ク リ プ ト
ライセンス等の追加費用 不要
G o l d e n G a t eA t t u n i t y
期間ライセンス 有 ライセンス 必要
下位Version同期 非サポート
開発工数 高
考慮可能
異Version同期 サポート
導入難易度 低
異Version同期 サポート
＜選定条件＞ 仕様要件 ・ 追加費用 ・ 導入難易度

23. 23
この時点でのスケジュール
6月
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
7月
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31
8月
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
9月
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30
10月
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31
11月
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30
12月
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31
Super Sale
メモリ追加
S/W交換
Weblogic設定変更
検証開始！
Next
Super Sale
移行方針検討
増強方針検討増強方針検討
メンテナンス
残り2ヶ月！
・ スケールアップ検証・方法確立
・ パフォーマンス検証
・ 障害試験
・ 環境整備
・ データ移行試験
・ などなど・・・
・ （スケールアウト検証）

24. 24
Attunity
主 な 機 能
 Clientサーバで稼働
 GUIベース
 Full Load で全データ移行
 更新データの伝搬

25. 25
差分同期検証
検 証 点
 移行元への設定
 Full Load＆レプリケーションの負荷
 トリガー・シーケンスの同期
 移行元と移行先のデータ整合性

26. 26
必須準備と注意点
SUPPLEMENTAL LOG
 Oracleの設定
 REDOログに更新列以外の列値を追加
 別DBへ更新を適用する際に行を一意に識別するのに利用可能
Node 2Node 3
Node 1
Node 2Node 3
Node 1
NEWNOW
伝搬REDOログ
SUPPLEMENTAL LOG

27. 27
必須準備と注意点
有 効 化 方 法
 DB全体
 ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
 各テーブル
 ALTER TABLE “SCHEMA".“TABLE" ADD SUPPLEMENTAL
LOG DATA (PRIMARY KEY) COLUMNS;
注 意 点
 有効化時にLOCKが取られる
 REDOログが増える

28. 28
Full Load＆レプリケーション負荷
Node 2Node 3
Node 1
NOW
Oracle10g
Node 2Node 3
Node 1
NEW
Oracle11g
Full Loadレプリケーション
問 題 無 し
 移行元DBのLoadAvg ＋1～2程度
 Full Load 40パラレル 300GB 約3時間半
問 題 有 り
 移行元DBへのSELECTによりShared Poolが侵食される
 リテラルなSQLをBind変数化するパッチでBug Fix

29. 29
トリガー・シーケンス
ト リ ガ ー
 移行先DBのトリガー 要注意
 同期開始前にトリガーの無効化
 移行完了後にトリガーの有効化
シ ー ケ ン ス
 移行先DBのシーケンスはカウントアップされない
 更新停止後の移行元DBのシーケンス確認
 移行先DBで手動でシーケンスを再設定

30. 30
データ整合性確認
要 件
 全テーブル、全データを比較して担保
 時間を極力最短化
方 法
 データをHASH化して比較
 PL/SQLを利用

31. 31
データ整合性
比 較 フ ロ ー
 比較対象DB同士をDBLinkで開通
Node 2 Node 3
Node 1
NOW
Oracle10g
Node 2 Node 3
Node 1
NEW
Oracle11g
DBLink
 移行先に比較処理用オブジェクト作成
結果管理
テーブル
 比較対象テーブル登録＆確認
対象テーブル ProcedureでデータのHASH化実行

32. 32
データ整合性
H A S H 化
 対象テーブルのカラム単位でORA_HASH関数を使ってHASH化
ORA_HASH
Column 1
Column 2
Column 3
Column 4
Column 5
TABLE A
結果管理
テーブル
 全レコード分のHASH値をSUMで合計
SUM
 カラム数分繰り返し
Colum 1 SUM
Colum 2 SUM
Colum 3 SUM
Colum 4 SUM
Colum 5 SUM
 １レコードとして結果を格納
 全テーブルで繰り返す

33. 33
データ整合性
比 較 フ ロ ー
 比較対象DB同士をDBLinkで開通
Node 2 Node 3
Node 1
NOW
Oracle10g
Node 2 Node 3
Node 1
NEW
Oracle11g
DBLink
 移行先に比較処理用オブジェクト作成
結果管理
テーブル
 比較対象テーブル登録＆確認
対象テーブル テーブル毎にデータをHASH化して格納
 同テーブルのHASH値を比較
結果管理
テーブル
300GBのデータ比較が10分で完了！

34. 34
HASH化比較の有用性
データ差分ケース
 ２億件程のテーブルデータ移行
 件数確認、サンプリング比較、目視確認で問題無し
有 用 性
 比較困難な「空文字・スペース・NULL」が比較可能！
HASH化比較で検知！
 空文字がスペースに置き換わるバグ

35. 35
この時点でのスケジュール
6月
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
7月
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31
8月
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
9月
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30
10月
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31
11月
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30
12月
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31
Super Sale
メモリ追加
S/W交換
Weblogic設定変更
Next
Super Sale
移行方針検討
増強方針検討増強方針検討
増強方針検討検証
本番検証本番検証
メンテナンス
メンテ準備開始！
メンテまで
残り3日！
・ 環境掃除
・ Full Load＆事前同期
・ メンテナンス

36. 36
3日前！
11月
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30
環境掃除！
環 境 掃 除
 [11/15 - 10:00] 検証用Attunity停止
 [11/15 - 11:00] 移行先DB掃除
 [11/15 - 13:00] 環境確認
 [11/15 - 18:00] 深夜作業に向けて帰宅！
メンテナンス
メンテまで
残り2日！

37. 37
2日前！
11月
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30
事前同期開始！
事 前 同 期
 [11/16 - 02:00] Full Load開始
 [11/16 - 03:00] 1時間監視
 [11/16 - 05:30] Full Load完了、差分同期中（ラグ大）
 [11/16 - 09:30] 差分同期中（ラグ無し）
メンテナンス
 [11/16 - 21:30] (作業関係無く)1NodeのCPU故障
メンテまで
残り1日！

38. 38
1日前！
11月
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30
決戦前夜！
決 戦 前 夜
 [11/17 - 22:00] 深夜メンテに向けて仮眠
 [11/17 - 23:00] 出社
メンテナンス
メンテ！

39. 39
メンテナンス作業とリスクヘッジ
作 業
 サービス停止（2：30）
 同期停止
 データ整合性確認
 トリガー・シーケンス設定
 バックアップ取得
 サービス再開（5：00）
リ ス ク ヘ ッ ジ
 テーブル毎のリカバリ方法カテゴライズ

40. 40
メンテ！
11月
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30
メンテナンス
メ ン テ ナ ン ス
 [11/18 - 02:30] サービス停止
 [11/18 - 02:45] 差分同期停止
 [11/18 - 03:00] データ比較完了
データ差分発覚！！
残り
2時間！

41. 41
データ差分
デ ー タ 差 分
 22テーブルで差分発覚
 SELECT MINUS で差分自体の確認
 差異例（対象カラムのみ記載）
TIMESTAMP
-------------------------------------------------------------
16-NOV-12 09.56.31.022934 PM (移行元)
16-NOV-12 09.56.31.229340 PM (移行先)
対 応
 22テーブルを22パラレルでFull Load

42. 42
メンテ！
11月
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30
メンテナンス
メ ン テ ナ ン ス
 [11/18 - 02:30] サービス停止
 [11/18 - 02:45] 差分同期停止
 [11/18 - 03:00] データ比較＆差分発覚
 [11/18 - 04:10] 差分調査・リカバリ＆データ比較
残り50分！

43. 43
メンテ！
11月
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30
メンテナンス
メ ン テ ナ ン ス
 [11/18 - 02:30] サービス停止
 [11/18 - 02:45] 差分同期停止
 [11/18 - 03:00] データ比較＆差分発覚
 [11/18 - 04:10] 差分調査・リカバリ＆データ比較
 [11/18 - 04;20] トリガー・シーケンス設定
 [11/18 - 04:50] バックアップ取得
 [11/18 - 05:00] サービス再開
ギリギリ
間に合った！

44. 44
この時点でのスケジュール
6月
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
7月
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31
8月
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
9月
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30
10月
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31
11月
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30
12月
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31
Super Sale
メモリ追加
S/W交換
Weblogic設定変更
Next
Super Sale移行方針検討
増強方針検討増強方針検討
増強方針検討検証
本番検証本番検証
メンテナンス
メンテ準備開始
メンテナンス
残り2週間！
・ 新環境⇒旧環境レプリ
・ CPU交換
・ Oracleパッチ適用
・ ノード追加
・ 環境整備
・ などなど・・・

45. 45
この時点でのスケジュール
6月
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
7月
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31
8月
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
9月
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30
10月
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31
11月
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30
12月
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31
Super Sale
メモリ追加
S/W交換
Weblogic設定変更
Next
Super Sale
移行方針検討
増強方針検討増強方針検討
増強方針検討検証
本番検証本番検証
メンテナンス
メンテ準備開始
セールへ！
逆同期
CPU交換
パッチ適用
ノード追加
コピー構築
環境整備
楽天
スーパーセール
開催！

46. 46
2012年12月 楽天スーパーセール
※ イメージです

47. 47
ちなみに・・・
パ フ ォ ー マ ン ス
 最低でも3倍は耐えられる状態にする
Before After Next
 検証できる限りの負荷に耐えられることを確認！

48. 48
まとめ
性 能 課 題
 楽天スーパーセールが乗り切れない
増 強
 最新IA機への移行
移 行 方 法
 差分同期データ移行
ス ー パ ー セ ー ル
 余裕を持って乗り切れた
データ整合性確認
 HASH化比較スクリプト

49. 49
まとめ
反 省 点
 メンテナンス当日に発生したデータ差分バグを事前に見つけられなかった
原 因
 本番稼働中のDBで、静止点をとった差分比較を行えなかった
と は い え
 レプリケーション製品を導入したことで、準備時間はかなり短縮できた
 操作性も高く、検証を何度も気軽に行えた

50. 50
2013年6月2日 楽天スーパーセール やります！
ご清聴ありがとうございました。