ヘテロジニアスメモリ型ストレージエンジンとは何か？

まだ聞いていないという方にお知らせしますが、マイクロンは最近、ヘテロジニアスメモリ型ストレージエンジン（HSE）をオープンソースコミュニティ向けに発表しました。ストレージクラスメモリ（SCM）とSSDのパフォーマンスを向上させつつ、書き込み増幅を減少させることでSSDの実効寿命を延ばすソリューションを提供することに重点を置いた設計となっています。これらを実現しつつ、大規模な導入が可能です。従来のストレージエンジンと比較すると、HSEはYahoo! Cloud Serving Benchmark（YCSB）のようなワークロードに対して、何倍もの効果をもたらすことがあります。

ヘテロジニアスメモリ型ストレージエンジン（HSE）とは何か？

なぜヘテロジニアスなのでしょうか？ マイクロンは、DRAM、SCM、SSDの多様なポートフォリオを有しているため、異種のメモリやストレージメディアタイプ間におけるデータ配置を賢く管理できるストレージエンジンを構築するインサイトとノウハウを持ち合わせています。従来のストレージエンジンがハードディスク向けに書かれているのとは異なり、HSEはSCMとSSDの高スループットと低レイテンシーを活用するために一から設計されています。

実装

HSEでは、異なるメディアタイプの利点を活用して、データストレージに「ステージング」と「キャパシティ」の2つのメディアクラスをサポートしています。ステージングメディアクラスは通常、高性能（IOPSおよび/またはMB/s）かつ低レイテンシーで、書き込みの耐久性が高いメディア（SCM、データセンタークラスのNVMe™対応のSSDなど）上で動作するように構成されます。短期的なホットアクセス向けのデータはステージングメディアクラスに割り当てられるのに対し、長期的なコールドアクセス向けのデータは通常、キャパシティメディアクラスの低コストで書き込みの耐久性が低いメディア（クアッドレベルセル［QLC］SSDなど）上で動作するように設計されます。これにより、HSEは高スループットと低レイテンシーを達成しつつ、書き込みの耐久性が低いメディアのサイクルの節約もしているのです。

構成可能な耐久性レイヤー

HSEの耐久性レイヤーは、ステージングメディアクラス上に存在し、ユーザーが構成可能な論理的構成です。ユーザーが定義可能なデータの持続性を提供し、停電などのシステム障害が発生した際に失われる可能性があるデータの上限をミリ秒単位で指定することが可能です。

まず、データがDRAMから耐久性レイヤーに取り込まれます。耐久性レイヤーの低レイテンシーと高スループットという要件を満たすため、より高速なステージングメディアクラスからストレージが割り当てられます。従来のログ先行書き込み（WAL）とは異なり、耐久性レイヤーは従来のジャーナリングで一般的に見られる「二重書き込み問題」を回避することで、書き込み増幅を大幅に削減します。

データエージング

保存したデータが古くなるにつれ、データはシステムの複数の層を通じて移行し、クエリ性能（完了時間）を最適化するためにガベージコレクションの一環として書き直しされます。この高度なプロセスについて以下で紹介します。

新しいデータを保存する必要がある際、まずは耐久性レイヤーに書き込まれます。

データが古くなるにつれ、バックグランドで行うメンテナンス操作として、キャパシティメディアクラスへの書き直しが行われます。

新しく転送されたデータによって、（以前書き込まれたレコードのアップデートまたは削除により）既存のデータが陳腐化される可能性があります。メンテナンス操作は、定期的に既存データをスキャンすることで、容量の再利用を可能にします。データの大部分が無効または陳腐化している場合、メンテナンスによって有効なデータのみを書き直すことで、陳腐化したデータ、つまりガベージコレクションが占有していた容量を解放します。クエリを効率的に処理するため、有効なデータは容易にスキャンができるように配置されます。

有効なデータは、高速なクエリ処理のため層に再編成されます。キーデータとバリューデータはこのプロセスを通じて、それぞれ別のストリームに分離されます。キーはより高速な検索を可能にするため、ステージングメディアクラスに書き込まれます。最終的に、最下層のより古いデータが指定されたキャパシティメディアクラスデバイスに書き込まれます。

クエリが処理され、両方のメディアクラスからデータが読み取られると、インデックスがDRAMにページキャッシュされます。LRU（最後に参照されてから最も時間が経っているもの）アルゴリズムがインデックスを自動的にランク付けすることで、インデックスの追跡を容易にします。システムDRAMが利用可能であると仮定し、最もホットである（最も頻繁にアクセスされる）インデックスをピン留めします。

メディアクラス性能

マイクロンのテスト環境において、ステージングメディアクラスデバイスとしてNVMe™対応のMicron 9300 SSDを1台、キャパシティメディアクラスデバイスとしてMicron 5210 SATA QLC SSDsを4台使用しました。Yahoo!® Cloud Serving Benchmark（YCSB）を使用し、1秒あたりの処理数と99.9%のテールレイテンシーを比較しました。

• 1回目のテスト：4台のMicron 5210 QLC SSDをキャパシティメディアクラスデバイスとして構成
• 2回目のテスト：4台の5210 SSDをキャパシティメディアクラスデバイス、1台のNVMe対応のMicron 9300 SSDをステージングメディアクラスデバイスとして構成

両方の構成において、同じスレッド数でYCSBのワークロードA、B、C、D、Fを実行しました¹。表1は、複数のYCSBワークロードの組み合わせを要約したもので、YCSBのドキュメントからアプリケーションの例を引用しています。表2から4では、ハードウェア、ソフトウェア、ベンチマーク構成に関するその他テスト詳細が示されています。

1. ワークロードEは普遍的にサポートされていないため、テストを実施しませんでした。

2. 構成が異なる場合、異なる結果が示される可能性があります。

スループット

YCSBは、データベースの読み込みから始まります。これは100%インサートワークロードです。9300を構成に追加することで、2TBのデータベースを読み込むのにかかる時間を4分の1に削減できます。

表1では、5つのYCSBワークロードにおける読み込みと実行フェーズのスループットが示されています。ワークロードA（50%更新）やワークロードF（50%インサート）のように大量書き込みを伴うワークロードにおいては、Micron 9300をステージングメディアクラスとして追加すると、全体のスループットをそれぞれ2.3倍と2.1倍増加させることができます。ワークロードBとD（5%更新／インサート）では、スループットの向上は控えめです。これは、これらのワークロードの95%がキャパシティメディアクラスを構成する5210 SSDから大多数の読み取りが行われるためです。

レイテンシー

図2では、99.9%の読み取り（テール）レイテンシーが示されています。9300を追加すると、全てのワークロードの読み取りテールレイテンシーが大幅に改善（2～3倍）しました（100%読み取りのワークロードCを除く）。新しく転送されてきた書き込みはまず9300に吸収され、データが古くなるにつれてバックグランドで徐々に5210へ書き込まれるという点を念頭に置いてください。キーデータ（インデックス）を9300に書き込むことで、2つめの構成における検索を高速化します。読み取りの一部は、5210の代わりに9300で処理されます（クエリ分布と読み取られるデータの経過時間に依存）。

さらに、5210への書き込み回数を削減することで、5210が処理する読み取りにおいても、進行中の書き込みとの競合が少なくなるため、テール読み取りレイテンシーがより低くなります。インサート／更新レイテンシーは、実行フェーズにおける2つの構成で類似しているため、図示されていません。

書き込みバイト数

最後に、各ワークロードの実行過程で5210に書き込まれたデータ量を測定しました。ステージングメディアクラスとして9300を追加すると、5210への書き込み回数が減少し、書き込みサイクルが節約されて書き込み寿命が延長します。表5に示されているように、読み込みの間（インサートのみのフェーズ）、5210に書き込まれるバイト数は2.4分の1に削減されます。

図3では、YCSBワークロードにおいて実行フェーズ中に書き込まれた総ギガバイト数が示されています。これには、ユーザーによる書き込みとバックグランドでの書き込みの両方が含まれています。ワークロードC（100%読み取り）を除いたワークロードでは、9300を構成に追加することで、5210への総書き込みバイト数が少なくとも2分の1以下になっています。

今後の開発

今後の開発では、アプリケーションがより細かく制御できるカスタムメディアクラスポリシーのように、HSE APIの特定の側面を拡張しその利用性を向上させることを検討しています。例として、アプリケーションがインデックス作成専用のキーバリューストア（KVS、リレーショナルデータベースのテーブルに相当）を作成する際、検索を高速化するため、ステージングメディアクラスを使用するKVSを指定することができます。また、このKVSのサイズがステージングデバイスの容量に収まらないほど大きくなった場合、アプリケーションはステージングメディアを優先的に使用しつつも、キャパシティメディアも使用するポリシーを設定できます。その他には、事前定義されたメディアクラスポリシーテンプレートの導入、アプリケーションが必要に応じてそれらのテンプレートを使えるようにするHSE APIの拡張も検討しています。今後の開発に引き続きご注目ください。