データ配置技術の略史

SSDデータ配置は学界と産業界の両方にとって重要なテーマである。データ配置技術により、ホストはSSDでのデータ配置場所をより細かくコントロールできる。 ホストシステムのコントロールを強化することで、データ配置技術の狙いは、i) SSD書き込み増幅の削減、 ii) サービス品質（QoS）の向上、iii) ホストのオーバープロビジョニングの削減、 iv) 総所有コストの最適化、などである。 ここ10年間、様々なレベルのホストとデバイスの連携を活用した数多くのデータ配置技術が提案されてきた。 このブログ記事では、データ配置技術の導入を必要とした課題の概要とその複雑な歴史について説明する。 私たちは思い出をたどり、様々なデータ配置の提案とその受容及び進化について説明することで、この歴史を掘り起こす。

1. SSDデータ配置技術が必要な理由は？

データ配置技術の必要性を理解するためには、まずSSDの仕組みとその機能から生じる課題を理解することが重要である。

SSDの基礎

SSDはデータを保存してプログラムできるNANDセルを使用して作られる。 シングルビットNANDセルを使用してデータを保存するSSDは、シングルレベルセル（SLC）SSDと呼ばれる。 同様に３ビットまたは４ビットのデータを保存するNANDセルを使用するSSDは、それぞれトリプルレベルセル（TLC）またはクアッドレベルセル（QLC）SSDと呼ばれる。 SSDにはダイ、プレーン、ブロック、ページで構成された複数のNANDパッケージが含まれている（図１）。 従来のNAND SSD（CNS）には通常、単一のオープンブロックがあり、その中に空きページがホストのデータとしてプログラムされる。 ホストは論理ブロックアドレス（LBA）に基づいてSSDに読み取り及び書き込み命令を下す。 NAND SSDは書き込み前に削除するという原則に従っているため、直接上書きすることはできない。 NAND SSDでの削除は削除ブロック（通常は数十から数百MBのサイズ）単位で行われるが、書き込みはページ（通常は４KB、16KBなどのサイズ）単位で行われる。 削除と書き込みの精度が一致しないため、同じLBAに対して上書きを行うホストでは、SSDが同じ物理アドレスにデータを書き込むことはないため、非常に管理が必要である。 SSDのフラッシュ変換レイヤー（FTL）は、複数のステップを使用して管理を行う。

• 開いているSSDブロックの利用可能な空きページに新しいデータを書き込む。


• 以前に書き込まれたデータがあった古いページを無効にする。


• 新しいページを指すようにFTLメタデータ情報を更新する。 ここでのメタデータはホストが使用する論理アドレスをNANDメディアの物理アドレスに変換するマッピング（L2P マッピング）を指す。

SSD書き込み増幅

消去ブロックを空にするためには、有効なデータページを他のブロックに移動する必要がある。 このプロセスはガベージコレクションと呼ばれ、SSDは有効なデータを再配置するために追加の読み取りと書き込みを実行する。ガベ ージコレクションによって発生する追加の書き込みにより、「書き込み増幅」が発生する。 総SSD書き込み数と総ホスト書き込み数の比率はガベージコレクションのオーバーヘッドを定量化し、SSD書き込み増幅係数（WAF）と呼ばれる。 SSD WAFの理想的な値は１であり、SSDがガベージコレクションを実行する必要がなかったことを示す。 ホスト書き込みパターンが連続している場合、SSD削除ブロック全体が無効になり、ガベージコレクションが回避されるため、SSD WAFは１になる。 ランダムなホスト書き込みパターンにより、有効なページと無効なページが混在し、ガベージコレクションによってSSD WAFが高くなる。 NANDセルにはプログラム/削除（P/E）サイクルの固有の数があり、それを過ぎると摩耗して故障し始める。 SSD WAFが１より大きい場合はガベージコレクションによって限られたP/Eサイクルが使い果たされ、SSDの故障が早まるため、理想的ではない。 ガベージコレクションにより、ホスト I/O作業で追加の遅延が発生し、性能とQoSが低下する。 そのため、持続的かつ確定的なホスト性能を実現し、SSDの早期障害を防ぐ鍵は、SSD WAFとガベージコレクションを最小限に抑えることである。

2. SSDデータ配置技術

SSD WAFはホストの書き込みパターンと関連するデータ特性または上書き速度（温度）の影響を受ける。 従来のSSDは温度の異なるホストデータを単一のオープンブロックに書き込むため、上書きパターンが非効率になり、SSD WAFが増加する。 ホスト入力がないとSSDはホストの書き込みパターンを認識しないため、SSD WAFをコントロールするのは困難である。 SSDデータ配置技術は様々なレベルのホスト入力（図２）を導入してデータ配置を実行し、ガベージコレクションを最小限に抑えることで、SSD WAFの課題に対処する。

SSDの使用に関する課題とデータ配置技術の必要性が明らかになったため、ブログ記事の残りの部分では、SSD データ配置の様々な試みについて説明する。 議論された技術ごとに、５つの主要テーマに焦点を当てた概要セクションを追加する。

1. ホストアシスト: この技術で使用されるホストアシストのレベルは？  


2. 導入の複雑さ:この技術を採用するためのホストスタックの変更はどの程度複雑なのか？


3. 下位互換性: この技術は、CNSの従来のブロックインターフェースに機能を追加したものなのか、それとも、データ配置を無視したいユーザーにとって、下位互換性に欠けるまったく新しいインターフェースとなるのか？


4. SSD WAF:ホストスタックがこの技術を採用した場合、SSD WAFはどのような効果が期待できるか?


5. 現状: 技術の現状はどうなっているか?

3. ホストアシストによるデータ配置の最初の試みの１つ

Open Channel SSD（OCSSD）はSSD 書き込み増幅の課題に取り組むために最初に行われたアプローチの 1 つである。 Open ChannelのアプローチはNANDジオメトリ、コントローラの配置、及びスケジューリングポリシーをホストに公開することであった。 このアプローチではホストがデータ配置を完全にコントロールし、ウェアレベリングやエラー管理などを実現して基盤となるメディアを管理することに依存する。 OCSSDではこのすべての機能を果たすために、ホストベースのFTLを実現する必要があった（図３）。 ホストはLinuxカーネルのLightNVM [２, 18]サブシステムを介して、このレベルのコントロールを実現することができ、そのために必要なインターフェースをホストに提供した。 LightNVMサブシステムにより、様々なアプリケーション、ストレージスタック、及びファイルシステムで論理データがデバイスに物理的にマッピングされる方法を完全にコントロールできるようになった。 OCSSDはFusion IOの独自のストレージスタックに対するオープンソースのアプローチであり、ホスト側のデータ配置とNANDメディアの管理を行っている[２]。 OCSSDは様々なデバイスベンダーがコントローラを構築し、一部のハイパースケーラーが自社のサービスの一部に導入したことで、業界で注目を集めた。この動きにより、Open Channel SSDを標準化するためのProject Denali [３、４]が創設され、主にMicrosoftが推進した。 特にアリババはOpen Channelと従来の動作モードの両方をサポートできる「デュアルモードSSD」と呼ばれるOCSSD [５、６]の独自バージョンを定義して展開することで、別の方向に進むことを決定した。 

書き込み増幅を解決するためのOpen Channelアプローチは大きな可能性を示したが、TLC SSDが一般的になったことで、ホスト管理のFTLの複雑さが増大した。 SSDはマルチビットNANDセルのプログラミングが複雑なため、ベンダー間で実現が異なっており、これらのSSD実現全体で耐久性を保証する複雑な実現を処理する責任はホストに残されていた。 これにより、基盤となるメディアを完全にコントロールするホストFTLアプローチの魅力が大幅に低下した。 OCSSDは標準化されず、最終的には廃止された。 

OCSSDの概要と現状::

• ホストアシスト: 完全なホストベースのFTL。


• 導入の複雑さ: 導入にはホストスタックへの大幅な変更が必要である。


• 下位互換性: 下位互換性なし。


• SSD WAF: SSD WAF１が保証される。


• 現状: 標準化されておらず、業界によって廃止されている。

4. 新しいデータ配置技術の誕生

OCSSDアプローチが業界で話題になり始めた頃、NVMeは「NVMeディレクティブ」[７]を標準化した。これはマルチストリームまたは単にストリームとして知られている人も多い。 ストリームのアプローチはホストが書き込みコマンドに「ヒント」のタグを付けられるようにすることである。 このヒントはSSDによって異なるデータタイプとして解釈され、異なるヒントを持つデータを異なる削除ブロックに配置できる（図３）。 このアプローチはOpen Channelの複雑なホストFTLアプローチよりもはるかに単純である。 マルチストリームの鍵はホストが異なるデータタイプを識別し、ヒントを適切に使用してSSDのガベージコレクションを減らし、最終的に書き込み増幅を減らすことである[８]。 マルチストリームSSDは従来のSSDと完全に下位互換性がある。 つまり、ホストが書き込みにヒントのタグを付けなかった場合、従来のSSDのように動作する。 多くの学界及び産業界の取り組みにより、マルチストリームSSDを使用して、様々なアプリケーションやエコシステムでSSD WAFを削減する様々な論文や講演が発表された。

Streamsは標準になって商用化され、Linuxカーネルのサポートもアップストリームに導入された。 しかし、確かなユースケースが不足し、業界での採用も少なかったため、LinuxカーネルはStreamsのサポートを削除した。 シンプルなインターフェースとホストスタックへの統合の容易さにもかかわらず、業界での支持が低かったため、ストリームは結局普及しなかった。

ストリームの概要と現状:

• ホストアシスト: 書き込みヒントを使用してSSDのデータを分離する。


• 導入の複雑さ: シンプルなインターフェースと導入により、ホストスタックへの変更を最小限に抑える必要がある。


• 下位互換性: 下位互換性あり。


• SSD WAF: WAFについては保証なし。


• 現状: 標準化。 しかし、トラクション不足のため低下した。

5. Open Channel SSDとSMR HDDから学んだ教訓を基に

Open Channel SSDの開発経験と、すでにShingled Magnetic Recording（SMR）HDDで採用されているZAC/ZBC仕様[９、 10]のゾーンストレージモデルを基に、Zoned Namespace（ZNS）インターフェースが誕生した[11、17]。 ZNSは基盤となるNANDメディアの管理の複雑さを排除し、メディアに依存しないデータ配置コントロールをホストに提供することを目指した。 ZNSはOCSSDアプローチから学び、従来のメディア管理をデバイスFTLに任せる（図３）。 ZNSはNVMeによって標準化され、NVMeにZNSコマンドセットが導入された。

ZNSの基本的な構成要素はゾーンであり、ゾーンは、ホストが厳密に順番に書き込むことができる領域である。 SSDはLBA空間をパーティション分割して形成された多数のゾーンで構成されており、ホストシステムによって管理される必要がある。 ホストはゾーンへの書き込みを順番に管理し、L2Pマップの維持、ガベージ コレクションのトリガーと実現、ゾーンの解放、その他のステートフルな操作など、FTL機能の多くを担当する。 ZNSはNANDメディアの管理をSSDに任せている。 そのため、ZNSを使用したSSD WAFは、厳格なシーケンシャル書き込み要件により１になるが、アプリケーション レベルの書き込み増幅（App. WAF）は増加する。 ZNSを使用したエンドツーエンドのWAF（アプリケーション + SSD）は、ゾーンと様々なステートフル操作を管理するホスト・ ソフトウェア・ スタックの実現に依存する。

ホストがステートフル操作を実行する必要があるため、それを実現する方法が１つもなく、ホスト・ソフトウェア・ スタックは非常に断片化された。 ホストがシーケンシャル書き込みを実行するためのZNSインターフェースの厳格な要件は、従来のホストスタックをZNSを採用するために再設計する必要がある。 ゾーンはLBAに基づいて分割されるため、ゾーンの厳格なシーケンシャル書き込み要件により、本質的にランダムなホスト書き込みパターンは課題となる。 たとえば、ログ構造化の書き込みのような本質的にシーケンシャルな書き込みパターンは、ゾーンのシーケンシャル書き込み制限に準拠しやすいため、ZNSで使用するのに最適である。 非シーケンシャルな書き込みパターンをシーケンシャルなゾーン書き込みに変換するために必要な管理は、多くの場合複雑であり、アプリケーションを大幅に再設計しなければ実現するのは容易ではない。 さらに、ZNSは一般的なブロックインターフェースから逸脱しているため、従来のSSDとの下位互換性がない。最終的に厳密なシーケンシャルインターフェースによってもたらされる複雑さは、ZNSがSSDベースのシステム向けの「唯一の」データ配置技術となることに対する大きな障害となる。

ZNSの概要と現状

• ホストアシスト: 厳密なシーケンシャル書き込み要件を持つゾーンを使用する。 ホストはデータの配置を管理するが、メディアの管理はデバイスに任せる。


• 導入の複雑さ: 導入にはホストスタックへの大幅な変更が必要である。


• 下位互換性: 下位互換性なし。


• SSD WAF: SSD WAF１が保証される。


• 現状: 標準化。 SMR HDDに採用されている。 NVMeのトラクションが低い。

6. 過去から現在まで - 多くの教訓とデータ配置エコシステムの統合の試み

OCSSD、NVMeストリーム、ZNSの試みから学ぶべき教訓がある。 教訓の一部は次のとおりである。

• メディア管理はSSDに任せる:ホスト側でNANDメディアを管理するのは非常に複雑であり、基盤となるNANDの特性に大きく依存する。 SSDは利用可能なメディアのより詳細な情報を持っているため、メディアを独自に管理するのに最適である。 これはデータ配置に対するOCSSDアプローチから得られた大きな教訓であった。


• ホストアプリケーション スタックの再設計や大幅な変更には消極的である:ホスト・ソフトウェア・ スタック、特に安定化したソリューションは、長年にわたりよく構築されたシステムであるため、多様なデータ配置技術や大規模な再設計を試みることに対して非常に脆弱である。 データ配置技術は絶えず進化しているため、新しい技術を採用するためにアプリケーションを継続的に再設計するというエンジニアリングの取り組みは、まったく意味がない。 これはZNSから得た重要な教訓である。


• 成功には業界の支援と確かなユースケースが不可欠である:Streamsと同様に、どんなに使いやすくても、確実なユースケースと顧客の後押しがなければ、データ配置技術は衰退することになる。

ZNSはある程度の支持を得ていたが、データ配置エコシステムがまだ安定しておらず、今後さらなる進展が期待できることは明らかであった。GoogleはSmart FTLと呼ばれるデータ配置方法を開発し、社内でユースケースに使用していた。 Googleは公開フォーラムでSmart FTLとその技術的な詳細についてさらに詳しく語り始めた[12]。 この頃、Metaは同様の公開フォーラムで自社のデータ配置技術であるDirect Placement Mode（DPM）について話し始めた[16]。 両社のアプローチにはいくつかの類似点があり、両社とも技術を標準化したいと考えていたため、協力するのは理にかなったことであった。 NVMeでのデータ配置方法を協力して標準化しようとする意欲が、最終的にNVMe Flexible Data Placement (FDP) [13、 14]の導入につながった。 FDPは両方のアプローチの主要なアイデアを取り入れ、標準化されている。 最も単純な形式のFDPはStreamsと非常によく似ている。 しかし、多くの微妙な違いにより、FDPはストリームのように単に書き込みに「ヒント」をタグ付けするだけでなく、ホストに多くの機能を提供できる。 表１ではStreams、ZNS、FDPの主な違いをまとめている。

FDPはホストにデータを分離する機能と、SSDを照会してSSDの状態に関する詳細情報を取得するメカニズムを提供することを目的としている。 これはフィードバック ループであり、これを使用してホストはデータ配置ロジックを微調整または変更し、最終的にWAFを～１にすることができる。 これにより、データ配置に使用されるホストとデバイスの連携レベルに関して、FDPはStreamsとZNSの間に位置付けられる（図２）。 FDPは顧客第一の技術であり、特定のユースケースを念頭に置いた顧客からFDPの採用が強く推進されている。 FDPエコシステムは、その急速な進歩を支えている多くの学界及び産業界の取り組みにより、急速に発展している。 FDPを構築し、推進するための重要なマントラは最小限の統合作業でデータ配置の利点の大部分を達成することである。

次のブログ記事ではFDPについてさらに詳しく掘り下げ、データ配置エコシステムにおけるFDPの現状についてご説明します。 ご期待ください！

7. データ配置の将来はどうなるか?

データ配置エコシステムは多くの紆余曲折を経ており、様々な時点で多くのテクノロジーがデータ配置の世界を支配してきた。 データ配置エコシステムが進化の終わりに達した、あるいはいずれかのテクノロジーが最高潮に達すると想定するのは単純すぎる。 ZNSはログ構造化の書き込みのように本質的にシーケンシャルな性質を持つワークロードに最適であることは明らかである。 ZNSはアプリケーション スタックの再設計が複雑すぎることが多いため、ランダムな書き込みパターンには適していない。 FDPはアプリケーション スタックへの変更を最小限に抑えて簡単に統合できるように設計されており、エンジニアリングのコストとSSD WAFの利点のトレードオフにおいて、最高のコストパフォーマンスを実現する。 CNSを使用するホストシステムがSSD WAF（Write Amplification Factor）に対するより良いコントロールを望んでいるが、最適なアプローチを確信できない場合は、FDPが明確な選択である。 これは実験と統合に必要な労力が少ないためである。 システムに既にログ構造化の書き込みパターンがない限り、厳格なインターフェース要件に準拠するため、ホストスタックを変更するのに必要なエンジニアリングコストのため、ZNSを試すことは困難になる可能性がある。 ホストデータを配置する最適な方法はホストスタックの設計と関連するワークロードに大きく依存する。 この主観的な性質を考えると、異なるユースケースを解決するために他の技術が登場することが予想される。 そのため、すべてのユースケースに対応する単一のデータ配置技術を探すのは無駄な作業になる可能性がある。複数のデータ配置技術が共存するかどうか、またそれらの技術がどのようなものになるかは、時間が経ってみなければ分からない。

参考文献