DWH専用機を導入したのに速度が上がらない？ 適材適所のシステム構築を考える：速度と信頼性を両立させるSSDの最適化とは

ビジネスインテリジェンスやデータマイニングの高速化を目的としたデータウェアハウス専用機が近年注目を集めている。しかし適用方法を見誤ると、高いコストを払って導入したにもかかわらず想定したスピードが出ない、ということもありうる。ここでは特にオンライントランザクション処理の高速化に必要なシステム構成について考える。

[ITmedia]

DWH専用機の台頭とDWH専用機の限界

　ビジネスインテリジェンスやデータマイニングの高速化を目的としたデータウェアハウス専用機が近年注目を集めている。従来のデータウェアハウス（DWH）システムは、ソースデータが格納されているデータベースから必要なデータをバッチ処理などでデータベースシステムにロードし、分析用キューブを作成してフロントエンドのGUIツールなどで分析を行うというものであった。

　通常のデータベースシステムは「行（Row）」ごとに格納する方法が採用されているが、高速化を目指すために「列（Column）」ごとに格納する方法を採用した専用データベースも存在している。しかし、いずれもデータをストレージに格納することから、分析対象となるデータが大きくなると、分析にかかる時間が長くなってしまうという状況は避けられなかった。

　ところが、データが大きくても高速で処理できることをうたうDWH専用機が出現して以降、分析結果をすぐに業務に反映できるという期待から、高額な投資にもかかわらず、特に流通業などでDWH専用機を導入する企業が増えてきた。

　DWH専用機ではデータの抽出を2段階に分割し、前段階でデータをある程度絞ることにより大量のデータI/Oが発生しないように工夫されたシステムや、そもそもデータI/Oが発生しないようにデータベース自体をメモリの中で処理するインメモリデータベースシステムも登場するなど、以前と比べて飛躍的に大量データを高速処理できるようになった。

　もともとDWHシステムを必要とし、すでに何らかの形で構築していた企業にとっては、既存データを使った事前検証でもその改善効果が明確に確認できたことから、DWH専用機はリプレース需要として多くの企業に導入された。

　一方で、新たにDWHを構築しようという企業にとっては、ソースデータがあるだけで抽出されたデータもないために何をどう分析してよいかもわからず、さらにDWHが実際に自社へ利益をもたらすのかどうかの判断は多くの社内手続きを必要とすることから、DWH専用機という高額な投資案件は検討途中で消滅するケースもある。そのためリプレース需要が一巡した後は、DWH専用機のニーズが固まるか否かは不透明――というのが現状ではないか。

OLTPシステムへの活用――オンライン処理とバッチ処理

　DWH専用機の新たな導入が難しい状況のなか、ユーザーのニーズとして多かったのが、オンライントランザクションシステムの高速化である。DWHとして提案された専用機であったが、高速であるならOLTPシステムにも使えるはずと、導入を決める企業が増えていった。実際、既存データを使った検証結果でも、その高速性は実証された。また、専用機1台でOLTPとDWHの両方を行うという使い方も増えている。

　しかし、DWH専用機は列（Column）型データ処理の効率化を追求しているため、オンライン処理やバッチ処理のOLTP、つまり行（Row）型データ処理の速度はDWHの場合と比べてそれほど高速化されていない。処理速度が上がったというケースでも、その要因はリプレース前の古いシステムからのハードウェア性能の向上の方が、要因としては大きかった。

　また、DWHでは列（Column）内の同一データをポインタに置換して容量を減らす圧縮技術が使われることが多く、それによるストレージ容量の削減が提案されるケースも多い。しかし実際には、OLTP系のデータでは同一データの出現率がそれほど多くなく、列での圧縮があまり奏功しなかったという実データの評価結果も見られるという。ベンダーが唱えるDWHベースでの性能や利点が、OLTPシステムでそのまま適用できると考えることは控えた方がよいだろう。

　図1はOLTP業務システムの1日のストレージI/Oの特性をイメージ化したものである。昼間はオンライン処理を行っているため、1秒間のI/O回数（IOPS）が大きく、帯域はそれほど大きくない。また、リードとライトがほぼ同程度行われていることが分かる。

図1　業務システムのストレージI/Oイメージ

　これは、端末から小さいサイズのデータを数多く読み書きしているためであり、この処理が遅くなるとユーザーはレスポンスが悪いと感じるようになる。夜間はバッチ処理が動くため、帯域が大きくなり、IOPSは若干下がる傾向にある。特に帯域はリードが大きく、ライトは小さいことが読み取れる。これらの処理が遅くなると、バッチ処理の完了が遅くなり、朝のオンライン開始時間までに終わらないという状況になる。

OLTPに合ったシステム構成とCPU性能の伸長に追いつくためのSSD

　これまでのOLTPシステムでは、オンライン処理やバッチ処理が通常のデータベースの動きを考慮した上で作られている。もちろん、その概念を打ち破り、例えば列（Column）型データベースを前提として作り替えることができれば、数時間のバッチ処理も数秒で終わってしまうなどのドラスティックな改革を実現できる可能性もある。しかし、そのような構築手法やアプリケーションアーキテクチャは現実のシステムインテグレーションレベルにはなっておらず、特にすでに作られているOLTPシステムに適用することは、まず不可能である。

　それでは、今のシステムを劇的に高速化するにはどうすればよいだろうか。それは、今までと同じアーキテクチャのまま高速化させる以外に方法はない。つまり、行（Row）型データベースを使い、サーバとストレージを使ったシステムである。

　もちろん、サーバに搭載するメモリを増やし、できるだけメモリ内で処理することで高速化を図る技術はこれまでにも存在したし、それを否定することはない。すべてのデータがメモリ内に入らない場合は、必ずストレージにアクセスされることになるし、障害に備えて揮発性のメモリから不揮発性のストレージに、ある期間ごとに書込みを行う必要がある（チェックポイント）ので、やはり従来システムの踏襲という形に落ち着くことになる。

　図2に見られるように、CPU性能はここ何年かで劇的な伸びを示しているが、それに比べてI/O性能は遅れをとっている。つまり、2004年ではバランスの良かったシステムも、現時点ではCPUに比べてI/Oが貧弱であると言わざるを得ない。また、オンラインのレスポンスはHDDの回転数に依存するが、こちらは2004年からまったく伸びていない。バッチ処理に影響のあるFC（ファイバチャネル）の帯域はせいぜい4倍程度にしかなっていないのである。

図2　CPUの性能推移とI/Oの性能推移

　これではいくら「今までと同じアーキテクチャのまま高速化させる」とは言っても無理な話である。FC帯域は数を揃えれば増やすことも可能であるが、HDD回転数は、それを採用している限り、どうしようもない。

　そこで登場したのが「SSD（Solid State Drive）」である。SSDはフラッシュメモリを使用し、HDDと互換のインタフェースである「SATA（Serial ATA）」や「SAS（Serial Attached SCSI）」を備えた、HDDに代わる不揮発性記録ドライブである。メモリは当然、回転待ち時間がなく、アドレスを指示すればすぐにデータが出てくるため、HDDより桁違いに高速なリード／ライトが可能となる。

　ただし、メインメモリに使用されるDRAMと異なる「NAND-Flash」というメモリを使用しているため、すでにデータが書かれたアドレスを書き換える処理ができないという欠点がある。そのため、データの書き換えは別の空きアドレスに書き込み、元のアドレスは無効領域として管理するという方法を採用している。NAND-Flashはある一定範囲（ブロック）を一度に消去することが可能なので、ブロックの中に無効領域が増えてくると、無効でないデータを別の場所にコピーして、ブロック内すべてが無効領域になった時点でブロックを消去する。この一連の動作を「ガベージコレクション」という。この作業にかかる時間が必要となるため、DRAMに比べると性能は劣るが、それでもHDDに比べると桁違いに速いことは間違いない。

　このSSDを使用すれば、数年前からまったく改善が見られなかったHDDの回転数による待ち時間が極端に短くなり、アクセスすればすぐにデータを読み出すことができるため、CPU性能の伸びに追いつける。実際、15000回転のHDDと比較した場合、4KBのランダムリード性能は約40倍にもなり、CPU性能を上回る性能改善となる。しかし、いくらSSDの性能が良いとはいえ、1個だけでよいかというと、容量の確保や信頼性などを考えると、HDDと同様、RAID構成を組むことが望ましい。並列化によるさらなる性能向上が見込まれるからだ。

IOPSと帯域の拡大でさらにOLTP性能が向上

　システム全体で見た場合、HDDをSSDにするだけで性能が改善されるとは限らない。OLTPシステムの性能改善には、図1にあるようにIOPSと帯域の両方を大きくする必要がある。

　まずIOPSについて説明すると、データベース処理でのストレージへのアクセスは、1つのデータを読み終えるまで次のデータを読まないということはほとんどなく、読み出しデータが返ってこなくても、連続して別のデータの読み込みや書き込みの要求を出すのが当たり前である。つまり、読み出し要求、書き込み要求が連続して並ぶことになるため、サーバからストレージへのパスが1本（あるいは少し）しかないと、そこに要求がたくさん並んでしまい、処理が順番待ちとなってしまう。

　もちろん、SSDは高速にリード／ライト要求をこなすため、HDDに比べれば順番待ちが早く解消されるだろうが、より多くの要求に応えるためには、ストレージへのパスはなるべく多い方がよいのである。これは具体的にはストレージに繋がるI/Oカード（ファイバチャネルカード）のコマンドキューのことである。コマンドキューがあふれた場合は、OSは次の要求を出すことができなくなってしまうため、処理を先に進めることができなくなってしまい、全体的にデータベースが遅いという現象として見えてくる。

　従って、SSDのように処理の速いストレージであれば、I/Oカードを増やすことにより多くの処理を同時に行うことができるようになるのである。つまり、IOPSがより大きくなるということである。

　CPU性能の伸びに対し、FC帯域はあまり伸びていないことが図2に示されているが、バッチ処理ではより大きな帯域が必要となることが図1からも分かる。エンタープライズ向けSSDで使用されるSASインタフェースの速度は6Gbps（12Gbpsのデバイスも登場し始めている）なので、これらのSSDをRAID構成にした場合、データの読み出し速度は6Gbpsに（パリティを除いた）台数をかけたものになる。

　この帯域でデータを読めるにもかかわらず、8GbpsのFCケーブル1本で接続していては、せっかくのSSDの高速性を損なってしまうことになる。ベンダーによっては、この接続をより高速な「InfiniBand」で接続している事例を見かけることもあるが、やはり信頼性と実績でいけば、FCカードを複数枚搭載して接続した方が安心である。

　また、冗長化という意味でも、カード故障時の影響がより少なくなること、さらには先のIOPSの向上という点でも効果があるため、なるべく多くのFCカードで接続することが望ましいと考える。接続する本数は6GbpsのSSDの数と8GbpsのFCの帯域合計が合うようにするのがよい。

　ここで1つの疑問を抱く方がいるかもしれない。HDDの場合も同様に6Gbpsのインタフェースを持っているが、これまでのHDDシステムでも多くのFCで接続すれば性能が出るのではないかという疑問である。

　これは、シーケンシャルリードばかりのアクセスならば正しいが実際はそうではない。HDDはシーケンシャルリードの場合には円盤上に書かれたデータを連続して読むため、大きな帯域でデータを送り出すことができる。例えば、ビデオ映像のようなデータを記録して再生するという場合である（ただし、実際にはビデオ映像は圧縮されているため、大きくても20Mbps程度で、SASの帯域を使い切るまでには至らない）。

　HDDでもシーケンシャルリードではSASの帯域を使うことができるが、ランダムリードになると、HDDのヘッドの読み出しと次の読み出しの間にヘッドの回転待ち時間ができてしまい、大きな帯域で読み出すことができない。従って、多くのFCケーブルで接続したとしても、HDDシステムでは帯域を使い切れないのである。また、OLTPシステムでは、HDDにきれいな順番でデータが並んで入っているわけではなく、表としては順番に読んでいるつもりでも、HDDとしてはそれほどシーケンシャルリードという状態になっているわけではない。そのため、SSDと同様の性能は出すことができないのだ。

---

　以上、OLTP処理高速化に向けたSSDによるI/O高速化と帯域を拡大する構成を考えた。適材適所の機器選択をすることで本来望む効果が得られるよう、検討いただきたい。