How Rakuten Reduced Database Management Spending by 90%

3,887
-1

Published on

How Rakuten Reduced Database Management Spending by 90%

Published in: Technology
1 Comment
16 Likes
Statistics
Notes
No Downloads
Views
Total Views
3,887
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
55
Comments
1
Likes
16
Embeds 0
No embeds

No notes for slide

How Rakuten Reduced Database Management Spending by 90%

  1. 1. 楽天事例紹介: Clustrix導入によるDB管理コストの削減 How Rakuten Reduced Database Management Spending by 90% October 17th, 2012 Ryutaro Yada(矢田 龍太郎) Database Platform Group Global Infrastructure Development Dept. Rakuten, Inc.
  2. 2. 自己紹介 矢田 龍太郎 2008年 楽天入社 現在の仕事  楽天を支えるためのデータベースプラットフォームの開発  新技術や新アーキテクチャの検討、検証、運用にのせるまでの整備 過去の仕事  某ベンダーにてOracleビジネス推進  Oracle社と協業し、新ソリューション開発、検証 など  Linkedin: http://www.linkedin.com/pub/ryutaro-yada/32/368/4b0 1
  3. 3. アジェンダ楽天について楽天のデータベース環境と運用課題ClustrixとはClustrix検証結果と導入効果まとめ 2
  4. 4. 楽天について 3
  5. 5. 楽天の紹介• 社員数 約3000人 (グループ 約7000人)• 市場・トラベルを含む40以上のサービス• 契約企業数12万社以上 登録商品数8000万件以上• グループ流通額 3.2兆円(2011年) 楽天市場
  6. 6. 楽天の海外展開 Our Goal is to become the No. 1 Internet Service in the WorldLS(UK) ★★ ★ ★ ★ ★★ ★ ★ ★★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★★ ★ ★★ ★ ★ ★ ★★ ★ ★ ★ ★★ ★ ★★ Taiwan ★ ★ ★ ★ *To be open soon ★ ★ ★ ★ ★ Ichiba (EC) ★ Travel ★ Performance marketing ★ ★ ★
  7. 7. グローバルにおける楽天のポジション• 楽天は、世界一のインターネット企業を目指している• それを支える強固かつ柔軟性の高いインフラが必要 ユニークビジター数による小売/オークションサイト グローバルランキング 2011 300000 250000 200000 150000 100000 50000 0 Amazon e-Bay Alibaba Apple Rakuten Walmart 出典: comScore Media Metrics
  8. 8. 楽天のデータベース環境と運用課題 7
  9. 9. 楽天のデータベース データベース数からみた内訳 約80%がMySQL (1100以上) MySQL のデータベースサーバ数 350台以上 MySQLの運用工数が一番大きい Oracle PostgreSQL Teraddata  本番環境におけるRDBMS Informix ごとのデータベース数  STGおよびDEVそれぞれに 同数のデータベース数が 存在 MySQL 8
  10. 10. MySQLデータベース環境の課題(1) データシャーディング運用  性能をスケールさせるために必要  インスタンス/データベース/テーブルの分割、データの再配置  アプリケーションのコード修正、データーベースへのアクセス制御 データ保護、HAの確保  レプリケーションでは障害時のデータロスをゼロにできない  障害時の切り替え、切り戻し運用に手間がかかる 9
  11. 11. MySQLデータベース環境の課題(2) オンラインメンテナンス性  スキーマ変更やインデックス追加・再作成  ロック、アクセス集中 台数が多くなりがち  負荷分散用のスレーブ、スレーブの冗長構成  個別サービスごとにサーバを用意しがち(サービスレベルの違い、 メンテナンス調整回避)  CPU利用効率の低下、データセンターコストの増大 10
  12. 12. Clustrixとは 11
  13. 13. Clustrixの特徴 アプライアンス型データベースサーバー クラスターデータベース NewSQL = LegacySQL + NoSQL  LegacySQL: SQLアクセス、トランザクション一貫性  NoSQL: スケーラビリティ、ハイパフォーマンス Fault Tolerance 機能 MySQL互換  通常のmysqlプロトコルでアクセスできる 12
  14. 14. Clustrix提供モデル 2つのモデル 13
  15. 15. Clustrix外観 SSD Infiniband  Low latency  High performance 14
  16. 16. Clustrixの動作イメージ 物理レイヤでデータが分散配置 冗長性の確保、自動リバランス パラレルクエリー実行 SQL SQL SQL SQL  データでなくクエ リを移動させる (Oracle RACとは異 なるコンセプト) 15
  17. 17. TPC-C ベンチマーク結果 16
  18. 18. GUI 17
  19. 19. 充実の管理系コマンド 18
  20. 20. Clustrix導入事例 日本では楽天が初めて 海外では多数実績あり 19
  21. 21. Clustrix検証結果と導入効果 20
  22. 22. 検証ポイント 性能 スケーラビリティ 耐障害検証 オンラインスキーマ変更 21
  23. 23. OLTP系性能結果(1) Insert 45000 40000 35000 30000 25000(ops/sec) 20000 15000 10000 5000 0 p3 p12 p24 p48 p96 p192 Single Throughput 4014.703409 8350.801098 10022.32827 10448.25479 10520.08066 10213.98278 Clx 3 nodesThroughput 6301.603599 18530.31626 26182.77331 30021.30841 27581.92104 24401.28904 Clx 4 nodes Throughput 6090.513193 20584.42 30544.8252 38545.21774 36837.10176 33221.72529 22
  24. 24. OLTP系性能結果(2) Update 25000 20000 15000(ops/sec) 10000 5000 0 p3 p12 p24 p48 p96 p192 Single Throughput 3854.243586 8018.593249 12186.20793 13385.77834 13395.06587 11538.29668 Clx 3 nodes Throughput 3377.359372 10741.77417 16505.79652 16964.01107 16189.88416 15379.62683 Clx 4 nodes Throughput 3682.99886 12679.26966 19737.63815 22232.7357 21568.39318 21303.72872 23
  25. 25. OLTP系性能結果(3) Read 80000 70000 60000 50000(ops/sec) 40000 30000 20000 10000 0 p3 p12 p24 p48 p96 p192 Single Throughput 6134.386466 26773.71202 44388.78477 56144.27281 57926.62433 49362.51106 Clx 3 nodes Throughput 5050.230295 17380.6806 27803.82494 39693.75633 49822.34026 56847.77879 Clx 4 nodes Throughput 5959.900064 20794.2083 34743.31655 54382.96419 70302.27313 76000.59175 24
  26. 26. OLTP系性能結果(4) Mix 40000 35000 30000 25000(ops/sec) 20000 15000 10000 5000 0 p3 p12 p24 p48 p96 p192 Single Throughput 3976.841546 8587.218158 11632.64122 12946.2536 13122.33748 12769.45794 Clx 3 nodes Throughput 3113.109431 12940.99191 21264.63309 26759.75291 25976.26625 25334.18054 Clx 4 nodes Throughput 5150.537999 15220.8469 25601.67909 34647.41616 34697.737 30804.09949 25
  27. 27. 重いSQLの実行性能比較 Clustrix IA with SSD SPARC with SANJ). Count+GroupBy+OrderBy+Limit 1.9s (3.4s) 2.1s (8.5s) 3.4s (409.32s)K). Count+GroupBy+OrderBy+Limit 0.7s (1.13s) 5.9s (7.49s) 13.0s (39.41s) L). 2000 of IN+GroupBy 3.8s (8.97s) 106.5s (103.77s) 193.0s (321.68s) M). Case+OrderBy 31.0s (45.66s) 47.3s (60.9s) 90.5s (112.24s) 26
  28. 28. パフォーマンス改善の例 あるサービスでのレスポンス改善例 Before 116.8ms After 21.4ms 27
  29. 29. 耐障害検証 Failure Test Items Downtime1 Front network (port1) No2 Front network (port2) No3 Internal network (primary) < 12s4 Internal network (standby) No Front SW1 Front SW25 MySQL instance < 4s 16 Node OS < 4s 117 Online data disk (SSD) failure < 5s 2 DB DB DB DB8 Log/work data disk (SATA) failure No 5,6 7,8 4 129 Infiniband switch (primary) < 12s 310 Infiniband switch (standby) No 10 911 Front network (port1&2) < 18s Infiniband SW1 Infiniband SW212 Internal network (primary&standby) < 12s 28
  30. 30. オンラインメンテナンス実行時間テーブル行数とサイズ small medium large row 50,000 500,000 5,000,000 size(byte) 113,639,424 1,063,190,528 10,696,130,560実行時間 Small Medium Largecreate column 1.6s 13.5 149.8create index 1.6s 13.0s 172.7sdrop column 1.5s 13.8s 125.5s drop index 0.5s 0.5s 0.5s 29
  31. 31. オンラインスキーマ変更中の影響 作業対象以外へのアクセス性能影響はなし 作業対象表へのアクセス性能は若干影響あり(夜間な どサービスへの影響少ない時間帯を考慮する)  500万件、10Gの 表に対してオンラ イン実行 30
  32. 32. Clustrix導入効果 シャーディング運用からの解放(1)Before …… DB DB DB DB …… No more sharding!After DB DB DB DB …… +
  33. 33. Clustrix導入効果 シャーディング運用からの解放(2)  アプリ修正不要  DB分割対応不要  アプリエンジニアとDBA双方のシャーディング工 数大幅削減(90%以上)  ある大規模シャーas-is ディングプロジェ クトでの実際の工 数を元に比較to-be DBA APP 0 2 4 6 8 10 12 14 man-month 32
  34. 34. Clustrix導入効果 集約によるコスト削減(1) 十分な性能とスケーラビリティ ミッションクリティカル並みの耐障害性 データロス無し 他のサービスに影響しない高いオンラインメン テナンス性 既存MySQLデータベースをClustrixに集約可能 33
  35. 35. Clustrix導入効果 集約によるコスト削減(2) 既存MySQLをすべてClustrixに集約したとすると サーバ台数は10分の1 月あたりのシステムコストは4分の1 Monthly Database Cost ¥ Current Clustrix 34
  36. 36. その他 35
  37. 37. バックアップ構成 ClustrixDB DB DB … Node 1 Node 2 Node 3 Replication Slave as first backup Backup by mysqldump MySQL DB NFS NAS 36
  38. 38. データ移行のやり方  DEVへレプリケーションして検証  PROへレプリケーションしてデータ移行  アプリのアクセス先をPROに変更 MySQL DB Replication Replication Clustrix DEV Clustrix PRO DB DB DBDB DB DB 37
  39. 39. その他の良い点 自動データデフラグメンテーション 手厚いサポートサービス  構成に関するアドバイス  トラブルシューティング  チューニングアドバイス  など 38
  40. 40. まとめ 39
  41. 41. Clustrixにより運用課題が解決 データシャーディング運用  不要、運用コスト激 減 データ保護、HAの確保  可能 オンラインメンテナンス  可能 台数が多くなりがち  集約可能  コスト削減 40
  42. 42. 楽天におけるClustrix 重要なデータベースプラットフォームのひとつ Database as a Service として提供 リードタイム無し 従量課金制 41
  43. 43. Clustrixセッションのご紹介• Robin Purohit, CEO of Clustrix  18 October at 11:00 in Room B  Session: Drive the New Wave of Big Data Applications with the Clustrix Relational Database Solution• Parrish  19 October at 11:00 in Room B  Technical Session: The Architecture of a Distributed Database for High Performance Applications• If you have questions, you can talk with Clustrix representatives at the Clustrix booth 42
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×