バッチ処理が終わらない――課題解決のカギを握る「DB高速化」という手段：システム高速化の現実解を探る

企業を取り巻くデータ量が爆発的に増大する中、処理時間を短縮するために必要なのがデータベースシステムの高速化だ。中でも、処理速度のボトルネックになりがちなI/Oの見直しは急務と言える。本稿では、企業が今すぐ取り組めるDB高速化の方法を紹介しよう。

[PR／ITmedia]

PR

　企業システムで扱うデータ量が増え続ける今、IT部門には大きな課題が突き付けられている。サーバの高性能化は著しく、仮想化技術を利用して難なく複数の業務システムで共用できるまでになった。一方、処理するデータを格納するデータベース（DB）システムは、サーバの処理能力に追いついていないのが現状だ。そのため、データ量が増えれば増えるほど処理時間がかかり、「夜間バッチ」が朝までに終わらないなどの事態も発生している。

　また、こうした状況では、経営層や業務部門からリアルタイムのデータ分析が求められても、実現するのは難しい。そこで急がれるのが、データ分析処理のボトルネックになっているDBシステムの高速化だ。

ボトルネックの最多原因はI/Oとストレージの性能不足

　DBがボトルネックになる原因はいくつかあるが、大別するとソフトウェアが原因の場合と、ハードウェアが原因の場合に分けられる。

　このうちソフトウェア側の原因としては、アプリケーションやDBの構造、SQL文、パラメータなどに問題があるケースが挙げられる。これを解決するには、アプリケーションやDBを見直す必要がある。具体的には、DBの構造やSQL文から性能のボトルネックになっている部分を見つけ出し、部分的に改修するか、場合によっては全面的にアプリケーションやDBを作り直すことになる。

　だが現実的には、エンジニアが不足していて社内のIT部門だけで対応することが難しかったり、膨大な工数・コストがかかったりするなど、そのハードルは極めて高い。したがって、業務システムそのものを完全にリプレイスする時期などでないと取り組みづらいことが多いだろう。なお、場合によってはパラメータをチューニングするだけで高速化できることもあるが、目を見張るような効果が得られることはごくまれだ。

　一方、ハードウェア側の問題としては、主にハードウェア処理能力が不足しているケースが挙げられる。

　原因がCPU性能やメモリ容量の不足なら、最新CPUと大容量メモリを備えたサーバに入れ替えれば、業務システムやDBシステムに手を付けなくてもDB性能は改善される。だが実際には、DBシステムは、ピーク時の性能を想定してCPU性能やメモリ容量に余裕を持って設計されている場合が多いため、それらがボトルネックになっているケースはそう多くない。

　ハードウェア側の問題で最も多いのは、I/O帯域やストレージ性能の不足だ。DBシステムではストレージ容量は気にしても、ストレージI/O性能の設計は忘れがちである。多少気にしていたとしても、どのように設計すればいいかはっきりとした指針もないため、ログはRAID1の領域に“とりあえず”配置しておく程度の対応しかされていないのが現状である。

　大量のデータを扱うDBシステムでは、HDDへの読み書きが頻繁に発生する。I/O帯域やストレージ性能が不足すると、この部分に遅延が発生するため、いくらCPUやメモリ容量があっても十分に活用できず、結果的にDBの性能が出ないのだ。

　しかし、なぜボトルネックの原因がI/O帯域やストレージにある場合が多いのか。それは前述した考慮不足もあるが、CPUやメモリなどと比べ、I/Oやストレージの性能進化のペースが遅いからだ。

ハードウェアの性能進化の不均衡（出典：日立製作所）

　例えばCPUの場合、約10年前のサーバではシングルコアのプロセッサしか存在しなかったが、現在では6コア〜10コアなどが当たり前であり、その相対性能は約28倍にも及んでいる。それに対しI/Oでは、ファイバチャネル（FC）の帯域は1〜2Gbpsから4〜8Gbpsへと約4倍高速化したにすぎず、HDDの回転数に至っては最大1万5000と、全く向上していない。この相対性能の差から、DB性能のボトルネックが発生している可能性が高いのである。

　この問題を改善する方法は、基本的にはハードウェアの入れ替えだ。つまり、I/Oインタフェースやストレージをより高速なものに変更するのだ。例えば、ストレージ装置を増設したり、HDDをSSDに換装したりすれば、I/Oとストレージが原因のボトルネックを解消できる可能性がある。

　既存の業務システムやDBシステムにできるだけ手を加えずに、DB性能のボトルネックを解消するためには、これが最も簡単な方法と言えるだろう。

DBの高速化を実現する方法（出典：日立製作所）

インメモリから分散まで、多様なソリューションが登場

　一方、DBの高速化に根本から取り組むなら、業務システムの更改時にDBシステムも合わせて刷新するのが一番だ。最近ではDB高速化の要求に応えるさまざまなソリューションが登場しているので、その一部を紹介しよう。

　既存のDBシステムに近い構成が可能なのが、DB専用アプライアンス製品の導入だ。DBアプライアンスは、サーバとストレージを一体化させたものであり、構成の自由度が制限される代わりに、サーバとI/O、ストレージとの性能のアンバランスが是正されている。DBとストレージの管理を一元化したり、運用を自動化する機能が搭載されていることも利点だろう。

　一方、DBシステム自体を性能重視の製品に移行するなら、インメモリDBという選択肢がある。インメモリDBとはデータストレージをメモリ上に置くもので、HDDをストレージとして利用する一般的なDBと比較して、非常に高速かつ安定した性能を発揮する。

　ただし、揮発するメモリ内にデータストレージを格納するため、可用性の面で課題が残る。また、HDDと比較するとシステムに搭載可能なメモリ容量ははるかに少なく全てのデータを入れられなかったり、入ったとしても大容量メモリを搭載することでコストが非常に高くつくという欠点もある。

　データ検索の高速化を実現する別のアプローチとしては、分散DBが注目されている。その代表格と言えるのが、ビッグデータのリアルタイム処理などに活用されるようになった「Hadoop」だ。Hadoopは、独自のファイルシステム上で動作する「HBase」という分散DBの仕組みを利用し、データを分割配置してバッチ処理を並列実行することで、超巨大テーブルを高速に処理できる。

　このほか、従来のDBの延長ではなく全く新しいDBを開発する取り組みも始まっている。例えば、日立製作所が製品化したデータアクセス基盤「Hitachi Advanced Data Binderプラットフォーム」（※1）は、「非順序型実行原理」（※2）という仕組みを取り入れたエンジンに、サーバとSSD搭載ストレージを組み合わせることで、標準のSQLに対応しながら、従来のDBと比べて劇的な高速化を実現するという。

※1 内閣府の最先端研究開発支援プログラム「超巨大データベース時代に向けた最高速データベースエンジンの開発と当該エンジンを核とする戦略的社会サービスの実証・評価」（中心研究者は東京大学の喜連川優教授）の成果を利用して開発

※2 東京大学の喜連川優教授および合田和生 特任准教授が考案した原理

直近の課題を解決する現実解は？

　ここまで、DBを高速化するためのさまざまな方法を紹介したが、「今動いている業務システムのDBを高速化したい」「バッチ処理を朝までに終わりにしたい」といった直近の課題を、できる限り容易に解決したいというのであれば、やはりI/Oとストレージの見直しが最も有効な策だろう。

　実は、このI/Oとストレージの見直しという分野は徐々に熱い市場になりつつある。次回はその代表的な製品の1つとして、日立の「DB高速化ソリューション for Oracle RAC on SSD」を紹介しよう。