オールフラッシュアレイとは
OLTPの検証から分かるPure Storageの実力
キャッシュによるアプローチの限界 ● キャッシュミスが発生すると効果はなく、全体のSLAを 保つことが困難 ● キャッシュヒット率を向上させるため、導入時にハード ウェア／ソフトウェア（データベース）での設計の追加 コストと工数が必要 ● アクセス負荷やデータ量の増加によって、キャッシュ ヒット率は変化し続けるため、運用中も定期的な監視と 対策が必要
2.2 オールフラッシュアレイによる
データベース高速化のアプローチ
オールフラッシュアレイを利用したデータベース高速化は、 ストレージ全体の最大レイテンシーを短縮することで、データベー スのI/O待ち時間を大幅に短縮するアプローチです。I/Oの最大 待ち時間が数十ミリ秒から数ミリ秒以下になるため、SQLの処 理時間を大幅に向上することができます。またストレージ性能が 十分に高速であるため、データベースキャッシュに依存しない安 定的な性能を実現することができ、データベースキャッシュの設 計・最適化のコストや工数を削減することができます（図３）。 オールフラッシュアレイによるアプローチの効果 ● データベースキャッシュ・ストレージキャッシュでのヒット 率に依存せず、I/O待ち時間を大幅に短縮し、SLAを容易 に保つことが可能 ● 導入・運用において、キャッシュヒット率を向上させる ためのコスト・工数が不要3 データベースシステムに求められる
オールフラッシュアレイ
3.1 ストレージアーキテクチャ
データベースを格納するストレージは、データベースサーバー に内蔵する形態と、共有ストレージを利用してデータベースサー バーと接続する形態の2つに分けられます。 エンタープライズにおけるデータベースサーバーは、耐障害 性や性能の向上を目的としてクラスタ化されていることが一般的 です。また仮想マシン上にデータベースサーバーを構築し、複数 の仮想マシンが複数のハイパーバイザーで構成されるクラスタ上 で動作する構成も多くあります。このような構成では、共有スト レージを選択する必要性があります（図４）。1 はじめに
複数のハイパーバイザーでストレージを共有する仮想化環境、 あるいは膨大なデータ処理に耐え得るデータベースのためのス トレージとして、近年一般的になっているのがNAND型フラッ シュを用いたストレージ“フラッシュストレージ”です。従来 のハードディスクでは物理的な限界となっているランダムアク セスI/O性能のボトルネックを解決するストレージとして注目さ れています。 オールフラッシュアレイに代表されるフラッシュストレージ をデータベースシステムに導入することで、ストレージI/O性能 に起因するボトルネックを解消して全体の性能を改善する効果が 得られます。さらに、ソフトウェアライセンス費用の削減という 面でも期待されています。本書では、データベースシステムに求 められるストレージ要件に最適なオールフラッシュアレイである ピュア・ストレージ社「Pure Storage FlashArray//m」での検証 結果をもとに、オールフラッシュアレイによるデータベースの高 速化とコスト削減について、その手法と効果を紹介します。2 オールフラッシュアレイによる
データベース高速化とコスト削減
2.1 従来のデータベース高速化のアプローチ
SQLの実行時間は、一般的にストレージへのI/O待ち時間に 大きく依存するため、I/O待ち時間を短縮することがデータベー ス高速化のファーストステップとあるといえます。従来、I/O待 ち時間を短縮するためには、データベースキャッシュを利用す ることが一般的でした。データベースサーバーに搭載されてい る高速なメモリを活用してキャッシュヒット率を高めることで、 ストレージへのI/Oを削減し、I/O待ち時間を短縮するアプロー チです（図１）。 またNANDフラッシュメモリの登場により、SSDなどのスト レージキャッシュを搭載したストレージ製品も広く普及していま す。部分的にNANDフラッシュメモリを利用することで、デー タベースキャッシュからミスしたI/Oがストレージキャッシュで ヒットし、ストレージ全体の平均レイテンシーの向上を安価に実 現するアプローチです（図２）。 この2つのアプローチに共通しているのは、サーバー側あるい はストレージ側でキャッシュを利用しているという点になります。 キャッシュは平均レスポンスタイムを向上させることは可能です が、キャッシュミスが発生した場合はその効果が得られないため、 最大レスポンスタイムは変わらず、全体的なSLAを保つことが 困難です。また、キャッシュヒット率を向上させるためのサー バー／ストレージの設計やデータベースでの最適化が導入段階で 求められるうえ、運用後も定期的にキャッシュヒット率を監視し、 必要に応じて対策をし続ける必要があります。図1: ストレージへのI/Oを削減してI/O待ち時間を短縮するアプローチ データベースサーバー ストレージ データベース キャッシュ（メモリ） HDD 数十ナノ秒 SQLの最大処理時間＝数十ミリ秒 ≒ ストレージの処理時間 10～数十ミリ秒 CPU 図3: オールフラッシュアレイを利用したデータベース高速化のアプローチ データベースサーバー ストレージ SQLの最大処理時間＝数ミリ秒 常に高速なデータアクセスを実現することで、安定的なデータベース性能を実現 データベース キャッシュ（メモリ） 数十ナノ秒 数ミリ秒 CPU
SSD
図4: クラスタ構成のDBサーバーとハイパーバイザー構成のDBサーバー Hypervisor Hypervisor ハイパーバイザー上で動作するデータベースサーバー VM VM DB DB DBサーバー DBサーバー クラスター構成のデータベースサーバー クラスタリング DB 共有ストレージ型のフラッシュストレージは大きく4つの種類 に分類することができます（図５）。 この中で、フラッシュメモリを搭載した共有ストレージとし て最も注目されているのがオールフラッシュアレイです。単に低 レイテンシーで高いストレージ性能を発揮するだけではなく、エ ンタープライズのストレージに求められる安定したアプリケーショ ン性能を提供するための信頼性や機能性を、従来のストレージと 同等のコストで提供しているフラッシュストレージです。3.2 ストレージの要件
ストレージを選定する上で最も重点的に比較するポイントは ストレージ性能です。ストレージベンチマークで高いスコアを達 成できる製品ではなく、エンタープライズシステムで利用される アプリケーションやデータベースにおいて、必要十分なストレー ジ性能を安定的に提供できることが求められます。 安定的なストレージ性能を提供するには、信頼性も求められ ます。ハードウェア障害が発生するコンポーネントは大きく分け 図2: ストレージ全体の平均レイテンシーの向上を安価に実現するアプローチ データベースサーバー ストレージ HDD 数十ナノ秒 SQLの最大処理時間＝数十ミリ秒 最大処理時間は変わらない 10～数十ミリ秒 CPU ストレージキャッシュ 数ミリ秒SSD
データベース キャッシュ（メモリ） DBサーバー DBサーバー クラスター構成のデータベースサーバー Hypervisor Hypervisor ハイパーバイザー上で動作するデータベースサーバー ストレージ ストレージると、データベースを格納するストレージデバイスと、データベー スサーバーからのI/Oリクエストを処理するストレージコントロー ラです。ストレージソフトウェアはストレージコントローラで動 作するため、ソフトウェアの不具合に起因する障害はストレージ コントローラの障害と同一とみなすことができます。 フラッシュメモリを利用したストレージデバイスの障害発生 率は、物理可動部が存在するHDDと比較して格段に減っています。 Bianca Schroeder氏らの調査報告（注1）によると、Google社 のデータセンターで利用しているSSDの年間交換発生率は、 HDDと比較して4分の1になっており、実際の運用環境でもその 効果が確認されています。しかしながら、面積あたりの容量密度 は高まっており、障害発生時の影響範囲が大きいという課題があ ります。そのため障害発生の頻度は減るということは一般的に言 えますが、障害発生時のSQLの処理性能への影響は選定時に把 握する必要があります。 ストレージコントローラはIAサーバーをベースとして構成され、 複数台で冗長化されているのが一般的です。しかしながら、どの 冗長化の方式でもメリット／デメリットが存在し、各ストレージ 製品によって障害時の動作の細部が異なるため、選定時に調査・ 判断をする必要があります。下記はストレージコントローラの冗 長化方式における、一般的なメリット／デメリットです（図６）。 データベースシステムに求められる オールフラッシュアレイの選定ポイント ● 高いストレージ性能ではなく、必要十分なストレージ性 能を安定的に提供できること ● フラッシュデバイスの障害発生率はHDDと比べて少な くなっていることは明らかだが、障害発生時の性能影響 の確認は必要 ● 一般的なストレージコントローラの冗長化方式は、いず れもメリット／デメリットが存在する。冗長化方式の仕 様や障害発生時の影響度を確認
3.3 Pure Storage FlashArray//m
前述したデータベースシステムのストレージに求められる要 件を満たすオールフラッシュアレイとして、「Pure Storage FlashArray//m」を紹介します。 FlashArray//mは、ピュア・ストレージ社が2015年に販売開 始したオールフラッシュアレイ「FlashArrayシリーズ」の最新モ 図6: ストレージコントローラの冗長化方式における一般的なメリット／デメリット
Active/Standby Active/Active スケールアウトSAN
メリット コントローラ障害発生時でも、正常時 と同じ性能を維持 ホストからすべてのポートに対しI/Oを実 行(マルチパス Round-Robin)。パスの負 荷分散が可能 コントローラを増設することで、性能の拡張が 可能。ホストからすべてのポートに対しI/Oを実 行(マルチパス Round-Robin)。パスの負荷分 散が可能 デメリット Active側のポートに対してのみI/Oを 実行する必要があるため、経路障害や マルチパスドライバに起因する問題が 発生する確率が高い コントローラ障害発生時に、性能低下 コントローラ障害発生時に性能低下。コントロー ラ間通信をするための接続が必要になるため、 障害ポイントが多くなる
※注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)
図5: 4種類に分類される共有ストレージ型フラッシュストレージ SSD搭載の従来型ストレージ ハイブリッドアレイ フラッシュアプライアンス オールフラッシュアレイ メリット これまで採用していた製品と同 じ機能・信頼性を引き続き利用 可能 アプリケーション性能の高速化 を比較的安価なコストで実現 低レイテンシーによるアプリケー ション性能の高速化 安定したアプリケーション性 能と、機能・信頼性を両立 デメリット フラッシュに最適化されていな いため、フラッシュの効果を十 分に得られない場合がある HDDへのアクセスが発生する と、アプリケーション性能全体 へ影響あり 非常に高価。一般的なストレー ジの機能・信頼性が不十分 新興メーカーや新製品が中 心で、選定の見極めが難しい 特長 HDDをSSDに置き換えたものなので、登場時期が早い キャッシュとして利用SSDとHDDを混在し、SSDを 専用に設計されたハードウェアで最適化 一般的なハードウェアで構成し、ソフトウェアで最適化
デルです。Pure Storage FlashArrayシリーズの特長である実ア プリケーションに最適化された高い性能、省スペース／省電力化、 長期利用を可能とする拡張性、シンプルな構成や操作といった特 長をハードウェアによるアプローチで一層強化したモデルとなり ます。また技術や製品コンセプトだけではなく、新しい販売モデ ルや保守プログラムを提供し、IT全体のTCO削減をもたらすス トレージです。 3.3.1 アプリケーションのI/Oに最適化されたパフォーマンス 一般的なストレージ性能を比較するための指標として用いら れるのは、4KBのブロックサイズに対するI/Oを実行した際の1 秒間あたりのI/O処理数 （IOPS）です。これは、一般的なスト レージにおける内部処理が4KB単位で処理されていることに起 因します。 しかしながら、エンタープライズシステムで利用されるアプ リケーションが実行するI/Oのサイズは、8～32KBであること が一般的です。このため従来のストレージでは、例えば32KBの I/Oのリクエストがあった場合、ストレージコントローラでは8 回の4KBの処理に分割する必要がありました（図７）。 ピュア・ストレージ社ではこの点に着目し、512バイト～ 32KBのI/Oリクエストを1回の内部処理で完結しています。内 部処理の分割のオーバーヘッドをなくすことで、実際のエンター プライズで利用されるI/O条件において、ストレージ性能を最大 化することを実現しているのです。Pure Storage FlashArray// m50では、最大で220,000 IOPS（32KBブロック)を実現して いますが、これは一般的なストレージと比較すると1,760,000 IOPS （4KBブロック)に相当することになります（図８）。 一般的なデータベースのブロックサイズは8KBですが、マル チブロックリード機能などにより大きなサイズでI/Oが行われます。 Pure StorageはI/Oサイズに関わらず高い性能を発揮できるため、 OLTPの高速化はもちろん、I/Oサイズが大きいシーケンシャル アクセスが発生するバッチ処理やバックアップの時間も大幅に短 縮することができるオールフラッシュアレイといえます。 3.3.2 コントローラ冗長化 Pure Storageのコントローラ冗長化の方式は、前述した従来 のアプローチのデメリットを排除し、マルチパスの容易性、障害 発生時でも変わらない性能、コントローラの拡張性のすべてを実 図8: 内部処理の分割のオーバーヘッドをなくすことでストレージ性能を最大化 （資料：ピュア・ストレージ社） カタログ値で用いられる ベンチマークのI/Oのサイズ 実際のアプリケーションが実行するI/Oサイズ 4K 8K 16K 32K 64K 1,000 800 600 400 200 0 250K IOP@4KBのストレージ 500K IOP@4KBのストレージ 750K IOP@4KBのストレージ IOPS （X 1000） I/Oサイズ 図7: Pure Storageと一般的なストレージのI/O処理方式の違い （資料：ピュア・ストレージ社） 内部での I/O実行数 内部での I/O実行数 512byte～32KBまで1回で処理できるので、 効率よく処理できる 4KB単位に分割して処理をするので オーバーヘッドが発生する 1 IO 1 IO 1 IO 1 IO 1 IO 2 IOs 4 IOs 8 IOs 一般的なストレージ 4K 4K 4K 4K 4K 4K 4K 4K 4K 4K 4K 4K 4K 4K 4K 4K 8K 16K 32K 4K 8K 16K 32K
現しています（図９）。 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 スケールアウト SAN Pure Storage FlashArray//m コントローラ障害発生時の 性能維持 × 〇 × 〇 マルチパス Round-Robinの 利用 〇 × 〇 〇 コントローラの拡張性 × × 〇 (コントローラを増設) 〇 (上位モデル・最新モデルに アップグレード) コントローラ間接続起因の 障害発生有無 〇 (なし) 〇 (なし) × (あり) 〇 (なし) 図10: Active/ActiveとActive/Standby双方のメリットを実現するコントローラ ①I/Oはすべてのポートを利用して アクセス（Active/Active） ②セカンダリコントローラにアクセスしたI/Oは、 PCI-eパスを経由してプライマリコントローラ で処理される（Active/Standby） プライマリコントローラ セカンダリコントローラ 図11: 上位モデルや新しい世代のコントローラへもアップグレードが可能 ③フェイル オーバー ①既存コントローラ取り外し ②上位モデル・最新モデル コントローラ装着 ④既存コントローラ取り外し ⑤上位モデル・最新モデル コントローラ装着
3.3.3 10年以上の長期利用 前述した最新モデルへのコントローラアップグレードを利用 すると、ハードウェアの保守終了に縛られずに、同一のストレー ジを長期間利用することが可能になります。また従来は、最新モ デルのストレージにリプレースする際、システムを停止しデータ を移行する必要がありましたが、データ移行をすることなく常に 最新モデルのストレージを利用することができます（図13）。 この技術的なアプローチに加え、Pure Storageでは「Evergreen Storage」というコンセプトのもと、保守契約期間中、最短3年 ごとに同レンジにおける最新モデルのコントローラを無償提供し ています。この無償提供されるコントローラを活用することで、 導入後は保守費と、有償アップグレード（コントローラ・容量） 時の増設費用のみで利用し続けることが可能です。また容量当た りの保守費は常に一定で提供しているため、毎年の経費の平準化 が可能となります（図14）。 スナップショットやレプリケーション、OSやハイパーバイザー との連携といったすべての機能は追加費用なしで利用することが でき、将来、新たな機能が提供された場合でも同様です。すなわ ち、時代によって進化するOSやアプリケーションとのコンパチ ビリティや連携も、常に対応し続けることができます。
4 データベースシステムにおける
Pure Storage FlashArray//mの
導入効果
これまでに紹介したデータベースシステムへのオールフラッシュ アレイの導入効果をPure Storage FlashArray//mで検証しました。
評価項目 ● データベースキャッシュ最適化アプローチとのアプリ ケーション性能の比較 ● データベースキャッシュヒット率の違いによるアプリ ケーション性能の比較 ● ストレージ障害発生時のアプリケーション性能への影響
図12: Pure Storage FlashArray//mの構成例
図13: データ移行をすることなく常に最新モデルのストレージが利用可能
SASポート（拡張シェルフ利用時）
マネジメントポート（1GbE） 電源
I/Oポート（FC or 10GbE iSCSI）
レプリケーションポート
（10GbE。レプリケーション利用時）
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)を利用し、
図15: 今回の検証システム 図14: 保守契約期間中は最短3年ごとに最新モデルのコントローラを無償提供 他社製ハイブリッドアレイ （SSDはRead/Writeキャッシュ） 16Gb FCスイッチ Brocade 6505 VM1: データベースサーバー（キャッシュ最適化なし） vCPUコア数: 8
データベース: Oracle Database 12c SE2 OS: Oracle Linux 6.7
ハイパーバイザー VMware ESXi 6.Ou2 サーバー
VM2: データベースサーバー（キャッシュ最適化あり） vCPUコア数: 8
データベース: Oracle Database 12c EE ＋Oracle Partitioning OS: Oracle Linux 6.7
VM3: Swingbench vCPUコア数: 4 ツール: Swingbench 2.5
OS: Oracle Linux 6.7
16Gb FCスイッチ Brocade 6505 Pure Storage FlashArray//m Pure Storage 従来のストレージ 1年目 2年目 3年目 4年目 5年目 6年目 7年目 8年目 9年目 10年目 4年目以降の保守費が上昇 ストレージの再選定・ リプレースやデータ移行が必要 従来のストレージ 製品 本体 製品 本体 製品 本体 保守 保守 保守 保守 保守 保守 保守 保守 保守 保守 保守 保守 保守 保守 保守 保守 保守 保守 保守 保守 Forever Flashによる コントローラアップグレード Forever Flashによる コントローラアップグレード Forever Flashによる コントローラアップグレード
VMware Storage vMotionで仮想マシンをストレージ間でマイグ レーションしながら検証を実施しました。またハイブリッドアレ イを利用した検証においては、ストレージキャッシュヒット率が 90%以上になるのを確認してから測定しています。
4.2 データベースキャッシュ最適化アプローチとの
アプリケーション性能の比較
本検証では、キャッシュ最適化がされていないデータベースサー バーをオールフラッシュアレイで動作させた場合に、キャッシュ 最適化がされたデータベースサーバーとのトランザクション数が 同等であることを確認しました（図16）。 データベースキャッシュヒット率が90%である場合、オール フラッシュアレイの環境で約3倍高いトランザクション性能を示 しました。これは、データベースサーバーのキャッシュ、ストレー ジのキャッシュ、どちらにもヒットしなかったI/Oが、HDDに アクセスした際のI/O応答時間の差に依存しているといえます。 またデータベースキャッシュヒット率が99%である場合と比較 すると1.06倍の性能であり、データベースキャッシュが最適化さ れていなくても、オールフラッシュアレイであれば同等以上の性 能が実現できるということを示しています。 レスポンスタイムで比較した場合、いずれのケースにおいて も平均レスポンスタイムでは運用上の実質的な差は見受けられま せんでした。しかしながら、最大レスポンスタイムにおいてはハ イブリッドアレイを利用した場合では2秒以上となっており、全 体のSLAに影響が出ているといえます。一方、オールフラッシュ アレイの場合は214ミリ秒に留まっており、10倍以上の改善効 果があるということが確認できました。4.3 データベースキャッシュヒット率の違いによる
アプリケーション性能の比較
本検証では、オールフラッシュアレイを利用したデータベー スシステムにおいて、データベースキャッシュヒット率に関わOracle Database 12c SE2
DBキャッシュヒット率 90% Oracle Database 12c EE + Oracle Partitioning DBキャッシュヒット率 99% ハイブリッドアレイ Pure Storage FlashArray//m ハイブリッドアレイ
平均レスポンスタイム (ms) 89 20 21 最大レスポンスタイム (ms) 2093 214 2399 図16:データベースキャッシュ最適化アプローチとのアプリケーション性能の比較 （東京エレクトロンデバイス 実測） 1秒間あたりの平均トランザクション数 （Oracle EE ＋ ハイブリッドアレイを1とした場合の相対値） トランザクションあたりのレスポンスタイム 1.2 1 0.8 0.6 0.4 0.2 0
ハイブリッドアレイ Pure Storage FlashArray//m ハイブリッドアレイ 0.35
1.06
1.00
Oracle Database 12c SE2 Oracle Database 12c EE＋Oracle Partitioning
DBキャッシュヒット率＝99% DBキャッシュヒット率＝90%
図17: データベースキャッシュヒット率の違いによるアプリケーション性能の比較 らず、安定した性能を実現することを確認しました（図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ミリ秒以下であり、 運用上の実質的な影響はないことを確認しました。5 まとめ
本書では、フラッシュストレージによるデータベース高速化ア プローチを紹介し、オールフラッシュアレイであるPure Storage FlashArray//mでの検証を通じて、その効果を確認しました。 データベースキャッシュヒット率が90％である時、ハイブリッ （東京エレクトロンデバイス 実測） 1秒間あたりの平均トランザクション数 （Oracle EE ＋ ハイブリッドアレイを1とした場合の相対値） 1.4 ハ イ ブ リ ッ ド ア レ イ ハ イ ブ リ ッ ド ア レ イPure Storage FlashArray//m Pure Storage FlashArray//m ハ Pure Storage FlashArray//m Pure Storage FlashArray//m
イ ブ リ ッ ド ア レ イ ハ イ ブ リ ッ ド ア レ イ 1.2 1 0.8 0.6 0.4 0.2 0 0.35 1.06 0.74 1.14 0.81 1.17 1.00 1.24
Oracle Database 12c SE2 Oracle Database 12c EE ＋Oracle Partitioning
ドアレイと比較し約3倍のトランザクション性能の向上を確認し、 キャッシュ最適化アプローチ (データベースキャッシュヒット率 99％)と比較して同等以上のトランザクション性能が実現できる ことを確認しました。最大レスポンスタイムは10倍以上向上し、 全体的なSLAを容易に保つことが可能であることを確認しました。 またオールフラッシュアレイにおいてキャッシュ最適化をし た場合でも、トランザクション性能の向上は1.17倍であり、キャッ シュヒット率に関わらず高いトランザクション性能を実現できる ということを確認しました。 ストレージ障害が発生した場合のアプリケーション性能への 影響においては、トランザクション数は最大で10％の低下にと どまり、最大レスポンスタイムも実運用上影響のない範囲である ことを確認しました。また障害発生時だけではなく、ピュア・ス トレージ社が提唱するEvergreen Storageのコンセプトであるオ ンラインでのコントローラアップグレードが可能であることの裏 付けを一部示しています。 以上のことから、データベースシステムのストレージとして Pure Storage FlashArray//mを採用することで、導入時における キャッシュ最適化のコスト削減を実現し、キャッシュヒット率の 低下やストレージ障害が発生しても安定的なアプリケーション性 能を維持することが可能であるということが、検証を通じて確認 できました。さらにEvergreen Storageのコンセプトにより、毎 年の経費を平準化しながら、リプレースすることなく常に最新の ストレージを長期利用することが可能であり、高い信頼性と稼働 率が求められるデータベースシステムのストレージとして最適で あるといえるでしょう。 最後に、ピュア・ストレージ・ジャパン株式会社様をはじめ、 本書の作成にご協力いただいた方々に、感謝と御礼を申し上 げます。 （東京エレクトロンデバイス 実測） 正常時 コントローラ障害 1SSD障害 2SSD 同時障害 平均レスポンスタイム (ms) 20 20 24 28 最大レスポンスタイム (ms) 214 203 367 395 図18: ストレージ障害発生時のアプリケーション性能への影響 1秒間あたりの平均トランザクション数 1.00 0.50 0.00 正常時 コントローラ障害 1SSD障害 2SSD同時障害 1.00 1.00 0.96 0.90 DBパフォーマンスお悩み相談所 東京エレクトロンデバイスでは、お客様の環境や課題のヒアリン グから調査・分析を行い、どのようなソリューションでDBパフォーマン スを改善できるのか、改善ポイントはどこかなどのご提案までを行う DBパフォーマンスお悩み相談を承っています。DBパフォーマンスの ボトルネックは今回ご紹介したストレージ性能以外にも多岐にわたり ます。分析結果をもとに、ハードウェア・ソフトウェア製品を活用したデー タベースシステム全体の最適化をご提案します。 URL: http://cn.teldevice.co.jp/case/detail/db_performance トランザクションあたりのレスポンスタイム
2016年7月 新宿 : 〒163-1034 東京都新宿区西新宿3-7-1 新宿パークタワー S34階 Tel.03-5908-1990 Fax.03-5908-1991 名古屋 : 〒451-0045 愛知県名古屋市西区名駅2-27-8 名古屋プライムセントラルタワー8階 Tel.052-562-0826 Fax.052-561-5382 大阪 : 〒540-6033 大阪府大阪市中央区城見1-2-27 クリスタルタワー33階 Tel.06-4792-1908 Fax.06-6945-8581 豊田 : 〒471-0027 愛知県豊田市喜多町1-140 ＧＡＺＡビル4階 Tel. 0565-30-1010 Fax.0565-30-1030 http://cn.teldevice.co.jp CN カンパニー 「Connect Beyond」は、ステークホルダーの皆様の期待と信頼に応えるため、
