不揮発性メモリモジュールと永続メモリは、データセンターコンピューティングにおける次の大きな進歩となるでしょう。高いストレージ密度とDRAMのようなパフォーマンス、DRAMのようなインターフェースを備えており、全く新しいアルゴリズムとシステムアーキテクチャが可能になります。これは、パフォーマンス保証を満たすためにDRAMに依存している高速なキー/バリューキャッシュサービスであるmemcachedにとって重要です。これは新しいテクノロジーですが、どのように活用できるでしょうか？

memcachedで、永続メモリは今日どのように使用できるでしょうか？
永続メモリは、将来どのように使用されるでしょうか？

Intelとの協力により、これらの質問に答えるために、Intel® Optane™ DC 永続メモリモジュール（以下PMEM）と、最小限に修正されたmemcachedを使用して実験を行いました。この記事では、ベンチマーク結果と、キャッシュシステムの将来のコードアーキテクチャの可能性について考察します。

永続メモリ

Intel® Optane™ DC 永続メモリモジュールは、バッテリーの助けを借りずに電源を切ってもメモリを記憶できるDDR4互換のメモリモジュールです。ただし、動作には互換性のあるマザーボードとプロセッサーが必要です。

DDR RAMには、速度、機能、密度という点でさまざまな種類があります。サーバーの場合、機能と速度は、マザーボード、CPU速度などのシステム内の他のコンポーネントとの組み合わせによって決定される傾向があります。最も重要な選択は、RAMの密度をどれだけにするかです。

サーバー向けの一般的なDRAMモジュールは、（今日現在）8〜64ギガバイトのサイズです。各密度には独自の価格帯があります。

     DRAM
16G  $7.5/gigabyte
32G  $7/gigabyte
64G  $9/gigabyte
128G $35/gigabyte

128Gモジュールは新しく、希少であり、それにふさわしい非常に高いコストがかかります。システム構築者は、メモリスロットとDRAM密度との間でトレードオフを決定する必要があります。クラウドプロバイダーは通常、高密度で小型で安価なシステムを求めています。

Intelのこれらの新しいモジュールには、128G、256G、512Gの密度があります。ギガバイトあたりのコストは128Gで最も低く、512Gで最も高くなります。システムのパフォーマンスは、システム内のモジュール数に応じて拡張されます。

キャッシュシステムの場合、128Gモジュールがスイートスポットに適合しているようです。この記事の残りの部分では、128Gモジュールで構成されたシステムのパフォーマンスについて検討します。

ベンチマーク

最小限の変更または全く変更なしで、どのようなパフォーマンス特性が見られるでしょうか？将来の設計方法について何を学ぶことができるでしょうか？主に3つの構成でテストしました。

コード変更なし。提供されたハードウェア上のDRAMベースラインのみ。
コード変更なし。システムメモリを拡張するためにメモリモードを使用。
最小限のコード変更：永続メモリストレージ上のアイテムメモリのみ。

extstoreを使用しないのはなぜですか？

Extstoreは、標準のSSD/NVMEデバイスを利用してメモリをオフロードするmemcachedの拡張機能です。これは、メタデータとキーデータをRAMに保持し、アイテムの「値」部分をストレージにポイントすることによって実現します。このトレードオフは、比較的大きな値（1k〜8k +）を持つアイテムに適しています。小さいサイズ（1k未満）では、使用できるディスクスペースに対して大量のRAMが必要です。

extstoreは大きな値には適していますが、memcachedには大量の小さなアイテムを処理するための機能がありません。PMEMをExtstoreと組み合わせることもできます。アイテムのメタデータとキーはPMEMに、値はNVMEフラッシュストレージに格納します。

テスト環境

テストは、memcached 1.5.12とmc-crusherを使用して行いました。テストスクリプトはこちらで入手できます。

テストは、カーネルビルド4.15.6のfedora 27を実行している単一のマシンで行いました。マシンのハードウェア仕様は以下のとおりです。

2x Xeon Cascade Lake CPU（24コア、各48ハイパースレッド）
12 x 16GB（192GB）のDDR4 RAM
1.5TBのIntel Optane DC永続メモリ（2:2:2構成）
OSディスク用の1 SSD

テストマシンは、NUMAマルチソケットサーバーでした。1つのNUMAノードを使用してmemcachedサーバーを実行しました。もう1つは、mc-crusherベンチマークを実行するために使用しました。CPUコアは、レイテンシーサンプリングプロセス用に予約されました。

次のOSレベルの構成変更を行いました。

/usr/bin/echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo
echo "4096" > /proc/sys/net/core/somaxconn
cpupower set -b 0
cpupower frequency-set -g performance

一貫性を保つためにターボを無効にしました。テストは、mc-crusherに割り当てられたCPUコア数によって段階的に行われます。ターボが有効になっていると、最初の数コアの方が高速になる可能性があります。また、実行ごとに異なる結果になる可能性もあります。
最小周波数は指定されていませんが、パフォーマンスCPUガバナーが有効になっています。
somaxconnsを増やしました。「ペースの速い」テストでは、大量の接続が迅速に確立されます。これにより、接続の切断を回避できます。
負荷生成は、UNIXドメインソケットを介して行われました。NUMAノードを横断するlocalhost上のTCPには、深刻なパフォーマンス制限と変動する結果がありました。
レイテンシーサンプラーアプリケーションはlocalhost上のTCPを使用しました。メインベンチマークと同じ回帰は発生しませんでした。これは、TCPスタックを元に戻すことによって、現実により近いレイテンシー結果を得るためです。
すべてのテストで、アイテムの値サイズは256バイトです。キーとメタデータを含めると、アイテムは平均で300バイト強になります。
テストのためにサーバーにロードされたキーの数は、1億2500万または10億です。これにより、パフォーマンスのベースラインが提供され、DRAMの制限を超えて拡張した場合の追加のオーバーヘッドが示されます。どちらの場合も、ハッシュテーブルのロードファクターは93％であり、これについては後述します。

Memcachedへのパッチ

ベンチマークを支援するために、3つの小さなパッチを使用しました。

UNIXドメインソケットとTCPソケットの両方で同時にリッスンできるようにするパッチ。通常、これは、ユーザーがクライアントを誤って構成したり、インターネット上でlocalhostにロックされたインスタンスを誤って残したりする可能性があるため許可されていません。これにより、UNIXソケットを介して負荷を生成しながら、TCPスタックを介してレイテンシーをサンプリングできます。
ハッシュテーブルを強制的に拡張するコマンドを追加するパッチ。通常、memcachedは、ハッシュテーブルの使用率がアイテム対バケット比の1.5倍に達した後、ハッシュテーブルを自動的に拡張します。一部の実験では、ハッシュテーブルを過剰にサイズ設定してテストしました。詳細は後述します。
特定のクライアントフラグでアイテムが作成されたときにメモリをmallocするパッチ。これはベンチマークでは使用しませんでしたが、実験で使用しました。

テスト

Memcachedの構成

すべての場合において、memcachedは48個のワーカースレッドを使用するように構成されています。すべてのテストで同じ起動引数を使用し、使用するメモリ量とそのソースのみを変更しました。その他の変更点は、LRUクローラーを無効にすることだけです。これは優先度の低いバックグラウンドスレッドであり、テスト結果をランダムに妨害しないようにします。

memcachedへの接続は、特定のワーカースレッドに固定されます。以下のすべてのテストでは、memcachedのすべてのワーカースレッドを利用するために、ベンチマークスレッドごとに少なくとも十分な接続を作成します。

ハードウェア構成

このクイックスタートガイドは、各テストでハードウェアを構成する方法に似ています。

Optaneメモリのさまざまなモードについては、こちらで説明しています。ここでは、メモリモードとアプリダイレクトを使用します。

DRAM

これらのテストはDRAMのみを使用し、永続メモリは使用しません。これがベースラインパフォーマンスです。

メモリモード

これらのテストでは、メモリモードが有効になっています。このモードでは、システムのDRAMと永続メモリが結合されて、揮発性メモリの大きなプールのように見えます。データの永続性はありません。再起動時にすべてが失われます。

アプリダイレクトモード

このモードでは、DRAMがmemcachedの内部構造とバッファ、およびチェーンされたハッシュテーブルのメインアレイに使用されます。
すべてのアイテムデータ（メタデータ、キー、値）は、永続メモリ領域に直接格納されます。
永続メモリは、DAXファイルシステムと、memcachedの再起動可能モードのプロトタイプパッチを使用して有効になります。永続メモリには、mmapされたファイルを介してアクセスされます。
注意：再起動可能モードは1.5.18でリリースされています。-e /path/to/dax/mount/memory_fileを追加するだけで、memcachedでアプリダイレクトモードを利用できます。
注意：hugepageを使用することで、DAXファイルシステムのパフォーマンスを向上させることができます。これはテストしませんでしたが、状況によっては大幅な改善が期待できます。

結果

ランダムセレクター
一様 - キーをランダムに選択。すべてのキーが同じ確率でフェッチされます。
zipf - キーを累乗曲線で選択。番号の小さいキーがより頻繁にフェッチされます。

キー数
10億 - 300G +のストレージ。注意：DRAMベースラインは常に1億2500万キーです。
1億2500万 - ワーキングセットはすべてのハードウェア構成のRAMに収まります。

スループットテスト：ベンチマークコアあたり48接続。最大リクエストレート。
大量にバッチ処理されたリクエストとレスポンス。低いシステムコールレート。
大量にバッチ処理されたリクエスト、バッチ処理されていないレスポンス。中程度のシステムコールレート。

レイテンシーテスト：接続ごとに75msごとに50リクエスト。ベンチコアあたり400接続。高いシステムコールレート。
読み取り専用
99%読み取り、1%書き込み
90%読み取り、10%書き込み

レイテンシーパーセンタイル- レイテンシーテストグラフのみに影響します

これらのテストを調整するのは非常に困難でした。ほとんどの実験では、3つのモードすべてがほぼ同じように動作しました。ここに違いが見えるという事実は、創造性の練習でした。

DRAMはベースラインとして機能しますが、400ギガバイトのRAMがないため、大規模なワークロードに対してDRAMとPMEMを直接比較する簡単な方法はありませんでした。この比較は依然として有効です。ここで示すのは、DRAMに適合するワークロードを持つ多数のマシンと、DRAMよりもはるかに大きいワークロードを持つ1台のマシンの比較です。以下は、テスト結果を理解するのに役立ついくつかの簡単な解釈です。

DRAMは予想どおりです。
メモリモードは中間です。すべてのテストで、1秒あたり約800万から1000万リクエストまでDRAMに近い値です。
- 「レイテンシ」ワークロードでは、メモリモードで差異が出始めます。多数のセットが混在すると、DRAMおよびPMEMモードよりもパフォーマンスが低下しますが、1秒あたり約800万リクエストまでは1ミリ秒の締め切りに違反するほどではありません。
App Directモードは驚くべき結果でした。メモリモードとは異なり、メモリをまったくキャッシュしないにもかかわらず、パフォーマンスは良くなったり悪くなったりします。
- ワークロードがDRAM（1億2500万キー）に収まる場合、App Directモードはレイテンシでは非常に近い値ですが、DRAMとメモリモードの両方にわずかに劣ります。
- 10億アイテムのワークロードでは、App Directはほぼ一貫してメモリモードを上回ります。総スループットは、依然として1秒あたり2000万リクエスト以上の驚異的な数ですが低くなる可能性がありますが、レイテンシは同等です。PMEMは、混合読み取り/書き込みシナリオを含む、ペースの速いテストで非常に優れたパフォーマンスを発揮します。
zipf分布は、スループットとレイテンシの大幅な向上により、メモリモードとApp Directの両方を改善します。メモリモードは、DRAMスループットをより密接に追跡します。
ペースの速いテストでは、平均レイテンシはほぼ同じです。Memcachedはリクエストの処理中にアイテムメモリにほとんど触れないため、App Directのレイテンシが高くても、他のすべての処理によって差は埋もれてしまいます。

これらのテストの検証、再実行、再最適化には長い時間を費やしました。通常のSSDやNVMEドライブのテストに慣れている場合、これらの結果は現実離れしています。次に、これが本番環境へのデプロイメントにどのように関連するかについて説明します。

現在機能していることは？

memcachedのユーザーは、ネットワークとメモリ容量という2つのボトルネックを計画する必要があります。最近では、extstoreユーザーは、大量の書き込みが発生するワークロードでフラッシュドライブのバーンアウトに対処する必要もあります。

ネットワークスループット

スループットはほぼ無制限です。いずれの場合も、サービスが故障する前に、実際のネットワークカードが故障します。1000万件の300バイトの応答は、20ギガビット以上のトラフィックです。既知のmemcachedワークロードのほとんどすべてにおいて、アイテムのサイズは数バイトから500キロバイト以上まで大幅に異なります。システムは、さまざまなサイズのアイテムが格納されている場合、50ギガビットのネットワークカードを簡単に飽和状態にすることができます。

300b、1kb、および2kbのTCP応答（キー/値+ TCP/フレームヘッダー）を取り上げましょう。次に、テストしたマシンでのやや現実的な読み取り負荷の場合の1秒あたり800万リクエストの上限を想定すると、NICの飽和状態はどのようになるでしょうか。

平均値が2キロバイトの場合、単一のインスタンスで100ギガバイトのNICを飽和させるのが妥当になります。実際には、システムコールオーバーヘッド、割り込みポーリングレートなどにより、これらの数値は常に低くなります。また、memcachedは現在、書き込みでうまくスケールしません。書き込みレートの高いワークロードで100ギガビットを達成するには、努力が必要です。

人々は、多くの場合、特殊なハードウェアの上にDPDKまたは同様のカスタムユーザースペースネットワーキングスタックを利用します。Memcachedは、デプロイメントをできる限りシンプルにすることを優先し、これらのライブラリをサポートしていません。さらに、単一ノードで1秒あたり10万リクエストを超えるユーザーはごくわずかであるため、通常は必要ありません。

私たちが確認したところ、PMEMは一般的なネットワークカードの場合、DRAMと同等です。

メモリ密度

メモリ密度は、企業が必要とするmemcachedサーバーの数を決定するもう1つの主要な要因です。バックエンド負荷を大幅に軽減するため、またはワーキングセットをメモリに収めるために、高いヒット率を得るのに十分なRAMが必要です。

memcachedインスタンスの数を少なくすることには限界があります。障害が発生した場合、他のサーバーがその役割を引き継ぐ必要があります。データベースバックエンドが追加のミスに対応し、残りのmemcachedノードのネットワークカードも同様です。

新しいレベルの密度を持つことで、データキャッシュのサイズを拡張する機会も増えます。海外のデータセンター、AI/MLモデル、事前に計算またはテンプレート化されたレンダリングからより多くのデータをキャッシュします。

私たちは順調なスタートを切っています。既存のコードを変更しなくても、サービスは現実的なシナリオではDRAMとほぼ同じように動作します。この状況を改善したい場合は、ユーザーはまずマイクロ秒単位のレイテンシに非常に敏感である必要があります。最適化するもう1つの目標は、PMEMへの書き込みを減らすことによるデバイスの寿命です。Intelは3年間の完全な書き込み負荷を保証していますが、企業が5年以上の間、高負荷を維持してハードウェアを使用する予定がある場合は、これが重要になる可能性があります。それでも、早期のドライブのバーンアウトに関する懸念からフラッシュデバイスが手の届かないところにある場合、PMEMは良い代替手段です。

その点について、これらの条件のいずれかに一致する場合は、ぜひご連絡ください！これによって制限されるユーザーは認識していません。

再起動可能なキャッシュ

1.5.18でリリースされた機能により、memcachedは正常にシャットダウンされた場合に再起動できます。多くのワークロードでは、これは悪い考えです。

ただし、アプリケーションがキャッシュの更新または無効化をキューに入れて再試行する機能がある場合、またはワークロードにとって問題がない場合は、再起動機能が大きなメリットになります。MemcachedプールはN+1（程度）としてサイズが決定されます。1つがダウンした場合に、追加のミス率に耐えるのに十分なサーバーが必要です。サーバーがアップグレードされた場合、交換用サーバーが再充填されるまでしばらく待ってから、次のサーバーに移動する必要があります。

再起動可能なモードでは、アイテムメモリと一部のメタデータは共有メモリセグメントに格納されます。memcachedが再起動した場合、古いデータと互換性がある場合は、ハッシュテーブルを再構築し、以前のデータを処理します。これにより、アップグレードがより簡単に行えるようになります。これは、DRAMまたはPMEMのどちらを使用しているかに関係なく、同じように機能します。

これでも、カーネルの更新など、マシンの再起動時にキャッシュが失われます。App Directモードで永続メモリを使用すると、共有メモリセグメントが再起動後も永続的に存在するため、キャッシュを失うことなく、マシンを完全に再起動（または修理）できます。それが合理的な時間内に行われる限り！

この変更によって、memcachedがクラッシュに対して安全になるわけではありません。これは、従来のデータベースとは異なる一連のトレードオフに基づいて設計されています。

TCO

ネットワークの使用率を最大化し、メモリ密度を高め、クラスターサイズを縮小することで、TCOを最大80%削減できます。これを詳しく見ていきましょう。

ハードウェアコストメトリック

クラスターサイズ：ネットワークポート、消費電力

ハイエンドスイッチング（10g、25g、50g）は、ネットワークポートあたり数百ドルから数千ドルかかる可能性があります。キャッシュサーバーの数を減らすと、ポートの使用量と電気代が削減されます。memcachedは、より大きなネットワークカードを有効に活用できるため、割り当てられた容量が無駄になることはありません。

シングルソケットサーバーとデュアルソケットサーバー

Memcachedワークロードには、CPUはほとんど必要ありません。ユーザーは、1つのシステムにより多くのRAMを搭載するためだけに、デュアルソケットシステムを実行している可能性があります。デュアルソケットシステムからシングルソケットシステムに切り替えるだけで、サーバーごとのコストをほぼ半分に削減できます。

RAM密度

DRAMの価格には常に曲線があります。たとえば、（現在のサーバーDIMMの場合）

16Gモジュールは1ギガバイトあたり7.5ドル
32Gモジュールは1ギガバイトあたり7.0ドル
64Gモジュールは1ギガバイトあたり9.0ドル

PMEMの1ギガバイトあたりのコストは、（この記事の執筆時点では）同程度の密度のDRAMのほぼ半分です。

（注：RAMの価格は変動します。これらの数値は説明を目的としたものです）。

     256G         32G      256G
     DRAM         DRAM     Optane
     +---+        +---+    +----+
     |32G|        |16G|    |128G|
     |   |        |   |    |    |
     |32G|        |16G|    |128G|
     |   |        +---+    +----+
     |32G|
     |   |        $7.5/gig   $4.5/gig
     |32G|
     |   |        $1392 total
     |32G|
     |   |
     |32G|
     |   |
     |32G|
     |   |
     |32G|
     +---+

$7/gig -> $1792 total

上記の2つの例を見てみましょう。256Gのキャッシュを用意するために、1つの構成では8つのRAMスロットが必要になる可能性があり、1ギガバイトあたり8ドルかかります。RAMで2000ドルです。8つのスロットを取得するには、マルチソケットサーバー、より高価なマザーボード、またはより少ないスロットでより高密度のRAMを使用する必要がある場合もあります。PMEMとの組み合わせでは、依然としてある程度のRAMが必要ですが、合計すると、単一のキャッシュノードのコストを数千ドル削減できます。

ハードウェアコストのスケーリング

上記の例は、256GのDRAMを搭載したノードを示しています。パフォーマンスは、モジュールがマシンに追加されるにつれてほぼ直線的にスケーリングします。マルチテラバイトノードを使用すると、ネットワークが許容する範囲内で、キャッシュクラスターのサイズを大幅に縮小できます。

キャッシュサイズを大幅に増やすと、インターネット帯域幅またはデータセンター間の帯域幅、高価なデータベースサーバー、高価なコンピューティングノードなど、他の場所でコストを削減できる可能性があります。

クラウド料金の問題

独自のデータセンターを運営している場合は、直接ハードウェアを購入する方が簡単に計算できます。PMEMは、最近ほとんどの人が支払っているクラウド料金にどのように適合しますか？

クラウド料金は、この新しいテクノロジーにとって現時点では大きな予測不能要素です。最近NVMEデバイスが導入されたとき、クラウドプロバイダーは、ストレージとRAMの最大量を備えた大規模なインスタンスに4TB以上のドライブを搭載していました。これらのインスタンスは非常に高価であり、memcachedまたはExtstoreを使用するmemcachedには最適ではありませんでした。

最近では、より少ないCPUとRAMを備えた、より少量のNVME（750Gから1TB程度）を備えたノードが登場しています。クラウドプロバイダーがこの市場に適合するインスタンスを顧客に提供することを期待しています。

より少ないRAM（16〜64G）
より少ないCPU（4〜12コア）
スケーラブルな量のPMEM（256Gからテラバイト）
スケーラブルなネットワークパフォーマンス

キャッシュおよびキー/値ストレージレイヤーは、ほとんどのインフラストラクチャの重要な部分です。クラウドユーザーのニーズに密接に結びついたインスタンスを持つことは、スタートアップ企業にとっては成否を左右する可能性があり、老舗企業にとっては大きな項目になります。ユーザーは、スケーリングが困難またはコストがかかる可能性のあるアーキテクチャのセクションについてあまり心配する必要がない場合、より迅速に市場に投入できます。

結論とパート2

Intel® Optane™ DCパーシステントメモリーモジュールは、高密度で、非常に低いレイテンシを備えています。データベースのニーズと比較すると、memcachedはPMEMへの参照が非常に少ないため、パフォーマンスはDRAMとほぼ同じです。1秒あたり数百万のリクエストで、1ミリ秒（0.5ミリ秒でも）のSLAを簡単に上回ります。PMEMは、クラスターサイズを縮小するか、使用可能なキャッシュを増やすことによって、大幅なコスト削減も実現できます。さらに、メモリモードを使用すると、古いバージョンのmemcachedでもデプロイメントは簡単です。

NVMEと現在のPMEMにより、超高密度キャッシュクラスターの新しいクラスが見えてきます

DC間のトラフィックを削減（Webオブジェクト、画像データ、コンテンツ配信ネットワーク）
バックエンド負荷を軽減。
ML推論データをキャッシュします。
ストリーミングサービス用のルックアサイドBLOBキャッシュ。
一時的なデータストレージに関するあらゆる問題点またはコストセンター。

昨年のNVMEの展開と同様に、これはデータセンターストレージにとって刺激的な時期であると考えています。この業界では革命はめったに起こらないため、あらゆるものを歓迎します。

この議論はパート2で引き続き行い、このプロジェクト中に検討し、テストしたソフトウェアおよびアルゴリズムの変更について見ていきます。

不揮発性メモリの揮発的な利点 - Dormando (2019年4月30日)