SSDの用途とシステムデータ設計(2/2)

# はじめに
　[前回の記事](https://qiita.com/ken-yossy/items/920e9e2b0516459b99fe)において、簡易モデルを使用してSSD設計視点で見たシステムデータにかかわる制約を説明し、またユーザ視点ではSSDの用途に応じて選ぶ重要性を説明しました。

　その説明では、「システムデータのWAF」を定義してそのシステムデータのWAFに課せられた制約を左右するパラメータのひとつを説明しました。

　そこで今回の記事では残るパラメータを説明します。

# まとめ

* SSDの安定動作にはシステムデータの設計も重要
* SSD設計の視点ではNANDフラッシュメモリを熟知し用途に合わせてシステムデータの書き込み量を抑えることが必要
* ユーザ視点では用途と使いかたに適したSSDの選定が重要

# SSDのシステムデータに課せられた制約（再掲）
　まず、説明で使用するSSDのモデルと前回導いた数式をもう一度示します。

　今回の説明で使用するSSDのモデルは以下の通りです。

* ユーザデータは全てTLC NANDに書き込む
* システムデータは全て（疑似）SLC NANDに書き込む

　SSD内部でのデータ書き込み処理についてWAFに注目したイメージ図が以下の図1です。

 ![SSD内部の書き込み処理イメージとWAF](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/439683/bc17f44a-5e7c-f64c-0c26-1f5530cf415f.png "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

　このモデルと導入した記号を用いて導いた$WAF_S$の満たすべき条件が以下の式(1)でした。
```math
WAF_S \leq \frac{\alpha}{3} \times \frac{WE_S}{WE_T} \times \frac{NBLK_S}{NBLK_T} \cdots (1)
```

　この式(1)は、$WAF_S$が常にこの条件を満たすように設計しないとSSDが「システムデータがもう書き込めないのでユーザデータを書き込めない」というストレージの機能が一部失われる状況に陥る可能性があることを意味します。

　前回の記事では、この式(1)の右辺のうち$NBLK_S$と$NBLK_T$の比について説明しました。そこで今回の記事では残りの2つ、つまり$WE_S$と$WE_T$の比と$\alpha$について説明します。

# 保証書き換え回数の比
　式(1)によれば、$WAF_S$の制約を緩めてSSDの動作を守るには$WE_S$が$WE_T$に対して十分大きいことが必要だとわかります。$WE_T$を減らすことは非現実的ですので$WE_S$を増やすことが必要です。

　NANDフラッシュメモリのブロックの保証書き換え回数は、特定の能力のエラー訂正(ECC)や環境（温度）およびデータの書き込みかたを条件に、その回数までであれば規定期間のデータ保持をメーカーが保証する、というものです。

　このため、メーカーの保証書き換え回数より多い回数データを書きかえるには、より強力なECCを用いる、動作温度管理をより厳格にする、頻繁にチェックしてエラーが増えすぎる前に救済する、などの工夫が必要です。

　つまり、NANDフラッシュメモリを熟知したうえで、ECCのようなハードウェアやSSDに記録したデータの管理方法への工夫が必要になります。もちろんこれらの工夫の結果を適切に評価する評価技術も必要です。

　ユーザ視点では、SSDを「NANDフラッシュメモリに優しく使う」ことができればSSDの寿命を最大限引き出せます。例えば動作環境温度を一定にする、電源断を可能な限り減らして運用する、などです。これが難しい場合、上記のような設計上のポイントをおさえた製品の選定が重要です。

# システムデータとユーザデータの書き込みサイズの比
　これは式(1)中の$\alpha$を指します。式(1)によれば、$\alpha$が大きいと$WAF_S$の制約が緩くなります。つまり$\alpha$ができるだけ大きくなるようにSSDを設計すべきです。

　$\alpha$が大きいことは、ユーザデータの書き込みサイズと比較してシステムデータのサイズが小さいことを意味します。わかりやすいシステムデータのひとつは「ログ」です。「どのLBAにデータが書き込まれた」などの記録や、SSDの内部状態や動作記録、そしてSMART情報などの統計情報、などです。

　$\alpha$を大きくするにはこのログなどをできるだけNANDフラッシュメモリに書かなければ良いことになります。この実現にはいくつかの方法があります。

　ひとつはSSDに十分なRAMを搭載することです。ログをためる十分なRAMがあればNANDフラッシュメモリに書き込む頻度を下げられます。DRAMの搭載もひとつの手です。

　そして、できるだけ電源を切らないことも重要です。なぜなら、電源を切るときには未書き込みのシステムデータを全てNANDフラッシュメモリに書き出して不揮発化しなければならないからです。
 
　ほかには、できるだけ大きなサイズでシーケンシャルライトすることも$\alpha$を大きくする効果が望めます。大サイズのシーケンシャルライトと小サイズのランダムライトで同じ合計サイズだけデータを書き込んだとき、後者のほうが作成されるログのサイズが大きくなる傾向にあります。大サイズのシーケンシャルライトに最適化した設計のSSDであればより効果が高くなります。

　ここで挙げた3つの例のうち、ひとつめはSSDの設計に、残りの2つはSSDの使いかたにかかわることです。

　上記のようにSSDを優しく使えば、システムデータの書き込みを最小限に抑えて結果として$\alpha$を大きくできる可能性が高くなります。

　一方上記のような使いかたができない厳しい動作環境や用途でSSDを使う場合、そのような環境下でも正しく安定して動作することを目指した設計を持つ製品を選定する必要があります。
 
# まとめ
　この記事では、前回の記事に引き続きSSDにおけるシステムデータの書き込み量がSSDの動作に与える影響とそれを左右する要因について説明しました。

　システムデータの書き込み量はSSDの用途と使いかたにより変化するため、NANDフラッシュメモリを熟知したうえでSSDが用途にあわせて設計されていることが重要です。ユーザ視点では、用途や使いかたに適したSSDを選択することが重要です。

# ライセンス表記
<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>の下に提供されています。