キーバリューストアはもはやローカルネットワーク上の小さなオブジェクトのキャッシュに限定されません。memcachedは今日、地理的に分散したデータセンター、データウェアハウス、機械学習トレーニングシステムなど、さまざまな環境に展開されています。これらの新しいレイアウトでは、アイテムのサイズがキロバイトからメガバイトになり、デバイスを結合したり、異なる速度のデバイスを階層化したりする価値が生まれています。

私たちの以前の投稿で、memcachedの拡張機能であるExtstoreを紹介しました。これにより、キャッシュデータをフラッシュストレージに移動できます。IntelとPacketと協力して、高速フラッシュSSDおよびOptane NVMeデバイスでextstoreをテストしました。ただし、これらのテストでは、多くの興味深い疑問が未解決のまま残りました。

• さまざまなスループットでのレイテンシの期待値をどのように管理できるか？
• デバイスの数が増加するにつれて、extstoreはどのように機能するか？

この投稿では、以前よりも厳しい監視と悪い条件下でテストを実行し、これらの質問に答えようとします。memcachedは、RAMのみを使用し、大量のバッチ処理を行うことで、48コアマシンで1秒あたり5,000万を超えるキーを処理できます。印象的ですが、現実のシナリオは、小さな個々のリクエスト、システムコール、コンテキストスイッチングなどで満たされています。潜在的なベンチマーキングを回避するために、RAM、フラッシュ、Optaneデバイス間でテストするときに、これらのニュアンスを再現しようとします。

マルチデバイス実験

テールレイテンシは、少数の遅いバックエンドリクエストが大多数のユーザートラフィックに影響を与える可能性があります。キャッシュシステムを使用すると応答時間を改善できますが、応答カーディナリティの高いサービスは、さらに影響を受ける可能性があります。ヒット率が低いと、キャッシュサービスへのクエリにかかる時間が、それらの失敗したリクエストに対する単なる時間税になる可能性があります。

興味深い研究が、多くのバックエンドを持つサービスの背後にある共有キャッシュプールについて行われています。これにより、いくつかのユースケースはカバーされますが、バックエンドがますます大きな応答を持つようになり、RAMベースのキャッシュを圧倒する可能性があるため、すべてを網羅しているわけではありません。アプリケーションの地理的な拡大により、すべてのサービスをすべての場所にデプロイする必要があるため、コストもかかる可能性があります。

ストレージスペースを拡張することでこれらの問題を解決しようとするために、コードは2つの構成でテストされました。ベンチマークでは、「Just a Bunch of Devices」（JBOD）を使用しました。すべてのデバイスは、読み取りと書き込みを均等に分散する1つの大きなページプールを作成します。JBODサポートはmemcached 1.5.10でリリースされました。

ベンチマークを行わなかった別のアプローチは、階層化ストレージでした。extstoreでは、保存されたデータは論理バケットに整理されます。これらのバケットは特定のデバイスにグループ化できるため、ユーザーは小型/高速および大型/安価なNVMeデバイスを混在させてハードウェアをデプロイできます。ネットワークブロックデバイスも使用できます。

ドラフトはこちらで追跡できます。詳細については、今後の投稿で説明します。

テスト設定

テストでは、mc-crusherのタグ4を「test-optane」スクリプトの下で使用しました。

テストハードウェアは、デュアル16コアIntel Xeon（合計32コア）、192G RAM、4TBフラッシュSSD、および3x 750G optaneドライブを搭載したサーバーでした。

CPUとメモリはNUMAノード0にバインドされ、シングルソケットサーバーのように動作します。これはユーザーがデプロイするものに近く、調査結果に集中できます。

これまでに行った他のテストでは、サンプリングされたリクエストレイテンシを使用したスループットに焦点を当てていました。1秒あたり数百万のキーのフェッチレートを可能にするために、少数のTCP接続で大量のバッチ処理が使用されました。このテストでは、単一デバイス構成とJBOD構成の両方で最悪のシナリオに焦点を当てました。パイプライン化されたリクエストを大量に送信する少数の接続の代わりに、数百の接続が個々のGETコマンドのセットを定期的に送信しています。

RAMのみのテストは、ベースラインとして存在します。これは、extstoreにまったく触れない最悪の構成を示しています。キャッシュをディスクに移動することの影響を判断するために、RAMと問題のドライブのパーセンタイルと散布図を比較することが重要です。

• アイテムの値はすべて512バイトです。バッファリングされたIOでは、パフォーマンスは最大4kまで同じでしたが、各サブテストの開始時間を短縮するために小さな値が使用されました。
• テストは、1秒あたり50,000件ずつ増加するターゲットリクエストレートでスケーリングされました。
• GETリクエストは、ベンチマーククライアントからサーバーへの50個のスタックでパイプライン化されました。これにより、主にベンチマーククライアントのシステムコールが節約されます。
• すべてのキーフェッチは、extstoreから個別にリクエストする必要があります。extstoreは、バッチ処理を許可すると、より少ないシステムコールで多くのIOリクエストを処理できます。
• Memcachedは、GET応答ごとに少なくとも1つのネットワークシステムコールを行います。

これにより、最悪のケースに偏った中間地点に着地します。ほとんどのユーザーはマルチキーフェッチを介してある程度のバッチ処理を行っているため、このベンチマークは現実的である必要があります。

ターゲットリクエストレートが増加するにつれて、レイテンシパーセンタイルをプロットします。また、経時的に取得されたすべてのサンプルの点群もあります。これは、外れ値と、各テスト中のパフォーマンスがどれだけ一貫しているかを示しています。

パフォーマンスを測定するためにパーセンタイル平均を使用することがいかに問題であるかを強調することが重要です。最初のグラフで傾向を特定するために使用します。次に、レイテンシの概要と、テストの全期間の散布図で補完します。これがないと、折れ線グラフでは問題なく見えるテストでも、実際には深刻な外れ値が発生したり、数秒間すべてのトラフィックが途絶えたりする可能性があります。

レイテンシパーセンタイル 50 75 90 95 99 - 本番環境のクエリレートにマウスオーバーして詳細な内訳を表示

結果

• グラフの途中で、平均レイテンシが大幅に上昇します。これは、そのデバイス構成のピークパフォーマンスレートです。たとえば、500kから550kの間では、SSDはスループットを増加させなくなり、リクエストはより長くキューに入れられます。
• 複数のデバイスに移行すると、レイテンシの崖は後になりますが、単一デバイスよりも悪化します。3つのOptaneドライブは、2つのドライブとほぼ同じように機能します。これは、ファイルシステムバッファキャッシュのロック競合が原因です。
• パーセンタイルを90以下に下げると、複数のデバイスは引き続き単一デバイスよりも優れたパフォーマンスを発揮します。つまり、競合が増加するにつれて、より多くの外れ値が発生します。
• ベンチマークは完璧なスケジューリングではありません。多くの外れ値（特にRAMテストの場合）は、リクエストの定期的なドッグパイルが原因で発生する可能性があります。これは、95パーセンタイルの結果がユーザーが見るものに近い可能性があることを意味します。

結論

• リクエストレート全体がレイテンシの崖を下回っており、レイテンシが許容範囲内であれば、RAMを非常に積極的に削減できます。Optaneドライブは、この最悪のシナリオではRAMのパフォーマンスに非常に近いですが、SSDも同様に優れたパフォーマンスを発揮します。
• リクエストレートがレイテンシの崖を上回っている場合は、RAMを追加するのが簡単な修正方法です。ほとんどのワークロードは最近性に大きく偏っているため、比較的小さな割合をRAMに移動すると、extstoreへの負荷を大幅に軽減できます。
• NUMAはより多くのRAMとCPUへのアクセスに役立ちますが、シングルソケットマシンは最も一貫したレイテンシを提供します。
• 内部バッチ処理の改善とダイレクトIOのサポートに関する今後の作業は、パフォーマンスに大きな影響を与える可能性があります。

ここで示す追加のテストは、1つまたは複数のデバイスを備えた単一マシンのパフォーマンスにおける最悪のシナリオのベースラインを示しています。1秒あたり約500,000のリクエストレートで、平均レイテンシが1ミリ秒未満の場合、ほとんどのワークロードは快適に適合します。ディスクスペースの拡張はうまく機能しますが、複数の高性能デバイスでのスループットを改善するには、さらなる開発が必要です。