大容量SSD（30TB超）は新たな課題をもたらします。最も重要なのは以下の2つです。
- 大容量SSDは、QLC（1セルあたり4ビットのデータを保存するクアッドレベルセル）NANDのような高密度NANDによって実現するが、QLC NANDはTLC（1セルあたり3ビットを保存するトリプルレベルセル）NANDよりも多くの課題が生じる。
- SSDの容量増加に伴い、昔から1：1000（DRAM対ストレージ容量）という比率だったマップ用のローカルDRAMメモリも、同様に増やすことが求められる。
現在では、1：1000の比率はもはや維持できない段階にきています。本当にそれが必要でしょうか。1：4000の比率ではどうでしょう？ 1：8000では？ それぞれ4分の1、8分の1にDRAM需要を削減できます。なぜそうしないのでしょう？
このブログでは、このアプローチの背後にある思考プロセスについて検討し、大容量SSDの今後の方向性を模索します。
まず、なぜDRAMはNAND容量と1：1000の比率でなければならないのでしょうか。SSDは、システムから送られてくる論理ブロックアドレス（LBA）をNANDページにマッピングし、そのすべてについてライブコピーを保持する必要があります。データをどこに書き込んだり読み出したりできるのかを把握するためです。LBAのサイズは4KBで、マップアドレスは一般的に32ビット（4バイト）であるため、4KBのLBAごとに4バイトのエントリーが1つ必要になります。したがって、比率は1：1000です。非常に大容量の場合は、これより少し多く必要になりますが、単純化のため、ここではこの比率で考えましょう。それによって推論を単純化でき、かつ結果に実質的な影響はないからです。
各LBAに1つのマップエントリーは、システムが最小限の粒度で書き込み（マップエントリーの作成）を行うことができるため、最も効果的な粒度です。これは、（SSDの書き込み性能や耐久性を測定・比較するために一般的に使用される）4KBのランダム書き込みで評価することがよくあります。
ただし、それは長期的には維持できない可能性があります。代わりに、4LBAごと（または、8、16、32+LBAごと）に1つのマップエントリーにするとどうなるでしょう？ 4LBAごとに1つのマップエントリー（つまり16KBごとに1つのエントリー）を使用すれば、DRAMのサイズを節約できるかもしれませんが、システムが4KBの書き込みを要求した場合はどうなるでしょう？ 16KBごとのエントリーにすると、SSDは16KBのページを読み込み、書き込む予定の4KBを変更し、16KBのページ全体を書き戻す必要があります。これはパフォーマンスに影響を与えます（「4KBの書き込み」だけではなく、「16KBの読み取り、4KBの変更、4KBの書き戻し」になります）。何より、耐久性に影響を与え（システムが書き込むのは4KBですが、最終的にSSDがNANDに書き込むのは16KBです）、SSDの寿命を4分の1に縮めます。耐久性プロファイルがより厳しいQLCテクノロジーでこのようなことが起こると厄介です。QLCで無駄にできないものがあるとしたら、それはなんといっても耐久性です。
そのため、一般的な考え方としては、SSDの寿命（耐久性）が著しく低下するのを避けるため、マップの粒度（正式な用語では間接単位（IU））は変更できないとされます。
ここまでに述べたことはすべて事実ですが、システムは本当に4KBの粒度でデータを書き込むのでしょうか。また、どのくらいの頻度で書き込むのでしょうか。確かに、Flexible IO tester（FIO）を4KBのRWプロファイルで実行するだけのためにシステムを購入することは可能ですが、実際には、システムをそのような方法で使用する人はいません。アプリケーション、データベース、ファイルシステム、オブジェクトストアなどを実行するために購入します。そのいずれかが4KBの書き込みを使用しているでしょうか？
マイクロンはそれを測定することにしました。TPC-H（データ解析）からYCSB（クラウド運用）まで、さまざまなデータベース（Microsoft® SQL Server®、RocksDB、Apache Cassandra®）上で実行される、さまざまなアプリケーションベンチマークのセットを選び、さまざまなファイルシステム（EXT4、XFS）と場合によってはRedHat® Ceph® StorageのようなSoftware Defined Storageソリューション全体で実行し、4KBの書き込みが発行された回数とそれが書き込み増幅に及ぼした影響（つまり、デバイスの寿命を縮める余分な書き込みがどれくらいあったか）を測定しました。
分析の詳細に入る前に、耐久性が問題となる際に書き込みサイズが重要である理由について説明する必要があります。
4KBの書き込みは「4KBを変更するための16KBの書き込み」を作成するため、書き込み増幅率（WAF）は4倍（4x）になります。しかし、8KBの書き込みの場合はどうでしょうか。同じIU内での書き込みであると仮定すると、「8KBを変更するための16KBの書き込み」になるため、WAF=2です。少し改善しました。16KBの書き込みはどうでしょうか。「16KBを変更するための16KBの書き込み」になるので、WAFにはまったく影響しない可能性があります。つまり、WAFに影響するのは小さな書き込みだけです。
書き込みがアラインされないかもしれない微妙なケースもあるため、WAFに影響するミスアラインメントが常に発生しますが、それもサイズが大きくなるにつれて急速に減少します。
以下の図はこの傾向を示しています。
ルカのブログ、IUの図1：16K IUによるWAFが示す「サイズの大きいIOほど影響は小さい」
サイズの大きな書き込みはWAFへの影響が最小限です。たとえば、256KBの書き込みはアラインされていれば影響なし(WAF=1x)となる可能性があり、アラインメントがずれていれば最小限の影響(WAF=1.06x)となります。4KBの書き込みによる4xという恐ろしい値よりもはるかにましです。
次に、SSDへのすべての書き込みをプロファイルして、IU内のアラインメントを確認し、各書き込みのWAFへの影響を計算できるようにする必要があります。結果は大きいほど良好です。私たちはこれを実行するために、いくつかのベンチマークに対してIOをトレースするようシステムを設定しました。20分間のサンプル（通常、各ベンチマークで1億から3億サンプル）を取得し、その後、それらを後処理してサイズとIUのアラインメントを調べてから、WAFへのIOの影響をすべて追加します。
以下の表は、各サイズのバケットに収まるIOの数を示しています。
ルカのブログ、IUの図2：ベンチマークによるWAF IUの実際のデータ（IO数別）
図に示したように、ほとんどの書き込みは、小さなサイズの4～8KB（悪い）バケットか、256KB+（良い）バケットに収まっています。
このIOがすべてアラインされていないと仮定して、上のWAFチャートを適用すると、「最悪のケース」列に示されている結果が得られます。ほとんどのWAFは1.xの範囲にあり、2.xの範囲にあるのは少数で、3.xの範囲にあるのは極めて例外的です。予想していた4倍よりずっとましですが、実用に耐えるほどではありません。
ただし、すべてのIOがアラインされていないわけではありません。なぜそうなるのでしょうか。なぜ、最新のファイルシステムが、こんな小さな粒度でアラインされないような構造を作るのでしょう？ 回答：そんな構造を作っているわけではありません。
私たちは、各ベンチマークで1億以上のIOをそれぞれ測定し、16KB IUでどのようにアラインされているかを判断するために後処理を行いました。結果は最終列である「測定値」WAF列に示されています。通常は5%未満、すなわちWAF≧1.05xであり、これはIUサイズを400%に増やし、QLC NANDと既存の小型DRAMテクノロジーを使って大容量SSDを作成できることを意味します。そのライフコストは想定した400%ではなく、5%強です。これは驚くべき結果です。
こんな意見もあるでしょう。「4KBと8KBの小さな書き込みが多数あり、それらのWAFへの影響はそれぞれ400%または200%です。こうした小さいけれど多数のIOによる影響があるため、集約されたWAFの値はもっと高くなるのではないでしょうか？」 確かにその数は多いですが、サイズが小さいのでペイロードも小さく、ボリュームに関する影響は最小限に抑えられます。上の表では、4KBの書き込みは1回の書き込みとしてカウントされ、256KBの書き込みも1回としてカウントされますが、後者は前者の64倍のデータ量になります。
上の表をIOの数ではなく、IOボリューム（すなわち、各IOサイズと移動データ）を考慮して調整すると、以下のようになります。
ルカのブログ、IUの図3：ベンチマークによるWAF IUの実際のデータ（ボリューム別）
ご覧のとおり、より高負荷のIOを示す色分けは右に偏っています。つまり、サイズの大きなIOは圧倒的な量のデータを移動させており、WAFの影響は小さいということです。
最後に、このアプローチがすべてのSSDワークロードに当てはまるわけではないことに注意してください。たとえば、最後の行は、Cephストレージノードのメタデータ部分を表しており、非常に小さなサイズのIOを実行しているため、WAF=2.35xという高い値になっています。大きなIUのドライブはメタデータのみには適していません。ただし、Cephでデータとメタデータを混在させると（NVMe SSDでは一般的なアプローチ）、データのサイズと量がメタデータのサイズと量を上回るため、WAFの合計値への影響は最小限に抑えられます。
マイクロンのテストでは、実際のアプリケーションや一般的なベンチマークでは、16K IUへの移行が有効なアプローチであることが示されています。次のステップは、これまでも決して現実的ではなく、現時点で進化の妨げにもなっているFIOを用いた4K RWでのSSDのベンチマーキングをやめるよう業界を説得することです。
さまざまなIUサイズの影響
当然出てくる関連質問の1つはこうです。「なぜ16KB IUサイズなのでしょう？ なぜ、32KBや64KBではいけないのでしょうか？」
これは非常に妥当な質問であり、具体的な調査を必要とします。また、次のようなもっと具体的な質問にしたほうがよいでしょう。「任意のベンチマークに対するIUサイズの違いによる影響は？」
すでにIUサイズの影響を受けないトレースが存在しているので、適切なモデルで実行し、その影響を確認するだけです。
図4は、WAFに対するIUサイズの影響を示しています。
ルカのブログ、IUの図4：WAFに対するIUサイズの影響
このグラフは以下のような結果を明らかにしています。
- IUサイズは重要であり、WAFはIUサイズとともに悪化する。良い解決策も悪い解決策もなく、誰もがニーズと目標に基づいて、さまざまなトレードオフを検討する必要があります。
- WAFの悪化は、上述の多くのケースで見てきたように、恐れているほどひどいものではない。最悪のケースである64KB IUと最も挑戦的なベンチマークの場合でも、懸念していた16倍よりもはるかに少ない2倍未満です。
- メタデータは、上で見たように、大きなIUの場合は常に悪い選択であり、IUが大きくなるほど悪化する。
- WAFのベンチマークに対する業界標準プロファイルであるJESD 219Aは、4KB IUではWAFが3%増すため、良いとは言えないが許容できる。これは一般的に許容できる範囲ですが、IUが大きくなると異常値となり、64K IUでは9倍近くになります。