はじめに

　これまで3回の記事で、NANDフラッシュメモリを不揮発メディアとするSolid State Drive（以降単にSSDと記載）の重要な設計パラメータのひとつであるIndirection Unit (IU)の説明をしてきました。

　今回は最終回として、現在のSSDにおいてIUが果たしている機能と、そのIUにかかわる技術について説明します。

まとめ

SSDにおけるIUはSSDの寿命を左右する重要な役割を果たしている
エンタープライズやデータセンターでのSSDの利用が広まるにつれて、それらの用途に適した形でIUをホストが管理する技術が開発され利用されている

ウェアレベリングとIUの密接な関係

　前回までの記事でIUはバッドブロック対応のために導入されたと説明しました。その後SSDが進化するにつれてIUの果たす役割はより重要になりました。それはIUの設計がSSDの寿命を左右するからです。

　SSDではNANDフラッシュメモリの制約からメモリ上のデータを直接上書きできません。このためGarbage Collection (GC)を行いますが、このGCの効率をIUの設計が左右します。一連の記事で使用しているページマッピングの例を使用すると、GCの処理ではデータをコピーした後に図1のように対応表を更新します。

図1：ページマッピングにおけるGC時の対応表更新処理イメージ

　対応表のあるエントリに記載の物理アドレスに記録されたデータを新しい物理アドレスにコピーした場合、それを対応表に記録した時点でデータ移動完了です。この更新により、同じ論理アドレスへのアクセスが正しくデータ移動先に行われ、古い記録先が回収されます。

　ページマッピングは、論理アドレスと物理アドレスの対応関係に物理ブロックに加えて物理ページ単位での自由度を持ちます。この自由度はGCにも活かされ、詳細は割愛しますが自由度がブロック単位のみのブロックマッピングと比べて格段にGCの効率が改善します。GCの効率改善はNANDフラッシュメモリへの余分な書き込みが減り寿命消費抑制に繋がります。

　前回説明したようにメーカーや製品によりIUの設計は多種多様です。しかしどの製品でも与えられた制約内で寿命というSSDの最重要指標を最大化できるように設計されています。

IUをホストが管理するSSDの使いかたもある

　これまでIUがSSDの内部設計パラメータである前提で説明しましたが、そうではないSSDもあります。さらに言えば、現在のSSDが登場する前から使われてきたNANDフラッシュメモリをメディアとするストレージではIUはストレージの設計パラメータではありませんでした。

　半分歴史の説明になりますが、この記事の後半ではそれらについて簡単にまとめます。

　なお、ACM Transactions on Storageというジャーナルに、学術論文を中心にSSDにおけるストレージ抽象化の歴史をまとめた論文が掲載されています^[1]（オープンアクセスなので全文閲覧可能です）。まだ論文全体は読み終えていませんが、この論文はSSDに限定しているもののこの記事で取りあげる技術の多くを含みより深くかつ広範な調査論文のようです。ご参考まで。

現在の典型的なSSD

　現在の典型的なSSDの簡易機能ブロック図は図2のようになります。

図2：典型的な現在のSSDの簡易機能ブロック図

　これらのSSDを使う場合、ホストはSSDとの間で標準されたコマンドインターフェースでデータを読み書きします。

　SSDはドライブ内部でウェアレベリングやバッドブロック管理を行い、またNANDフラッシュメモリに適したエラー訂正(ECC)機能を備えます。

　このことから、SSDはNANDフラッシュメモリの不良やエラーさらには長寿命実現のための処理などすべてをホストに対して隠蔽していると言えます。

　IUはバッドブロック管理とウェアレベリングに必要な設計ですので、図2のようなホストとSSDの役割分担であればIUはSSDの内部設計パラメータとなります。基本的にホストはIUのことを知る必要がありません。

ホストが生のNANDフラッシュメモリを扱う使いかた

　これに対し、以前からホストが「生」でNANDフラッシュメモリを扱う使いかたがあります。よく"Raw NAND"と呼ばれるものです。組み込み系機器では今でも行われている使いかたです。

　ホストがRaw NANDを扱う場合、ホストとドライブの境界は図3のようになります。

図3：Raw NAND使用時のホストとドライブの役割分担

　Raw NANDを使う場合はバッドブロック管理と誤り訂正はホスト側の責務となります。バッドブロックを避ける処理や誤り訂正符号のパリティを計算してそのパリティもNANDに書き込む処理、さらにウェアレベリングもホストが実装しなければなりません。このため適切なIUの設計はホストの責務となります。

　以前はNANDフラッシュメモリの容量が小さく、また必要な誤り訂正能力も相対的に低く済みホストのプロセッサで実行できたことも、このように使われてきた理由です。

　一番身近な例はLinuxのMemory Technology Device (MTD)だと思います。MTDについては以下のドキュメントが参考になります。

誤り訂正だけNANDフラッシュメモリに任せる使いかた

　NANDフラッシュメモリのインターフェースバンド幅が高くなるにつれて、それに見合う性能の誤り訂正処理をホスト側で実行することが辛くなりました。この流れで登場したのが、誤り訂正処理のみドライブ（NANDフラッシュメモリ）側で実行する形態です。具体的な製品例はキオクシアのBENAND^[2]です。

　この形態の製品におけるホストとドライブの境界は図4のようになります。

図4：ビルトインECC型ストレージ使用時のホストとドライブの役割分担

ドライブ内のデータ記録場所をホストが決める使いかた

　NANDフラッシュメモリを用いたドライブがフロッピーディスクドライブ(FDD)やハードディスクドライブ(HDD)の代替を目指すにあたり、ホストからFDDやHDDと同様にアクセスできるようドライブ自身がそれらと同じインターフェースの皮を被りました。この結果図2のような役割分担になり、現在ではこれが一般的になりました。

　図2の役割分担では、ホストから書き込まれたデータをどのNANDフラッシュメモリのどこに書き込むかを決めるのはドライブです。さらにGCなどドライブ内でのデータ移動をいつどのデータに対して行うかを決めるのもドライブです。つまり、ドライブ内でのデータ配置やデータ移動処理はホストに対して「隠蔽」されています。

　この「隠蔽」がなければNANDフラッシュメモリの利用効率が上がると主張し「どこにデータを配置するか、どのデータをどこに移動させるか、をホスト側で決める」ために提唱された仕組みのひとつがOpen-Channel SSDです。その成果はLightNVMとしてLinuxカーネルにマージされ、NVM Express (NVMe)でのZoned Namespace (ZNS)につながりました^[3]。

　この形態では、バッドブロック管理までをドライブ側が、ウェアレベリングを含むデータの書き込み先決定をホスト側が担当します（図5）。

図5：ホストマネージドSSDのホストとドライブの役割分担

　図5の形態ではウェアレベリングをホスト側で制御するためIUはホスト側の設計パラメータです。

　エンタープライズやデータセンター環境でのSSDの利用が広まり始めると、Open-Channel SSDが目指した「利用効率の向上」がさらに求められるようになりました。ただ、NANDフラッシュメモリは世代を経るごとにその複雑さや扱いにくさが増したため、Open-Channel SSDのようにすべてをホスト側で制御することは辛くなりました。

　このような背景で様々な技術が生まれました。NVMeで標準化された技術だけでも上に挙げたZNSに加えてNVMSetとEndurance Group、そして最も新しいものにFlexible Data Placement (FDP)^[4]があります。ほかにはLinux Foundation傘下のプロジェクトであるSoftware-Enabled Flash (SEF)もあります。

　これらの仕組みは程度の差はあれど「どこにデータを配置するか、どのデータをどこに移動させるか、をホスト側で決める」ことによるNANDフラッシュメモリの利用効率向上を目指したものです。

　多少古いですが、Qiitaにも以下のような記事があります。どれくらい前からこれらの技術の必要性が提唱されて技術開発が行われてきたのかがわかります。

KubernetesのRaw Block Volumeサポートについて考える。
次世代ストレージZNS SSD

おわりに

　今回の記事では、現在のSSDにおいてIUが果たしている機能と、そのIUに関連してSSDの利用拡大に合わせて開発された技術について説明しました。

　SSDはその性能や寿命などが使われかたに大きく変化するデバイスであることは以前から説明してきました。今回紹介した様々な技術も特定の「SSDの使いかた」を熟知した技術者により開発されたものです。

　今後も特徴的な「使いかた」とそれに対応したSSD技術を紹介できればと思います。

References

[1] Xiangqun Zhang, el al., "Storage Abstractions for SSDs: The Past, Present, and Future," in ACM Transactions on Storage, vol. 21, no. 1, pp. 1 -- 44, January 2025
[2] キオクシア、「OEM・産業機器向けBENAND™」、2025年2月18日閲覧
[3] LightNVM、2025年2月18日閲覧
[4] Amber Huffman and Chris Sabol, "Overcoming the Write Amplification Problem with NVM Express® Flexible Data Placement"、2025年2月18日閲覧

ライセンス表記

この記事はクリエイティブ・コモンズ表示 - 継承 4.0 国際ライセンスの下に提供されています。