企業が取り扱うデータ量が増大する中、大容量で処理スピードの速いオールフラッシュアレイの普及が進んでいます。日立製作所は、データ圧縮技術を搭載したオールフラッシュアレイ「Hitachi Virtual Storage Platform Fシリーズ」を開発。高性能を維持しつつ、データ圧縮によるオールフラッシュアレイのビットコスト低減を実現するという難問に、各技術分野の研究者たちが挑みました。
（2016年9月1日 公開）
松下はい。大量のセンサーデータを分析し、得られた情報を新たな価値としてお客さまに提供するIoTビジネスの増加などにより、今後も企業が取り扱うデータ量は爆発的に増えていくと予測されています。このような世の中の動きに追随していくためには、大容量で処理スピードの速いストレージが必要になります。そういった高性能なストレージを必要とされているお客さまが、SSDなどのフラッシュドライブを記憶デバイスとして搭載したオールフラッシュアレイにどんどん乗り換えています。
小関オールフラッシュアレイの場合、データの読み出し命令を出してからデータが返ってくるまでの時間が、従来のHDDを搭載したストレージと比べて圧倒的に短くなります。例えば、Webサイトでオンライン予約をするとき、予約ボタンをクリックしてからすぐに応答が欲しいですよね。このように、処理を早く終わらせたいというお客さまにとって、高性能なオールフラッシュアレイはとても良い選択肢になります。
小関日立が2012年に自製のフラッシュドライブモジュール（以下、フラッシュモジュール）であるHAF（Hitachi Accelerated Flash）を発表してから、他社からも数多くのフラッシュドライブが発表され、価格はかなり下がってきています。しかし、HDDと比べると高価なのは確かです。そこで、よりビットコスト…記憶容量当たりの価格を落としていくための一つのアプローチとして、データ圧縮技術が注目されています。
松下例えば、100 KBのデータをストレージに書き込もうとするとき、従来は100 KBの記憶容量が必要でした。データ圧縮により２分の1にできたとすると50 KBの記憶容量を購入すれば良いことになります。この場合、記憶容量当たりの価格は半分となり低価格化に貢献します。
これにより、「オールフラッシュアレイは高いもの」という認識が変わっていけば、より一層オールフラッシュアレイが普及していくでしょう。
松下そうですね。ただ、データ圧縮技術には大きな課題があります。それは「I/O性能…I/O処理速度が低下してしまう」ということです。
一般的に、圧縮処理や圧縮データを非圧縮状態に戻す伸張処理は、ストレージコントローラで動作するソフトウェアで行っています。一方で、I/O処理（データの読み書きを行う処理）も同じストレージコントローラで行っているため、圧縮・伸張処理の影響でI/O処理が遅くなってしまいます。
I/O処理を早く終わらせるためにオールフラッシュアレイを導入しているのに、圧縮・伸張処理によってそれが遅くなってしまったら本末転倒ですよね。そのため、I/O性能を維持したまま、データ圧縮をどのように実現するかが大きな課題でした。
小関そこでわたしたちが考えたのが、図1にあるように、圧縮・伸張処理を複数のフラッシュモジュールに分散させる方法です。
オールフラッシュアレイでは、ソフトウェアが動くストレージコントローラに、たくさんのフラッシュモジュールが接続されます。フラッシュモジュールが圧縮・伸張処理を分担することで、ストレージコントローラの負荷を減らし、I/O性能を維持できるのではと考えました。
図1 データ圧縮の違い
小関ポイントは二つあります。一つは、フラッシュモジュールでの高速な圧縮・伸張処理の実現です。
これについては、HAF DC2（Hitachi Accelerated Flash Data Compression 2）という専用のフラッシュモジュールを新たに開発しました。HAF DC2は、HAFの第2世代機にあたるものです。
このHAF DC2には、ハードウェアの圧縮エンジンが搭載されていて、データの圧縮・伸張を高速に実行できます。また、圧縮エンジンには日立独自のアルゴリズムを実装し、ハードウェアの処理性能を最大限に引き出せるようにしています。
松下もう一つのポイントは、フラッシュモジュールの容量管理方法です。データ圧縮により得られた空き容量をストレージコントローラからどうやって利用できるようにするか、という課題を解決する必要がありました。
例えば、フラッシュモジュールが100 KBの記憶容量を持っているとします。ストレージコントローラがフラッシュモジュールに対して100 KBのデータを書き込んだところ、フラッシュモジュールの圧縮エンジンによって2分の1に圧縮されて50 KBの圧縮済みデータが格納されたとします。この場合、ストレージコントローラは100 KBのデータを書き込んだので、そのフラッシュモジュールには空き容量がなくなったと認識してしまいます。つまり、データ圧縮によりフラッシュモジュールに空き容量が生まれたとしても、その空き容量をストレージコントローラが認識できないと、さらにデータを書き込むことができません。
この課題を解決するため、フラッシュモジュールは、物理的に書き込み可能な容量よりも大きな容量をあらかじめストレージコントローラに提供しています。その一方で、ストレージコントローラは、フラッシュモジュールにどのくらい空き容量があるかを監視しています。さらに、図2にあるように、各フラッシュモジュールの空き容量を統合し、利用可能な記憶容量としてストレージ管理者に提供することで、データ圧縮によって生まれた空き容量を有効に活用できるようにしました。
この仕組みは特許を取得しています*。これは、日立がストレージコントローラとフラッシュモジュールの両方を自製しているからこそ、実現できた方式だと思います。
図2 ストレージコントローラの空き容量管理の仕組み
小関そのとおりです。いままでは、フラッシュモジュールのようなデバイスを開発するチームと、ストレージコントローラを開発するチームは分かれていて、それぞれ単独の機能を設計していました。会話する機会もそれほど多くなかったですね。
しかし、今回は双方が連携して一つの機能を実現するので、どちらか片方の開発が遅れると評価ができません。また、もし不備があった場合にどう直していくか、どちらがどこまで動作を担保するか、という話も出てきます。そういったところで食い違いが生まれないように、きちんと会話して仕様を固めていきました。
松下研究所では、どのような仕組みにするのかなど、全体の骨組みを決めていきました。研究所で考えた仕組みは事業部に承認いただけたのですが、大変だったのは事業部で開発がスタートしたあとでした。先ほど、各フラッシュモジュールの空き容量を監視・統合して、利用可能な記憶容量を提供する、という話をしましたが、この考え方を設計に落とし込むのに苦労しました。
松下事業部のソフトウェア開発担当者にとって、HDDやSSD、フラッシュモジュールのようなデバイスは容量が固定で、変わらないものでした。しかし、今回の開発では圧縮率によってフラッシュモジュールの空き容量が変動するため、どれだけ書き込めるかわからないデバイスをコントロールしなければならない、ということになります。事業部にとってはいままでの前提ががらっと変わる話なので、「本当にコントロールできるのか」「本当にこの仕組みで問題は起こらないのか」という観点で、仕組みの妥当性を事業部と一緒に検証していきました。
例えば「ストレージコントローラがフラッシュモジュールの空き容量を監視する周期は何秒だけど、その周期の間にストレージコントローラが受け取る書き込み要求は最大でこれくらい。だから、フラッシュモジュールからデータがあふれてしまう可能性があるのではないか」というように。このような課題を、チームの知恵を結集して解決していきながら、ようやく完成させることができました。
松下リリースの1年半ぐらい前から事業部に常駐し、長くかかわったプロジェクトだったので、製品が出来上がったときは事業部のメンバーと一緒に喜びを分かち合いました。常駐していた研究所のメンバーでストレージコントローラの研究者はわたしだけだったこともあり、事業部の一員のように接していただきました。事業部メンバーと強いつながりを作れたことは、自分にとって大きな財産であり、今後も大切にしていきたいと思います。
小関仕組みを考案するだけでなく、事業部のメンバーと協力しながら、その仕組みの製品適用まで行うのがわたしたちのスタンスです。研究の成果が製品というかたちで世の中に出ていくのは、やりがいがありますね。家族にも「こういう製品を作っているんだよ」と説明しやすいです。基幹システムなど、一般の人は見えないところで使われている製品なので、実際に動いている様子を見せられないのが残念ですけれど（笑）。
松下オールフラッシュアレイが普及してきて、お客さまのストレージに対する考え方が変わってきているように思います。従来は「ITシステム全体の中でストレージは遅いもの」という考え方が一般的で、IT部門のストレージ管理者が性能を引き出すためにチューニングをすることが多かったと思います。日立のストレージも、性能をチューニングするためのさまざまな設定が可能になっています。
しかし最近では、ビジネス部門が直接IT製品を購入し、新しいビジネスを開始するためのプラットフォームとして利用するという潮流があります。ビジネス部門のお客さまはIT製品の専門家ではないので、設定作業やチューニング作業をできるだけ少なくしたい、というご意見をいただくこともあります。ストレージ専門の管理者の数も減ってきていますし、もっと容易にストレージを使えるようにするための研究が必要ではないかと考えています。冷蔵庫や洗濯機などの家電製品のように、買ってきてすぐに使い始められる。そのくらい簡単に使えることが、お客さまにとって価値になるのではないでしょうか。
小関数多くのストレージの中から、お客さまに日立のストレージを選んでいただくために、どのような付加価値を提供していくか。市場や業界の変化を早期にキャッチして、具体的なアイデアを提案していくことが、わたしたちの今後の課題だと思っています。
松下事業部で開発支援をしていたときに、プロジェクトマネジメントの重要性を強く感じました。ストレージのソフトウェア開発は非常に大規模なプロジェクトです。このような大規模プロジェクトをスムーズに進めていくというのは一朝一夕にできることではありません。研究でも開発でも、さまざまな方と協力して進めていくことが多いですから、マネジメントスキルを磨くことで、チームリーダーとしても活躍できるようになりたいですね。
小関わたしは入社以来、開発寄りの応用研究をしているのですけれど、最近は、基礎的な研究にも携わってみたいなと思っています。すぐに世に出るかわからないけど、新しい種をまくような。さまざまなかたちで社会に貢献できるところが、日立の研究者の魅力ではないでしょうか。
