SSDのIndirection Unit (IU) (1/4)：導入経緯と基本設計

# はじめに
　NANDフラッシュメモリを不揮発メディアとするSolid State Drive（以降単にSSDと記載）の設計における重要なパラメータのひとつにIndirection Unit (IU)と呼ばれるものがあります。

　このIUは、ユーザがSSDについて重視する指標である寿命そして性能と関係がとても深いものです。

　ただその反面、「IUが大きいSSDに小さいアクセスをすると効率が悪く寿命消費も速くなる」「IUにあわせたアクセスをすると性能が良い」などの結論だけが広く知られているかと思います。もちろんこの結論はほとんどの場合正しく、SSDの選定やSSDに効率良くアクセスするプログラムを作成する際にはこのポイントを抑えておくことが重要です。この詳細はMicronの技術ブログ記事<sup>[1]</sup>にもまとめられています。

　そこで今回からの記事では、IUがどんなものでありどのようにして寿命や性能に与えるのかというメカニズムと、IUに関連する技術をまとめます。初回の今回はSSDにおいてIUが必要である理由などの基本的な説明です。

# まとめ
* SSDに間接参照やIUが導入された最も大きな理由はNANDフラッシュメモリの不良ブロックを避けるため
* 基本的な間接参照の仕組みだけでは性能低下や寿命消費加速が大きく、後に改良された

# なぜ間接参照する必要があるのか
　まず、SSDでIUを使用した間接参照をする理由から説明を始めます。

　説明のために、メモリ管理ユニット(Memory Management Unit: MMU)を備えるプロセッサとそれを利用したOSが提供する仮想アドレス空間の仕組みを比較対象とします。

　図1に両者をならべて示します。図1を見ると、あるアドレスを別のアドレスに変換しているという意味で同様の機能を提供しているように見えます。確かに機能の視点では同じです。

![仮想アドレス空間とSSDそれぞれにおけるアドレス変換](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/439683/419d5309-07e2-1af6-d26d-f2497abe09ad.png "仮想アドレス空間とSSDそれぞれにおけるアドレス変換")
_図1：仮想アドレス空間とSSDそれぞれにおけるアドレス変換_

　しかし、両者はその導入経緯つまり導入に至る理由が異なります。

　仮想アドレス空間の導入理由のひとつは、限られた物理メモリを効率良く利用することです。これは、仮想アドレス空間のほうがシステムに実装される物理メモリ容量と比べてはるかに広いことなどが要因です。マルチプロセスやメモリ保護の実現に欠かせないことも大きな理由ですが、それらについては触れません。

　一方、SSDにおいてアドレス変換による間接参照を導入した最も大きな理由は、NANDフラッシュメモリが不良ブロックを抱えていることです。

　これを表したのが図2です。

![仮想アドレス空間導入理由とSSDにおける間接参照導入理由の比較](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/439683/da985330-65f4-95c6-994f-c7cc3dc299dc.png "仮想アドレス空間導入理由とSSDにおける間接参照導入理由の比較")
_図2：仮想アドレス空間導入理由とSSDにおける間接参照導入理由の比較_

　仮想アドレスの導入目的はわかりやすいです。仮想アドレス空間のほうが物理メモリ空間よりも広いわけですから、仮想アドレスを使用する側（プロセスなど）の変更なしにシステムの動作を実現するには仮想アドレス空間に適切に物理メモリに写像するアドレス変換が必要です。

　これに対してSSDの場合、ホストが指定する論理ブロックアドレス(Logical Block Address: LBA)空間よりも、SSDが備えるNANDフラッシュメモリの容量のほうが広いです。なぜなら、SSDはLBA空間全域にデータを書き込むことができなければならないからです。100セクタのLBA空間を持つSSDはどんな状況でもホストに100セクタ分の容量を提供できなければなりません。

　それであればSSDが備えるNANDフラッシュメモリにリニアアドレスを割り当てて、LBAと直接対応させれば良いように見えます。それにもかかわらず間接参照が必要となる理由は、SSDが搭載するNANDフラッシュメモリに不良ブロック(Bad Block)が存在することです。

　図2のように、SSDは搭載するNANDフラッシュメモリに存在する不良ブロックを避けてLBAとNANDフラッシュメモリ上の記憶領域を対応させなければなりません。このため、SSDはホストが指定したLBAから間接参照により実際の物理アドレスを解決し、得られた物理アドレスにアクセスする方法を採用しています。

　NANDフラッシュメモリにおける不良ブロックの存在は現時点では避けられません。つまり、SSDにおいて間接参照が必要とされる最も大きな理由は、性能や寿命ではなく「不良ブロックを避けること」です。

# 間接参照とIUの導入
　以上のように、SSDではNANDフラッシュメモリの不良ブロックを避けるために間接参照を導入しました。

　するとその間接参照の単位を決める必要があります。ここでIUが登場します。

　説明したとおり間接参照の導入目的は「不良ブロックを避けること」ですから、IUを「NANDフラッシュメモリのブロック」とするのが自然です。実際、SSD登場初期のIUはNANDフラッシュメモリのブロックでした。つまりIUサイズはブロックサイズとなります。当時はブロックサイズが2 MBなどと小さく、ページサイズも2 KBや4 KBという時代です。

　例えば、ブロックサイズが2 MiBでページサイズが2 KB（1ブロック1,024ページ）というNANDフラッシュメモリを使用したSSDにおいて、セクタサイズ512バイトで512 GiBのLBA空間に対してIUをNANDフラッシュメモリのブロックとした場合、間接参照の設計例は以下の図3のようになります。

　この図3の設計におけるIUサイズは、NANDフラッシュメモリのブロックサイズである2 MiBです。
 
![SSDにおける間接参照の具体例](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/439683/e82b012f-7e43-e066-35ee-f31dfe863b4a.png "SSDにおける間接参照の具体例")
_図3：SSDにおける間接参照の具体例_

　この間接参照を用いてLBAから物理アドレスを解決するには、まずLBAをIUサイズで区切ります。IUサイズは2 MiBでセクタサイズは512バイトですから、IUサイズを示すビット数は21-9=12です。つまり、LBAの下位12ビットはブロック内での位置を示すリニアなオフセットです。なお上位18ビットをここでは「仮想ブロック番号」と呼ぶこととします。

　そこで上位18ビットを使用して仮想ブロック番号と物理ブロック番号の対応表を参照してアクセス先物理ブロックを特定します（図3ではブロックK）。

　アクセスする物理ブロックを特定した後は、LBAの下位12ビットをページ番号を示す10ビット（図3では100）とページ内オフセットを示す2ビット（図3では1）に分解します。すると、特定されたページの特定されたオフセットがアクセス先の物理アドレスとなります。

　これがSSDにおける間接参照とIUの基本的な仕組みです。この仕組みは、NANDフラッシュメモリのブロック単位で対応表を作成するため「ブロックマッピング」と呼ばれることもあります。

　図3の「仮想ブロック番号と物理ブロック番号の対応表」の各要素には物理ブロックの番号が格納されますが、不良ブロックの物理ブロック番号は格納されません。このようにして不良ブロックの使用を避けられます。なお、図3のような表を作成するかどうかは設計依存ですのでご注意ください。

　この図3はSSDにおけるごく基本的な間接参照とIUの仕組みです。最近のSSDではさらに複雑な仕組みが実装されています。

　というのも、図3のような簡素な仕組みでは、ホストが、アクセス先LBAがLBA空間に広く分散したランダムライトをすると、SSDはNANDフラッシュメモリのブロックをどんどん消費してしまい、すぐにGarbage Collection (GC)が必要となり性能は大きく低下しかつ寿命消費が加速するからです。いわゆる「プチフリ」と呼ばれた現象が発生していたのも図3のような基本的な間接参照の仕組みのみが実装されていた頃の話です。

　ここまで来て初めて、SSDにおける間接参照およびIUの設計に、性能と寿命消費速度への考慮が必要になります。
 
# おわりに
　この記事では、SSDにおいて間接参照およびIUが導入された経緯と、SSDにおける間接参照の最も基本的な仕組みを説明しました。

　最後に説明したように、この基本的な仕組みだけでは大幅な性能低下や寿命消費加速を避けられず、SSDの設計は進化しました。その進化にあわせ、IUのサイズは縮小や拡大の経過をたどります。次回はその間接参照の進化を説明します。

# References
[1] マイクロンブログ、_「[現実世界のワークロードによって、データ粒度の高効率化、SSDの超大容量化が可能に](https://jp.micron.com/about/blog/storage/innovations/real-life-workloads-more-efficient-large-ssd-capacities)」_、2023年9月（2024年11月13日閲覧）

# ライセンス表記
<a rel="license" href="http://creativecommons.org/licenses/by-sa/4.0/"><img alt="クリエイティブ・コモンズ・ライセンス" style="border-width:0" src="https://i.creativecommons.org/l/by-sa/4.0/88x31.png" /></a><br />この記事は<a rel="license" href="http://creativecommons.org/licenses/by-sa/4.0/">クリエイティブ・コモンズ 表示 - 継承 4.0 国際 ライセンス</a>の下に提供されています。