ヤフーを支えるフラッシュストレージ

ヤフーを支える
フラッシュストレージ
ヤフー株式会社
宇佐美茂正

自己紹介
• 氏名：宇佐美茂正（うさみしげまさ）
• 勤務先：ヤフー株式会社
• 職種：DBA
• 業務
• DB環境構築
• DB運用業務
• SQLチューニング
• DB監査
※ Oracle Database 関連の業務を主に行っています
Copyright (C) 2016 Yahoo! Japan Corporation. All Rights Reserved. 無断引用・転載禁止
2

このセッションの概要
弊社のOracle Databaseを稼動させるシステム構成として、
過去にどのようなものが採用されてきたのかをご紹介し
ます
そして、過去の構成で問題となった点を明らかにし、そ
れに対してどういったアプローチで解決させたのかを説
明させて頂きます
3

アジェンダ
1. Yahoo! JAPANのRDB運用状況
2. Oracle環境のこれまでの構成と問題点
3. 次世代構成の選定
4. フラッシュストレージ導入の必要性
4

１．Yahoo! JAPANのRDB運用状況
5

多種多様なサービス
6

KVS
社内で運用しているデータ関連のプラットフォーム
7
RDB
DWH

KVS
社内で運用しているデータ関連のプラットフォーム
8
RDB
DWH

Yahoo! JAPANのRDB運用チーム
• 2005年頃発足
• DBAのスペシャリスト集団
• 現在は正社員15名+業務委託4名
• 運用しているデータベース数
• Oracle 242個
• MySQL 635個
• チームの目的
• RDBの集約管理
• 運用コストの削減
• 社内へのRDB教育
• 次世代構成の検討
• RDB技術の最新情報の収集
9

Yahoo! JAPANでのOracle,MySQLの住み分け
• Oracle
• ミッションクリティカルなサービス
• セキュアのデータを扱うサービス
• 処理量が多いサービス
• 会計・勘定系サービス
• MySQL
• Web系のサービス
• Oracleの必要がないサービスはMySQL推奨
• 2016年からセキュアのデータも扱う（自社で監査システムを
作成）
10

全社Oracle環境に求められているもの
• 高いパフォーマンス
• 高い可用性
• 安定運用
• BCP
• 強固なセキュリティ
昨今、Oracleを利用する案件は、性能、可用性、BCP、セ
キュリティ等の要望レベルが非常に高くなっています
そうでない案件はMySQLが選択される事が多い為です
特に、赤文字３つの項目が重要視されています
11

2． Oracle環境のこれまでの構成と問題点
12

2005年~2010年第一世代
13
• シングルインスタンス
• Oracle 9i or 10g
• ミッドレンジサーバ
（冷蔵庫みたいなやつ）
• メモリ 64G〜128G
• 商用ストレージ(HDD)
• Solaris
• HA Softwareによる冗長化
• FCによる接続
• 内部でコントローラ冗長化
アプリケーション
データベースサーバー
ストレージサーバー

第一世代のイメージ
14
FCFC
GR03_LUN
GR02_LUN
GR01_LUN
Storage
DB DB DB
VOL
VIP
GR01
DB DB DB
VOL
VIP
GR02
DB DB DB
VOL
VIP
GR03
DB node 3DB node 1 DB node 2
Fail Over

2005年~2010年第一世代
15
GOOD
• 高価
• Solarisが社内非標準
• 筐体が大きい
• 無停止構成ではない
• 高価
• オペレーションがベンダー
頼り
• 筐体が大きい
• 安定
• メモリたくさん
• 高速
• 安定
• 運用中ダウン0
GOOD BAD

2010年~ 第二世代
16
• Oracle RAC
• Oracle 11gR2
• 1Uのサーバ
• メモリ 72G
• 1G eth NIC (Interconnect)
• 10G eth NIC/SFP (Storage)
•商用ストレージ(HDD)
• OracleLinux
• Oracle Grid Infrastructureに
よる冗長性
• iscsiによる接続
• Oracle ASMによる冗長化

第二世代のイメージ
17
storage node 03storage node 02
Oracle GI(Grid Infrastructure)
DB node 1 DB node 2 DB node 3
Oracle ASM (Auto Storage Manager)
Instance
Node 1
Instance
Node 2
Instance
Node 3
RAC DB
LUN06
LUN05
LUN04
LUN03
LUN02
LUN01
10G eth Network
storage node 01

18
• OracleRAC
• インターコネクト通信がボ
トルネックに(NW帯域)
• IO性能がボトルネックに
• 安価
• 安定
• 1U
• 比較的安価
• 安定
• オペレーションしやすい
GOOD
BAD

19

2010年~ 第二世代課題
• インターコネクト通信での待機が発生
• キャッシュフュージョン
(Oracleインスタンス間でバッファキャッシュを共有する機能）
20

2010年~ 第二世代課題
• インターコネクト通信での待機が発生
• キャッシュフュージョン
(Oracleインスタンス間でバッファキャッシュを共有する機能）
• ディスクへの読み書きがボトルネックに
21

2010年~ 第二世代課題事例①
• 広告の入稿システムがIOのボトルネックで遅延
• 競合他社よりかなり遅い
22

2010年~ 第二世代課題事例②
• メール配信PFの処理がデータ量増加とともに遅延
• バッチ処理が12時間ほどかかってしまう
• 1日2300回APIがタイムアウトしてしまう
23

2014年~ 第三世代
24
• Oracle RAC
• Oracle 11gR2
• 1Uのサーバ
• メモリ 128G
• InfiniBand HCA搭載
• 1Uのサーバ
• メモリ 32G
• PCIe-SSDカード2枚搭載
• Oracle Linux
よる冗長化
• ISer (iSCSI Extention for
RDMA)による接続

第三世代のイメージ
25
Oracle ASM (Auto Storage Manager)
IB HCA IB HCA IB HCA IB HCA IB HCA IB HCA
DB Instance 1 DB Instance 2 DB Instance 3
Oracle Grid Infrastructure
IB HCA IB HCA
PCI-SSD PCI-SSD
Partition 1 Partition 1
IB HCA IB HCA
PCI-SSD PCI-SSD
IB HCA IB HCA
PCI-SSD PCI-SSD
Storage node 1 Storage node 2 Storage node 3
RAC DB
IB HCA IB HCA
PCI-SSD PCI-SSD
IB HCA IB HCA
PCI-SSD PCI-SSD
IB HCA IB HCA
PCI-SSD PCI-SSD
Storage node 4 Storage node 5 Storage node 6
Network 01(56Gbps)
InfiniBand Switch InfiniBand Switch
Network 02(56Gbps)
DB node 1 DB node 2 DB node 3

2014年~
26
• OracleRAC
• Iserでメモリの断片化が発
生
• 台数を並べる必要がある
• オンラインでディスクの切
り直しができない
• 安価
• 1U
• かなり安価
• HDDよりかなり高速
• 1U
GOOD
BAD

2014年~ 第三世代効果
• インターコネクト通信をInfinibandにしたことで遅延解
消
27

2014年~ 第三世代効果
• インターコネクト通信をInfinibandにしたことで遅延解
消
• HDDをPCIe-SSDにした事でIOボトルネック解消
28

• データベースの待機クラスが大幅に変化
• I/Oの待機が大幅に減少
• CPU処理時間が大半の割合を占めるようになった
29
Wait Class 項目
HDD x iSCSI
第二世代
PCI-SSD x IB (iSer)
第三世代
User I/O
DB Time(%) 79.3 3.5
Avg Wait(ms) 53 0
Commit
DB Time(%) 4.3 0.2
Avg Wait(ms) 83 1
Cluster
DB Time(%) 3.7 0.4
Avg Wait(ms) 12 0
DB CPU
DB Time(%) 13.7 56.3
Avg Wait(ms) - -

• その結果、SQL性能も大幅に良くなりました
• 処理スピードが10～20倍に
競合他社とも引けをとらない性能となった
30
対象SQL 比較項目
従来構成
HDD x 10G
新構成
SSD x IB
SQLその１
実行時間(s) 10.63 0.10
I/O時間 10.41 0.07
DB CPU(%) 0.6 32.1
I/O(%) 97.9 70.6
SQLその2
実行時間(s) 20.29 0.13
I/O時間 20.18 0.09
DB CPU(%) 0.5 33.1
I/O(%) 99.5 70.6

31

→バッチ処理が10時間→2時間に
→1日2300回のタイムアウトが1日0~1回に
32

2014年~ 第三世代 DBサーバー課題
• Iserの部分でデータベースサーバーのメモリが断片化し
てしまう
• ほうっておくとメモリの獲得に失敗してしまい、OSダウン
• 根本的に解決する方法がなく、定期的にOS再起動などで対応
33

2014年~ 第三世代 STサーバー課題①
• PCIe-SSDの1枚の容量がおよそ2Tほどで横に台数を並べ
ないと容量が確保できない
• 障害点増加、管理煩雑
• 一番多い基盤で現在18台運用
34

35
ASMで2重化
ストレージサーバー18台

36
ASMで2重化
必ずどこか２台にデータが書かれている状態

37
ASMで2重化
１台で障害発生
障害発生

38
ASMで2重化
１台で障害ASMが障害発生した機器をサービスアウト
データのリバランスを行います。
障害発生
リバランス処理

39
ASMで2重化
障害発生
リバランス完了

40
ASMで2重化
リバランスが完了した段階で、正常復旧
データの２重化が保証されます
サービスアウト

41
ASMで2重化
リバランス中は冗長化されてないデータが存在
障害発生

42
ASMで2重化
もしもリバランス処理中に二重障害が発生
したらデータの冗長性が保てなくなり、
データベースが停止してしまいます
障害発生
障害発生

43
ASMで2重化
当然台数が多いとこのリスクは高まります
障害発生
障害発生

44
ASMで2重化
回避策
• データを3重化する
→管理するサーバーが増えてしまう
→予算的に厳しい
→書き込みが遅くなる
障害発生
障害発生

2014年~ 第三世代 STサーバー課題②
45
DBサーバー3台基盤１ DBサーバー3台基盤２
それぞれのデータベースサーバーが
ストレージサーバーを見ています

46
SSDカード SSDカード
1台につき2枚SSDカードがささっています

47
基盤1
基盤2
基盤1
基盤2
中でパーティションを切っています

48
基盤1
基盤2
基盤1
基盤2
基盤２で増やしたくなった時、

49
基盤1
基盤2
基盤1
基盤2
オンラインでは切り直し不可能

50
基盤1
基盤2
基盤1
基盤2
すべてのセッションを一度切らないといけません

51
1台ずつ順番にセッションを切って切りなおします

これを手順で表すと
1. ASMから対象のストレージサーバーをOFFLINE
2. 対象のストレージサーバーからiscsiログアウト
3. 2を全データベースサーバー分実施
4. STサーバーのSSDのパーティションを切り直し
5. 対象のストレージサーバーにiscsiログイン
6. ASMから対象のストレージサーバーをONLINE
7. 1~6をストレージ台数分実施
とても大変
52

Oracle環境の課題まとめ
• IO性能がボトルネック
• 解消するためPCIe-SSD+Infiniband構成(第三世代)を構築
→処理速度はかなり速くなったが、
• メンテナンスの煩雑化、障害点増加
• PCIe-SSDでは容量に制限があるため、どうしてもストレージ
台数が増えてしまう
• オンラインでデバイスの切り直しができない
→事故が増えた…
53

次世代構成のストレージに求められる要件
以上のことから次世代構成のストレージは
• 容量が多い（少ない台数で済む）
• 高性能（PCIe-SSDにも引けをとらない）
• オンラインメンテナンス可能
• ストレージ間通信の安定
• ストレージ側での冗長性担保
上記を満たしている事が理想
54

3.次世代構成の選定
55

選定候補
前段の要求に見合ったストレージを模索
• 第一候補
• NVMe x SDS ( Software Defined Storage )の構成
• 第二候補
• ALL Flash Storage x FC ( SCSI )の構成
56

候補1 NVMe x SDS
57
• Oracle RAC
• Oracle 12cR1
• 1Uのサーバ
• メモリ 256G
• 1Uのサーバ
• メモリ 64G
• NVMeカード2枚搭載
• Oracle Linux
よる冗長化
• 10G ethによる接続
• SDS ( Software
Defined Storage ) によ
る管理

候補１のイメージ
58
Oracle ASM
RAC DB
DB
Instance
DB
Instance
DB
Instance
Core Switch
Edge Switch
10G Switch
(Storage & Interconnect)
10G Switch
(Storage & Interconnect)
ST node 1 ST node 2 ST node 3
• Service NW
• 1Gbps NW x 1
• Bonding
• Interconnect NW
• 10Gbps x 2
• Bonding (mode 6)
• Storage NW
• SDS ( 独自プロトコル)
• 10Gbps NW x 2
• bonding (mode 6)

候補2 ALL Flash Storage x FC(SCSI)
59
• Oracle RAC
• Oracle 12cR1
• 1Uのサーバ
• メモリ 256G
• ALL Flash Storage
• Oracle Linux
よる冗長化
• FC ( SCSI )による接続
• 内部コントローラ冗長化

候補２のイメージ
60
Oracle ASM
RAC DB
DB
Instance
DB
Instance
DB
Instance
Core Switch
16G FC Switch
FC SAN 01
16G FC Switch
FC SAN 02
Edge Switch
Flash Storage 02Flash Storage 01
10G Switch
Interconnect NW 01
10G Switch
Interconnect NW 02
• Service NW
• 1Gbps NW x 1
• Bonding
• Interconnect NW
• 10Gbps NW x 2
• Storage NW
• 16Gbps FC SAN x 2
• Multipath ( 4 path)

性能比較
• Caribrate IO
• Oracle社提供の単純なIO性能測定プロシージャ
• Swingbench
• 元Oracle社エンジニアが作成したフリーベンチマークツール
• http://dominicgiles.com/swingbench.html
61

Caribrate IO
(I/O性能比較)
62

MAX IOPS(最大秒間I/Oリクエスト)
63
268875
1153229
1258268 1269320
0
200000
400000
600000
800000
1000000
1200000
1400000
HDD x iSCSI
第二世代
PCI-SSD x IB(iSer)
第三世代
NVMe x SDS
候補１
ALL Flash Storage x
FC(SCSI)
候補２
MAX IOPS

MAX IOPS(最大秒間I/O転送量)
64
3085
17516
8788
14594
0
2000
4000
6000
8000
10000
12000
14000
16000
18000
20000
HDD x iSCSI
第二世代
PCI-SSD x IB(iSer)
第三世代
NVMe x SDS
候補１
ALL Flash Storage x
FC(SCSI)
候補２
MAX MBPS

MAX IOPS時平均待機時間
65
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
HDD x iSCSI
第二世代
PCI-SSD x IB(iSer)
第三世代
NVMe x SDS
候補１
ALL Flash Storage x FC(SCSI)
候補２
LATENCY
1ミリ秒以下

Swingbench
( SQL性能比較 )
66

平均レスポンスタイム(ミリ秒)
67
11
33
68 95
4
13
49
106
6
22
93
181
7
25
75
172
1
10
100
1,000
10 100 300 500
Session
Average Responce Time
HDD x iSCSI
第二世代
PCI-SSD x IB(iSer)
第三世代
NVMe x SDS
候補１
候補２

Query Per Second
68
649
2539
3756 3710
2030
7880 7932
6821
1781
5395
6266
6480
1702
6093
6927
6213
0
1000
2000
3000
4000
5000
6000
7000
8000
9000
10 100 300 500
Session
Query Per Second
HDD x iSCSI
第二世代
PCI-SSD x IB(iSer)
第三世代
NVMe x SDS
候補１
候補２

検証時のCPU使用率
69
10
60
70 70
40
100 100 100
35
95 95 95
30
80 80
90
0
10
20
30
40
50
60
70
80
90
100
10 100 300 500
Session
CPU
HDD x iSCSI
第二世代
PCI-SSD x IB(iSer)
第三世代
NVMe x SDS
候補１
候補２

待機イベント
70
54%
6%
2%
2%
2%
34%
HDD x iSCSI
db file sequential read
log file sync
gc current block 2-way
gc buffer busy acquire
read by other session
その他

待機イベント
71
57%
18%
6%
3%
3%
3%
2%
2%2%2%2%
ALL Flash Storage x FC ( SCSI )
CPU
file sequential read
g file sync
cr block 2-way
cr grant 2-way
cr block 3-way
file scattered read
current block 2-way
current block 3-way
cr multi block request
その他

性能まとめ
IOPS
• ALL Flash Storage が最も限界IOPSが高かった
SQL性能
• ALL Flash Storage x FC, NVMe x SDS共にほぼ同等の性能
だった
DB待機イベント
• ALL Flash StorageはCPUが上位に来ていてIOがボトルネッ
クになっていない
72

運用面障害テスト
73
ALL Flash Storage x FC (SCSI) NVMe x SDS
ストレージ障害テスト ○ ○
DB障害テスト ○ ○
10Gスイッチ障害テスト ○ ○
FCスイッチ障害テスト ○ -
障害テストはどちらもクリア

運用面ネットワーク環境
74
NWの安定性もどちらもクリア
利用するNWの安定性 ○ ( FC )
※安定実績あり
○ ( Ehternet )
利用プロトコルの
メモリ枯渇時の安定性
○ ( SCSI )
○
(SDSプロトコル)

運用面メンテナンス性
オンラインでのメンテナンス可能
75
ストレージ側での
LUN切り出し
○ ○
ストレージ側での
Target設定変更
○ ○
イニシエーター側での認識 ○ ○
ASMにDisk追加 ○ ○

運用面耐障害性
76
ALL Flash Storageのほうがより可用性が高い
ホスト冗長性 ○ (コントローラー冗長) × Oracle側で冗長
フラッシュ冗長性 ○ ( 独自RAID) × Oracle側で冗長

運用面サポート体制
77
サポート先 DBサーバー：A社
ストレージ：C社
(オンサイト保守)
DBサーバー :A社
STノード：A社
SSDカード：B社
SDSソフト：B社
24時間365日サポート ○ ×
ストレージ障害時の保守窓口がALL Flash Storage は一本化
24/365のサポートを受けられた

運用面集約性
78
必要台数 2台~ 7台〜
ALL Flash Storage 2台に集約

選定結果
• パフォーマンス
ALL Flash Storage x FC(SCSI) = NVMe x SDS
• 運用・耐障害性
ALL Flash Storage x FC(SCSI) >> NVMe x SDS
以上の事から
弊社ではALL Flash Storageを選定しました
79

ALL Flash Storage導入の効果
２台に集約
運用コスト大幅減
80

ALL Flash Storage導入の効果
81
HDDからFlash Storageへ
パフォーマンス向上

４．フラッシュストレージ導入の必要性
82

I/O性能が改善される事によるメリット
83
•HDDの構成
• I/O処理がボトルネックとなる
• DBシステムとしては健全な状態ではない
• CPUリソースを使い切る前にI/Oで限界を迎えてしまう
• CPU ライセンス費用がもったいない
• 余計にDBノード増設も必要となってくる
•フラッシュストレージの構成
• I/Oのボトルネックが解消
• DB処理時間の大半がCPU時間へ変化
• CPUリソースを使い切る形となる
• DBシステムとして健全な状態となる

安定稼動、安定運用は大切
• ストレージで頻繁に事故が起こると困る
• ストレージ側でも可用性は担保されているべき
• 電源冗長
• コントローラー冗長
• RAIDグループ機能
• Etc…
※ソフトウェアによるストレージの冗長化に頼りすぎる
のは良くない
84

最後に
85

選定時の検証は入念に
• 検証環境
• 本番と全く同じスペック、構成を用意
• 検証内容
• 性能検証
• 障害テスト
• メンテナンステスト
• Etc…
※稼動させてみなければ解らない事は多い
86

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

ヤフーを支えるフラッシュストレージ

ヤフーを支えるフラッシュストレージ

More Related Content

What's hot

Viewers also liked

Similar to ヤフーを支えるフラッシュストレージ

More from Yahoo!デベロッパーネットワーク

ヤフーを支えるフラッシュストレージ