Oracle Database 環境におけるピュアストレージの優位性

FlashArray //m シリーズによる⼀貫した⾼性能とライセンスコスト削減の実現

ピュア・ストレージ・ジャパン株式会社

⽬次

はじめに .................................................................................. 1

検証⽬的 .................................................................................. 1

製品および機能紹介 .................................................................... 3

FlashArray //m シリーズ ....................................................... 3

インラインでのデータ削減機能 ................................................. 4

検証システム構成 ....................................................................... 5

検証結果 .................................................................................. 7

OLTP ワークロード検証結果（中負荷） ...................................... 7

OLTP ワークロード検証結果（⾼負荷） ...................................... 9

総括：検証結果の考察 ............................................................... 13

OLTP システムにおけるオールフラッシュストレージ活⽤法の考察 ... 13

FlashArray //m シリーズによる DB ライセンスコストの削減 ......... 14

1

はじめに

昨今、データベース環境でのオールフラッシュストレージ導⼊事例が増えています。ピュア

ストレージでもデータベース環境の導⼊事例が⾶躍的に増えており、サーバ仮想化（VSI）

とデスクトップ仮想化（VDI）を凌ぐ 44%に達しました（図 1：2015 年時点）。

図 1. ピュアストレージ導⼊実績

オールフラッシュストレージは、⾼速な I/O を提供する⼀⽅で GB 単価が⾼いため、コスト

をかけてでも極めて⾼い I/O 性能を必要とするデータベース環境で使⽤されるのが⼀般的で

した。近年では、フラッシュデバイス⾃体の GB 単価も下がり続け、オールフラッシュスト

レージが実装するインラインでのデータ削減機能を利⽤することで、SAS HDD 並の GB 単

価を実現することが可能になりました。GB 単価が同等であれば、フラッシュデバイスは

SAS HDD と⽐較して⾼い I/O 性能はもちろん、圧倒的に低い故障率や⾼速なリビルド処理

などの多数のメリットがあり、運⽤管理のコスト削減も期待できます。これにより、極めて

⾼い I/O 性能が必要ではなくても、SAS HDD の代替としてオールフラッシュストレージを

選択するケースが増えてきています。本資料では、Oracle Database 環境で実施したオンラ

イントランザクション処理（以降、OLTP）ワークロードの検証結果を交えながら、Oracle

Database 環境における1ピュアストレージの優位性をご紹介します。

検証⽬的

HDD を搭載したストレージを基準とした従来の OLTP システムではストレージ I/O 性能が

ボトルネックになりがちなため、DB 処理性能を劣化させないためにキャッシュヒット率を

100%近くで維持することが重要です（図 2）。

1 本資料でご紹介するピュアストレージの優位性の多くは、Oracle Database 以外のデータ

ベース環境でも同様です。

, &

C

- E

F

F C , A A E

E A B B

%

2

図 2. 従来の OLTP システムのイメージ図

近年では、TB 級のメモリを⼀般的なサーバに搭載できるため、⼩〜中規模のデータベース

であれば、⼤部分のデータを DB サーバでキャッシュ可能と⾔えます。しかしながら、⼤容

量メモリを搭載した DB サーバでも、OLTP システムの複雑なワークロードの全てをキャッ

シュ上で処理することは困難です（図 3）。

図 3. キャッシュミスが多発するケースの例

Oracle Database の機能であるパーティション機能2や圧縮機能3を使⽤することで、ストレ

ージ I/O 量を削減し、メモリサイズ不⾜によるキャッシュヒット率を改善することが可能で

す。しかし、メンテナンスや障害後の再起動によってキャッシュはクリアされます。ストレ

ージ I/O がボトルネックになりがちな環境では、TB 級メモリがウォームアップされるまで

DB 処理性能の⼤幅な劣化を引き起こします。また、OLTP システムにバッチ処理で投⼊した

新規データは、キャッシュを介さずストレージに直接書き込む⼿法が⼀般的です。この場合

も、TB 級メモリがウォームアップされるまで DB 処理性能の⼤幅な劣化を引き起こします。

2 Oracle Partitioning オプション

3 Oracle Advanced Compression オプション

%

01

���!������

������$(

� �� �"+���

��� ����'����

#)&������+�

%, *��������

3

オールフラッシュストレージであれば、これらの全てケースで⼀貫して⾼い DB 処理性能を

提供することが可能です。複雑なチューニングや運⽤管理の⼯夫も不要です。本検証では、

OLTP システムの DB 処理性能の向上と Oracle Database Enterprise Edition 追加オプショ

ンのライセンスコスト削減を実現するベストプラクティス確⽴を⽬的として、ピュアストレ

ージが提供するオールフラッシュストレージ FlashArray //m シリーズを使⽤した各種の検

証結果をご紹介します。

製品および機能紹介

FlashArray //m シリーズ

ピュアストレージが提供する FlashArray //m シリーズは、以下の 4 点を開発⽅針としたオ

ールフラッシュストレージです。

l MINI：ミニサイズ

l 3U シャーシで 15〜120TB の有効容量

l 業界で最も⼤規模なデータ削減

l 消費電⼒は 1 kW 以下

l MODULAR：モジュールの拡張

l 約 1/2PB の有効容量まで拡張可能

l 容量とパフォーマンスを中断なしで拡張

l MIGHTY：強⼒なパフォーマンス

l 最⼤ 300,000 32K IOPS

l 最⼤ 9GB/s 帯域

l 1ms 未満の待ち時間

l MEANINGFUL：有意義なシンプルさ

l 6 本のケーブルでアプライアンス的な導⼊

l HA、DR、バックアップ搭載

l チューニングなしで作業負荷を軽減

l クラウドベースの管理と保守

l 参考 URL：http://www.purestorage.co.jp/products/flash-array-m

4

図 4. FlashArray //m シリーズのラインアップ

図 5. FlashArray //m シリーズのスペック

インラインでのデータ削減機能

FlashArray //m シリーズはデータの重複排除と圧縮の機能が常時有効化されており、アー

キテクチャに完全にバンドルされた無償の機能です。データベース環境では圧縮は有効です

が、重複排除の効果はほとんど期待できない、というのが⼀般的です。ピュアストレージが

提供する重複排除であればデータベース環境で圧縮はもちろん、重複排除の効果も期待でき

るため、他社と⽐較して⼤きなデータ削減効果が期待できます。次の図（図 6）はピュアス

トレージによるデータ削減の実績4です。

4 ピュアストレージを導⼊いただいたお客様環境のデータ削減率をまとめたもの

0/2 1

,

043 /2

, 043 /2

,

4 CRI / CV M

• 8 7•• 50 RGE e

• ) 0 u u• 0

n o a• ) PO SR -5D 41 O 5D3 1 7• PO SR s u 5D3

o o e b dhk w l b g M b M, up dh ) 0 e dc g

•• ,) B O A• ). .KH

• 17G 0 NON S CNRPC GNS D FHG e 6/ t• y b / 2 rn d a 17G e22 A /9 A2799• 2TC PC SV HODC /72 2Wdhk o ie• c d ct o m A /9

• 8 7•• ,50 RGE e

• 8 7•• .50 RGE e

• +) 0 up• + . 0

• )) + 0 up• ) - 0

• up a ,• , )),B A• ). .KH up a . .KH

• up a• ) . .. A• , ,8H up a . .KH

ta

• -EO G 6CRUG 1• . 50 /9

• EO G 6CRUG 1• +50 /9

• +EO G 6CRUG 1• 50 /9

4 CRI / CV M 4 CRI / CV M,

• - PO SR +5D 41 O 5D3 1 7• PO SR s u 5D3

• - PO SR +5D 41 O 5D3 1 7• PO SR s u 5D3

5

図 6. お客様環境でのデータ削減の実績

l ⽔⾊の系列：重複排除によるデータ削減実績

l 橙⾊の系列：圧縮によるデータ削減実績

⽔⾊の系列の通り、データベース環境であっても、重複排除によって 1.5〜1.8 倍のデータ

削減実績があることが分かります。更に圧縮によるデータ削減効果も合わせることで、デー

タベース環境で 3〜5 倍5のデータ削減率が期待できます。

検証システム構成

次の図（図 7）はハードウェア構成の概念図です。

図 7. ハードウェア構成の概念図

5 データベース側で圧縮機能を使⽤している場合は、FlashArray //m20 によるデータ削減

率はやや減少し、約 2 倍の効果

��� �����

GD1

FB

DC

FB

/A�PA

44 02 A����

00 0 8

/A�PA

44 02 A�������

6

VMware vSphere 6.0 Update 1 上に作成したサーバ（以降、DB サーバ）を 2 台使⽤し、

Oracle Database 12c Release 1Enterprise Edition をインストールし、2 ノードの Oracle

Real Application Clusters（RAC）を構成しました。DB サーバとストレージ間の接続は、

8Gbps FC による SAN を構築しました。

次の表は DB サーバ（表 1）およびストレージ（表 2）の情報です。

表 1. DB サーバ情報

ハイパーバイザ VMware ESXi 6.0 Update 1

CPU Intel Xeon E5-2697v3

vCPU 数 8 コア

仮想メモリ 48GB

OS Oracle Linux 6.7

データベース Oracle Database 12c Release 1 Enterprise Edition

Oracle Real Application Clusters（RAC）

Oracle Automatic Storage Management（ASM）

表 2. ストレージ情報

モデル FlashArray //m20 10TB モデル

OS Purity 4.5.5

ドライブ 10TB：512GB モジュール x 20（256GB SSD x 40）

接続 FC：8Gbps FC x 4 ポート

次の図（図 8. ストレージ構成）はストレージ構成です。FlashArray //m20（以降、

FlashArray //m20）から LUN を 2 つ作成し、それぞれ別の Oracle ASM ディスクグループ

を作成しました。⼀⽅の Oracle ASM ディスクグループには、Oracle Database のパーティ

ション機能を使⽤した 1.5TB のデータベースを作成しました。もう⼀⽅の Oracle ASM ディ

スクグループには、パーティション機能を使⽤しないで 1.5TB のデータベースを作成しまし

た。

7

図 8. ストレージ構成

1.5TB のデータベースは、ピュアストレージのインラインでのデータ削減機能によって、そ

れぞれ 1/8、1/9 のサイズ（185GB、160GB）になりました（図 9. ピュアストレージによ

る）。

図 9. ピュアストレージによるデータ削減効果

検証結果

OLTP ワークロード検証結果（中負荷）

本検証では、OLTP ワークロードの負荷量は中負荷と⾼負荷の 2 パターン使⽤し、それぞれ

DB クライアントがアクセスするデータの量（以降、Working Set Size：アクセス範囲）を

増加させていくことで、データベースに格納されるデータ量の増加や、ユーザ数の増加に伴

う DB サーバにおけるキャッシュヒット率の劣化を再現し、以下の傾向を確認しました。

l 「キャッシュヒット率」による DB 処理性能および DB サーバ CPU 使⽤率への影響

l 「パーティション機能」による DB 処理性能および DB サーバ CPU 使⽤率への影響

次のグラフは、中負荷時の性能（図 10）と CPU 使⽤率です（図 11）。

20 1 0

.

4 4

.

#

1 201

0. 15 0. 15

4 #

86 86

8

図 10. 中負荷時の DB 処理性能

図 11. 中負荷時の DB サーバ CPU 使⽤率

)

)

)

)

)

)

)

)

(

)

,

)3/ 3/ )3/ 3/ )3/ 3/ )3/ ( 3/ ()3/ ) 3/

0/7

FDBF

9F

0/9E

BFG

BFF

: E B 8 G 8 3/

968. 54 968. 522 7186. 54 7186. 522

%

(

)

1 1 1 1 1 % 1 % 1 1 1 1

5:C:

466B

D8B

7 5:B 5 D: 1

46 9: 32 46 9: 32

46 9: 300 46 9: 300

9

検証結果から、以下の 2 つのことが確認できました。

1. キャッシュミスが多発した場合でも、キャッシュヒット率 100%並の DB 処理性能

アクセス範囲が 5GB〜20GB の場合、DB サーバの物理メモリのキャッシュヒット率がほぼ

100%であり、ストレージ I/O が発⽣していない理想の OLTP システムと⾔えます。その

後、アクセス範囲の増加に伴いキャッシュミスが多発しますが、DB 処理性能が劣化しませ

んでした。この結果から、FlashArray //m20 が極めて低いレイテンシで I/O を返すこと

で、OLTP システムにおける I/O ボトルネックを発⽣させず、⼀貫した DB 処理性能を提供

する効果があることを確認できました。

2. パーティション機能を使⽤しない場合でも、使⽤時と同等の DB 処理性能

パーティション機能を使⽤しない場合（図 10：⽔⾊の系列）とパーティション機能を使⽤

した場合（図 10：橙⾊の系列）の DB 処理性能は、ほぼ同等の値でした。パーティション機

能を使⽤しない場合は、対象のデータに辿り着くためにアクセスしなければならない索引の

ブロック数が増加します。しかしながら、本検証のように I/O ブロック数が増加した場合で

も、極めて⾼い IOPS を提供できる FlashArray //m206であれば DB 処理性能に影響を与え

ないことが確認できました。

OLTP ワークロード検証結果（⾼負荷）

ここまでの検証結果は、CPU を 16 コアの約 50%である 8 コアを使⽤する中負荷の結果で

した。次に、DB サーバに接続するセッション数を増加させることで、16 コア全てを使い切

る⾼負荷の状態の結果をご紹介します。次のグラフは、⾼負荷時の性能（図 12）と CPU 使

⽤率です（図 13）。

6 本検証で使⽤したピュアストレージ FlashArray //m20 の 32KB 読み込み性能は 150,000

IOPS

10

図 12. ⾼負荷時の DB 処理性能

図 13. ⾼負荷時の DB サーバ CPU 使⽤率

(

,

(

,

),

(

)3/ 3/ )3/ 3/ )3/ 3/ )3/ ( 3/ ()3/ ) 3/

0/7

FDBF

9F

0/9E

BFG

BFF

: E B 8 G 8 3/

968. 54 968. 522 7186. 54 7186. 522

%

(

)

1 1 1 1 1 % 1 % 1 1 1 1

5:C:

466B

D8B

7 5:B 5 D: 1

46 9: 32 46 9: 32

46 9: 300 46 9: 300

11

検証結果から、以下の 2 つのことが確認できました。

1. キャッシュミスが多発した場合でも、キャッシュヒット率 100%並の DB 処理性能

キャッシュヒット率の違いによる傾向は、中負荷時と同じ結果になりました。

2. パーティション機能を使⽤しない場合、使⽤時と⽐較して DB 処理性能が減少

パーティション機能による傾向は、中負荷時と異なる結果になりました。パーティション機

能を使⽤しない場合、DB サーバの CPU 使⽤率は約 85%で頭打ちになり、本環境の最⼤性

能を引き出すことができませんでした。複数セッションから⼤量の挿⼊（INSERT）または

更新（UPDATE）処理が特定の索引ブロックに集中した結果、Oracle 内部のボトルネックが

発⽣しました（図 14：enq TX - index contention）。⼀⽅、パーティション機能を使⽤し

た場合、索引ブロックが Oracle 内部で分割されます。その結果、Oracle 内部ボトルネック

（enq TX - index contention）が改善され、DB サーバ CPU を使い切ることで（約

100%）、本環境の最⼤性能を引き出すことができました。

図 14. パーティション未使⽤時の Oracle 待機イベント

12

図 15. パーティション使⽤時の Oracle 待機イベント

次のグラフ（図 16）は、本検証で最も I/O 負荷が⾼い状況（図 12：⾚⾊の円）における、

ピュアストレージの I/O 統計情報です。

図 16. FlashArray //m20 の I/O 統計情報

������ ����

13

アクセス範囲は 50GB で、データベースのキャッシュ（Database Buffer Cache）サイズで

ある 20GB を⼤きく超えているため、ストレージ I/O が多発している状況です。CPU は両ノ

ードで 16 コアを 100%使い切っている状況で、ストレージに求められた IOPS は約 11,160

IOPS でした。この時のレイテンシは読み込みが 0.41ms、書き込みが 0.31ms であり、極

めて低いレイテンシを提供できていることが分かります。

総括：検証結果の考察

OLTP システムにおけるオールフラッシュストレージ活⽤法の考察

オールフラッシュストレージは⾼性能という特性上、選定時に IOPS が着⽬されがちです

が、本検証では DB サーバ CPU を 16 コア最⼤限使い切った状況で、ストレージに要求され

た IOPS は約 11,160 IOPS でした（図 16）。本検証で使⽤した FlashArray //m20 は最安

価モデルでありながら、32KB 読み込みで 150,000 IOPS を提供します7。そのため、

11,160 IOPS を提供している状態でも、FlashArray //20 は⾮常に余裕ある状態と⾔えま

す。⼀⽅、11,160 IOPS を 10,000 rpm の SAS HDD で満たすには、100〜200 ドライブ8

という⼤量の SAS HDD が必要になるため、⾮常に厳しい性能要件と⾔えます。実システム

では、SQL の特性によって CPU バウンドか I/O バウンドかの傾向は変化しますが、いずれ

にせよ OLTP ワークロードでオールフラッシュストレージの最⼤ IOPS に達するケースは稀

と⾔えます。

これにより、OLTP システムではオールフラッシュストレージの IOPS より容量を使い切る

傾向があります。HDD を搭載したストレージとは真逆の特性を持つオールフラッシュストレ

ージを最⼩限のコストで最⼤限活⽤するには、「容量」をベースに考えることをお勧めしま

す。例えば、FlashArray //m20 は最⼩構成（5TB：512GB モジュール x 10（256GB SSD

x 20）でも 9〜15TB の有効容量9を提供します。GB 単価は SAS HDD 並であるため、仮に

フラッシュ並の I/O 性能が必要ないデータベースであっても、サイズが⼩さいものから統合

していくことで、統合密度を最⼤化できます。統合されたデータベースの DB 処理性能は

「⼀貫」したものになるため、ワークロードの分析、それに対する最適なハードウェア構成

やチューニングから解放され、それにかかる⼯数および コストを削減する効果が期待できま

す。

7 32KB 読み込み時の IOPS であり、8KB であれば更に⾼い IOPS が期待できます。 8 I/O サイズ、読み込みと書き込みの割合、RAID 構成に依存します。

9 データ削減率を 3〜5 倍とした場合の容量

14

図 17. 容量から考えるデータベース統合の例

FlashArray //m シリーズによる DB ライセンスコストの削減

Oracle の圧縮機能10は Oracle Database Enterprise Edition の追加オプションであるため

有償であり、DB サーバの CPU コア数の増加に⽐例してライセンス料も肥⼤化します。また

圧縮機能を使⽤する場合は、更新が多い OLTP システムには不向きである等、オーバーヘッ

ドを考慮した検討が必要になります。

ピュアストレージの FlashArray //m シリーズであれば、インラインでの重複排除と圧縮の

機能が常時有効化されており、アーキテクチャに完全にバンドルされた無償の機能です（参

考：「インラインでのデータ削減機能」章）。更に、データベース環境であっても 3〜5 倍

の⾼いデータ削減率が期待できるにも関わらず、オーバーヘッドはありません。次のグラフ

（図 18）は圧縮率の違いによる FlashArray //m シリーズの性能傾向です。

図 18. 圧縮率の違いによる性能傾向

ピュアストレージではインラインでのデータ削減を前提とした独⾃の I/O アーキテクチャを

開発および実装しています。その結果、ただでさえ⾼い I/O 性能がデータ削減率の増加に伴

10 Oracle Advanced Compression オプション

0 -53 / 0 2

,A B

B- -

- - -- - - - -

0. 21 0

46

8

8

15

い I/O 性能が向上する唯⼀のストレージと⾔えます。よって、OLTP システムのワークロー

ドに対する向き不向きや、オーバーヘッドを考慮する必要がありません。

Oracle のパーティション機能11も同様に、Oracle Database Enterprise Edition の追加オプ

ションであるため有償であり、DB サーバの CPU コア数の増加に⽐例してライセンス料も肥

⼤化します。また、表の構造を理解したパーティションキーの検討、それに合わせて SQL ⽂

の改修など、パーティションを使いこなすための検討事項には、⾼い DB スキルと⼯数を必

要とします。

ピュアストレージの FlashArray //m シリーズであれば、パーティション機能を使⽤せずと

も⾼い DB 処理性能を期待できます。パーティション機能を使⽤しない場合、対象データに

アクセスするために読み込む必要がある DB ブロック数が増加するため、ストレージに要求

される I/O 数も増加します。HDD を搭載したストレージでは、その I/O 性能要件を満たす

ために⼤量の HDD が必要です。コストと設置スペースの肥⼤化の観点で⾮現実的なため、

パーティション機能の使⽤およびチューニングで対応するのが⼀般的でした。

FlashArray //m シリーズであれば⾼い I/O 性能要件も⾮常に余裕ある状態で満たすことが

できるため、パーティション機能を使⽤せずとも⾼い DB 処理性能を期待できます。

11 Oracle Partitioning オプション

16

Oracle Database 環境におけるピュアストレージの優位性

FlashArray //m シリーズによる⼀貫した⾼性能とライセンスコスト削減の実現

2016 年 4 ⽉ 10 ⽇ 1.0 版

ピュア・ストレージ・ジャパン株式会社