« [最新鋭、IBM FlashSystem A9000を大解剖!] | メイン | カーネル vs ユーザーモード »

2016/09/14

ウェブスケールインフラストラクチャ上のオールフラッシュのパフォーマンス

本記事の原文はNutanix社のGlobal Engineering / R&D TeamでManager Business Critical Appsを務めるMichael Webster氏によるものです。原文を参照したい方はAll Flash Performance on Web Scale Infrastructureをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら

Fig020_2

オールフラッシュストレージアレイは今日では人気を博し、従来からのミッションクリティカルなファイバーチャネルのアレイから大きくビジネスを移行させつつ有ります。そして、従来型の3層構造のアーキテクチャは少しだけですが、シンプルになりました。僅かな数の仮想マシンが大きなパフォーマンスを必要とするようなスケールアップ型のワークロードに対し、優れたパフォーマンスを提供し、さらに、データ削減のテクニックを利用してキャパシティの削減も同時に提供しています。オールフラッシュシステムがさらに優れているのは大きな負荷がかかったり、キャパシティが限界に近い状態であったとしても一貫したパフォーマンスと低遅延を提供するということです。しかし、従来型のアーキテクチャに比べて少しだけシンプルだ、ということはまったくもってシンプルであるとは程遠いのも事実です(FCの管理オーバーヘッドだけ)。そして、まだインフラストラクチャがインビジブルであるともいえません。まだ幾つかの制限があります。オールフラッシュが欲しくて、更に制限のないスケールアウトも欲しい、数千の仮想マシンを動作・サポートしなくてはならない、でも管理を従来型の3層構造よりも簡単にしたいとなったらどうしますか? 効率よくインフラストラクチャをインビジブルにしたいのです。

答えはとても簡単です。インフラストラクチャが将来そうなるのと同じで、Nutanixを選択すればよいのです。Nutanixは1年前にオールフラッシュソリューションを打ち出しました、そして一貫した高パフォーマンスと想定通りの低遅延優先度の高いワークロードに対して望むお客様に大きな人気を博しています。NX 9040ノードは6本のIntel S3700というエンタープライズクラスのSSDとE5 v2を2ソケット、最大で512GBのメモリを融合させています。このソリューションは2ラックユニットのスペースに2ノード(最大でラックあたり364TBの物理フラッシュストレージ)収めることが出来ます。これはOracleデータベースやSQLサーバ、SAP、Temnos T24 core Bankingなどにうってつけのプラットフォームで、これら全てを動作させているお客様までいます。特に、Nutanixのデータ削減機能やデータ回避機能と組み合わせると、同じ物理ストレージ内で更に多くのキャパシティを利用することが出来ます。Josh Odgers氏(NPX #001)はEC-Xと呼ばれる新しい機能(訳注:リンク先は英文、現在のところ翻訳予定なし)についての記事を公開しています。

Nutanixのデータ削減

データ削減には圧縮、データ重複排除そして、EC-Xなどが含まれます。データ回避機能は例えばVAAI統合、シンプロビジョニング、そしてスマートクローンとスナップショットなどで、不必要なデータや重複したデータを最初に作成しない機能です。データベースやビジネスクリティカルアプリケーションでは、圧縮は推奨されています。重複排除については大規模なデータで異なるデータが多い場合にはさほど効果的ではないというケースも有ります。こうした手法によってそのまま利用するよりも、もっと利用できるキャパシティが増える可能性がありますが、その効果はワークロードによって様々です。2:1、3:1もしくはもっと高い割合のことも有ります。単一の手法だけでも、ワークロードに向いている手法であればもっと高い割合になることもあるのです。

データベースにおいてSQLサーバで透過的データ暗号化(TDE)やOracleでアドバンスドセキュリティ暗号化を利用しているような場合、これほどには効果が出ない場合もあります。NX9040を含む、同じプラットフォームでデータ最終暗号化をサポートしており、これによってアプリケーション自身での暗号化を不要にする事も可能です。暗号化されたワークロードにおいてキャパシティを効率的に削減するのは難しいものです。以下のイメージはNX9040の単一クラスタでNutanixのPRISMユーザーインターフェイスから見た際のOracle RAC データベースがどれほどの削減がなされたかを表しています。これは実現出来ていることのほんの一例でもちろん、ワークロードに依存します。効果は様々なのです。

Fig021

上記のイメージからはデータベースが5.57TiBのキャパシティをデータ削減前に利用していたということが分かります。データベース自身は3TBですから、データ保護やデータ保全性のためのオーバーヘッドがあることが分かります。データ削減が行われた後のキャパシティは1.95TiBのみです。この削減効果は圧縮からの効果のみです。もしも圧縮とEC-Xを組み合わせれば、もっと大きな削減効果を得ることが出来るはずです。Nutanixクラスタが大きくなれば、データ削減の手法は更に効率的なものになります。

もう一つ圧縮の例を上げましょう。今回はExchangeにJetStress Databaseで負荷をかけたものです。(注意 : JetStressは実際の世界ではあり得ないワークロードでここでのデータ削減率は実際のExchange環境での物よりも高い可能性があります。)

Fig022

殆どの環境では検証・開発のワークロードが本稼動系とともに動作しています。Nutanixのやり方では、ワークロードのスナップショットの作成やクローンの作成してもストレージ消費は増えることはありません。これ等の操作ではデータに変更がないからです。これはテンプレートを展開する際にもESXiとVAAI(VMware API for Array Integration)で同様に実現されます。新しい仮想マシンを欲しいだけ展開しても、実際にデータが書き込まれるまではストレージの消費は増えないのです。

こうした手法を利用して、100%完全なデータを開発・検証環境で利用しながら、ストレージの消費を抑えることが可能です。高いレベルでコードが動くという確信を持ちながら、本稼動系へとワークロードを移行することができ、いつでも検証環境の状態へと戻ることも出来るのです。全ては数秒で追加ストレージキャパシティを消費するという心配は必要ありません。

Nutanixのデータ削減とデータ除外手法についてはNutanixバイブルの分散ストレージファブリックのセクションもご参照ください。

Nutanixのオールフラッシュのパフォーマンス

データ削減や回避の手法によってワークロードのパフォーマンスも様々に変化します。単一のアプリケーションからのIOパターンが単一であるということはほとんどありません。ですから、パフォーマンスを検証するのにもっともよい方法は実際のアプリケーションを利用することです。実際のアプリケーションは4KBサイズのIOだけを生成するということは一般的にはありません。ですから、今回はNutanixのオールフラッシュのパフォーマンスを検証するためにSLOB(SLOBのオフィシャルページはこちら)、SwingbenchBenchmark Factory for DatabaseHammerDBのようなツールを利用しました。ここではSLOBを利用して取得したイメージを例に提示します。

IOパフォーマンスを検証する際に、文脈を無視して、単独の計測値だけを見てはいけません、そうしなければ検証は意味が無いものになってしまいます。IOPSを例に取ると、IOサイズ、レイテンシ、スループットが異なれば劇的に値が変化します。ですから、IOPS単独だけでは確かな計測ができているとはいえません。今回のテストでは、Oracle RAC環境に対して、SLOBを利用して大量の小さなReadを生成しました。それぞれのReadは8Kで、これはデータベースの生のページサイズです。このIOパターンは100%ランダムです。トランザクションログのIOはかなり大きなIOサイズであり、当然シーケンシャルです。

以下のダイアグラムのテストを行ったシステムは2ノードのOracle RACクラスタ(それぞれのノードで 48 vCPU、192GBメモリ)を2台のNX4170(4 x E-4657L v2, 512GBメモリ)と4台のNX9040(2 x E5-2690 v2 512GBメモリ)で構成されたNutanixクラスタ上で動作させています。いずれのシステムも旧世代のIntelのIvy Bridgeのプロセッサ技術を利用しています。ハイパーバイザーはESXi 5.5を利用しており、後にESXi 6.0にアップグレードしたところ、更によいパフォーマンスを示しました。

Oracle RAC SLOB IOPS

Fig023

上のイメージでは2つのテストが行われています。一つ目は30%がupdate(更新、データ書き換え)であるというワークロード、もう一つは100% select(選択、データ参照)のワークロードです。updateのワークロードではきっかり70K IOPSが生成されています。

Oracle RAC SLOB レイテンシ

Fig024

異なるベンチマークの最中のレイテンシが上に表示されています。updateの多いテストではレイテンシは高くなり4ミリ秒ほどになっており、ピークでは7ミリ秒になっています。selectの多いワークロードに於いてはレイテンシは0.45ミリ秒です。2つ目のテストでのレイテンシが低いのはハイパーバイザーを最新ヴァージョンにアップグレードすることによって更に低くなりました。

Oracle RAC SLOB スループット

Fig025

上のグラフから読み取れるのはupdateが多いテストではスループットはカッチリ800MB/秒で、selectが多いテストでは1.13GB/秒でした。思い出して欲しいのはこれはNutanixのハイパーコンバージドアプライアンスであり、全体で8ラックユニットのスペースにコンピューティングとストレージの両方が収まっているということです。近い将来、Nutanixはもっとこうしたパフォーマンスを実現するための物理的なスペースと電源要件を削減する予定です。もっと小さなスペースで、そして、もっとシンプルな環境でオールフラッシュのワークロードを動作させることができる様になります。

オールフラッシュが必要なのか?

利用するか、利用しないかは当然皆様のご選択です。Nutanixは強力なオールフラッシュのオプションをNX9040で提供しています。将来のプラットフォームではこれをさらに推し進め、もっと極端なワークロードへも対応できるようにしていきます。Nutanixのプラットフォームではあらゆるノードのタイプでいくらかのフラッシュが搭載されています。データはフラッシュとハードディスクにおいてブロックレベルでのアクセス頻度に応じた階層がが行われます。オールフラッシュが必要か、そうでないかということは結局のところ、ソリューション全体のライフタイムの中で予想通りの結果を売ることが出来るか、というところに帰結します。アプリケーションがホットデータしかなく、フラッシュの上にすべてデータが有ることを保証したい場合にはオールフラッシュはそれに答えてくれます。オールフラッシュプラットフォームはオーバーヘッドが小さく、データ階層化の必要性がありません。ですが、ほとんどのワークロードにおいてはデータ階層化は非常に効率的で、充分です。

現段階で、オールフラッシュに向いているのはデータベースやアプリケーションサーバのような、低遅延サービスの保証が必要とされるものです。特に、パフォーマンス以外にも、仮想化によって物理ノードあたりのシステム数を上げることでライセンス上のメリットを受けられるような場合、更に多くのアプリケーションをノードに仮想化することが出来ます。OracleやSQLサーバを考えてみてください。

Nutanixは最近ハイブリッドのノードにおいても、フラッシュピンニングという機能をアナウンスしました。まだリリースされていません(原文執筆時、現在はリリース済み)が、リリースされた暁には仮想マシンや仮想化ディスクをフラッシュ層にピン留めすることが出来るようになります。この機能は標準のハイブリッドとオールフラッシュオプションの中間に位置するようなものです。時が経つにつれ、ほとんどのシステムはフラッシュの寡占状態になり、ハードディスクはスナップショットやバックアップ、アーカイブなどでのみ利用されるようになるのではないかと予想しています。

おわりに

今回の記事に掲載したイメージのとおり、ハイパーコンバージドのウェブスケールプラットフォームのオールフラッシュは特筆すべき管理の簡単さ、低遅延、制限のないスケールアウトが必要な環境において、優れたパフォーマンスを提供します。プラットフォームにより多くの利用可能なストレージキャパシティを提供するデータ削減と回避の手法は他のオールフラッシュアレイと同様にNutanixでも動作します。これが唯一上手くフィットしないところがあるとすれば単一の極端なワークロードまたは仮想マシンがアレイのパフォーマンスの全てを必要とするというようなケースでスケールアウトできない、計画もないというような場合だけです。こうした状況であればPure Storageのような物を選択する方が良いでしょう。それ以外のすべての場合、Nutanixは他のものに比べ遥かにシンプルなソリューションで優れたパフォーマンスと無制限の拡張性を提供することが出来ます。

記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw) 今後は (@Networld_NTNX)

いかがでしょうか? 既に様々なベンダーからオールフラッシュストレージソリューション、オールフラッシュハイパーコンバージドソリューションが提供されていますが、今回あえてこの記事を翻訳したのはいくつかのブロク/ニュースに記載されているように当社が国内で提供を行ってきた(そして私の大好きな!)PernixDataのテクノロジーが上でお見せしてきたような優れたパフォーマンスに加えて利用ができるようになるとの期待からです。PernixData社のソリューションはFlashだけではなく、メモリ、そしておそらくは今後多く登場してくるメモリクラスストレージ(または大容量不揮発性メモリ)のテクノロジーにまで利用することが出来るようになっています。Nutanix社のCVM(VSA)の実装とPernixData社のin-kernelの実装が今後どうなっていくかなど、興味はつきませんが、PernixData社が大好きな私以外の皆様の興味にも答えられるように、今後も面白い記事を選びながら更新していきたいと思います! 引き続きよろしくお願いいたします。