はじめに
NANDフラッシュメモリを用いたSolid State Drive（以降単にSSDと記載します）の寿命を語るうえで、書き込み効率(Write Amplification Factor: WAF)は重要な指標のひとつです。
JEDECが発行する仕様[1]では、WAFを「不揮発性記憶媒体に書き込んだデータサイズをホストがSSDに書き込んだデータサイズで割り算した値」と定義しています。WAFはワークロードに依存しますが、このWAFが小さいほど寿命消費の少ない優れた製品であるとされます。
上記「不揮発性記憶媒体に書き込んだデータサイズ」には、ユーザデータだけでなくSSD自身の動作に必要なシステムデータも含まれます。NANDフラッシュメモリに書き込むシステムデータのサイズはSSDの用途により大きく異なります。このことはSSDの設計の違いにあらわれ、またSSDを選定するとき用途にあわせたSSDを選定すべき理由にもなります。
そこで今回の記事では、簡易モデルを使用してSSD設計視点で見たシステムデータにかかわる制約を説明し、またユーザ視点ではSSDの用途に応じて選ぶことの重要性を説明します。
まとめ
- SSDがNANDフラッシュメモリに書き込むシステムデータのサイズはSSDの用途により異なる
- SSDの寿命を引き出すにはシステムデータの用途に合わせた適切な設計が必要
- ユーザ視点では、用途にあわせたSSDの選定が重要
システムデータ設計の重要性
冒頭で説明したように、WAFを左右するNANDフラッシュに書き込むシステムデータのサイズはSSDの用途に依存します。WAFはワークロードに依存する指標ですからこれは当然です。
例えば、サイズの大きな書き込みが多い、また常時通電で不意の電源断がほとんどない、などの特徴を持つエンタープライズ向けやデータセンター向けSSDでは、システムデータはRAM上で保持すれば良く、NANDフラッシュメモリに書き込むシステムデータのサイズは小さくて済む傾向があります。
逆に、サイズの小さい書き込みが多い、電池駆動などの理由で電源断が多い、などの特徴を持つインダストリアル向けSSDでは、SSDの正常動作維持のためにシステムデータをNANDフラッシュメモリに書き込む頻度が高くなることがあります。
あるSSDの寿命は一定ですから、用途に応じたシステムデータの書き込みサイズの多少をSSDの設計に反映させることは必須です。
特に、ユーザデータとシステムデータそれぞれの記録領域をSSD内部で完全に分離独立させる管理方式の場合、「システムデータがもう書き込めないのでユーザデータも書き込めない」という状況に陥る可能性があります。
そこでそのような状況に陥らないために必要な設計を明らかにし、ユーザ視点で見たその意味を説明します。
説明用簡易モデル
今回の説明では以下のようなSSDをモデルとして使います。
- ユーザデータは全てTLC NANDに書き込む
- システムデータは全て（疑似）SLC NANDに書き込む
搭載しているNANDの種類（SLCやQLCなど）にかかわらず、上記のような分離独立した制御を行わず全部まとめて管理およびウェアレベリングなどの制御を行うSSDでは以下の議論は適用できません。ご注意ください。ちなみに、その場合は制御がより複雑になります。
ここで「システムデータのWAF」を定義します。
図1は、SSD内部でのデータ書き込み処理についてWAFに注目したイメージ図です。
図1：SSD内部の書き込み処理イメージとWAF
ホストからSSDにデータの書き込みが要求されると、SSDはそのユーザデータをユーザデータ用記憶領域に書き込みます。このとき、状況に応じて変化するWAFの分だけ追加でユーザデータを書き込みます。
図1の例では、ホストから書き込まれたユーザデータに加え、その2倍のサイズのデータをユーザデータのGCにより書き込んでいます。この場合、ユーザデータのWAFは3になります。
同じことがシステムデータにも言えます。前述したユーザデータをユーザデータ用記憶領域に書き込むことにより、システムデータにも不揮発化の必要なデータが生まれます。例えば書き込みのログです。
図1の例では、書き込みが必要なシステムデータに加え、そのサイズと等しいサイズのデータをシステムデータのGCにより書き込んでいます。この倍率のことをこの記事では「システムデータのWAF」と呼ぶことにします。図1の例ではシステムデータのWAFは2であると言えます。
このあとの説明用に以下の記号を定義します。
- $WE_T$：TLCブロックの保証書き換え回数
- $WE_S$：SLCブロックの保証書き換え回数
- $BLKSZ_T$：TLCブロックに書き込めるデータサイズ（ブロックサイズ）
- $BLKSZ_S$：SLCブロックに書き込めるデータサイズ（ブロックサイズ）
- $NBLK_T$：TLCブロック（ユーザデータ用ブロック）の数
- $NBLK_S$：SLCブロック（システムデータ用ブロック）の数
- $\alpha$：システムデータを単位サイズ書き込む間に書き込めるユーザデータのサイズ
- $WAF_S$：システムデータのWAF
$\alpha$が多少わかりにくいと思います。この$\alpha$は、例えばシステムデータ（ログなど）4 KBにユーザデータ書き込み4 MB分の情報を格納できる場合には4 MB ÷ 4 KB = 1,024になるような値（比率）です。大きいほうが良い値です。
図1の場合、$\alpha$は図2のように示すことができます。
図2：図1を使用した$\alpha$の説明
図2のように、ユーザデータ領域にデータを書き込むことにより生じる不揮発化が必要なシステムデータのサイズを特徴づけるパラメータが$\alpha$です。
SSDのシステムデータに課せられた制約
前節で説明したモデルと導入した記号を用いると、このSSDが「システムデータがもう書き込めないのでユーザデータを書き込めない」という状況に陥ることを避けるために満たさなければならない条件として、以下の不等式が得られます。
(NBLK_T \times BLKSZ_T \times WE_T) \times \frac{1}{\alpha} \times WAF_S \leq WE_S \times BLKSZ_S \times NBLK_S\ \cdots (1)
式(1)左辺の括弧内はユーザデータにかかわる式です。TLCブロック数にブロックサイズを掛け算してさらにTLCブロックの保証書き換え回数を掛けることで、保証内に書き込み可能なユーザデータの総サイズを表現しています。
同様に、式(1)の右辺は保証内に書き込み可能なシステムデータの総サイズを表現しています。
つまり式(1)は、保証内に書き込み可能なシステムデータの総サイズ（右辺）は、保証内に書き込み可能なユーザデータの総サイズにシステムデータのWAFなどを掛けたサイズより 大きくなければならないことを意味しています。
この不等式を$WAF_S$について解くと以下のようになります。
WAF_S \leq α \times \frac{WE_S}{WE_T} \times \frac{NBLK_S}{NBLK_T} \times \frac{BLKSZ_S}{BLKSZ_T}
ここで、TLCブロックのブロックサイズはSLCブロックのブロックサイズの3倍ですから、$BLKSZ_T = 3 \times BLKSZ_S$であり以下のように簡略化できます。
WAF_S \leq \frac{α}{3} \times \frac{WE_S}{WE_T} \times \frac{NBLK_S}{NBLK_T} \ \cdots (2)
具体例
$WAF_S$がどのような値でなければならないのかを確かめるために、ほかのパラメータに具体的な値を入れてみます。
TLC NANDフラッシュメモリを128 GiB分搭載したSSDを考えます。TLCブロックのブロックサイズが24 MiBとすると単純計算では総ブロック数5,460個程度となります。実際には余剰ブロックが数%程度ありますのでここでは総数5,600個とします。
このSSDのセクタサイズを512バイトまた表記容量を128 GBとします。JEDECの計算式によると、このSSDの総セクタ数は以下のように求まります。
21,168 + (1,953,504 \times 128) = 250,069,680
セクタサイズは512バイトとしましたのでこのSSDにユーザが記録できる総容量は以下のように求まります。
250,069,680 \times 512\ B = 128,035,676,160\ B \fallingdotseq 125\ GB
TLCブロックのブロックサイズは24 MiBとしましたので、この総容量を賄うには5,088個のTLCブロックが必要となります。すると残りブロック数は5,600 - 5,088 = 512個になります。この残りブロックの中からシステムデータ用ブロックや余剰（オーバープロビジョニング）領域を確保します。
ここは製品により大きく異なるのですが、ここではユーザデータ用の余剰分として残りのうち約4割を割り当てることとします。具体的には512個のうち218個をユーザデータ用とします。すると残りの294個がシステムデータ用となります。つまり$NBLK_S = 294$で$NBLK_T = 5,088+218 = 5,306$となります。
保証書き換え回数については、例として$WE_T = 3,000$また$WE_S = 10,000$とします。
すると式(2)は次のように計算できます。
WAF_S \leq \frac{α}{3} \times \frac{10,000}{3,000} \times \frac{294}{5,306} \fallingdotseq0.06\alpha
この式は、例えば$\alpha$が100ならばどのようなワークロードでも$WAF_S$が常に6以下になるように設計しなければならない、ということを意味します。
$WAF_S$も1以上の値ですから、この式は実際には以下のようになります。
1 \leq WAF_S \leq 0.06\alpha
これが、この例で示したSSDにおいて$WAF_S$が満たさなければならない制約となります。
SSDの設計上のポイント：システム用ブロックの数
ここで式(2)をもう一度示します。SSDを設計する側としては、$WAF_S$の制約を緩くしたいので右辺を可能な範囲で大きくしたいです。
WAF_S \leq \frac{α}{3} \times \frac{WE_S}{WE_T} \times \frac{NBLK_S}{NBLK_T} \ \cdots (2)
この式(2)より、$WAF_S$を左右する要素は3つあることがわかります。1つめは$\alpha$です。2つめは$WE_S$と$WE_T$の比で、3つめが$NBLK_S$と$NBLK_T$の比です。
この3つのうち、この記事では$NBLK_S$と$NBLK_T$の比について説明します。
ブロック数の視点で式(2)の右辺を大きくするには、$NBLK_S$を増やせば良いことがすぐにわかります。SSD内の総ブロック数は変わりませんので、$NBLK_S$を増やすと$NBLK_T$は減ります。$NBLK_T$が減るとユーザデータ用の余裕容量（オーバープロビジョニング(OP)）が減るので性能に影響が出ます。
このように、$NBLK_S$と$NBLK_T$はシステム全体のバランスを意識した注意深い調整が必要です。
SSDが今回例に挙げたモデルのような設計なのか、そして適切に設計されているかどうかをユーザ視点が判断することは難しいです。
このためユーザの視点では、用途や要求性能にあわせたSSDを選択すること、そして実際のワークロードを用いて動作を確認すること、が重要だと言えます。
まとめ
この記事では、SSDが搭載するNANDフラッシュメモリへ書き込まれるシステムデータに注目し、簡易モデルを用いてシステムデータの書き込み量がSSDの動作に与える影響を示しました。
システムデータの書き込み量はSSDの用途に応じて変化するため、SSDがその用途にあわせて設計されていることが重要です。ユーザ視点では、用途に応じたSSDを選択することがとても重要です。
次回の記事では、$WAF_S$を左右する式(2)中の残り2つの要素について説明します。
References
[1] JEDEC, "Solid-State Drive (SSD) Requirements and Endurance Test Method", JESD218B.02, June 2022
ライセンス表記
この記事はクリエイティブ・コモンズ 表示 - 継承 4.0 国際 ライセンスの下に提供されています。