楽天市場を中心に多くのサービスを展開する楽天グループ。 サービスの根幹を支えるデータベースシステムでは、異なるフラッシュストレージを適材適所で使い分けています。「フラッシュストレージ＝DB高速化」が常識となりつつありますが、楽天がフラッシュストレージを使う狙いは、他にもあるようです。 本セッションでは、サービス要求に応えるべく日々奮闘する楽天のインフラエンジニアが登壇。増加の一途をたどるサービス数、データサイズ、アクセス数、DB数……そんな激動のインフラをどう安定的に稼働させているのか、プライベートクラウドにおけるフラッシュストレージの導入を中心に、その裏側を明かします。 また、種々のストレージを運用した経験から、フラッシュストレージと他のストレージの違いについてもお伝えします。

1. 楽天プライベートクラウドを支える
フラッシュストレージ
Feb/22/2017
Koichi Takaizumi
Server Platform Group, Rakuten, Inc.

2. 2
Rakuten, Inc.
Founded: February 7, 1997
IPO: April 19, 2000 (JASDAQ Stock Exchange)
Office: Rakuten Crimson House (Tokyo, Japan)
Employees: 12,981 (as of Dec, 2015)

3. 3

4. 4

5. 5
 楽天のシステム概要/規模
 楽天のストレージの歴史
 ALL-Flashのメリット、デメリット
 PoCのポイント

6. 6
Overview
概要/規模

7. VMs
7
27000+ VMs
2012 2016

8. Provisioning
8
500+ VMs/month
2016/01 2016/08

9. Hosts
9
900+ hosts
2015 2016

10. Storage (Production)
10
0.0 TB
200.0 TB
400.0 TB
600.0 TB
800.0 TB
1000.0 TB
1200.0 TB
1400.0 TB
1600.0 TB
1800.0 TB
2014-04
2014-05
2014-06
2014-07
2014-08
2014-09
2014-10
2014-11
2014-12
2015-01
2015-02
2015-03
2015-04
2015-05
2015-06
2015-07
2015-08
2015-09
2015-10
2015-11
2015-12
2016-01
2016-02
2016-03
2016-04
2016-05
2016-06
2016-07
2016-08
Storage Capacity (Overall Production Env)
TTL USED
2014 2016
1600+ TB

11. 11
All Flash Array 数
2013 2014 2015
1 4
10
2016
12

12. 12
ストレージカタログ
Type IOPS Availability Latency
High No-Limit 99.999% 10ms
Standard 500 99.999% 20ms
Dev/Stg 500 99.99% Best Effort

13. 13
物理構成とストレージカタログ
High
All-Flash
Standard
Hybrid HDD
Dev/Stg

14. 14
カタログ別使用率
60
15
15
10

15. 15
種類別使用率(論理サイズ)
40
5
55

16. 16
物理構成とストレージカタログ
High
All-Flash
Standard
Hybrid HDD
Dev/Stg

17. 17
History
楽天のストレージの歴史

18. 18
200x

19. 19
200X
SAN + SPARC
• Sun Microsystems SF10k, SF15k, SF25k, v480
• SAN Storage, 15K Disk, 10K Disk
• 4 fabric
…
…

20. 20
201x

21. 21
physical virtual

22. 22
201x
Rakuten Infrastructure as a Service

23. 23
201x～ のRIaaS構成
Fabric Network
(10GbE, 8,16G FC)
StorageBlade Server
1U Server
VMware

24. 24
用途
 Web, DB, Batch, SAP, VDI
 Linux, Windows

25. 25
Pros and Cons
ALL-Flashのメリット、デメリット

26. 26
Performance
0
5000
10000
15000
20000
25000
H社 SSD H社 10000 FC
IOPS

27. 27
IO Performance
 New Search
i ndex=i dx_ common_ 3y sour cet ype=pur est r g_ moni t or | r egex Name="^ . *$" | r egex host name="^ . *$" |
t i mechar t span=1m sum( ops_ r ead) as r ead sum( ops_ wr i t e) as wr i t e
Date tim e range
 5,280 events (8/28/14 7:30:00.000 PM to 8/28/14 11:30:00.000 PM )
_time
read
write
8:00 PM
Thu Aug 28
2014
9:00 PM 10:00 PM 11:00 PM
100,000
25,000
50,000
75,000
Visualization
✓5,280 events (8/28/14 7:30:00.000 PM to 8/28/14 11:30:00.000 PM )
_time
read_ latency
write_ latency
8:00 PM
Thu Aug 28
2014
9:00 PM 10:00 PM 11:00 PM
2
4
6
_tim e ↕ read_latency ↕ write_latency ↕
2014-08-28 19:30:00 1.082000 0.556000
2014-08-28 19:31:00 0.821000 0.715000
2014-08-28 19:32:00 0.777000 0.713000
2014-08-28 19:33:00 0.744000 0.584000
Visualization
Latency [msec]
IOPS

28. 28
Cost

29. 29
Tiering

30. 30
The issue of Auto Tiering
• Latency spikes during region moves2014- 05- 24
Read ServiceTim e
Write ServiceTim e
00:00 01:00 02:00 03:00 04:00 05:00 06:00 07:00 08:00 09:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00
0
200
400
600
800
Running Not running
• To been addressed.
• To reduce the impact ,
we migrated top-tier VMs from FC to SSD

31. 31
All Flash
 New Search
i ndex=i dx_ common_ 3y sour cet ype=pur est r g_ moni t or | r egex Name="^ . *$" | r egex host name="^ . *$" |
t i mechar t span=1m sum( ops_ r ead) as r ead sum( ops_ wr i t e) as wr i t e
Date tim e range
 5,280 events (8/28/14 7:30:00.000 PM to 8/28/14 11:30:00.000 PM )
_time
read
write
8:00 PM
Thu Aug 28
2014
9:00 PM 10:00 PM 11:00 PM
100,000
25,000
50,000
75,000
Visualization
✓5,280 events (8/28/14 7:30:00.000 PM to 8/28/14 11:30:00.000 PM )
_time
read_ latency
write_ latency
8:00 PM
Thu Aug 28
2014
9:00 PM 10:00 PM 11:00 PM
2
4
6
_tim e ↕ read_latency ↕ write_latency ↕
2014-08-28 19:30:00 1.082000 0.556000
2014-08-28 19:31:00 0.821000 0.715000
2014-08-28 19:32:00 0.777000 0.713000
2014-08-28 19:33:00 0.744000 0.584000
Visualization
Latency [msec]
IOPS

32. 32
Migration

33. 33
FC to FC

34. 34
Flash to Flash

35. 35
All Flash Storage のメリット
 圧倒的な高IO、低遅延
 Tieringストレージと比べてリーズナブルなSSD単価
 性能問題からの解放
 問い合わせ激減
 階層間移動(Tiering)時の影響なし
 オンラインアップグレード時の影響低下
 マイグレーションの自由
 Disk故障の減少 => 運用コストの低下

36. 36
All Flash導入から3年以上
 導入以来、大きな障害はほぼゼロ
 SSD壊れにくい, 10件以下
 重複排除ストレージについては新たな考慮点も
 キャパシティ計画が難しい
 パフォーマンスペナルティ

37. 37
課題
パフォーマンスペナルティ
高負荷になると容量を消費することも
サイジング
どれくらいリダクションされるのか？
突然のパフォーマンス低下, 既圧縮データ
マイグレーションの自由
オペレーションの増加
 NANDの供給不足

38. 38
System使用領域の増減

39. 39
Point of PoC
PoCのポイント

40. 40
これまでに検証したプロダクト
 Violin
 Nimbus
 StoreVirtual VSA
 PureStorage
 Nutanix
 VSAN
 3Par
 XtremIO
 NimbleStorage
 NetApp cDOT
 ScaleIO

41. 41
Requirement
必要な機能は？
必要な性能は？
状態を確認できるか？
コスト

42. 42
選定基準
• Work
• 基本機能、望むファンクションが機能するか？
• HA
• H/W障害、復旧時のインパクトは？復旧までの時間
• Performance
• 望むパフォーマンスが出るか？
• Visibility
• フェイルを通知、検知できるか？
• 性能限界点等を見積もれるか？

43. 43
多角的な観点でのPoC
 Yen/GB
 Yen/IOPS
 消費電力（ランニングコスト）
 可用性
 SPOF (Single Point of Failure)
 制限事項の確認、volume数、サイズ、ホスト数、…
 管理性
 IOパフォーマンス（IOPS、Latency)
 サイジング指標
 重複排除 / 圧縮
 VAAIサポート

44. 44
事前検証（PoC）の重要性
 カタログスペックとは？
 ミックスワークロード vs 4K Read
 ロングラン
 計画テイクオーバ時の影響
 障害テイクオーバ時の影響
 圧縮/重複排除有効時のパフォーマンスは安定している
か
 電力 （ランニングコスト）
 PoC と現実の違い

45. 45
データリダクション
 Free GBをチェックする
 Used GB = Capacity GB– Free GB
 システムが消費するGB、共通使用領域で消費するGB等
 圧縮済みのデータ、重複排除済みのデータ

46. 46
パフォーマンス測定
 毎秒測定 IOPS, Latency , iostat
 クライアントサイドで測定
 想定する IOサイズ、Read/Write率で測定
 ioblazer, vdbench
 使用率 80% 以上
 ロングラン (2日以上)
 パフォーマンス測定時はUsed GBの変化もチェック
 圧縮/重複排除有効時のパフォーマンス

47. 47
HA,障害検証
 IO負荷かけ続けた状態
 毎秒測定 IOPS, Latency
 shutdown, takeover , 計画停止
 交換可能モジュールを物理的に外す(ベンダーの許可)
 SSD, HDD
 FC, iSCSI ケーブル
 電源ボタン、ケーブル
 SASケーブル
 …

48. 48
H/A
Hot-swap IO Wait [sec]
priority expected actual result priority expected actual result
Controller 1 Yes Yes 1 60 sec 60sec
Shelf I/O Module 1 Yes Yes 1 60 sec 3 sec
decrease
performance
75%
SSD 1 Yes Yes 1 0 sec 0 sec
decrease
performance
50%
NVRAM 1 Yes Yes 1 0 sec Under 5sec
Power Supplies 1 Yes Yes 1 0 sec 0 sec
iSCSI Cable 1 Yes Yes 1 60 sec 60 sec
SAS Cable 1 Yes Yes 1 60 sec 0 – 16 sec
IB Cable 1 Yes Yes 1 0 sec 6 sec
Fans 1 Yes Yes 1 0 sec (60 sec)
Priority
1:Must
2:Nice to have
3:Don’t care

49. 49
Error Trap / Healthy Visibility
Mail/SNMP Trap/Logging GUI/CLI Visibility
priority expected actual result priority expected actual result
Controller 1 Yes Yes 1 Yes Yes
Shelf I/O Module 1 Yes Yes 1 Yes Yes
SSD 1 Yes Yes 1 Yes Yes
NVRAM 1 Yes Yes 1 Yes Yes
Power Supplies 1 Yes Yes 1 Yes Yes
iSCSI Cable 1 Yes Yes 1 Yes Yes
SAS Cable 1 Yes Yes 1 Yes Yes
IB Cable 1 Yes Yes 1 Yes Yes
Fans 1 Yes non-
removable
1 Yes Yes
Priority
1:Must
2:Nice to have
3:Don’t care

50. 50
例）コントローラ障害時の性能劣化
○ 最大70msecのレイテンシが10秒間発生

51. 51
例）コントローラ障害時の性能劣化
☓ 約5分間IOPSが10,000->700に低下

52. 52
ロングラン

53. 53
5 minutes

54. 54
48hours

55. 55
重複排除

56. 56
例）重複排除機能による性能劣化
○ 重複排除OFF時、安定した性能

57. 57
例）重複排除機能による性能劣化
× 重複排除ON時、IOPS大幅低下。不安定な性能

58. 58
Feature
期待

59. 59
あったらいいな
障害時のサービス復旧時間 1秒以下

60. 60
Wrap up
まとめ

61. 61
まとめ
今では Flash ありき
電力消費量 == ランニングコスト
各ベンダー H/W に大きな違いはないが…
データリダクションは容量見積が難しい
PoCは必須
パフォーマンス = CPU + (GB)
新興ベンダー
老舗ベンダー

62. 62
さいごに

63. 63

64. 64
ご清聴ありがとうございました