【160715】入稿_PureStorage_wp_ted_nb.indd

Size: px

Start display at page:

Download "【160715】入稿_PureStorage_wp_ted_nb.indd"

さゆりしげい
5 years ago
Views:

1 DB性能の安定化を10年以上実現するオールフラッシュアレイとは OLTPの検証から分かるPure Storageの実力

2 複数のハイパーバイザーでストレージを共有する仮想化環境あるいは膨大なデータ処理に耐え得るデータベースのためのストレージとして近年一般的になっているのがNAND 型フラッシュを用いたストレージフラッシュストレージです従来のハードディスクでは物理的な限界となっているランダムアクセスI/O 性能のボトルネックを解決するストレージとして注目されていますオールフラッシュアレイに代表されるフラッシュストレージをデータベースシステムに導入することでストレージI/O 性能に起因するボトルネックを解消して全体の性能を改善する効果が得られますさらにソフトウェアライセンス費用の削減という面でも期待されています本書ではデータベースシステムに求められるストレージ要件に最適なオールフラッシュアレイであるピュアストレージ社 Pure Storage FlashArray//m での検証結果をもとにオールフラッシュアレイによるデータベースの高速化とコスト削減についてその手法と効果を紹介します 2.1 従来のデータベース高速化のアプローチ SQL の実行時間は一般的にストレージへのI/O 待ち時間に大きく依存するため I/O 待ち時間を短縮することがデータベース高速化のファーストステップとあるといえます従来 I/O 待ち時間を短縮するためにはデータベースキャッシュを利用することが一般的でしたデータベースサーバーに搭載されている高速なメモリを活用してキャッシュヒット率を高めることでストレージへのI/O を削減し I/O 待ち時間を短縮するアプローチです ( 図 1) またNAND フラッシュメモリの登場により SSD などのストレージキャッシュを搭載したストレージ製品も広く普及しています部分的にNANDフラッシュメモリを利用することでデータベースキャッシュからミスしたI/O がストレージキャッシュでヒットしストレージ全体の平均レイテンシーの向上を安価に実現するアプローチです ( 図 2) この2つのアプローチに共通しているのはサーバー側あるいはストレージ側でキャッシュを利用しているという点になりますキャッシュは平均レスポンスタイムを向上させることは可能ですがキャッシュミスが発生した場合はその効果が得られないため最大レスポンスタイムは変わらず全体的なSLA を保つことが困難ですまたキャッシュヒット率を向上させるためのサーバー / ストレージの設計やデータベースでの最適化が導入段階で求められるうえ運用後も定期的にキャッシュヒット率を監視し必要に応じて対策をし続ける必要がありますキャッシュによるアプローチの限界キャッシュミスが発生すると効果はなく全体のSLA を保つことが困難キャッシュヒット率を向上させるため導入時にハードウェア / ソフトウェア ( データベース ) での設計の追加コストと工数が必要アクセス負荷やデータ量の増加によってキャッシュヒット率は変化し続けるため運用中も定期的な監視と対策が必要 2.2 オールフラッシュアレイによるデータベース高速化のアプローチオールフラッシュアレイを利用したデータベース高速化はストレージ全体の最大レイテンシーを短縮することでデータベースの I/O 待ち時間を大幅に短縮するアプローチです I/O の最大待ち時間が数十ミリ秒から数ミリ秒以下になるため SQL の処理時間を大幅に向上することができますまたストレージ性能が十分に高速であるためデータベースキャッシュに依存しない安定的な性能を実現することができデータベースキャッシュの設計最適化のコストや工数を削減することができます ( 図 3) オールフラッシュアレイによるアプローチの効果データベースキャッシュストレージキャッシュでのヒット率に依存せず I/O 待ち時間を大幅に短縮し SLA を容易に保つことが可能導入運用においてキャッシュヒット率を向上させるためのコスト工数が不要 3.1 ストレージアーキテクチャデータベースを格納するストレージはデータベースサーバーに内蔵する形態と共有ストレージを利用してデータベースサーバーと接続する形態の2つに分けられますエンタープライズにおけるデータベースサーバーは耐障害性や性能の向上を目的としてクラスタ化されていることが一般的ですまた仮想マシン上にデータベースサーバーを構築し複数の仮想マシンが複数のハイパーバイザーで構成されるクラスタ上で動作する構成も多くありますこのような構成では共有ストレージを選択する必要性があります ( 図 4) 02

3 共有ストレージ型のフラッシュストレージは大きく4つの種類に分類することができます ( 図 5) この中でフラッシュメモリを搭載した共有ストレージとして最も注目されているのがオールフラッシュアレイです単に低レイテンシーで高いストレージ性能を発揮するだけではなくエンタープライズのストレージに求められる安定したアプリケーション性能を提供するための信頼性や機能性を従来のストレージと同等のコストで提供しているフラッシュストレージです 3.2 ストレージの要件ストレージを選定する上で最も重点的に比較するポイントはストレージ性能ですストレージベンチマークで高いスコアを達成できる製品ではなくエンタープライズシステムで利用されるアプリケーションやデータベースにおいて必要十分なストレージ性能を安定的に提供できることが求められます安定的なストレージ性能を提供するには信頼性も求められますハードウェア障害が発生するコンポーネントは大きく分け図 1: ストレージへの I/O を削減して I/O 待ち時間を短縮するアプローチデータベースサーバーストレージ数十ナノ秒 10~ 数十ミリ秒 CPU データベースキャッシュ ( メモリ ) HDD SQL の最大処理時間 = 数十ミリ秒ストレージの処理時間図 2: ストレージ全体の平均レイテンシーの向上を安価に実現するアプローチデータベースサーバーストレージ数十ナノ秒数ミリ秒 10~ 数十ミリ秒 CPU データベースキャッシュ ( メモリ ) ストレージキャッシュ HDD SQL の最大処理時間 = 数十ミリ秒最大処理時間は変わらない図 3: オールフラッシュアレイを利用したデータベース高速化のアプローチデータベースサーバーストレージ数十ナノ秒数ミリ秒 CPU データベースキャッシュ ( メモリ ) SQL の最大処理時間 = 数ミリ秒常に高速なデータアクセスを実現することで安定的なデータベース性能を実現図 4: クラスタ構成の DB サーバーとハイパーバイザー構成の DB サーバー DB DB DB クラスタリングストレージストレージクラスター構成のデータベースサーバーハイパーバイザー上で動作するデータベースサーバーー上で動作するデー 03

4 るとデータベースを格納するストレージデバイスとデータベースサーバーからのI/O リクエストを処理するストレージコントローラですストレージソフトウェアはストレージコントローラで動作するためソフトウェアの不具合に起因する障害はストレージコントローラの障害と同一とみなすことができますフラッシュメモリを利用したストレージデバイスの障害発生率は物理可動部が存在するHDD と比較して格段に減っています Bianca Schroeder 氏らの調査報告 ( 注 1) によると Google 社のデータセンターで利用しているSSD の年間交換発生率は HDD と比較して4 分の1になっており実際の運用環境でもその効果が確認されていますしかしながら面積あたりの容量密度は高まっており障害発生時の影響範囲が大きいという課題がありますそのため障害発生の頻度は減るということは一般的に言えますが障害発生時のSQL の処理性能への影響は選定時に把握する必要があります注 1:Bianca Schroeder, Raghav Lagisetty and Arif Merchant, Flash Reliability in Production: The Expected and the Unexpected, 14th USENIX Conference on File and Storage Technologies (FAST 16) ストレージコントローラはIA サーバーをベースとして構成され複数台で冗長化されているのが一般的ですしかしながらどの冗長化の方式でもメリット / デメリットが存在し各ストレージ製品によって障害時の動作の細部が異なるため選定時に調査判断をする必要があります下記はストレージコントローラの冗長化方式における一般的なメリット / デメリットです ( 図 6) データベースシステムに求められるオールフラッシュアレイの選定ポイント高いストレージ性能ではなく必要十分なストレージ性能を安定的に提供できることフラッシュデバイスの障害発生率はHDD と比べて少なくなっていることは明らかだが障害発生時の性能影響の確認は必要一般的なストレージコントローラの冗長化方式はいずれもメリット / デメリットが存在する冗長化方式の仕様や障害発生時の影響度を確認 3.3 Pure Storage FlashArray//m 前述したデータベースシステムのストレージに求められる要件を満たすオールフラッシュアレイとして Pure Storage FlashArray//m を紹介します FlashArray//mはピュアストレージ社が 2015 年に販売開始したオールフラッシュアレイ FlashArray シリーズの最新モ図 5: 4 種類に分類される共有ストレージ型フラッシュストレージ S S D 搭載の従来型ストレージハイブリッドアレイフラッシュアプライアンスオールフラッシュアレイこれまで採用していた製品と同アプリケーション性能の高速化低レイテンシーによるアプリケー安定したアプリケーション性メリットじ機能信頼性を引き続き利用を比較的安価なコストで実現ション性能の高速化能と機能信頼性を両立可能フラッシュに最適化されていな HDD へのアクセスが発生する非常に高価一般的なストレー新興メーカーや新製品が中デメリットいためフラッシュの効果を十とアプリケーション性能全体ジの機能信頼性が不十分心で選定の見極めが難しい分に得られない場合があるへ影響あり特長 HDDをSSDに置き換えたものなので登場時期が早い SSDとHDDを混在し SSDをキャッシュとして利用専用に設計されたハードウェアで最適化一般的なハードウェアで構成しソフトウェアで最適化図 6 : ストレージコントローラの冗長化方式における一般的なメリット / デメリット Active/Standby Active/Active スケールアウト S A N コントローラ障害発生時でも正常時ホストからすべてのポートに対し I /O を実コントローラを増設することで性能の拡張がメリットと同じ性能を維持行 ( マルチパス Round-Robin) パスの負荷分散が可能可能ホストからすべてのポートに対し I / O を実行 ( マルチパス Round-Robin) パスの負荷分散が可能 A c tive 側のポートに対してのみ I /O をコントローラ障害発生時に性能低下コントローラ障害発生時に性能低下コントローデメリット実行する必要があるため経路障害やマルチパスドライバに起因する問題がラ間通信をするための接続が必要になるため障害ポイントが多くなる発生する確率が高い 04

5 デルです Pure Storage FlashArrayシリーズの特長である実アプリケーションに最適化された高い性能省スペース / 省電力化長期利用を可能とする拡張性シンプルな構成や操作といった特長をハードウェアによるアプローチで一層強化したモデルとなりますまた技術や製品コンセプトだけではなく新しい販売モデルや保守プログラムを提供し IT 全体の TCO 削減をもたらすストレージですアプリケーションのI/O に最適化されたパフォーマンス一般的なストレージ性能を比較するための指標として用いられるのは 4KB のブロックサイズに対するI/O を実行した際の1 秒間あたりのI/O 処理数 (IOPS) ですこれは一般的なストレージにおける内部処理が4KB 単位で処理されていることに起因しますしかしながらエンタープライズシステムで利用されるアプリケーションが実行するI/O のサイズは 8~32KB であることが一般的ですこのため従来のストレージでは例えば32KB の I/O のリクエストがあった場合ストレージコントローラでは8 回の4KB の処理に分割する必要がありました ( 図 7) ピュアストレージ社ではこの点に着目し 512バイト~ 32KB のI/O リクエストを1 回の内部処理で完結しています内部処理の分割のオーバーヘッドをなくすことで実際のエンタープライズで利用されるI/O 条件においてストレージ性能を最大化することを実現しているのです Pure Storage FlashArray// m50では最大で 220,000 IOPS(32KBブロック ) を実現していますがこれは一般的なストレージと比較すると1,760,000 IOPS (4KB ブロック ) に相当することになります ( 図 8) 一般的なデータベースのブロックサイズは 8KB ですがマルチブロックリード機能などにより大きなサイズでI/O が行われます Pure Storage はI/O サイズに関わらず高い性能を発揮できるため OLTP の高速化はもちろん I/O サイズが大きいシーケンシャルアクセスが発生するバッチ処理やバックアップの時間も大幅に短縮することができるオールフラッシュアレイといえますコントローラ冗長化 Pure Storage のコントローラ冗長化の方式は前述した従来のアプローチのデメリットを排除しマルチパスの容易性障害発生時でも変わらない性能コントローラの拡張性のすべてを実図 7: Pure Storage と一般的なストレージの I/O 処理方式の違い内部での I/O 実行数一般的なストレージ内部での I/O 実行数 1 IO 4K 4K 4K 1 IO 1 IO 8K 8K 4K 4K 2 IOs 1 IO 16K 16K 4K 4K 4K 4K 4 IOs 1 IO 32K 32K 4K 4K 4K 4K 4K 4K 4K 4K 8 IOs 512byte~32KB まで 1 回で処理できるので効率よく処理できる 4KB 単位に分割して処理をするのでオーバーヘッドが発生する ( 資料 : ピュアストレージ社 ) 図 8: 内部処理の分割のオーバーヘッドをなくすことでストレージ性能を最大化カタログ値で用いられるベンチマークの I/O のサイズ 1, K IOP@4KBのストレージ 500K IOP@4KBのストレージ 750K IOP@4KBのストレージ IOPS (X 1000) 実際のアプリケーションが実行する I/O サイズ 4K 8K 16K 32K 64K I/O サイズ ( 資料 : ピュアストレージ社 ) 05

現しています ( 図 9) Pure Storageのコントローラは 2 台で冗長化されておりそれぞれプライマリ / セカンダリの役割を持っていますサーバーからのI/O はすべてのポートで受け付けるため Active/Active の冗長化であるといえますしかしながらセカンダリコントローラで受け付けたI/O はシャーシのミッドプレーンにあるPCI-e

6 現しています ( 図 9) Pure Storageのコントローラは 2 台で冗長化されておりそれぞれプライマリ / セカンダリの役割を持っていますサーバーからのI/O はすべてのポートで受け付けるため Active/Active の冗長化であるといえますしかしながらセカンダリコントローラで受け付けたI/O はシャーシのミッドプレーンにあるPCI-e バスを介してプライマリコントローラに転送され内部処理はすべてプライマリコントローラで処理されますすなわち内部処理はActive/Standby の冗長化でありコントローラ障害が発生しても性能低下の発生はありませんこのアーキテクチャにより Active/ActiveとActive/Standbyの両方のメリットを実現しています ( 図 10) Active/Active Active/Standbyともにデメリットになるのが性能の拡張性ですこの課題をPure Storage では同世代の上位モデルや将来登場する新しい世代のコントローラにアップグレード可能とすることで解決していますコントローラを1 台ずつ停止しアップグレードしていくためオンラインでアップグレードできることはもちろん作業中の性能低下も発生することなくアップグレードすることが可能です ( 図 11) また障害の発生個所となり得る接続ケーブルを可能な限り排除したハードウェアであることも特長の一つです電源供給や外部ホストと通信するケーブル以外は容量拡張時に利用する SAS ケーブルとレプリケーションを利用する10GbE ケーブルのみというシンプルな構成です ( 図 12) 図 9: 従来のアプローチのデメリットを排除した Pure Storage のコントローラ冗長化方式 Active/Active Active/Standby スケールアウト S A N Pure Storage FlashArray//m コントローラ障害発生時の性能維持〇〇マルチパス Round-Robinの利用〇〇〇コントローラの拡張性〇 ( コントローラを増設 ) 〇 ( 上位モデル最新モデルにアップグレード ) コントローラ間接続起因の障害発生有無〇 ( なし ) 〇 ( なし ) ( あり ) 〇 ( なし ) 図 10: Active/Active と Active/Standby 双方のメリットを実現するコントローラプライマリコントローラセカンダリコントローラ 2 セカンダリコントローラにアクセスした I/O は PCI-e パスを経由してプライマリコントローラで処理される (Active/Standby) 1I/O はすべてのポートを利用してアクセス (Active/Active) 図 11: 上位モデルや新しい世代のコントローラへもアップグレードが可能 1 既存コントローラ取り外し 3 フェイルオーバー 2 上位モデル最新モデルコントローラ装着 4 既存コントローラ取り外し 5 上位モデル最新モデルコントローラ装着 06

この無償提供されるコントローラを活用することで導入後は保守費と有償アップグレード

データベースキャッシュ最適化アプローチとのアプリりの保守費は常に一定で提供しているため

7 DB 性能の安定化を10 年以上実現するオールフラッシュアレイとは年以上の長期利用ち時代によって進化するOSやアプリケーションとのコンパチ前述した最新モデルへのコントローラアップグレードを利用ビリティや連携も常に対応し続けることができますするとハードウェアの保守終了に縛られずに同一のストレージを長期間利用することが可能になりますまた従来は最新モ 4 データベースシステムにおける Pure Storage FlashArray//mの導入効果デルのストレージにリプレースする際システムを停止しデータを移行する必要がありましたがデータ移行をすることなく常に最新モデルのストレージを利用することができます図13 これまでに紹介したデータベースシステムへのオールフラッシュこの技術的なアプローチに加え Pure Storageでは Evergreen アレイの導入効果をPure Storage FlashArray//mで検証しました Storage というコンセプトのもと保守契約期間中最短3年ごとに同レンジにおける最新モデルのコントローラを無償提供し評価項目ていますこの無償提供されるコントローラを活用することで導入後は保守費と有償アップグレードコントローラ容量時の増設費用のみで利用し続けることが可能ですまた容量当たデータベースキャッシュ最適化アプローチとのアプリりの保守費は常に一定で提供しているため毎年の経費の平準化ケーション性能の比較が可能となります図14 データベースキャッシュヒット率の違いによるアプリケーション性能の比較スナップショットやレプリケーション OSやハイパーバイザーストレージ障害発生時のアプリケーション性能への影響との連携といったすべての機能は追加費用なしで利用することができ将来新たな機能が提供された場合でも同様ですすなわ図12: Pure Storage FlashArray//mの構成例 SASポート拡張シェルフ利用時 I/Oポート FC or 10GbE iscsi レプリケーションポート 10GbE レプリケーション利用時電源マネジメントポート 1GbE 図13: データ移行をすることなく常に最新モデルのストレージが利用可能 07

4.1 検証環境今回の検証ではハイパーバイザー (VMware vsphere ESXi) で動作する仮想マシン上にデータベースサーバーを構築し仮想マシンをHDD とSSD に搭載したハイブリッドストレージおよびオールフラッシュアレイである Pure Storage FlashArray//mに格納しましたハイパーバイザーとストレージ間はFC スイッチを介して接続されています ( 図

の負荷を生成しデータベース処理性能 (Transaction Per Sec: TPS) とレスポンスタイムの傾向を確認しました VM1: データベースサーバー ( データベースキャッシュ最適化なし ) キャッシュヒット率が90/95/97% になる構成 ( データベースキャッシュ割当を変化させながら利用 ) データベースは Oracle Database 12c Standard

を実行するサーバーストレージは SSD をストレージキャッシュ (Read/Write) として構成したHDD とSSD を搭載したバイブリッドアレイとオールフラッシュアレイ (Pure Storage FlashArray//m) を利用し図 14: 保守契約期間中は最短 3 年ごとに最新モデルのコントローラを無償提供 Pure Storage 製品本体 Forever Flash

従来のストレージストレージの再選定リプレースやデータ移行が必要図 15: 今回の検証システム VM1: データベースサーバー ( キャッシュ最適化なし ) vcpu コア数 : 8 データベース : Oracle Database 12c SE2 OS: Oracle Linux 6.

8 4.1 検証環境今回の検証ではハイパーバイザー (VMware vsphere ESXi) で動作する仮想マシン上にデータベースサーバーを構築し仮想マシンをHDD とSSD に搭載したハイブリッドストレージおよびオールフラッシュアレイである Pure Storage FlashArray//mに格納しましたハイパーバイザーとストレージ間はFC スイッチを介して接続されています ( 図 15) データベースサーバー ( 図中の VM1 VM2 ) はバッファキャッシュに割り当てるメモリ量を調整することでキャッシュヒット率が異なる2つの環境を構築しましたベンチマークツールは Swingbenchを利用し 150GBのOrder Entry(OE) スキーマを生成しましたそしてデータベースサーバーとは異なる仮想マシン ( 図中の VM3 ) からそれぞれの環境にOLTP の負荷を生成しデータベース処理性能 (Transaction Per Sec: TPS) とレスポンスタイムの傾向を確認しました VM1: データベースサーバー ( データベースキャッシュ最適化なし ) キャッシュヒット率が90/95/97% になる構成 ( データベースキャッシュ割当を変化させながら利用 ) データベースは Oracle Database 12c Standard Edition 2を利用 VM2: データベースサーバー ( データベースキャッシュ最適化あり ) キャッシュヒット率 99% 以上になる構成キャッシュ最適化機能である Oracle Partitioningを利用するためにデータベースは Oracle Database 12c Enterprise Editionを利用 VM3: ベンチマークツール (Swingbench) を実行するサーバーストレージは SSD をストレージキャッシュ (Read/Write) として構成したHDD とSSD を搭載したバイブリッドアレイとオールフラッシュアレイ (Pure Storage FlashArray//m) を利用し図 14: 保守契約期間中は最短 3 年ごとに最新モデルのコントローラを無償提供 Pure Storage 製品本体 Forever Flash によるコントローラアップグレード Forever Flash によるコントローラアップグレード Forever Flash によるコントローラアップグレード保守保守保守保守保守保守保守保守保守保守 1 年目 2 年目 3 年目 4 年目 5 年目 6 年目 7 年目 8 年目 9 年目 10 年目保守保守保守保守保守保守保守保守保守保守製品本体 4 年目以降の保守費が上昇製品本体従来のストレージストレージの再選定リプレースやデータ移行が必要図 15: 今回の検証システム VM1: データベースサーバー ( キャッシュ最適化なし ) vcpu コア数 : 8 データベース : Oracle Database 12c SE2 OS: Oracle Linux 6.7 VM2: データベースサーバー ( キャッシュ最適化あり ) vcpu コア数 : 8 データベース : Oracle Database 12c EE +Oracle Partitioning OS: Oracle Linux 6.7 ハイパーバイザー VMware ESXi 6.Ou2 サーバー VM3: Swingbench vcpu コア数 : 4 ツール : Swingbench 2.5 OS: Oracle Linux Gb FC スイッチ Brocade Gb FC スイッチ Brocade 6505 他社製ハイブリッドアレイ (SSD は Read/Write キャッシュ ) Pure Storage FlashArray//m 08

9 VMware Storage vmotion で仮想マシンをストレージ間でマイグレーションしながら検証を実施しましたまたハイブリッドアレイを利用した検証においてはストレージキャッシュヒット率が 90% 以上になるのを確認してから測定しています 4.2 データベースキャッシュ最適化アプローチとのアプリケーション性能の比較本検証ではキャッシュ最適化がされていないデータベースサーバーをオールフラッシュアレイで動作させた場合にキャッシュ最適化がされたデータベースサーバーとのトランザクション数が同等であることを確認しました ( 図 16) データベースキャッシュヒット率が90% である場合オールフラッシュアレイの環境で約 3 倍高いトランザクション性能を示しましたこれはデータベースサーバーのキャッシュストレージのキャッシュどちらにもヒットしなかった I/O が HDD にアクセスした際のI/O 応答時間の差に依存しているといえますまたデータベースキャッシュヒット率が99% である場合と比較すると 1.06 倍の性能でありデータベースキャッシュが最適化されていなくてもオールフラッシュアレイであれば同等以上の性能が実現できるということを示していますレスポンスタイムで比較した場合いずれのケースにおいても平均レスポンスタイムでは運用上の実質的な差は見受けられませんでしたしかしながら最大レスポンスタイムにおいてはハイブリッドアレイを利用した場合では2 秒以上となっており全体のSLA に影響が出ているといえます一方オールフラッシュアレイの場合は214 ミリ秒に留まっており 10 倍以上の改善効果があるということが確認できました 4.3 データベースキャッシュヒット率の違いによるアプリケーション性能の比較本検証ではオールフラッシュアレイを利用したデータベースシステムにおいてデータベースキャッシュヒット率に関わ図 16: データベースキャッシュ最適化アプローチとのアプリケーション性能の比較秒間あたりの平均トランザクション数 (Oracle EE + ハイブリッドアレイを 1とした場合の相対値 ) ハイブリッドアレイ Pure Storage FlashArray//m ハイブリッドアレイ DB キャッシュヒット率 =90% Oracle Database 12c SE2 DB キャッシュヒット率 =99% Oracle Database 12c EE +Oracle Partitioning トランザクションあたりのレスポンスタイム Oracle Database 12c SE2 DB キャッシュヒット率 90% Oracle Database 12c EE + Oracle Partitioning DB キャッシュヒット率 99% ハイブリッドアレイ Pure Storage FlashArray//m ハイブリッドアレイ平均レスポンスタイム (ms) 最大レスポンスタイム (ms) ( 東京エレクトロンデバイス実測 ) 09

10 らず安定した性能を実現することを確認しました ( 図 17) ハイブリッドアレイにおいてデータベースキャッシュヒット率が上がるとトランザクション数も比例して向上し最大 2.8 倍の効果が見られました一方オールフラッシュアレイにおいては1.17 倍の効果に留まりましたこのことからオールフラッシュアレイにおいてはデータベースキャッシュヒット率を考慮せずに高いデータベース性能を実現することができるといえます 4.4 ストレージ障害発生時のアプリケーション性能への影響本検証ではストレージ障害 ( コントローラ / フラッシュモジュール ) が発生した際におけるデータベース性能への影響を確認しました ( 図 18) データベースキャッシュヒット率 90% のデータベースサーバーに対して SwingbenchでOLTPの負荷を生成しながら Pure Storage FlashArray//m のコントローラ / フラッシュモジュールをオフラインにすることで障害発生時と同じ状況下で検証しました正常時と比較したトランザクション数においてコントローラ障害が発生した際は正常時と同じトランザクション数を維持していることを確認しましたフラッシュモジュール障害においては 1 本障害時は96% 2 本同時障害時は90% のトランザクション数で動作していることを確認しましたこの性能低下の要因はフラッシュモジュール障害時には正常なフラッシュモジュール内のデータパリティから失われたデータを再構成するリビルド処理が発生するためですしかしながらその影響は極めて小さいといえますレスポンスタイムにおいてはコントローラ障害時のレスポンスタイムは平均および最大ともに正常時と同程度であることを確認しました SSD 障害においては平均レスポンスタイムで 1.2~1.4 倍最大レスポンスタイムで1.7~1.8 倍の上昇が見受けられましたが最大レスポンスタイムでも400 ミリ秒以下であり運用上の実質的な影響はないことを確認しました本書ではフラッシュストレージによるデータベース高速化アプローチを紹介しオールフラッシュアレイである Pure Storage FlashArray//m での検証を通じてその効果を確認しましたデータベースキャッシュヒット率が90% である時ハイブリッ図 17: データベースキャッシュヒット率の違いによるアプリケーション性能の比較 1 秒間あたりの平均トランザクション数 (Oracle EE + ハイブリッドアレイを 1とした場合の相対値 ) Pure Storage FlashArray//m 1.14 Pure Storage FlashArray//m Pure Storage FlashArray//m Pure Storage FlashArray//m DB キャッシュヒット率 =90% DB キャッシュヒット率 =95% DB キャッシュヒット率 =97% DB キャッシュヒット率 =99% Oracle Database 12c SE2 Oracle Database 12c EE +Oracle Partitioning ( 東京エレクトロンデバイス実測 ) 10

11 ドアレイと比較し約 3 倍のトランザクション性能の向上を確認しキャッシュ最適化アプローチ ( データベースキャッシュヒット率 99%) と比較して同等以上のトランザクション性能が実現できることを確認しました最大レスポンスタイムは10 倍以上向上し全体的なSLA を容易に保つことが可能であることを確認しましたまたオールフラッシュアレイにおいてキャッシュ最適化をした場合でもトランザクション性能の向上は1.17 倍でありキャッシュヒット率に関わらず高いトランザクション性能を実現できるということを確認しましたストレージ障害が発生した場合のアプリケーション性能への影響においてはトランザクション数は最大で10% の低下にとどまり最大レスポンスタイムも実運用上影響のない範囲であることを確認しましたまた障害発生時だけではなくピュアストレージ社が提唱する Evergreen Storage のコンセプトであるオンラインでのコントローラアップグレードが可能であることの裏付けを一部示しています以上のことからデータベースシステムのストレージとして Pure Storage FlashArray//mを採用することで導入時におけるキャッシュ最適化のコスト削減を実現しキャッシュヒット率の低下やストレージ障害が発生しても安定的なアプリケーション性能を維持することが可能であるということが検証を通じて確認できましたさらに Evergreen Storageのコンセプトにより毎年の経費を平準化しながらリプレースすることなく常に最新のストレージを長期利用することが可能であり高い信頼性と稼働率が求められるデータベースシステムのストレージとして最適であるといえるでしょう最後にピュアストレージジャパン株式会社様をはじめ本書の作成にご協力いただいた方々に感謝と御礼を申し上げます DBパフォーマンスお悩み相談所東京エレクトロンデバイスではお客様の環境や課題のヒアリングから調査分析を行いどのようなソリューションで D Bパフォーマンスを改善できるのか改善ポイントはどこかなどのご提案までを行う DBパフォーマンスお悩み相談を承っています DBパフォーマンスのボトルネックは今回ご紹介したストレージ性能以外にも多岐にわたります分析結果をもとにハードウェアソフトウェア製品を活用したデータベースシステム全体の最適化をご提案します URL: 図 18: ストレージ障害発生時のアプリケーション性能への影響 1 秒間あたりの平均トランザクション数 (Oracle SE2 {DBキャッシュヒット率 =90%} + Pure Storage FlashArray//mの正常時を1 とした場合の相対値 ) 正常時コントローラ障害 1SSD 障害 2SSD 同時障害トランザクションあたりのレスポンスタイム正常時コントローラ障害 1SSD 障害 2SSD 同時障害平均レスポンスタイム (ms) 最大レスポンスタイム (ms) ( 東京エレクトロンデバイス実測 ) 11

12 本書に関する著作権は東京エレクトロンデバイス株式会社に帰属します本書またはその一部を無断で複製することは固くお断りいたしますまた本書の記述に誤りや欠落があっても東京エレクトロンデバイス株式会社はいかなる責任も負わないものとします本書およびその記述内容は予告なしに変更される場合があります本書に記載されている各社の社名製品名およびサービス名は各社の商標または登録商標です 2016 年 7 月 CNカンパニー新宿 : 東京都新宿区西新宿新宿パークタワー S34 階 Tel Fax 大阪 : 大阪府大阪市中央区城見クリスタルタワー 33 階 Tel Fax 名古屋 : 愛知県名古屋市西区名駅名古屋プライムセントラルタワー 8 階 Tel Fax 豊田 : 愛知県豊田市喜多町 GAZAビル4 階 Tel Fax つくば : 茨城県つくば市東新井 15-4 関友つくばビル7 階 Tel Fax Connect Beyond はステークホルダーの皆様の期待と信頼に応えるためあらゆる即成概念を越えて皆さまと共に新たな価値の創造に挑戦するという私たちの姿勢を表しています WP1607

PowerPoint プレゼンテーション

PowerPoint プレゼンテーション Oracle GRID Center Flash SSD + 最新ストレージと Oracle Database で実現するデータベース統合の新しい形 2011 年 2 月 23 日日本オラクル Grid Center エンジニア岩本知博進化し続けるストレージ関連技術高速ストレージネットワークの多様化低価格化 10GbE FCoE 8Gb FC ディスクドライブの多様化および大容量 / 低価格化