How Rakuten Reduced Database Management Spending by 90%

October 17th, 2012 Ryutaro Yada(矢田龍太郎)

Database Platform Group

Global Infrastructure Development Dept. Rakuten, Inc.

楽天事例紹介: Clustrix導入によるDB管理コストの削減

How Rakuten Reduced Database Management Spending by 90%

自己紹介

1

矢田龍太郎

2008年楽天入社

現在の仕事楽天を支えるためのデータベースプラットフォームの開発

新技術や新アーキテクチャの検討、検証、運用にのせるまでの整備

過去の仕事某ベンダーにてOracleビジネス推進

Oracle社と協業し、新ソリューション開発、検証など

Linkedin: http://www.linkedin.com/pub/ryutaro-yada/32/368/4b0

アジェンダ

2

楽天について

楽天のデータベース環境と運用課題

Clustrixとは

Clustrix検証結果と導入効果

まとめ

3

楽天について

楽天の紹介

楽天市場

• 社員数約3000人 (グループ約7000人)

• 市場・トラベルを含む40以上のサービス

• 契約企業数12万社以上登録商品数8000万件以上

• グループ流通額 3.2兆円(2011年)

楽天の海外展開

Our Goal is to become the No. 1 Internet Service in the World

★ ★

★ ★

★ ★

★ ★

★ ★

★ ★

Taiwan

★ ★

★ ★

★ ★

★ ★ ★ ★

★ ★

★ ★

★ ★ ★ ★ ★ ★

★ ★

★ ★

LS(UK)

★ ★

★ ★ Ichiba (EC) ★ ★ Travel ★ ★ Performance marketing

★ ★

★ ★ ★ ★

★ ★ ★ ★

★ ★ ★ ★

★ ★

*To be open soon

http://www.rakuten.de/

グローバルにおける楽天のポジション

• 楽天は、世界一のインターネット企業を目指している

• それを支える強固かつ柔軟性の高いインフラが必要

0

50000

100000

150000

200000

250000

300000

Amazon e-Bay Alibaba Apple Rakuten Walmart

ユニークビジター数による小売／オークションサイトグローバルランキング 2011

出典： comScore Media Metrics

7

楽天のデータベース環境と運用課題

楽天のデータベース

8

データベース数からみた内訳約80％がMySQL (1100以上)

MySQL のデータベースサーバ数 350台以上

MySQLの運用工数が一番大きい

MySQL

Informix

Oracle PostgreSQL Teraddata

本番環境におけるRDBMSごとのデータベース数

STGおよびDEVそれぞれに

同数のデータベース数が存在

MySQLデータベース環境の課題(1)

9

データシャーディング運用性能をスケールさせるために必要

インスタンス/データベース/テーブルの分割、データの再配置

アプリケーションのコード修正、データーベースへのアクセス制御

データ保護、HAの確保レプリケーションでは障害時のデータロスをゼロにできない

障害時の切り替え、切り戻し運用に手間がかかる

MySQLデータベース環境の課題(2)

10

オンラインメンテナンス性スキーマ変更やインデックス追加・再作成

ロック、アクセス集中

台数が多くなりがち負荷分散用のスレーブ、スレーブの冗長構成

個別サービスごとにサーバを用意しがち（サービスレベルの違い、メンテナンス調整回避）

CPU利用効率の低下、データセンターコストの増大

11

Clustrixとは

Clustrixの特徴

12

アプライアンス型データベースサーバー

クラスターデータベース

NewSQL = LegacySQL + NoSQL LegacySQL: SQLアクセス、トランザクション一貫性

NoSQL: スケーラビリティ、ハイパフォーマンス

Fault Tolerance 機能

MySQL互換通常のmysqlプロトコルでアクセスできる

Clustrix提供モデル

13

２つのモデル

Clustrix外観

14

SSD

Infiniband

Low latency

High performance

Clustrixの動作イメージ

15

物理レイヤでデータが分散配置

冗長性の確保、自動リバランス

パラレルクエリー実行 SQL

SQL SQL SQL データでなくクエリを移動させる(Oracle RACとは異なるコンセプト)

TPC-C ベンチマーク結果

16

GUI

17

充実の管理系コマンド

18

Clustrix導入事例

19

日本では楽天が初めて

海外では多数実績あり

20

Clustrix検証結果と導入効果

検証ポイント

21

性能

スケーラビリティ

耐障害検証

オンラインスキーマ変更

OLTP系性能結果(1)

22

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

0

5000

10000

15000

20000

25000

30000

35000

40000

45000

(ops/sec)

Insert


23

p3 p12 p24 p48 p96 p192




0

5000

10000

15000

20000

25000

(ops/sec)

Update


24

p3 p12 p24 p48 p96 p192




0

10000

20000

30000

40000

50000

60000

70000

80000

(ops/sec)

Read


25

p3 p12 p24 p48 p96 p192




0

5000

10000

15000

20000

25000

30000

35000

40000

(ops/sec)

Mix

重いSQLの実行性能比較

26

Clustrix IA with SSD SPARC with SAN

J). 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)

パフォーマンス改善の例

27

あるサービスでのレスポンス改善例

Before 116.8ms

After 21.4ms

耐障害検証

28

Failure Test Items Downtime

1 Front network (port1) No

2 Front network (port2) No

3 Internal network (primary) < 12s

4 Internal network (standby) No

5 MySQL instance < 4s

6 Node OS < 4s

7 Online data disk (SSD) failure < 5s

8 Log/work data disk (SATA) failure No

9 Infiniband switch (primary) < 12s

10 Infiniband switch (standby) No

11 Front network (port1&2) < 18s

12 Internal network (primary&standby) < 12s

DB DB DB

Infiniband SW1 Infiniband SW2

DB

Front SW1 Front SW2

1

3

5,6

2

4

11

12

9 10

7,8

オンラインメンテナンス実行時間

29

Small Medium Large

create column 1.6s 13.5 149.8

create index 1.6s 13.0s 172.7s

drop column 1.5s 13.8s 125.5s

drop index 0.5s 0.5s 0.5s

実行時間

small medium large

row 50,000 500,000 5,000,000

size(byte) 113,639,424 1,063,190,528 10,696,130,560

テーブル行数とサイズ

オンラインスキーマ変更中の影響

30

500万件、10Gの

表に対してオンライン実行

作業対象以外へのアクセス性能影響はなし

作業対象表へのアクセス性能は若干影響あり(夜間などサービスへの影響少ない時間帯を考慮する)

Clustrix導入効果シャーディング運用からの解放(1)

DB DB DB DB

……

…… No more sharding!

DB DB DB DB…… +

Before

After

Clustrix導入効果シャーディング運用からの解放(2)

32

0 2 4 6 8 10 12 14

to-be

as-is

man-month

DBA

APP

アプリ修正不要

DB分割対応不要

アプリエンジニアとDBA双方のシャーディング工数大幅削減（90%以上）

ある大規模シャーディングプロジェクトでの実際の工数を元に比較

Clustrix導入効果集約によるコスト削減(1)

33

十分な性能とスケーラビリティ

ミッションクリティカル並みの耐障害性

データロス無し

他のサービスに影響しない高いオンラインメンテナンス性

既存MySQLデータベースをClustrixに集約可能

Clustrix導入効果集約によるコスト削減(2)

34

既存MySQLをすべてClustrixに集約したとすると

サーバ台数は10分の1

月あたりのシステムコストは4分の1

Current Clustrix

¥

Monthly Database Cost

35

その他

バックアップ構成

36

DB

Node 1

DB DB

Node 2 Node 3

DB

MySQL

NAS

NFS

Backup by mysqldump

Replication

Slave as first

backup

Clustrix

…

データ移行のやり方

37

DBMySQL

Replication

DB DB DB

Clustrix PRO DB DB DB

Clustrix DEV

Replication

DEVへレプリケーションして検証

PROへレプリケーションしてデータ移行

アプリのアクセス先をPROに変更

その他の良い点

38

自動データデフラグメンテーション

手厚いサポートサービス構成に関するアドバイス

トラブルシューティング

チューニングアドバイス

など

39

まとめ

Clustrixにより運用課題が解決

40

データシャーディング運用

データ保護、HAの確保

オンラインメンテナンス

台数が多くなりがち

不要、運用コスト激減

可能

可能

集約可能

コスト削減

楽天におけるClustrix

41

重要なデータベースプラットフォームのひとつ

Database as a Service として提供

リードタイム無し

従量課金制

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

Technology

How Rakuten Reduced Database Management Spending by 90%