楽天プロジェクトX:基幹DB移設 編

4,115 views

Published on

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

Published in: Technology
0 Comments
11 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,115
On SlideShare
0
From Embeds
0
Number of Embeds
305
Actions
Shares
0
Downloads
73
Comments
0
Likes
11
Embeds 0
No embeds

No notes for slide

楽天プロジェクトX:基幹DB移設 編

  1. 1. 楽天プロジェクトX:基幹DB移設 編Vol.01 2013/05/31楽天株式会社上加世田 暁http://www.rakuten.co.jp/
  2. 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. 3アジェンダ1 背景2 性能課題・原因調査3 増強・移行検討4 移行要件・検証5 実施と結果6 まとめ
  4. 4. 42012年6月 楽天スーパーセール
  5. 5. 5会員情報管理DB会員情報 楽天会員8000万人以上の会員情報を管理
  6. 6. 6システム構成環 境 Oracle 10g 3 ノード RAC Weblogic 接続 アプリケーション・パーティショニング制御Node 2 Node 3Node 1
  7. 7. 7スーパーセール時の負荷ピ ー ク 時 の 負 荷CPU使用率Load Averageピーク
  8. 8. 8性能課題性 能 課 題 DBがセッションを捌き切れない 会員がログインできない→ 楽天スーパーポイントが利用できない→ イベント参加情報が連携できない※ イメージです
  9. 9. 9この時点でのスケジュール6月1 23 4 5 6 7 8 910 11 12 13 14 15 1617 18 19 20 21 22 2324 25 26 27 28 29 307月1 2 3 4 5 6 78 9 10 11 12 13 1415 16 17 18 19 20 2122 23 24 25 26 27 2829 30 318月1 2 3 45 6 7 8 9 10 1112 13 14 15 16 17 1819 20 21 22 23 24 2526 27 28 29 30 319月12 3 4 5 6 7 89 10 11 12 13 14 1516 17 18 19 20 21 2223 24 25 26 27 28 293010月1 2 3 4 5 67 8 9 10 11 12 1314 15 16 17 18 19 2021 22 23 24 25 26 2728 29 30 3111月1 2 34 5 6 7 8 9 1011 12 13 14 15 16 1718 19 20 21 22 23 2425 26 27 28 29 3012月12 3 4 5 6 7 89 10 11 12 13 14 1516 17 18 19 20 21 2223 24 25 26 27 28 2930 31Super Sale原因調査開始!NextSuper Saleメンテナンス残り6ヶ月!・ 原因調査・ 課題解決・ 増強・ パフォーマンス検証・ などなど・・・
  10. 10. 10原因調査O r a c l e Oracleの設定? Weblogicの設定? セッション数・コネクションプール不足?H / W S/Wの高負荷? Disk I/O? CPU不足? メモリ不足?⇒ 対応!⇒ 対応!⇒ 対応!⇒ 対応!
  11. 11. 11Evnents Waits TotalWaitTime(s)Waits/txnExecutionscursor: pin S 2,515,782 1,136 32.5 235,2701Weblogicの設定問 題 点 Weblogic 死活監視 都度 “SELECT 1 FROM DUAL;” を発行Select1Select1Select1Select1Select1Select1Select1Select1Select1Select1Select1Select1Select1Select1Select1Select1Select1Select1Select1Select1Select1Select1Select1Select1Select1Select1Select1Select1Select1Select1Select1Select1Select1Select1Select1Select1Select1Select1Select1Select1Select1Select1Select1Select1Select1Select1Select1Select1Select1Select1Select1 Node 2 Node 3Node 1
  12. 12. 12Weblogicの設定対 応 死活監視実行頻度を1秒毎に変更Select1Select1Select1Select1Node 2 Node 3Node 1
  13. 13. 13ここまでの結果として負 荷 試 験 結 果 対応前の1.5倍まで耐えられる!Before After
  14. 14. 14まだ足りない・・・さ ら な る 増 強 3倍のパフォーマンスが必須!Before After Next
  15. 15. 15この時点でのスケジュール6月1 23 4 5 6 7 8 910 11 12 13 14 15 1617 18 19 20 21 22 2324 25 26 27 28 29 307月1 2 3 4 5 6 78 9 10 11 12 13 1415 16 17 18 19 20 2122 23 24 25 26 27 2829 30 318月1 2 3 45 6 7 8 9 10 1112 13 14 15 16 17 1819 20 21 22 23 24 2526 27 28 29 30 319月12 3 4 5 6 7 89 10 11 12 13 14 1516 17 18 19 20 21 2223 24 25 26 27 28 293010月1 2 3 4 5 67 8 9 10 11 12 1314 15 16 17 18 19 2021 22 23 24 25 26 2728 29 30 3111月1 2 34 5 6 7 8 9 1011 12 13 14 15 16 1718 19 20 21 22 23 2425 26 27 28 29 3012月12 3 4 5 6 7 89 10 11 12 13 14 1516 17 18 19 20 21 2223 24 25 26 27 28 2930 31Super Saleメモリ追加S/W交換Weblogic設定変更増強検討開始!NextSuper Saleメンテナンス残り3ヶ月!・ 増強・移行検討・ パフォーマンス検証・ 実施方法の確立・ などなど・・・
  16. 16. 16増強増 強 案Node 1Node 2Node 3Node 4Node 5Node 6Node 1Node 2Node 3スケールアウト? スケールアップ?New 1New 2New 3Oracle11gNode 1Node 2Node 3Oracle10g
  17. 17. 17スケールアウト(ノード追加)検討デ メ リ ッ ト 機種が古い 購入コスト・RACKコストなど必要 Node追加作業の検証が必要 Node数増に伴うアプリケーション改修 調達に時間が必要Node 1Node 2Node 3Node 4Node 5Node 6Node 1Node 2Node 3メ リ ッ ト 実績あるサーバ DB自体の移行が不要
  18. 18. 18スケールアップ(最新IA機へ移行)検討デ メ リ ッ ト 実績の無いサーバ Oracle11g にVersion UPが必要 パフォーマンス以外に障害試験等が必要 監視やバックアップ等の運用整備が必要 DBのデータ移行が必要メ リ ッ ト 既存環境と同様の3Node RAC 機種自体が既に購入済みのため購入フローが不要 事前のパフォーマンス試験など可能Node 1Node 2Node 3New 1New 2New 3Oracle11gOracle10g
  19. 19. 19方針決定増 強 方 針 メインプラン :スケールアップ(最新IA機へ移行) バックアッププラン :スケールアウト(ノード追加)Node 1Node 2Node 3Node 4Node 5Node 6Oracle10gNode 1Node 2Node 3Oracle11gNew 1New 2New 3Node 1Node 2Node 3スケールアウト スケールアップ
  20. 20. 20移行要件要 件 メンテナンス時間の最短化 移行後の有事の際に戻せる仕組み会員情報DB特性 テーブル数 :約90個 データサイズ:約300GB 特記事項 :楽天の全サービスが使うNode 2 Node 3Node 1
  21. 21. 21移行方法一 括 デ ー タ 移 行 差 分 同 期 移 行 準備が楽 データ整合性信頼度高 停止時間が4時間以上必要 停止時間短縮可能 差分同期の仕組みが必要 データ担保が必要Node 2Node 3Node 1Node 2Node 3Node 1NOW NEWNode 2Node 3Node 1Node 2Node 3Node 1NOW NEWOracle10g Oracle11g Oracle10g Oracle11g
  22. 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. 23この時点でのスケジュール6月1 23 4 5 6 7 8 910 11 12 13 14 15 1617 18 19 20 21 22 2324 25 26 27 28 29 307月1 2 3 4 5 6 78 9 10 11 12 13 1415 16 17 18 19 20 2122 23 24 25 26 27 2829 30 318月1 2 3 45 6 7 8 9 10 1112 13 14 15 16 17 1819 20 21 22 23 24 2526 27 28 29 30 319月12 3 4 5 6 7 89 10 11 12 13 14 1516 17 18 19 20 21 2223 24 25 26 27 28 293010月1 2 3 4 5 67 8 9 10 11 12 1314 15 16 17 18 19 2021 22 23 24 25 26 2728 29 30 3111月1 2 34 5 6 7 8 9 1011 12 13 14 15 16 1718 19 20 21 22 23 2425 26 27 28 29 3012月12 3 4 5 6 7 89 10 11 12 13 14 1516 17 18 19 20 21 2223 24 25 26 27 28 2930 31Super Saleメモリ追加S/W交換Weblogic設定変更検証開始!NextSuper Sale移行方針検討増強方針検討増強方針検討メンテナンス残り2ヶ月!・ スケールアップ検証・方法確立・ パフォーマンス検証・ 障害試験・ 環境整備・ データ移行試験・ などなど・・・・ (スケールアウト検証)
  24. 24. 24Attunity主 な 機 能 Clientサーバで稼働 GUIベース Full Load で全データ移行 更新データの伝搬
  25. 25. 25差分同期検証検 証 点 移行元への設定 Full Load&レプリケーションの負荷 トリガー・シーケンスの同期 移行元と移行先のデータ整合性
  26. 26. 26必須準備と注意点SUPPLEMENTAL LOG Oracleの設定 REDOログに更新列以外の列値を追加 別DBへ更新を適用する際に行を一意に識別するのに利用可能Node 2Node 3Node 1Node 2Node 3Node 1NEWNOW伝搬REDOログSUPPLEMENTAL LOG
  27. 27. 27必須準備と注意点有 効 化 方 法 DB全体 ALTER DATABASE ADD SUPPLEMENTAL LOG DATA; 各テーブル ALTER TABLE “SCHEMA".“TABLE" ADD SUPPLEMENTALLOG DATA (PRIMARY KEY) COLUMNS;注 意 点 有効化時にLOCKが取られる REDOログが増える
  28. 28. 28Full Load&レプリケーション負荷Node 2Node 3Node 1NOWOracle10gNode 2Node 3Node 1NEWOracle11gFull Loadレプリケーション問 題 無 し 移行元DBのLoadAvg +1~2程度 Full Load 40パラレル 300GB 約3時間半問 題 有 り 移行元DBへのSELECTによりShared Poolが侵食される リテラルなSQLをBind変数化するパッチでBug Fix
  29. 29. 29トリガー・シーケンスト リ ガ ー 移行先DBのトリガー 要注意 同期開始前にトリガーの無効化 移行完了後にトリガーの有効化シ ー ケ ン ス 移行先DBのシーケンスはカウントアップされない 更新停止後の移行元DBのシーケンス確認 移行先DBで手動でシーケンスを再設定
  30. 30. 30データ整合性確認要 件 全テーブル、全データを比較して担保 時間を極力最短化方 法 データをHASH化して比較 PL/SQLを利用
  31. 31. 31データ整合性比 較 フ ロ ー 比較対象DB同士をDBLinkで開通Node 2 Node 3Node 1NOWOracle10gNode 2 Node 3Node 1NEWOracle11gDBLink 移行先に比較処理用オブジェクト作成結果管理テーブル 比較対象テーブル登録&確認対象テーブル ProcedureでデータのHASH化実行
  32. 32. 32データ整合性H A S H 化 対象テーブルのカラム単位でORA_HASH関数を使ってHASH化ORA_HASHColumn 1Column 2Column 3Column 4Column 5TABLE A結果管理テーブル 全レコード分のHASH値をSUMで合計SUM カラム数分繰り返しColum 1 SUMColum 2 SUMColum 3 SUMColum 4 SUMColum 5 SUM 1レコードとして結果を格納 全テーブルで繰り返す
  33. 33. 33データ整合性比 較 フ ロ ー 比較対象DB同士をDBLinkで開通Node 2 Node 3Node 1NOWOracle10gNode 2 Node 3Node 1NEWOracle11gDBLink 移行先に比較処理用オブジェクト作成結果管理テーブル 比較対象テーブル登録&確認対象テーブル テーブル毎にデータをHASH化して格納 同テーブルのHASH値を比較結果管理テーブル300GBのデータ比較が10分で完了!
  34. 34. 34HASH化比較の有用性データ差分ケース 2億件程のテーブルデータ移行 件数確認、サンプリング比較、目視確認で問題無し有 用 性 比較困難な「空文字・スペース・NULL」が比較可能!HASH化比較で検知! 空文字がスペースに置き換わるバグ
  35. 35. 35この時点でのスケジュール6月1 23 4 5 6 7 8 910 11 12 13 14 15 1617 18 19 20 21 22 2324 25 26 27 28 29 307月1 2 3 4 5 6 78 9 10 11 12 13 1415 16 17 18 19 20 2122 23 24 25 26 27 2829 30 318月1 2 3 45 6 7 8 9 10 1112 13 14 15 16 17 1819 20 21 22 23 24 2526 27 28 29 30 319月12 3 4 5 6 7 89 10 11 12 13 14 1516 17 18 19 20 21 2223 24 25 26 27 28 293010月1 2 3 4 5 67 8 9 10 11 12 1314 15 16 17 18 19 2021 22 23 24 25 26 2728 29 30 3111月1 2 34 5 6 7 8 9 1011 12 13 14 15 16 1718 19 20 21 22 23 2425 26 27 28 29 3012月12 3 4 5 6 7 89 10 11 12 13 14 1516 17 18 19 20 21 2223 24 25 26 27 28 2930 31Super Saleメモリ追加S/W交換Weblogic設定変更NextSuper Sale移行方針検討増強方針検討増強方針検討増強方針検討検証本番検証本番検証メンテナンスメンテ準備開始!メンテまで残り3日!・ 環境掃除・ Full Load&事前同期・ メンテナンス
  36. 36. 363日前!11月1 2 34 5 6 7 8 9 1011 12 13 14 15 16 1718 19 20 21 22 23 2425 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. 372日前!11月1 2 34 5 6 7 8 9 1011 12 13 14 15 16 1718 19 20 21 22 23 2425 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. 381日前!11月1 2 34 5 6 7 8 9 1011 12 13 14 15 16 1718 19 20 21 22 23 2425 26 27 28 29 30決戦前夜!決 戦 前 夜 [11/17 - 22:00] 深夜メンテに向けて仮眠 [11/17 - 23:00] 出社メンテナンスメンテ!
  39. 39. 39メンテナンス作業とリスクヘッジ作 業 サービス停止(2:30) 同期停止 データ整合性確認 トリガー・シーケンス設定 バックアップ取得 サービス再開(5:00)リ ス ク ヘ ッ ジ テーブル毎のリカバリ方法カテゴライズ
  40. 40. 40メンテ!11月1 2 34 5 6 7 8 9 1011 12 13 14 15 16 1718 19 20 21 22 23 2425 26 27 28 29 30メンテナンスメ ン テ ナ ン ス [11/18 - 02:30] サービス停止 [11/18 - 02:45] 差分同期停止 [11/18 - 03:00] データ比較完了データ差分発覚!!残り2時間!
  41. 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. 42メンテ!11月1 2 34 5 6 7 8 9 1011 12 13 14 15 16 1718 19 20 21 22 23 2425 26 27 28 29 30メンテナンスメ ン テ ナ ン ス [11/18 - 02:30] サービス停止 [11/18 - 02:45] 差分同期停止 [11/18 - 03:00] データ比較&差分発覚 [11/18 - 04:10] 差分調査・リカバリ&データ比較残り50分!
  43. 43. 43メンテ!11月1 2 34 5 6 7 8 9 1011 12 13 14 15 16 1718 19 20 21 22 23 2425 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. 44この時点でのスケジュール6月1 23 4 5 6 7 8 910 11 12 13 14 15 1617 18 19 20 21 22 2324 25 26 27 28 29 307月1 2 3 4 5 6 78 9 10 11 12 13 1415 16 17 18 19 20 2122 23 24 25 26 27 2829 30 318月1 2 3 45 6 7 8 9 10 1112 13 14 15 16 17 1819 20 21 22 23 24 2526 27 28 29 30 319月12 3 4 5 6 7 89 10 11 12 13 14 1516 17 18 19 20 21 2223 24 25 26 27 28 293010月1 2 3 4 5 67 8 9 10 11 12 1314 15 16 17 18 19 2021 22 23 24 25 26 2728 29 30 3111月1 2 34 5 6 7 8 9 1011 12 13 14 15 16 1718 19 20 21 22 23 2425 26 27 28 29 3012月12 3 4 5 6 7 89 10 11 12 13 14 1516 17 18 19 20 21 2223 24 25 26 27 28 2930 31Super Saleメモリ追加S/W交換Weblogic設定変更NextSuper Sale移行方針検討増強方針検討増強方針検討増強方針検討検証本番検証本番検証メンテナンスメンテ準備開始メンテナンス残り2週間!・ 新環境⇒旧環境レプリ・ CPU交換・ Oracleパッチ適用・ ノード追加・ 環境整備・ などなど・・・
  45. 45. 45この時点でのスケジュール6月1 23 4 5 6 7 8 910 11 12 13 14 15 1617 18 19 20 21 22 2324 25 26 27 28 29 307月1 2 3 4 5 6 78 9 10 11 12 13 1415 16 17 18 19 20 2122 23 24 25 26 27 2829 30 318月1 2 3 45 6 7 8 9 10 1112 13 14 15 16 17 1819 20 21 22 23 24 2526 27 28 29 30 319月12 3 4 5 6 7 89 10 11 12 13 14 1516 17 18 19 20 21 2223 24 25 26 27 28 293010月1 2 3 4 5 67 8 9 10 11 12 1314 15 16 17 18 19 2021 22 23 24 25 26 2728 29 30 3111月1 2 34 5 6 7 8 9 1011 12 13 14 15 16 1718 19 20 21 22 23 2425 26 27 28 29 3012月12 3 4 5 6 7 89 10 11 12 13 14 1516 17 18 19 20 21 2223 24 25 26 27 28 2930 31Super Saleメモリ追加S/W交換Weblogic設定変更NextSuper Sale移行方針検討増強方針検討増強方針検討増強方針検討検証本番検証本番検証メンテナンスメンテ準備開始セールへ!逆同期CPU交換パッチ適用ノード追加コピー構築環境整備楽天スーパーセール開催!
  46. 46. 462012年12月 楽天スーパーセール※ イメージです
  47. 47. 47ちなみに・・・パ フ ォ ー マ ン ス 最低でも3倍は耐えられる状態にするBefore After Next 検証できる限りの負荷に耐えられることを確認!
  48. 48. 48まとめ性 能 課 題 楽天スーパーセールが乗り切れない増 強 最新IA機への移行移 行 方 法 差分同期データ移行ス ー パ ー セ ー ル 余裕を持って乗り切れたデータ整合性確認 HASH化比較スクリプト
  49. 49. 49まとめ反 省 点 メンテナンス当日に発生したデータ差分バグを事前に見つけられなかった原 因 本番稼働中のDBで、静止点をとった差分比較を行えなかったと は い え レプリケーション製品を導入したことで、準備時間はかなり短縮できた 操作性も高く、検証を何度も気軽に行えた
  50. 50. 502013年6月2日 楽天スーパーセール やります!ご清聴ありがとうございました。

×