ニンブルストレージ／川端 真氏、DBオンライン／谷川 耕一
各社各様、フラッシュはいつどのように使うべきか？
谷川：近年データベースを高速化する技術で注目されているもののひとつにフラッシュがあります。「速い」の定義や目的は多様ではありつつも、いま現場でデータベースの速さにはどのようなものが求められているのか、将来性や懸念点など多角的にお話しいただけたらと思います。
川端：ストレージベンダーから参加します。みなさん「ニンブルストレージ」を聞いたことがあるでしょうか。昨年日本法人ができたばかりです。データベースに速さを求めるのであればストレージにフラッシュを使えばいいのですが、コストがかかります。ディスクにはディスクのいいところがあります。ニンブルストレージはディスクとフラッシュの特性を生かして、安価でも高速を目指しています。
谷川：絶対的な速さを追求するよりは、お客様が求めている速さを適度なコストで応えるというところでしょうか。
川端：そうです。ニンブルの優れているところは、容量を犠牲にせず低コストで高いパフォーマンスを提供する点です。適切な価格でパフォーマンスを提供することにより、幅広いお客様に快適なストレージ環境を提供しています。
谷川：逆にEMCさんはストレージに関しては上から下まで幅広いラインナップで提供しているかと思います。いま顧客の現場を見るとどうですか？
若松：普遍的な課題一つ見ても状況が変わってきています。例えば、バッチ処理に時間がかかるという課題です。バッチ処理は連続的なシーケンシャルアクセスだからHDDのほうが効率的、と考えられがちですが、仮想化、シンプロビジョニング、データベースアプリ側の重複排除、圧縮機能等の効率化技術を使うと、データベースからはシーケンシャルでも、ストレージへのアクセスはランダムになります。
実際の例を挙げると、イスラエルの保険会社CLAL Insurance社では、仮想環境で運用していたデータベースの月次レポーティングのバッチ処理に14時間かかっており、毎月初日は14時までシステムが利用できないという状況でした。最初に既存のハイエンドストレージにSSDを追加したハイブリッドストレージを試しましたが、わずか2時間速くなっただけ。それをオールフラッシュアレイにすることで、バッチ処理を8時間半短縮することができ、5時半にはバッチ処理を完了できるようになりました。これにより、年間90万ドルの機会損失が解消できる見込みです。ハイブリッドストレージと違い、チューニングに時間をかける必要もありません。そこではなく、他に時間をかけるべきだという見方も増えています。オールフラッシュアレイへの投資もすぐに回収できます。
かたや、新しいニーズも増加しています。分析などデータベースの活用方法の拡大と、アプリのアジャイル開発の要望が増加しており、そのタイミングでストレージの性能とコストを見直してフラッシュを選択するケースも出てきています。スコットランドの投資管理会社Baillie Gifford社では、テスト、開発、分析、レポーティングのためにデータのコピーを20個取っていました。オールフラッシュにすることで、コピーする時間が大幅に短縮され、開発にかける期間を30%短縮できました。オールフラッシュストレージの重複排除技術を活用したことで、29TBのデータ容量をわずか1.45TBに抑えることができました。従来同じデータでありながら用途の違いで、分けて持っていたデータをコンソリデーションすることでリアルタイムに分析ができるだけでなく、コストが下げられるというメリットがあります。
谷川：佐野さん、先日のテープの発表会では「速いフラッシュと単価が安いテープの二極化が進む」と話していましたね。
佐野：データベースに対する速さのニーズというのは一般的にお客様のほうが敏感です。本番のデータベースを早くしたいなら「フラッシュを使えばいい」ということは誰でも分かります。ただ若松さんからご指摘があったように、開発のスピードを上げたいという要望も多いです。例えば動画や音声を用いた製品。本番の製品は圧縮しますが、開発段階ではあまり圧縮しません。またゲーム業界も本番環境よりも、開発環境をよくしたいという要望があります。ヒットを作れるかどうかはクリエーターの腕にかかっていますから、開発環境を良好にすることはとても大事です。
データベースに関しては、まずサイズ。動画と違いキャラクターベースでさほど容量が大きくならないのでフラッシュが使われるケースが多いです。適用場所もいろいろあります。例えばログだけフラッシュを使うケースだと、書き込みのスピードが速くなります。参照はメモリにヒットさせればいいのでメモリを10～20TBでも積めばいいわけです。
逆もあります。仮想環境やソフトウェアでストレージを二重化してリードを「prefered」、つまり優先的に行います。読み込みの比率が高いシステムで読み込みを常にフラッシュから行えば全体的な高速化が実現します。やめたければ「リードだけ」なのでやめればいい。そんな作戦もあります。
データベースも幅広くあります。NoSQLもデータベースと言うのであれば……
谷川：言います言います。
佐野：単体のデータベースの欠点は、厳密にはクラスタリングできませんよね。1つのOSの上に動いているので。親玉は1つなのでそこがボトルネックになります。それで親玉のデータを「主記憶に展開したい」という要望があります。実際にやっている人に「その状態で電源切れる？」と聞いてみると、みんな「怖くて切れない」と言うのです（笑）。コンセントを抜いて、無停電電源装置を使いデータロストしないようにシャットダウンして、無事に再起動できますか？ IBMでは主記憶のフラッシュをCPUにバスで直結する技術があります。
谷川：それはフラッシュを主記憶の記憶装置のように？
佐野：NoSQLは常に参照するテーブルと、ポインターとして保有するテーブルを差別化できます。ディスクよりは速くて主記憶より遅いレイヤーに、主記憶より速くアクセスできればデバイスドライバを経由するオーバーヘッドがなくなるとか、過負荷でなくなるとか、メリットが出てきます。データベースを速くするといっても、開発環境を速くする、本体を速くするなどいろんな作戦があります。
意外かもしれませんがお客様は「高いから買わない」とは言いません。すべてをフラッシュに入れ替えたお客様もいます。
谷川：「高いから」とコストで敬遠するお客様は少ないということですか？
若松：データベースは、CPUコアベースのライセンス費用とそれに伴うメンテコストが高いのが課題だと考えられているケースが多いと思います。同じ性能を出すためのコストを、システム全体としては安くしようと思ったときに、逆にストレージに投資するという考え方があります。なぜなら、ストレージの処理性能が足りなくてIOがボトルネックになると、サーバ側のCPU利用率が上がらないからです。使われていないCPUコアを抱えた上に、そのためのライセンス費用がかかるわけです。逆に、ストレージのIO性能が上がればCPUの利用率が上がって、より少ないコア数で同じIOをさばけるようになります。ストレージのIOボトルネックを排除することで、導入ライセンスコストを削減し、システム全体として安くなったという事例が、EMCのオールフラッシュアレイを導入したITサービス事業者のCMA社で実際にありました。
何が言いたいかというと、「高い」というのをストレージのハードウェア単体だけで考えるべきではない、ということです。特に新規に導入する際には、です。逆に、既存のデータベースのサーバのCPU数を減らすことには抵抗があると思います。そのとき、しばしばストレージ単体のROIだけで見られてしまうわけですが、そういったケースでも、ほかのアプリケーションと比べてデータベースは最終的にストレージのコストで敬遠されることは少ないです。最近ではさらに「速くする」ニーズのほうが強くなっているように感じています。
