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

513 Views

September 29, 16

#Oracle Database #フラッシュストレージ #パフォーマンス向上 #システム構成 #RDB運用

スライド概要

この資料は、アイティメディア株式会社主催のイベント「第2回 @IT製品比較セミナー～違いのわかる人のための主要フラッシュストレージ徹底解剖～」にて、
Yahoo! JAPANのOracle Databaseのプラットフォームでは、どのような経緯でフラッシュストレージ導入に至ったのか説明したものになります。

【イベントの概要】
■イベント名
第2回 @IT製品比較セミナー～違いのわかる人のための主要フラッシュストレージ徹底解剖～
■主催
アイティメディア株式会社
■共催
伊藤忠テクノソリューションズ株式会社
■イベントURL
https://itmedia.smartseminar.jp/public/seminar/view/901

【セッションの概要】
■日時
2016年 9月14日(水) 13:35～14:25 頃
■タイトル
ヤフーを支えるフラッシュストレージ

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

@ydnjp

スライド一覧

2023年10月からSpeaker Deckに移行しました。最新情報はこちらをご覧ください。 https://speakerdeck.com/lycorptech_jp

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

（ダウンロード不可）

関連スライド

深層学習による自然言語処理入門: word2vecからBERT, GPT-3まで

Yahoo!デベロッパーネットワーク 160.3K

ゼロから始める転移学習

Yahoo!デベロッパーネットワーク 85.6K

ヤフーにおける WebAuthn と Passkey の UX の紹介と考察 #idcon #fidcon

idcon fidcon

Yahoo!デベロッパーネットワーク 72.7K

OpenID Connectとネイティブアプリを取り巻く仕様と動向 Yahoo! JAPANの取り組み #openid #openid_tokyo

openid openid_tokyo

Yahoo!デベロッパーネットワーク 57.5K

運用業務とスクラムは本当に組み合わせにくいのか︖運用業務が大半を占めるプロダクト開発での試行錯誤

devsumi

Yahoo!デベロッパーネットワーク 34.8K

ヤフーのオンプレ機械学習基盤AIPFについて #ml_kubernetes

ml_kubernetes

Yahoo!デベロッパーネットワーク 28.9K

各ページのテキスト

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

このセッションの概要弊社のOracle Databaseを稼動させるシステム構成として、過去にどのようなものが採用されてきたのかをご紹介しますそして、過去の構成で問題となった点を明らかにし、それに対してどういったアプローチで解決させたのかを説明させて頂きます Copyright (C) 2016 Yahoo! Japan Corporation. All Rights Reserved. 無断引用・転載禁止 3

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

10.

Yahoo! JAPANでのOracle,MySQLの住み分け • Oracle • • • • ミッションクリティカルなサービスセキュアのデータを扱うサービス処理量が多いサービス会計・勘定系サービス • MySQL • Web系のサービス • Oracleの必要がないサービスはMySQL推奨 • 2016年からセキュアのデータも扱う（自社で監査システムを作成） Copyright (C) 2016 Yahoo! Japan Corporation. All Rights Reserved. 無断引用・転載禁止 10

11.

全社Oracle環境に求められているもの • • • • • 高いパフォーマンス高い可用性安定運用 BCP 強固なセキュリティ昨今、Oracleを利用する案件は、性能、可用性、BCP、セキュリティ等の要望レベルが非常に高くなっていますそうでない案件はMySQLが選択される事が多い為です特に、赤文字３つの項目が重要視されています Copyright (C) 2016 Yahoo! Japan Corporation. All Rights Reserved. 無断引用・転載禁止 11

12.

13.

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

14.

第一世代のイメージ GR02 GR01 VIP DB GR03 VIP DB DB DB DB VIP DB DB VOL VOL DB DB VOL Fail Over DB node 1 DB node 2 DB node 3 FC FC Storage GR03_LUN GR02_LUN GR01_LUN Copyright (C) 2016 Yahoo! Japan Corporation. All Rights Reserved. 無断引用・転載禁止 14

15.

2005年~2010年 GOOD 第一世代 BAD データベースサーバー • 安定 • メモリたくさん • 高速 GOOD • • • • 高価 Solarisが社内非標準筐体が大きい無停止構成ではないストレージサーバー • 安定 • 運用中ダウン0 • 高価 • オペレーションがベンダー頼り • 筐体が大きい Copyright (C) 2016 Yahoo! Japan Corporation. All Rights Reserved. 無断引用・転載禁止 15

16.

2010年~ 第二世代アプリケーション • Oracle 11gR2 • Oracle RAC データベースサーバー • OracleLinux • Oracle Grid Infrastructureによる冗長性 • • • • 1Uのサーバメモリ 72G 1G eth NIC (Interconnect) 10G eth NIC/SFP (Storage) ストレージサーバー • iscsiによる接続 • Oracle ASMによる冗長化 •商用ストレージ(HDD) Copyright (C) 2016 Yahoo! Japan Corporation. All Rights Reserved. 無断引用・転載禁止 16

17.

第二世代のイメージ Oracle GI(Grid Infrastructure) Instance Node 1 Instance Node 2 Instance Node 3 RAC DB Oracle ASM (Auto Storage Manager) DB node 1 DB node 2 DB node 3 10G eth Network storage node 03 storage node 02 storage node 01 LUN06 LUN05 LUN04 LUN03 LUN02 LUN01 Copyright (C) 2016 Yahoo! Japan Corporation. All Rights Reserved. 無断引用・転載禁止 17

18.

2010年~ 第二世代 GOOD BAD • OracleRAC データベースサーバー • 安価 • 安定 • 1U • インターコネクト通信がボトルネックに(NW帯域) ストレージサーバー • 比較的安価 • 安定 • オペレーションしやすい • IO性能がボトルネックに Copyright (C) 2016 Yahoo! Japan Corporation. All Rights Reserved. 無断引用・転載禁止 18

19.

20.

21.

22.

23.

24.

2014年~ 第三世代アプリケーション • Oracle 11gR2 • Oracle RAC データベースサーバー • Oracle Linux • Oracle Grid Infrastructureによる冗長化 • 1Uのサーバ • メモリ 128G • InfiniBand HCA搭載ストレージサーバー • ISer (iSCSI Extention for RDMA)による接続 • Oracle ASMによる冗長化 • 1Uのサーバ • メモリ 32G • PCIe-SSDカード2枚搭載 Copyright (C) 2016 Yahoo! Japan Corporation. All Rights Reserved. 無断引用・転載禁止 24

25.

第三世代のイメージ Oracle Grid Infrastructure DB Instance 2 DB Instance 1 DB Instance 3 RAC DB Oracle ASM (Auto Storage Manager) IB HCA IB HCA IB HCA IB HCA IB HCA DB node 2 DB node 1 IB HCA DB node 3 InfiniBand Switch InfiniBand Switch Network 01(56Gbps) IB HCA Partition 1 PCI-SSD IB HCA Partition 1 PCI-SSD Storage node 1 IB HCA Partition 1 PCI-SSD Network 02(56Gbps) IB HCA Partition 1 PCI-SSD Storage node 2 IB HCA Partition 1 PCI-SSD IB HCA Partition 1 PCI-SSD Storage node 3 IB HCA Partition 1 PCI-SSD IB HCA IB HCA Partition 1 PCI-SSD Partition 1 PCI-SSD Storage node 4 Copyright (C) 2016 Yahoo! Japan Corporation. All Rights Reserved. 無断引用・転載禁止 IB HCA Partition 1 PCI-SSD Storage node 5 IB HCA Partition 1 PCI-SSD IB HCA Partition 1 PCI-SSD Storage node 6 25

26.

2014年~ GOOD BAD • OracleRAC データベースサーバー • 安価 • 1U • Iserでメモリの断片化が発生ストレージサーバー • かなり安価 • HDDよりかなり高速 • 1U • 台数を並べる必要がある • オンラインでディスクの切り直しができない Copyright (C) 2016 Yahoo! Japan Corporation. All Rights Reserved. 無断引用・転載禁止 26

27.

28.

29.

2010年~ Wait Class User I/O Commit Cluster DB CPU 第二世代課題事例① 項目 HDD x iSCSI 第二世代 PCI-SSD x IB (iSer) 第三世代 DB Time(%) 79.3 3.5 Avg Wait(ms) 53 0 DB Time(%) 4.3 0.2 Avg Wait(ms) 83 1 DB Time(%) 3.7 0.4 Avg Wait(ms) 12 0 DB Time(%) 13.7 56.3 Avg Wait(ms) - - • データベースの待機クラスが大幅に変化 • I/Oの待機が大幅に減少 • CPU処理時間が大半の割合を占めるようになった Copyright (C) 2016 Yahoo! Japan Corporation. All Rights Reserved. 無断引用・転載禁止 29

30.

2010年~ 対象SQL SQLその１ SQLその2 第二世代課題事例① 比較項目従来構成 HDD x 10G 新構成 SSD x IB 実行時間(s) 10.63 0.10 I/O時間 10.41 0.07 DB CPU(%) 0.6 32.1 I/O(%) 97.9 70.6 実行時間(s) 20.29 0.13 I/O時間 20.18 0.09 DB CPU(%) 0.5 33.1 I/O(%) 99.5 70.6 • その結果、SQL性能も大幅に良くなりました • 処理スピードが10～20倍に競合他社とも引けをとらない性能となった Copyright (C) 2016 Yahoo! Japan Corporation. All Rights Reserved. 無断引用・転載禁止 30

31.

32.

2010年~ 第二世代課題事例② • メール配信PFの処理がデータ量増加とともに遅延 • バッチ処理が12時間ほどかかってしまう • 1日2300回APIがタイムアウトしてしまう →バッチ処理が10時間→2時間に →1日2300回のタイムアウトが1日0~1回に Copyright (C) 2016 Yahoo! Japan Corporation. All Rights Reserved. 無断引用・転載禁止 32

33.

2014年~ 第三世代 DBサーバー課題データベースサーバー • Iserの部分でデータベースサーバーのメモリが断片化してしまう • ほうっておくとメモリの獲得に失敗してしまい、OSダウン • 根本的に解決する方法がなく、定期的にOS再起動などで対応 Copyright (C) 2016 Yahoo! Japan Corporation. All Rights Reserved. 無断引用・転載禁止 33

34.

35.

36.

37.

38.

39.

40.

41.

42.

43.

44.

45.

46.

47.

48.

49.

50.

51.

52.

2014年~ 第三世代 STサーバー課題② これを手順で表すと 1. ASMから対象のストレージサーバーをOFFLINE 2. 対象のストレージサーバーからiscsiログアウト 3. 2を全データベースサーバー分実施 4. STサーバーのSSDのパーティションを切り直し 5. 対象のストレージサーバーにiscsiログイン 6. ASMから対象のストレージサーバーをONLINE 7. 1~6をストレージ台数分実施とても大変 Copyright (C) 2016 Yahoo! Japan Corporation. All Rights Reserved. 無断引用・転載禁止 52

53.

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

54.

次世代構成のストレージに求められる要件以上のことから次世代構成のストレージは • • • • • 容量が多い（少ない台数で済む）高性能（PCIe-SSDにも引けをとらない）オンラインメンテナンス可能ストレージ間通信の安定ストレージ側での冗長性担保上記を満たしている事が理想 Copyright (C) 2016 Yahoo! Japan Corporation. All Rights Reserved. 無断引用・転載禁止 54

55.

56.

57.

候補1 NVMe x SDS アプリケーション • Oracle 12cR1 • Oracle RAC データベースサーバー • Oracle Linux • Oracle Grid Infrastructureによる冗長化 • 1Uのサーバ • メモリ 256G ストレージサーバー • 10G ethによる接続 • Oracle ASMによる冗長化 • SDS ( Software Defined Storage ) によ • 1Uのサーバ • メモリ 64G • NVMeカード2枚搭載る管理 Copyright (C) 2016 Yahoo! Japan Corporation. All Rights Reserved. 無断引用・転載禁止 57

58.

候補１のイメージ • 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) Core Switch Edge Switch DB Instance DB Instance DB Instance RAC DB Oracle ASM DB node 1 DB node 2 10G Switch (Storage & Interconnect) ST node 1 DB node 3 10G Switch (Storage & Interconnect) ST node 2 Copyright (C) 2016 Yahoo! Japan Corporation. All Rights Reserved. 無断引用・転載禁止 ST node 3 58

59.

候補2 ALL Flash Storage x FC(SCSI) アプリケーション • Oracle 12cR1 • Oracle RAC データベースサーバー • Oracle Linux • Oracle Grid Infrastructureによる冗長化 • 1Uのサーバ • メモリ 256G ストレージサーバー • FC ( SCSI )による接続 • 内部コントローラ冗長化 • Oracle ASMによる冗長化 • ALL Flash Storage Copyright (C) 2016 Yahoo! Japan Corporation. All Rights Reserved. 無断引用・転載禁止 59

60.

候補２のイメージ • Service NW • 1Gbps NW x 1 • Bonding • Interconnect NW • 10Gbps NW x 2 • Storage NW • 16Gbps FC SAN x 2 • Multipath ( 4 path) Core Switch Edge Switch DB Instance RAC DB Oracle ASM DB node 1 16G FC Switch FC SAN 01 Flash Storage 01 DB Instance DB Instance DB node 2 16G FC Switch FC SAN 02 DB node 3 10G Switch Interconnect NW 01 10G Switch Interconnect NW 02 Flash Storage 02 Copyright (C) 2016 Yahoo! Japan Corporation. All Rights Reserved. 無断引用・転載禁止 60

61.

性能比較 • Caribrate IO • Oracle社提供の単純なIO性能測定プロシージャ • Swingbench • • 元Oracle社エンジニアが作成したフリーベンチマークツール http://dominicgiles.com/swingbench.html Copyright (C) 2016 Yahoo! Japan Corporation. All Rights Reserved. 無断引用・転載禁止 61

http://dominicgiles.com/swingbench.html

62.

63.

MAX IOPS(最大秒間I/Oリクエスト) MAX IOPS 1400000 1258268 1269320 1153229 1200000 1000000 800000 600000 400000 268875 200000 0 HDD x iSCSI 第二世代 PCI-SSD x IB(iSer) 第三世代 NVMe x SDS 候補１ Copyright (C) 2016 Yahoo! Japan Corporation. All Rights Reserved. 無断引用・転載禁止 ALL Flash Storage x FC(SCSI) 候補２ 63

64.

MAX IOPS(最大秒間I/O転送量) MAX MBPS 20000 17516 18000 16000 14594 14000 12000 10000 8788 8000 6000 4000 3085 2000 0 HDD x iSCSI 第二世代 PCI-SSD x IB(iSer) 第三世代 NVMe x SDS 候補１ Copyright (C) 2016 Yahoo! Japan Corporation. All Rights Reserved. 無断引用・転載禁止 ALL Flash Storage x FC(SCSI) 候補２ 64

65.

MAX IOPS時平均待機時間 LATENCY 1 0.9 0.8 0.7 0.6 0.5 0.4 1ミリ秒以下 0.3 0.2 0.1 0 HDD x iSCSI 第二世代 PCI-SSD x IB(iSer) 第三世代 NVMe x SDS 候補１ Copyright (C) 2016 Yahoo! Japan Corporation. All Rights Reserved. 無断引用・転載禁止 ALL Flash Storage x FC(SCSI) 候補２ 65

66.

67.

平均レスポンスタイム(ミリ秒) Average Responce Time 1,000 181 172 93 100 75 33 25 106 68 95 49 22 11 10 13 7 6 HDD x iSCSI 第二世代 PCI-SSD x IB(iSer) 第三世代 NVMe x SDS 候補１ ALL Flash Storage x FC(SCSI) 候補２ 4 1 10 100 300 500 Session Copyright (C) 2016 Yahoo! Japan Corporation. All Rights Reserved. 無断引用・転載禁止 67

68.

Query Per Second Query Per Second 9000 7932 7880 8000 7000 6821 6927 6266 6093 6000 6213 6480 5395 5000 4000 3000 2030 2000 1702 1781 3756 3710 300 500 2539 HDD x iSCSI 第二世代 PCI-SSD x IB(iSer) 第三世代 NVMe x SDS 候補１ ALL Flash Storage x FC(SCSI) 候補２ 1000 0 649 10 100 Session Copyright (C) 2016 Yahoo! Japan Corporation. All Rights Reserved. 無断引用・転載禁止 68

69.

検証時のCPU使用率 100 100 CPU 100 100 95 95 80 80 90 80 70 70 60 95 90 70 HDD x iSCSI 第二世代 PCI-SSD x IB(iSer) 第三世代 NVMe x SDS 候補１ ALL Flash Storage x FC(SCSI) 候補２ 60 50 40 40 35 30 30 20 10 10 0 10 100 300 500 Session Copyright (C) 2016 Yahoo! Japan Corporation. All Rights Reserved. 無断引用・転載禁止 69

70.

待機イベント HDD x iSCSI db file sequential read 34% log file sync gc current block 2-way 54% gc buffer busy acquire read by other session 2% 2% 2% その他 6% Copyright (C) 2016 Yahoo! Japan Corporation. All Rights Reserved. 無断引用・転載禁止 70

71.

待機イベント ALL Flash Storage x FC ( SCSI ) CPU file sequential read 2%2% 2%2% 2% 3% 3% 3% g file sync cr block 2-way cr grant 2-way 6% cr block 3-way 57% 18% file scattered read current block 2-way current block 3-way cr multi block request その他 Copyright (C) 2016 Yahoo! Japan Corporation. All Rights Reserved. 無断引用・転載禁止 71

72.

性能まとめ IOPS • ALL Flash Storage が最も限界IOPSが高かった SQL性能 • ALL Flash Storage x FC, NVMe x SDS共にほぼ同等の性能だった DB待機イベント • ALL Flash StorageはCPUが上位に来ていてIOがボトルネックになっていない Copyright (C) 2016 Yahoo! Japan Corporation. All Rights Reserved. 無断引用・転載禁止 72

73.

運用面障害テスト ALL Flash Storage x FC (SCSI) NVMe x SDS ストレージ障害テスト ○ ○ DB障害テスト ○ ○ 10Gスイッチ障害テスト ○ ○ FCスイッチ障害テスト ○ - 障害テストはどちらもクリア Copyright (C) 2016 Yahoo! Japan Corporation. All Rights Reserved. 無断引用・転載禁止 73

74.

運用面ネットワーク環境 ALL Flash Storage x FC (SCSI) NVMe x SDS 利用するNWの安定性 ○ ( FC ) ※安定実績あり ○ ( Ehternet ) ※安定実績あり利用プロトコルのメモリ枯渇時の安定性 ○ ( SCSI ) ※安定実績あり ○ (SDSプロトコル) ※安定実績あり NWの安定性もどちらもクリア Copyright (C) 2016 Yahoo! Japan Corporation. All Rights Reserved. 無断引用・転載禁止 74

75.

運用面メンテナンス性 ALL Flash Storage x FC (SCSI) NVMe x SDS ストレージ側での LUN切り出し ○ ○ ストレージ側での Target設定変更 ○ ○ イニシエーター側での認識 ○ ○ ASMにDisk追加 ○ ○ オンラインでのメンテナンス可能 Copyright (C) 2016 Yahoo! Japan Corporation. All Rights Reserved. 無断引用・転載禁止 75

76.

運用面耐障害性 ALL Flash Storage x FC (SCSI) NVMe x SDS ホスト冗長性 ○ (コントローラー冗長) × Oracle側で冗長フラッシュ冗長性 ○ ( 独自RAID) × Oracle側で冗長 ALL Flash Storageのほうがより可用性が高い Copyright (C) 2016 Yahoo! Japan Corporation. All Rights Reserved. 無断引用・転載禁止 76

77.

運用面サポート体制 ALL Flash Storage x FC (SCSI) NVMe x SDS サポート先 DBサーバー：A社ストレージ：C社 (オンサイト保守) DBサーバー :A社 STノード：A社 SSDカード：B社 SDSソフト：B社 24時間365日サポート ○ × ストレージ障害時の保守窓口がALL Flash Storage は一本化 24/365のサポートを受けられた Copyright (C) 2016 Yahoo! Japan Corporation. All Rights Reserved. 無断引用・転載禁止 77

78.

79.

選定結果 • パフォーマンス ALL Flash Storage x FC(SCSI) = NVMe x SDS • 運用・耐障害性 ALL Flash Storage x FC(SCSI) >> NVMe x SDS 以上の事から弊社ではALL Flash Storageを選定しました Copyright (C) 2016 Yahoo! Japan Corporation. All Rights Reserved. 無断引用・転載禁止 79

80.

81.

82.

83.

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

84.

安定稼動、安定運用は大切 • ストレージで頻繁に事故が起こると困る • ストレージ側でも可用性は担保されているべき • • • • 電源冗長コントローラー冗長 RAIDグループ機能 Etc… ※ソフトウェアによるストレージの冗長化に頼りすぎるのは良くない Copyright (C) 2016 Yahoo! Japan Corporation. All Rights Reserved. 無断引用・転載禁止 84

85.

86.

87.