Optane Memory H10を使い倒してわかった利用制限と性能

NANDメモリーよりも高速かつ低遅延な「3D XPoint」を採用したOptane Memoryと、3D QLC NAND SSDをひとつの基板に実装したIntelのハイブリッドNVMe SSD「Optane Memory H10 with Solid State Storage」（以下、H10）。

前回の記事では、HP製ノートPC「HP Spectre x360 13"」に組み込まれた状態で性能をチェックしたが、今回はH10を取り外し、自作PC環境でより詳細な検証を行なった。

H10はそもそもどのような環境で利用できるのか。また、Optane Memory部分(以下、Optane部とする）とQLC NAND SSD部分（以下、SSD部とする）は、すでに市販されている同社のOptane Memory単体版やQLC NAND SSD「SSD 660p」との違いがあるのかどうか、など気になる部分を中心にレポートする。

H10はまさに「ニコイチ」の製品

まずは、H10の外観から見ていこう。H10はSSD 660pやOptane Memory単体版の基板と共通する部分が多い。このことから、おそらくH10はSSD 660pとOptane Memory単体版をかなり素に近い状態でひとつの基板にまとめた「ニコイチ」製品、と見てほぼ間違いないだろう。

実際にH10のSSD部のコントローラーやDRAMの位置は、SSD 660pとほぼ一致している。また、搭載コントローラーはいずれもSilicon Motion（SMI）製で、DRAMはNANYAのDDR3Lの256MB品だ。H10のSSD部だけを見ると、コントローラーとDRAM、シングルパッケージの3D QLC NANDで構成された極小のSSDといった感じで、そのままM.2 2230のSSDとして販売できそうな構成と言える。

一方で、H10のOptane部も、Optane Memory単体版と酷似したレイアウトとなっている。こちらもチップの配置などがほぼ同じで、コントローラーと思われるカスタムASICも同じようなものが採用されている。異なるのは3D XPointがシングルダイのパッケージからマルチダイのパッケージへ変更されていることぐらいで、SSD部と同様、そのままM.2 2230の製品として販売できそうな感じだ。

H10はIntel 300シリーズ搭載マザーボードじゃないと起動ドライブとして運用できない

まずはH10が実際にどのような環境で利用できるのか検証してみた。H10の公式動作環境は、前回のファーストインプレッションでもお伝えしたように、CPUは第8世代CoreのCoffee Lake以降を利用するプラットフォームに限定されている。また、H10のOptane部をSSD部のキャッシュとして利用するには、Intel RST Driver 17.2以降のインストールも必要となる。

実際にこの条件を満たしているIntel Z390チップセットを採用したASUSのマザーボード「PRIME Z390-A」にH10をセットしてみると、普通にNVMe SSDとして認識され、特に何の設定を行なわなくてもSSD部とOptane部をそれぞれ独立したNVMe SSDとして利用できた。

また、UEFIでストレージの動作モードを「Intel RST Premium With Intel Optane System Acceleration（RAID）」に設定すれば、H10のOptane部をSSD部のキャッシュに利用できるようになるという本来の動作も問題なく行なえた。

ただし、一般的なNVMe SSDやOptane Memory単体版とは設定方法が異なる点もあった。それは、H10をセットしたM.2スロットのPCH Remapped PCIeコントローラーの設定（ASUS製マザーボードのUEFIの場合は「M.2_X PCIE Storage RAID Support」と表示）が、強制的に「Enable」（今回の場合は「RST Controlled」）に設定されるとともに、グレーアウトして設定が変更できなくなることである。

この挙動は、マザーボード側が接続した機器が厳密にチェックしているということの裏返しだ。つまり、対応マザーボードじゃないとH10はきちんと動かないようになっているということになる。

試しに、H10の対応動作環境に含まれていないIntel Z270チップセットを搭載したASUS「PRIME Z270-K」にH10をセットしてみると、デフォルト設定ではドライブが見えず、RAIDモードにして初めてドライブが認識できた。しかし、OSインストール作業時には再びドライブとして見つからなくなる。つまり、起動ドライブとして利用することはできなかったのだ。

とはいえ、データドライブとしてなら運用できるので、Intel 200シリーズチップセット搭載マザーボードでもH10そのものを利用できないことはない。Intel RSTソフトできちんとOptaneキャッシュも適用できた。単体版のOptane Memoryでは起動ドライブ以外にOptaneキャッシュを適用する場合、Intel RSTではなく、Intel SRT機能を使わなければできなかった（しかもその制限で32GBモデルのみの裏技だった）のでありがたい進化点だ。

H10のOptane部は自身のSSD部のみしかキャッシュにできない

また、H10のOptane部は対応環境において小容量のNVMe SSDとして利用できることは前述した通りだが、キャッシュとして利用する場合はH10のSSD部の専用キャッシュとしてしか利用できない。つまり、Optane Memory単体版ではできていた、SATA接続SSDやHDDへのキャッシュ利用が、できないように設計されているのである。

実は検証前に、H10のSSD部は起動ドライブでOptane部はデータドライブ用HDDのキャッシュに使えれば、M.2スロットが1基しかないマザーボードにとってかなり便利な製品になるだろうと思っていたのだが、そうは問屋が卸さなかった。こちらも将来的にIntel RSTのバージョンアップなどで使えるようになるといいのだが……、Intelがこの用途を想定していないわけはないので、おそらく現状は技術的に厄介な事情を抱えているのだと思われる。

H10の性能を単体パーツと比較

さて、ここからはH10のSSD部とOptane部の性能が、それぞれSSD 660pやOptane Memory単体版とどの程度異なるのかを検証していく。今回試すH10はSSD部が512GB、Optane部が32GBのため、SSD 660pは512GBモデル、Optane Memory単体版は32GBモデルを用意。H10はSSD部とOptane部それぞれの素性を調べるために、Optaneキャッシュを切った状態、つまり別個のドライブとして認識している状態で検証する。

テストは定番の「CrystalDiskMark」のほか、「TxBENCH」を使用した。検証環境は以下となる。

まずはCrystalDiskMarkの結果から見ていこう。H10のSSD部とSSD 660pを比較した場合、大きな違いが見られたのはシーケンシャルリードの速度のみである。H10のSSD部が1626MB/sだったところ、SSD 660pは1847MB/sと221MB/sほど速かった。それ以外の項目についてはほぼ同等で、誤差レベルと言っていい性能差だった。

この差は内部インターフェースの最大転送速度が大きく関係している。H10のSSD部は最大転送速度が2000MB/sのPCI Express 3.0×2接続であるのに対し、SSD 660pは最大速度が4000MB/sのPCI Express 3.0×4接続となる。そして、PCI Express 3.0×2接続の場合、概ね1600MB/sから1700MB/sぐらいが実効転送速度の限界になる。そのため、H10のSSD部はSSD 660pと比べてシーケンシャルリードで差がついたのだ。

逆に言えば、シーケンシャルリード以外の性能差はほぼないので、この接続インターフェースの制限さえなければ、H10のSSD部とSSD 660pの基本的な性能はほぼ同じになるはず。SSD部の純粋なポテンシャルはSSD 660pと同等と考えて良いだろう。

次は、H10のOptane部とOptane Memory単体版の違いを見てみよう。こちらはファームウェアの味付けの違いが顕著だった。H10のOptane部は4KB（QD32）ランダムリードの速度はOptane Memory単体版よりも約90MB/sほど遅いものの、逆にライトの速度はシーケンシャルもランダムも全般的に60MB/s以上速かった。

この違いはH10のOptane部がそもそもH10のSSD部のキャッシュ専用に用意されている点に要因がある。つまり、用途を考慮して、Optane Memory単体版よりもライト速度の高速化に振った調整を施していると考えるのが自然だろう。

SLCキャッシュ枯渇後の書き込み挙動が異なる

続いて、TxBENCHで容量全域にシーケンシャルライト（128KB、QD32）を実行したときの速度推移を見ていこう。しかし、このテストは結果を見る前に前置きが必要だろう。ポイントは「SLCキャッシュ」と呼ばれる、QLC NANDの一部のメモリーセルアレイを疑似的にSLCとして運用して、高速化する技術だ。

SLCはひとつのメモリーセルに1bitで記録する方式のため、4bitで記憶するQLCと比べて記録に必要なメモリーセルが4倍必要になる。仮に512GBのQLC NAND SSDの全領域をSLCキャッシュとして運用できる設定になっていれば、SLCキャッシュは最大で128GBとなる。この128GBに収まる範囲内でのデータ転送なら、QLC NANDでもSLC NANDのように高速運用できるわけだが、問題は収まらなかった場合だ。

SLCキャッシュにデータが収まらないと（つまり、SLCキャッシュが枯渇すると）、極端に速度が遅くなるのだ。この原因は後述するが、SLCキャッシュを最大容量ギリギリまで設けているSSDほどペナルティーが大きくなり、下手をするとHDDよりも遅くなるケースすらある。そのため、SLCキャッシュの設定容量はメーカーや製品ごとに変わってくる。そのさじ加減を全域シーケンシャルライトテストで見ようというわけだ。

さて、前置きが長くなったがグラフからわかる通り、H10のSSD部とSSD 660pはほぼ同じ地点で途中から一気に書き込み速度が低下している。これはSLCキャッシュが枯渇したことを意味し、ここからはQLC NANDの空き領域で作業しているので遅くなっているのだ。遅くなった地点は約74GBぶん書いたところ。つまり、いずれのSSDもSLCキャッシュは74GBとなり、QLC NAND計算だと4倍の296GBとなる。おそらく全容量（512GB）の内、約60％（約300GB）程度がSLCキャッシュに設定されていると推測できる。

そして、ここまでの挙動は両者共通だが、SLCキャッシュが枯渇した後の書き込み速度とその推移の仕方は異なっている点が非常に興味深い。

SLCキャッシュ枯渇後の平均書き込み速度はH10のSSD部が47.05MB/sで、SSD 660pは平均61.23MB/sと若干ながら速かった。これは、SSD 660pがずっと60MB/s前後の速度で安定しているのに対し、H10のSSD部は定期的に20MB/s前後まで速度が低下し、しばらくすると60MB/s前後に戻るという挙動を繰り返していたからだ。

なぜ、H10のSSD部がこのような挙動になるのかは不明だが、少なくとも今回テストを行なったモジュールでは、現状SSD 660pとは異なる調整が行なわれていることは間違いない。なお、このような挙動はコントローラーの抱える問題でなければ、通常ファームウェアで修正できるため、将来的に挙動が変わる可能性がある。

実際にSSD 660pもリリース当初のファームウェアでは、現在のH10のSSD部並みか、それ以下の速度しか出ていなかったと筆者は記憶している。ゆえに、H10のSSD部も将来的にファームウェア更新によって、挙動が変更されたとしても不思議ではない。

アプリケーションのロード速度で見るH10の性能

最後は、実際のアプリケーションのロード時間比較でその実力を見てみよう。検証に使用したのは、画像編集ソフト「GIMP」と「ファイナルファンタジーXIV 紅蓮のリベレーター」の公式ベンチマーク。なお、比較用にSSD 660pのほか、Intelの高速NVMe SSDである「SSD 760p」を用意した。Optaneキャッシュは有効にした状態と無効にした状態、両方の結果を掲載する。

まずは画像編集ソフト「GIMP」を使用したベンチマークの結果から見ていこう。140枚の写真（合計500MB）を順次ロードし、読み込んだ写真に修正を加えた後、別フォルダーに保存するのにかかった時間を計測している。また、このベンチマークはバックグラウンドで何も行なっていない状態で実行したときと、バックグラウンドで容量18GBのファイルを2回コピーしながら、実行したときの2種類の条件で実施した。

バックグラウンドで何も行なっていないときはすべて横並びになった。写真の枚数はそれなりに多いが、処理が比較的軽いことに加え、シングルスレッドの動作になるため、大きな差が出なかったようだ。

一方で、バックグラウンドでファイルコピーしながらテストした場合は、負荷が増えたことによってマルチスレッド処理になり、各個の性能差が表われた。トップは自力の性能が最も高いSSD 760p、Optaneキャッシュを有効にしたH10は約22秒遅れの2番手。次いでSSD 660p、ビリはOptaneキャッシュ無効のH10となった。

H10はOptaneキャッシュを有効にしたことにより、約14秒ほど高速化している。これは2回目のバックグラウンドコピーでOptaneキャッシュが利き、そこで浮いたリソースのぶん、無効時よりも高速になったのだろう。つまり、写真編集や動画編集をしながら、頻繁に比較的大きな同じデータを整理するといった作業をすると、H10のポテンシャルは活かされるということだ。

続いて、ファイナルファンタジーXIV 紅蓮のリベレーター公式ベンチマーク（以下、FF14ベンチマーク）の結果を見てみよう。このベンチマークは6つのシーンのローディングタイムを計測し、合計してくれる。

また、現在のOptaneキャッシュは、特定のフォルダーやファイルを優先的にOptane Memoryに配置するピン留めという機能が搭載されている。この機能の効果を調べるために、このベンチマークを実行しているフォルダーを登録した（ピン留めした）状態でも検証している。

Optaneキャッシュを有効にした場合、キャッシュされるデータ量が増える2回目以降にローディングタイムが短くなる。ゆえに、1回目は素の性能が高いSSD 760pに負けているが、2回目以降はH10が勝つという番狂わせが起きている。

また、H10はピン留め時に最速タイムを記録しているが、フォルダー登録を行なっていない場合と比べると誤差の範囲といった具合だ。もともとOptaneキャッシュの内容が書き換わるのを明示的に防ぐ機能なので、ピン留めしたからといって劇的に高速化するというわけではない。あくまでOptaneキャッシュがほかのデータのキャッシュで埋まってしまわないよう、優先的にキャッシュしてほしいデータを指定する方法だと理解していただきたい。

まとめ：QLC NANDの弱点を補うSLCキャッシュをうまく補完するOptane Memory

H10に搭載している3D QLC NANDはチップあたりのGB単価に優れ、SSDの低価格化に一役も二役も買っている。しかし、3D TLC NANDと比べて書き込み速度がかなり遅いという課題がある。この課題を緩和するために、SLCキャッシュを3D TLC NAND採用製品よりも多めに設け、見かけ上の書き込み速度を上げている。また、SLCキャッシュ内のデータをある程度バッファーとしてそのままキープしておくことで、QLC領域への無駄な書き込みを減らし、不必要に寿命を削らないようにもしている。

とはいえ、SLCキャッシュの増量は良いことばかりではない。前述にも挙げたが、例えばSLCキャッシュをSSDの総記録容量ギリギリまで設けると、そのSLCキャッシュが枯渇した瞬間、ただでさえ遅い書き込みがさらに遅くなってしまうという問題に直面することになる。これは、NANDメモリーを記憶媒体に用いるSSDの宿命でもある。NANDメモリーには様々な制約があり、これが手かせ足かせとなって空き容量が減れば減るだけボディーブローのように効いてくるからだ。

少々難しい話になるが、なぜ書き込み速度が異様に遅くなるのか、その原理を説明する前にまず前提条件として、現在のSSDの仕組みをおさらしよう。

例えば、512GBのSSDには総容量「549,755,813,888バイト」のNANDメモリーチップが搭載されている。しかし、ユーザーが使用できる実容量、つまりOSから見える容量は、「512,110,190,592バイト」しかない。パッケージなどに書かれているストレージ容量の表記は、10の倍数表記が一般的となっているため、10の倍数表記でみると「512,110,190,592バイト」は約512GBであり、釈然としない方も多いとは思うが、容量表記的には何も間違ってはいない。

では、差し引かれた「37,645,623,296バイト」もの容量は一体どこに行ってしまったのだろうか。実は、この部分が予備領域や管理領域と呼ばれている部分である。この領域は常に固定された領域ではなく、寿命の延命などに活用されている。NANDメモリーのように書き換え回数に寿命がある記憶媒体では、全領域を均等に書き換えることで寿命を最大化している。

約512GBの領域でデータを均等に書き込むより、約549GBの領域をフル活用して均等にデータを書き込んだほうが、より多くのデータが書き込めることは誰の目からみても明らかだろう。つまり、NANDメモリーを採用したSSDとは、512GB製品の場合、10の倍数表記で約549GBの領域をうまく使って、約512GBの容量をユーザーに提供すれば良いというのが基本的な考え方なのである。

SLCキャッシュはこれを逆手にとって、高速化のキャッシュに利用する方法だ。すなわち、SLCキャッシュを多く設ければ設けるだけ、物理的な容量は実際には少なくなっているが、最終的に辻褄があうように見せればストレージ的にはOKというわけだ。そういう意味では、仮想ドライブのようなものである。

ここからが本題である。なぜSLCキャッシュを多く設けた場合、大きなペナルティーが発生するのか。その最大の原因は、NANDメモリーは上書きが行なえないため、書き込み作業の前に必ず、消去作業をしなければならないことにある。NANDメモリーの消去は、ミリ秒単位の大きな時間がかかる。しかも、SLC、MLC、TLC、QLCの順で消去に必要な時間が長くなる。QLCの場合、書き換え回数を増やすために消去を行なう場合も時間をかけて調整しなければならない。雑に消去すると、書き換え回数の減少につながってしまうからだ。

QLC NANDで512GBのSSDの全容量をSLCキャッシュに割り当てると、実用容量は4分の1の128GBになってしまう。だが実際には、まだ約37GB分の予備領域が残っているというのは前述した通りだ。SLCキャッシュが枯渇しても書き込みが続く場合は、この約37GBの領域をうまく活用して、物理的な容量を増やしながら書き込みを継続していくことになる。つまり、SLCキャッシュの容量を減らしながら、QLCで使う領域を増やしていく必要があるというわけだ。

具体的には、SLCキャッシュ内のデータを残っている約37GBの領域に移動させ、QLC領域の移動先の物理アドレスを変換テーブルに登録する。次にSLCキャッシュ内の移動済みデータが記録されていた領域が消去できるようであれば消去し、QLCとして再利用する。これを繰り返す。なお、「消去できるようであれば」としたのは、NANDメモリーの読み書きはページと呼ばれる単位で行なうが、消去はページを複数束ねたブロックと呼ばれる単位で行なう必要があるという制限があるからだ。

ページあたりの容量やブロックが何ページで構成されているかはNANDメモリーによっても異なるが、Samsungや東芝メモリの64層3D TLC NANDメモリーの場合、ページあたりの容量が16KB、ブロックは768ページとなっているようだ。つまり、読み書きは16KBごとに行なえるが、消去は12MBごとでしか行なえない計算になる。NANDメモリーではデータを別の場所に移動させても、消去単位のブロック内に必要なデータが残っている場合は、消去を行なえない。したがって、データを動かしたからといって、必ずしも消去を行なえるわけではないのだ。

そのため、NANDメモリーを採用したSSDの場合、消去を伴わない書き込みは速いが、消去しながらの書き込みは消去に多くの時間がかかるため遅くなるのだ。それゆえ、SLCキャッシュが枯渇すると、QLC NAND SSDは素の書き込み速度が遅いだけでなく、消去にも多くの時間がかかるため、その相乗効果で大きなペナルティーを払うことになるわけだ。

実のところ、QLC NAND SSDを世に出すにあたっての課題は、SLCキャッシュをどの程度設けるかの「さじ加減」になっている。SLCキャッシュを多めに設けすぎると、それが枯渇したときのペナルティーが大きくなる。一方で、少なすぎると書き込み性能がガクッと落ち、使い勝手が悪くなるからだ。

H10では、この課題をOptane MemoryをSLCキャッシュの補助として活用するという方法で緩和している。Optane Memoryに最初にデータを書き込むことで、QLC SSD内部の管理に時間的な余裕が生まれ、より効率的な管理を行なうための時間が稼げる。もちろん、SLCキャッシュの容量を超えてしまうような連続書き込みが発生してしまうと意味はないが、一般的なユーザーの使用では、今回使用したH10のSSD部に設けられた約74GBというSLCキャッシュを超えるような連続書き込みが発生するケースは、巨大な動画の保存にでも使用しない限りほぼないだろう。

本来、3D XPointのような高速な不揮発メモリーは、DRAMの代わりに使うというのが理想だ。3D XPointは低レイテンシーなのでそれだけのポテンシャルはある。しかし、3D XPointをDRAMの代わりに利用しようとすると、現状では相当にコスト高になってしまうという課題がある。Optane Memoryとして利用するのが現実的なラインだろう。

とはいえ、ベンチマークの結果が示している通り、そのOptane Memory利用でもSLCキャッシュが同容量のSSD 660pよりも一定の性能をうまく引き出し、3D QLC NANDの弱点をうまく補完していると言えるだろう。利用環境の制限はあるものの、起動ドライブだけではなくデータドライブとしてもキャッシュを有効にして使える点も、Optane Memory単体版にはなかった特徴だ。まだ、市場にはH10搭載PCは登場していないが、各社どのようなPCに採用してくるのか楽しみにしたい。