SSDを「速いまま使える人」と「遅くする人」の決定的な違い | ストレージ再考 第6話

SSDの速度や寿命は、製品性能だけで決まるわけではない。書き込み量や用途によって体感は大きく変わる。速さを維持できる人と失う人の違いを整理する。

第5話SSDは本当に速いのか──見落とされがちな「速度の盲点」ではSSDが常に高速とは限らず、状況によっては速度が低下することがある点を取り上げた。多くの場合、その現象は「SSDは万能ではない」という理解で片付けられてしまう。しかし、その裏側にはもう一つの事情がある。そのためSSDの内部では、寿命をできるだけ長く保つためのさまざまな制御が行われている。前回触れた速度の変化も、実はその **「寿命を守る仕組み」**と深く関係している。
言い換えれば、SSDの速度の振る舞いを理解するためには、まず Flashメモリの書き込み寿命という制約を知る必要がある。そこで今回は、SSDの根本的な特徴とも言える Flashメモリの書き込み寿命について見ていく。

SSDはなぜ劣化するのか。どの程度の寿命があるのか。そして、それは実際の運用にどのような影響を与えるのか。速度の話のさらに奥にある、SSDの「もう一つの現実」を整理してみよう。
 そして、「速いまま使える」時間をできるだけ長くするということは、遅くなることのその先にある寿命を先送りすることができる使い方にするということである。

1 フラッシュメモリはなぜ劣化するのか

第5話では、SSDが時間とともに遅く感じられる理由を説明した。その背景には、ガベージコレクションやウェアレベリングなど、内部管理処理の増加がある。
しかし、その処理が存在する理由を理解するには、フラッシュメモリそのものの性質を知る必要がある。
フラッシュメモリは、HDDのような機械ではない。回転する部品も、摩耗する軸受けもない。それでも、書き込みには寿命がある。
理由は、データを書き込むときの動作にある。NANDフラッシュでは、セルと呼ばれる小さな記憶領域に電荷を閉じ込めることでデータを保持する。
この電荷の出し入れは、絶縁膜を強い電圧で通過させるという動作で行われる。

この処理は元の状態に完全に戻るものではない。書き込みと消去を繰り返すたびに、絶縁膜は少しずつ劣化していく。つまりフラッシュメモリは、使えば減る寿命を最初から持っているストレージである。

この寿命は、一般に P/E回数(Program / Erase cycle) として示される。セルがどれくらいの回数、書き込みと消去を繰り返せるかの目安だ。
SLC、MLC、TLC、QLCといった分類は、容量効率や価格の違いだけでなく、この耐久性の違いにも関係している。
ただし重要なのは、SSDはこの制限を前提に設計されているという点である。フラッシュメモリの寿命は避けられない。だからこそSSDは、書き込みを分散し、劣化を管理しながら動作する。

第5話で見た「速度の変化」は、実はこの寿命管理の仕組みの一部でもある。そしてこの仕組みを理解すると、SSDの使い方について、もう一つの視点が見えてくる。

それが、「速く使うこと」と「長く使うこと」は、実は同じ方向にあるという考え方である。

2 書き込み回数という制約

フラッシュメモリの寿命は、しばしば「書き込み回数」で語られる。
たとえば、

  • SLC:約10万回
  • MLC:約数千回
  • TLC:約1000回前後

といった数字を見たことがある人も多いだろう。しかし、この数字は「その回数で壊れる」という意味ではない。実際には、同じ回数を書き込んでも、すべてのセルが同じように劣化するわけではない。

あるセルは早く劣化し、別のセルはずっと安定した状態を保つ。

NANDフラッシュを構成する個々のセルのレベルで見ると、劣化は書き込み回数の増加とともに進む摩耗型の変化である。
書き込みと消去を繰り返すことで絶縁層が少しずつ傷み、電荷を保持する特性が変化していく。

しかし、SSDやUSBメモリといった装置全体のレベルで見ると、この劣化は単純な直線として現れるわけではない。実際には、セルごとの製造ばらつきや使用条件の違いによって、劣化の進み方に差が生じる。そのためストレージ全体として観察すると、寿命の変化は一様な摩耗曲線ではなく、セルごとのばらつきを背景にした統計的な現象として現れる

この性質があるため、SSDの内部では

  • 書き込み位置を分散する
  • 劣化したセルを避ける
  • エラー訂正を強化する

といった管理処理が行われている。

言い換えると、SSDは

SSDは「壊れない装置」として設計されているわけではない。
セルが少しずつ劣化していくことを前提に、書き込み位置の分散やエラー訂正によって、装置全体として安定した動作を保つよう設計されたストレージである。

こうして、セルごとの状態のばらつきが少しずつ大きくなってくると、
SSD全体としては 内部の管理処理が増え始める状態 になる。

このとき現れやすいのが、
前回の記事で触れた 速度や応答性の変化 である。

SSDの内部では、
個々のセルの状態を監視しながら、
書き込み先の調整やエラー補正などの 管理処理 が行われている。

セル単位では、まだ寿命に達していないものがほとんどであり、
装置としても 故障した状態ではない

しかし、セルの状態のばらつきが増えると、
それを吸収するための 内部処理の回数や負荷 が増えていく。

その結果として現れるのが、
ユーザーから見ると 「SSDが少し遅くなった」ように感じる現象 なのである。

3 SLC / MLC / TLC / QLC の本当の違い

前節で触れた通り、SSDの速度や耐久性は、単に「高速か低速か」では語れない。セルごとの物理特性や構造、さらに制御の工夫によって、同じSSDでも使い方次第で性能や寿命は大きく変化するのだ。ここでは、代表的なフラッシュメモリの種類である SLC、MLC、TLC、QLC を取り上げ、それぞれの特徴と設計上の意図を整理してみよう。

セル種類速度耐久性容量効率技術的工夫・実現方法
SLC×1セルに1ビットのみ記録。セル状態は2値(0/1)のみで安定性高く、書き換え耐性も高い
MLC1セルに2ビット記録。電圧を4段階に分けてセル状態を管理。高速性・耐久性はSLCより低下
TLC△~×△~×◎◎1セルに3ビット記録。電圧を8段階に分け、多段階制御と誤り訂正(ECC)で信頼性確保
QLC××◎◎◎1セルに4ビット記録。電圧16段階管理。ECCや書き込み分散制御(ウェアレベリング)必須で高速性維持

技術的ポイント補足

  1. 電圧分割で多ビット記録
    • MLC:4段階電圧で2ビット/セル
    • TLC:8段階電圧で3ビット/セル
    • QLC:16段階電圧で4ビット/セル
      → 電圧管理の精度が耐久性・速度の限界に直結
  2. 誤り訂正と分散制御
    • ECC(Error Correction Code)やウェアレベリングを用いて、書き込み耐性の低い多ビットセルでも安定動作を実現
  3. トレードオフの理解
    • SLC:速度・耐久優先 → 容量効率低
    • QLC:容量・コスト優先 → 速度・耐久性低
      → 設計目的に応じて最適セルを選択

技術的視点:セルサイズと積層構造

SLC~QLCの違いは、単に「1セルに記録するビット数」だけではない。
実際のフラッシュメモリでは、セルの物理サイズの縮小や**積層構造(3D NAND)**といった技術も組み合わされている。

記録密度を高めるための方法は大きく二つある。

  • セルを小さくして平面方向の密度を上げる
  • セルを垂直方向に積み上げる

それぞれが異なる技術的課題を持っている。

セル密度(セルの微細化)

セルを小さくすると、同じ面積により多くのセルを配置できるため、記録密度は向上する。

しかしセルが小さくなると、蓄えられる電荷量も減る。
すると次のような影響が現れる。

  • 耐久性が低下しやすい
    セルの劣化による電荷量の変化が、読み取り判定に影響しやすくなるため
  • 書き込み制御が難しくなる
    微小な電荷量を精密に調整する必要があるため、書き込み処理が複雑になる

つまり、セルの微細化は記録密度を高める一方で、耐久性と書き込み制御の余裕を小さくする方向に働く。


積層(3D NAND)

もう一つの方法が、セルを垂直方向に積み重ねる3D NAND構造である。

平面上でセルをこれ以上小さくするのが難しくなったため、
現在のフラッシュメモリではこの方法が主流になっている。

積層構造では、セルサイズを極端に小さくせずに記録密度を高められる。
しかし、その代わりに次のような課題が生まれる。

  • 配線やアクセス経路が長くなる
  • 読み書き制御が複雑になる
  • セル管理のための制御処理が増える

その結果、SSD内部ではより高度な管理アルゴリズムが必要になる。

ここのようにフラッシュメモリでは、

・1セルの多値化(SLC→QLC)
・セルの微細化
・3D積層

といった技術を組み合わせて記録密度を高めている。

しかし物理的には、
高速性・耐久性・記録密度・コストをすべて同時に最大化することはできない。

そのため実際の製品では、
どの性能を優先し、どこで折り合いをつけるかという設計判断が必要になる。

SSDの仕様やグレードの違いは、
この折り合いの取り方の違いによって生まれている。


4 SSDはどうやって寿命を延ばしているのか

「壊れ方」を管理するコントローラ

半導体メモリの容量は、長い間2のn乗という形で増えてきた。

64KB、128KB、256KB、512KB……。

この増え方は偶然ではない。メモリはアドレス信号によってセルを選択する構造になっており、アドレス線が1本増えるごとに、アクセスできるセル数は 2倍になる。さらにセルは行列のマトリクス構造で配置されるため、この2倍単位の増え方は、半導体メモリの設計と自然に対応している。これは主に SRAM や DRAM の世界の話である。

この世界では、すべてのメモリセルが正常に動作し続けることを前提にしても
製品として成立してきた。つまり、メモリ全体を均質なセルの集合として扱うことができた。


一方、ストレージの世界では昔から別の表現が使われていた。「HDDの容量は羊羹である」という比喩がある。 羊羹を包丁で切るように、ディスクの容量は好きな長さで切り分けて使える
実際のHDD容量も、

20GB
80GB
500GB
3TB

といったように、必ずしも 2のn乗にはなっていない。

これはHDDが「2^nの容量になる必然性がない」記録領域を持つ装置だからである。

一方、SSDやUSBメモリの内部で使われているNANDフラッシュメモリは、半導体メモリである。

そのためフラッシュメモリチップ単体は、
基本的に

8GB
16GB
32GB
64GB

といったように、
2のn乗の容量で製造されている。

しかしSSDという製品になると、容量は必ずしもその形にはならない。

480GB
500GB
960GB

といったように、2のn乗から少し外れた容量が普通に存在する。

メモ: さらには、USBメモリ自体も各個体のUSBメモリのサイズをエクスプローラーなどで確認すると容量が微妙に異なっていることを確認できる。

これはSSDがセルの故障を許容する設計を採用しているためである。フラッシュメモリのセルは、書き込みを繰り返すことで必ず劣化する。そのためSSDでは、すべてのセルが同じ寿命で最後まで使えることを前提にするのではなく、一部のセルが故障しても装置としては動き続けるという考え方で設計されている。
この設計を採ると、容量の扱い方も変わる。装置内部には故障したセルを置き換えるための予備領域(オーバープロビジョニング)が用意される。また製造段階でも、不良セルの配置などによって利用可能な領域はわずかに変わる。

その結果、フラッシュメモリチップ自体は2のn乗であっても、SSD製品としての容量は必ずしも2のn乗にはならない。

言い換えれば、半導体メモリでありながら羊羹のような容量管理が行われるのである。


そして、このような使い方で関係してくる、もう一つ重要な要素が存在する。それが、コントローラによる寿命管理である。 SSDは壊れない装置として設計されているのではない。壊れ方を管理する装置として設計されているのである。

コントローラが行っている「寿命管理」

セルごとに寿命にはばらつきがあり、使われ方によって劣化の進み方も変わる。もし同じ場所にばかり書き込みが集中すれば、そのセルだけが早く寿命を迎えてしまう。そこでSSDのコントローラは、書き込みを装置全体に分散させるように動作している。たとえば、同じファイルを書き換えているように見えても、内部では毎回別のセルに書き込まれていることが多い。

これを一般に ウェアレベリング(Wear Leveling:摩耗平準化技術) と呼ぶ。

さらにSSDは、壊れ始めたセルを検出して使用を避けたり、エラー訂正によって読み出しを補助したりといった処理も行っている。

つまりSSDの内部では、

  • 書き込みを分散する
  • 劣化したセルを避ける
  • エラー訂正で読み出しを補助する

といった複数の仕組みが組み合わさり、装置全体の寿命を延ばすように設計されている。言い換えればSSDは、

セルの寿命を延ばしているというよりも、
セルの寿命を「使い切る」ように設計された装置

なのである。

ウェアレベリング(Wear Leveling:摩耗平準化)の話は、既に第5話でしているので、スペック的な話はそれを参照してほしい。
では実際のところ、
SSDを長く、そして速く使うにはどうすればよいのでしょうか。

5 SSDを長く速く使える人の使い方

SSDの寿命を決めるのは 書き込み です。

NANDフラッシュメモリには書き込みと消去を繰り返せる回数(P/Eサイクル)に上限があります。つまりSSDにとって重要なのは

  • 保存しているデータ量
    ではなく
  • どれだけ書き込みが発生しているか

です。

ここまでは第5話で説明しました。

しかし実際のSSDでは、単純に「ユーザーが書き込んだ量」だけで寿命が決まるわけではありません。SSD内部では、書き込みに伴っていくつかの処理が発生するためです。

その代表が ガーベジコレクション(Garbage Collection) です。

SSDでは既存データを直接上書きすることができません。
データを更新する場合、SSDは次のような処理を行います。

  1. 新しい場所に更新データを書き込む
  2. 古いデータは「無効」として扱う
  3. 後でまとめてブロック単位で消去する

この「まとめて整理して消す処理」がガーベジコレクションです。

例えば、あるブロックに次のようなデータがあったとします。

[A][B][C][D]

ここで A が更新された場合、SSDはAと同じ場所を上書きするのではなく、
別の空き領域に新しいデータを書き込みます。

[A’]

この時点で元のブロックは

[invalid][B][C][D]

のような状態になります。

ブロックには有効データが残っているため、すぐには消去できません。
そこでSSDは、残っている有効データ

B C D

を別の場所へコピーし、その後でブロック全体を消去します。

このとき内部では

  • B をコピー
  • C をコピー
  • D をコピー

といった 追加の書き込み が発生します。

つまり、ユーザーが行った書き込みは

A → A'

の1回だけですが、SSD内部では

B
C
D

といったコピー書き込みが追加で発生します。

このように、ユーザーが書き込んだ量よりも実際の書き込み量が増えてしまう現象を
Write Amplification(書き込み増幅) と呼びます。

そして、この現象はSSDの使い方によって大きく変わります。

特に影響が大きいのは

  • 頻繁な更新処理
  • 小さな書き込みの繰り返し
  • 同じデータ領域の繰り返し更新

といったパターンです。

これらの操作では、SSD内部でガーベジコレクションが頻繁に発生し、結果として実際の書き込み量が増えていきます。ここで重要なのは、SSDは内部でウェアレベリングによって書き込みを分散させようとする、という点です。つまり、ユーザーが「同じ場所を更新している」つもりでも、実際にはSSD内部では別のセルへ書き込みが分散されます。しかしその結果として、ガーベジコレクションによるコピー処理が増え、最終的には NANDへの書き込み総量が増える という形で負荷が現れます。

つまり、SSDに負荷を与えるのは「同じセルへの書き込み」そのものではなく

頻繁な更新処理そのものです。

SSDを長く使うという観点では、

  • (不必要に)更新を繰り返さない
  • 小さな書き込みを大量に発生させない

といった使い方が、結果としてSSD内部の書き込み量を抑えることにつながります。

なお、ガーベジコレクションの基本的な動作については、
次の動画でも概念を見ることができます。

(GCの基本動作を説明した動画)

この動画はSSDの内部処理を簡略化した説明ですが、「更新 → 無効データ → まとめて整理」という流れは実際の動作に近いものです。

SSDは単なる「速い記憶装置」ではなく、内部でかなり複雑なデータ整理を行いながら動作しています。

そのため、SSDの寿命や性能を考える上で重要なのは単純な容量や空き領域ではなく、

どのような書き込みパターンが発生しているか

なのです。

※参考動画 https://www.youtube.com/watch?v=E8xr087Ka0c

6 壊れたUSBメモリの中で起きていたこと

ここまで見てきたように、フラッシュメモリの寿命は「突然の故障」として訪れるものではない。多くの場合は、
 ・書き込みの蓄積
 ・エラー訂正の増加
 ・内部処理の増加
という形で、動作の変化として先に現れる

つまり、「速いまま使える時間」を長くするということは、単に快適さの問題ではない。それは、ストレージの寿命を先送りする使い方でもある。

そしてこの話は、決してSSDだけの話ではない。実際に、長く使っていたUSBメモリのひとつが、ある日から書き込みが極端に遅くなり、やがて正常に使えなくなった。

故障と言えば故障なのだが、その挙動を見ていると、単なる突然死というより、内部のフラッシュが限界に近づいた結果のようにも見える。
では実際に、内部では何が起きていたのだろうか。そこで次は少し寄り道として、このUSBメモリを実際に分解して調べてみた記録を紹介したい。


関連記事

parameter/使い分けの軸を定義する──データとデバイスの分析パラメータ|ストレージ再考 第4話

ストレージはデバイスではなくデータの性質で選ぶ時代へ。
重要度・更新頻度・レイテンシ感度などの観点から、
HDD・SSD・NASの使い分けを整理する「ストレージ再考」第4話。

前回は、さまざまな記憶装置や媒体が生まれては消えながら、多様な記憶デバイスが存在してきたこと、そしてそれらを組み合わせてシステムが構築されてきたことを振り返った。
そして、それらをいかに使いこなすかという点において、「うまく使い分ける」という発想が重要であることを確認した。

では、その使い分けは、何を基準に行えばよいのだろうか。

記憶デバイスの選択は、どうやって行われてきたのか。
基本的な方向性は、「安い」「速い」の二つの軸であろう。

この二つの指標は、長い時間をかけて記憶装置の進化を方向づけてきた。
容量単価は下がり、速度は向上し、それに合わせてシステムの構成も変わってきた。
「より安く、より速く」という判断は、きわめて合理的だったと言える。

しかし実際の運用の現場では、この二軸だけでは説明できない選択が数多く存在する。

storages1

高速ではない媒体に、あえて重要なデータを置く。
コストが高くなるにもかかわらず、冗長化を行う。
頻繁に使うわけではないのに、低遅延の領域に配置する。

「安い」「速い」という基準だけでは、これらの判断は説明できない。

では、何が判断を分けているのか。

その起点は、デバイスではなく、データそのものにある。


データの性質からしか説明できない選択がある

同じ容量のデータであっても、扱い方がまったく異なることがある。
それは、データごとに「性質」が異なるからだ。

業務のためのデータ。
記録として残すデータ。
分析のために蓄積されるデータ。
残すこと自体が目的となるデータ。

同じ「ファイル」という形をしていても、その意味は同じではない。
意味が違えば、置き方も変わる。

ここで初めて、ストレージの選択は「速度」や「容量」だけでは決められないものになる。


データは、それぞれ違う目的で存在している

データは、単に保存されるために存在しているわけではない。
必ず「何に使うか」という目的を持っている。

日々の業務を動かすためのもの。
あとから参照するための記録。
将来の分析に備える素材。
長く残し続けること自体が意味になるもの。

目的が変われば、求められるストレージの姿も変わる。

ここで、選択の起点はデバイスから離れ、
「どのようなデータなのか」という問いへと移っていく。


データごとに“待てる時間”が違う

すぐに取り出せなければならないデータがある。
多少待っても問題のないデータがある。
今すぐ使う予定はないが、いつか必要になるかもしれないデータもある。

速度は、単なる性能指標ではない。
そのデータが「どれだけ待てるか」という性質の表れでもある。

ここで初めて、「速いこと」の意味が定まる。
すべてを高速にする必要はない。
必要な場所にだけ速さが求められる。


変わり続けるデータ、変わらないデータ

書き換えられ続けるデータがある。
追記されながら成長していくデータがある。
一度書いたら、そのまま動かないデータもある。

この違いは、見た目には分かりにくい。
しかし、ストレージとの相性を大きく左右する。

頻繁に更新されるデータは、書き込み性能や耐久性を必要とする。
ほとんど変化しないデータは、安定した保管が優先される。

データの「変化の仕方」が、置き場所を決めていく。


失えないデータがある

ここで、もう一つの視点が現れる。

失っても問題のないデータと、失ってはならないデータがある。

この違いは、容量や速度では測れない。
それは「価値」の問題である。

重要なデータほど、守るための仕組みが必要になる。
冗長化やバックアップは、コストの問題ではなく、価値に対する設計になる。

ここに至って、ストレージの選択は、
単なる性能比較から「守るための構成」へと変わっていく。


データは時間の中に存在している

データには寿命がある。

短期間だけ使われて消えていくもの。
数年にわたって参照されるもの。
長く残し続けることが前提となるもの。

時間が変われば、データの価値の形も変わる。
役割が終わったあとに、記録として残る場合もある。

ここでストレージは、「保管場所」という意味を越え、
時間の中でデータを支える器としての役割を持ち始める。


ここまで見てくると、ストレージの選択は、
「どのデバイスを使うか」という問題ではなくなっている。

データがどのような目的を持ち、
どれだけ待てるのか、
どれほど変化し、
どれほどの価値を持ち、
どのくらいの時間の中に存在するのか。

その性質の組み合わせによって、置き場所が決まっていく。

ストレージは「デバイスで選ぶ」のではない。
「データの性質から設計される」のである。


関連記事

関連外部リンク

https://aws.amazon.com/jp/s3/storage-classes/intelligent-tiering

https://cloud.google.com/blog/ja/products/databases/introducing-bigtable-tiered-storage

https://qiita.com/tomozilla/items/152b76195e9ced933efb

https://docs.aws.amazon.com/ja_jp/msk/latest/developerguide/msk-enable-cluster-tiered-storage-cli.html