ピュア・ストレージがアプリケーションをシンプルかつ高速にする理由

データベースはビジネスを支える重要なシステムであり、その中核コンポーネントがストレージです。データベース環境で必要な性能を発揮し、コスト効率や運用性に優れ、将来にわたって活用できるストレージ製品を選びたいものです。本稿では、The Orange Ring – Tech セミナー第 12 回の内容を抜粋してご紹介します。

村山雅彦

5月 11, 2020

38分

はじめに

ピュア・ストレージ・ジャパンは、お客様のデジタル変革を支援する取り組みの一環として、技術セミナー「The Orange Ring – Tech」を開催しています。

データベースはビジネスを支える重要なシステムであり、その中核コンポーネントがストレージです。データベース環境で必要な性能を発揮し、コスト効率や運用性に優れ、将来にわたって活用できるストレージ製品を選びたいものです。2019 年 11 月 29 日開催の The Orange Ring – Tech セミナー第 12 回では、FlashArray がデータベース環境にも最適である理由をプリンシパル・システムズ・エンジニアの岩本が、また、VMware vSphere 環境におけるチューニングのコツについて、わたくし村山が実践を交えながら解説しました。本稿では、当日の内容を抜粋してご紹介します。

データベース環境にも最適なピュア・ストレージ

企業 IT の多くは、データベースを活用しています。迅速な経営判断を行うためには、膨大な情報をどれだけすばやく扱えるかが重要です。データベースの性能を決める要素として、ストレージは最も影響度の高いコンポーネントといえるでしょう。

現在のストレージ分野では高速なフラッシュ・メモリが一般的となり、その性能を活用したデータベース製品が広まりつつあります。とはいえ、どのようなフラッシュ・ストレージでもよいというわけではありません。単なる機器性能だけでなく、TCO の最適化や運用負荷の軽減、ベンダー・サポートも重要な検討要素となるでしょう。

ピュア・ストレージは 2019 年に創業 10 周年を迎え、製品ポートフォリオも強化されています。中核であるオールフラッシュ・ストレージの FlashArray//X、容量単価を抑えることのできる安価な FlashArray//C、非構造化データ向けの FlashBlade など、幅広いラインアップでさまざまなデータ・タイプをサポートしています。

データベースの領域では、FlashArray//X シリーズが活躍します。「FlashArray//X シリーズは、ローエンドでもハイエンドでも同じアーキテクチャを採用しており、いずれのモデルも 99.9999％の可用性を維持します。そのためスモール・スタートが得意で、容易に拡張していくことができるという特長も備えています。」（岩本談）

FlashArray//X がデータベースに最適なストレージである理由として、3 + 1 の要素があげられます。

容量単価とスペースの最適化
ワークロードを選ばないアーキテクチャで高い性能を発揮
運用と監視が極めてシンプル

プラス：これまでのストレージ製品にはなかった永久保証プログラム Evergreen Storage で進化

ピュア・ストレージがデータベース環境に最適な 3 ＋ 1 の理由

それぞれの理由をくわしく見ていきましょう。

1. 容量単価とスペースの最適化－高いデータ削減率で HDD 並みの容量単価を実現

今どきのストレージ製品は、圧縮や重複排除といった技術で実際に格納されるデータ量を削減し、見かけ上のデータ容量を拡大する機能を有しています。単に機能の有無で各社製品の〇✕比較表を作成すれば、いずれも “〇” という評価になるでしょう。しかし、ぜひ注目してほしいのが、データ削減率です。

ピュア・ストレージは、高価なイメージのあるフラッシュ・ストレージも HDD（SAS）並みの価格であれば採用しやすいという考えから、データ削減率を追求して開発を行っています。おおよそのデータ削減率が 3 ～ 5 倍になれば、HDD 並みの容量単価を実現できます。

HDD（SAS）並みの価格を実現するには

「データベース環境の国内事例では、平均すると 4 ～ 5 倍程度の効果が得られています。ある国内企業の Oracle 環境の実データでテストしたところ、他社製品では 1 倍強～ 2 倍弱程度であったものが、FlashArray では 4 倍超の性能を示しました。」（岩本談）

このデータ削減率を最大限に活用したのが、サントリーグループ各社の IT を担うサントリーシステムテクノロジー株式会社様の事例です。同社は当時、サーバー仮想化や Oracle Database でラック 5 本分のシステムを運用していました。ピュア・ストレージにより 5 倍のデータ削減効果を得て、5 ラックを 11U サイズに縮小することができました。さらに、ストレージ性能も 10 倍に向上し、堅牢なシステムを構築できました。

2. ワークロードを選ばないアーキテクチャ－ボトルネックを解消

FlashArray は、「ワークロードを選ばない」という点でも人気のストレージです。多くのストレージ製品は、4 KB のブロック・サイズに最適化してカタログ・スペックを示していますが、4 KB を扱うアプリケーションはほとんどありません。8 KB ～ 16 KB の領域から FlashArray の性能が他社製品を凌駕しはじめ、32 KB ～ 64 KB の領域では FlashArray が群を抜いて高性能です。

ワークロードを選ばないアーキテクチャ

データベース（読み込み）は 8 KB サイズが標準的ですが、フラッシュ・ストレージでボトルネックになることはありません。データベースで性能劣化が懸念されるのは、書き込みやバッチ処理です。例えば、Oracle Database のバッチ処理では、デフォルトなら 1 MB で I/O が要求されます。Microsoft SQL Server なら 64 KB です。つまり、スモール I/O の IOPS ではなく、ラージ I/O の帯域幅に注目すべきなのです。リード性能とライト性能のギャップが小さいかどうか、大きなブロック・サイズでも高い性能を示すかどうかを選定ポイントと考えましょう。

「大手商社の株式会社山善様の事例は、FlashArray の性能に着目されました。パッケージ・ソフトのためデータベースのチューニングができず、ハードウェアによる改善を図ったのです。FlashArray によってバッチ処理の性能が 70 ～ 90％も向上し、データベース・サイズは 10 分の 1、ラックスペースは 12U から 3U に削減されました。」（岩本談）

3. 運用と監視が極めてシンプル－ Oracle Database 環境の運用、将来設計も容易

データベース用のストレージとしては、運用や監視についても注目したいところです。特にバックアップは、重要な要素の 1 つです。

Oracle Database 12c では、バックアップ・モードにすることなく、ストレージで取得したスナップショットを Oracle 社が正式にサポートするというアナウンスがありました。いくつかの準拠すべき要件はありますが、バックアップ運用がシンプルになるという大きなメリットがあります。
参照：Oracle® Database バックアップおよびリカバリ・ユーザーズ・ガイド 12c リリース 1（12.1）「サード・パーティのスナップショット・テクノロジを使用したバックアップの作成」項

要件を満たしていることは大前提として、ストレージ製品を選定するうえで重要になるのが、次の 2 点です。

データベース関連ファイルのレイアウト
複数ボリューム間のスナップショットの一貫性

FlashArray は、以前から大規模 Oracle 環境のバックアップに活用されていました。ある大手金融事業者様の事例では、Oracle Database で株取引環境の次世代執行基盤向けストレージとして採用していただき、シンプルなバックアップとクローン運用を実現されています。システム試験のたびに 2 時間かけて行っていた前後処理を、スナップショットを活用して数秒へ短縮できたとのことです。

動画：Oracle を高速かつ簡単にクローン
〜プレゼン編〜

動画：Oracle を高速かつ簡単にクローン
〜デモ編〜

運用をシンプルにする管理ツール Pure1 にも注目です。ストレージ・アレイのログは、30 秒ごとにクラウド上のサポート環境である CloudAssist へ送信され、蓄積されます。このログは、サポート・ベンダーやエンジニアが確認できるようになっており、故障や故障の予兆が発見されると、ストレージ・アレイはアラートを発信します。この通知はユーザー担当者だけでなく、Pure1 を通じてピュア・ストレージの営業担当者やパートナーの SE などにも送られ、必要に応じてサポート・チケットが自動的に発行されるのです。

関係者全員がリアルタイムに状況を把握

例えば、Pure1 を活用されている株式会社NTTデータ様の事例では、システム障害時でも組織階層ごとに状況を瞬時にシェアすることが可能になりました。プロアクティブな保守ができるため、サービス品質が向上したという評価をいただきました。また、Pure1 のキャパシティ・ツールやフォアキャスト・ツールを活用することで、容量推移のトレンドを把握して高精度な予測を実現することで、システム全体をプロアクティブに最適化されています。

「Evergreen Storage もデータベース運用の TCO 削減に効果的です。いったん導入すれば、保守費用のみで永続的にアップグレードが可能です。ピュア・ストレージでは、毎年、新コントローラを発表しており、性能や機能がどんどん向上しています。3U サイズでスケールアウトしていく必要もなく、ラックスペースや消費電力が肥大化することもありません。」（岩本談）

動画：エンタープライズ・ストレージの概念が変わります ― “Evergreen”

Queue Depth に注目して vSphere 環境を高速化する

このセクション以降は、わたくし村山がお話しさせていただいた内容となります。

ピュア・ストレージは、サーバー仮想化環境にも最適です。ここからは、国内でもシェアの高い VMware vSphere 環境を高速化する手法をご紹介します。

VMware をはじめとした仮想化環境は、仮想マシンからストレージまでにハイパーバイザや HBA アダプタ、SAN スイッチなどを介しており、深い階層状になっています。

ストレージまでの階層

高速化（パフォーマンス・チューニング）とは、性能が制限されているポイントを他に移す作業です。ある部分でのボトルネックを安易に解消しても、他の部分でボトルネックが発生しては全体の問題は解決できません。複数のポイントで段階を追って調整していくことが重要です。

ストレージの性能を調整する場合には、Queue Depth（キュー深度：1 回に処理できるリクエスト数）の数値に着目する必要があります。並列で 10 個の処理ができれば、Queue Depth == 10です。リクエストが増えれば、11 番目以降は待ち行列に並ぶことになります。

VMware vSphere 環境の Queue Depth には、次の 4 つがあげられます。

Storage Array Queue Depth Limit
Device Queue Depth Limit
vSCSI Adapter Queue Depth Limit
Virtual Disk Queue Depth Limit

次のセクションでは、あるトラブルシューティングの事例を取り上げて、実際に Queue Depth を調整していく手法を解説します。

複数ポイントの同時調整で期待値どおりの性能へ回復

事例の対象となるシステム構成は、以下のとおりです。

96 スレッドでディスク I/O を行う
準仮想化 SCSI アダプタをデフォルト設定で使用
ファイバー・チャネルで接続された FlashArray 上のデータストアに仮想ディスクを配置

このシステムでは、以下のような性能に課題がありました。

仮想ディスクから見たディスク遅延が大きく、オールフラッシュなのに遅い
遅延の期待値が 0.7 ミリ秒だとすると、次の性能を発揮することが期待される
– 1 スレッドあたり 1,429 IOPS
– 96 スレッドでは 13 万 7,000 IOPS
→ しかし、実際には 6 万 5,000 IOPS しか出ていない

ゲスト OS ／アプリケーションから見ると、遅延は 1.46 ミリ秒ほどでした。ところが FlashArray では、0.4 ミリ秒でリクエストに応えていました。つまり、上述した階層の中で、1 ミリ秒ほどのロスがあるということです。

仮想マシンと FlashArray の稼働状況

ESXi では、esxtop コマンドで遅延の状況を確認できます。DAVG（Device Latency）、KAVG（Kernel Latency）といったキーワードが並びますので、それぞれどの領域から見た遅延であるかをしっかり認識しておきましょう。

DAVG（Device Latency）、KAVG（Kernel Latency）

実際に確認すると、ACTV（Active）が 32、QUED（Queued）が 32 弱ということがわかりました。DQLEN（Device Queue Length：対象 LUN の Queue Depth の上限）を見ると 32 となっており、33 番目以降は待ち状態になっていたのです。つまり、このまま仮想ディスクの Queue Depth を増やしても、全体の遅延は解消されないということです。ボトルネックが、カーネルやゲスト OS といった下位レイヤーに移ってしまうためです。

DQLEN（Device Queue Length）

では、DQLEN 値を大きくしてみましょう。標準的な vSphere 環境では、物理 HBA の Queue Depth と、Sched-num-req-outstanding 値の両方を調整する必要があるため注意してください。

物理HBAの Queue Depth 値
- 各メーカ毎に異なるデフォルト値
- 適切に変更　https://kb.vmware.com/s/article/1267
Sched-num-req-outstanding 値
- LUN 毎に設定
- 適切に変更　https://kb.vmware.com/s/article/1268
関連する全ホストに適用（ホストの再起動が必要）

変更後の DQLEN

実際に値を調整すると、いずれの領域でもボトルネックは発生しておらず、レスポンス・タイムは 0.7 ミリ秒へ改善、約 13 万 IOPS を実現できました。

エンドツーエンドで改善

FlashArray は高性能なため、通常はなにも変更せずに運用できます。特定の性能要件があり、FlashArray 側の負荷が高くないのに十分な性能がでない場合には、チューニングが必要な場面があります。設定は慎重に適用することと、ホストの再起動が必要になることに注意しましょう。いずれにせよ、FlashArray 側の設定を変更する必要はありません。