実証試験：Micron 9300を使用したLightbits Labs™ Apache Cassandra®のパフォーマンス
今日のデータセンターは、高性能SSDを高速、スケーラブル、電力効率の高いNVMe™プロトコル上に集約しています。容量需要がSSDのプールを必要としたとき、ディスアグリゲーテッドストレージの問題を解決するためにNVMe Over Fabrics（NVMe-oF™）が導入されました。容量を柔軟に特定のアプリケーションに割り当てられる、ラックスケールのNVMe SSDのリモートプールを支えます。次に、課題は単一サーバーを超え、データセンター全体でパフォーマンスを向上し、パフォーマンスとNVMeの投資を最大化する方法になりました。
NVMe標準の共同作成者として、マイクロンはSoftware Defined Storage分野、特にディスアグリゲーテッドストレージソリューションを調査し、経験を共有します。過去のNVMe-oF導入の最大の課題の1つは、RDMA（リモートダイレクトメモリアクセス）構造の管理と構成でした。
私は、マイクロンのオースティンにあるソリューションラボのエンジニアリングチームを率いており、チームは業界のリーダーによる新たなテクノロジーに対する実験を行います。最近、Lightbits Labs™のNVMe over TCP（NVMe/TCP）ソリューションと呼ばれる、NVMe-oFの新たなプロトコルのテストを行いました。これは、RDMAの複雑性を回避するものです。
これはマイクロンにとって興味深いものでした。なぜなら、スイッチでRDMAを有効化するのは些細なことではないからです。ネットワーク管理が複雑になる条件です。NVMeトランスポートに標準TCPを使用するということは、スイッチに特別な機能や設定が必要なく、図1に示すようにソリューションが簡単にデプロイおよび使用できるということを意味します。この簡素化のトレードオフは、RDMAプロトコル（ネイティブイーサネットを使用）と比較して、TCPプロトコルスタックによって生じる追加のレイテンシーです。
ネットワーク接続されたソリューションの成功は、アプリケーションサーバーにあるローカルストレージを使用した類似の構成との比較した結果に応じます。このテストの目標は、ローカルNVMeデバイスと比較して、Lightbits LightOS NVMe/TCPがクラウドワークロードに発生させるオーバーヘッド（あれば）を判断することでした。
NVMe/TCP用のLightbitsソリューション
Lightbitsのストレージソリューションは、高度なストレージソフトウェアLightOS®とLightfield™ストレージアクセラレーションPCIeアドインカードの組み合わせであり、圧縮、バックエンドオペレーションのオフロード、グローバルフラッシュ変換レイヤー（「グローバルFTL」）の管理を行い、さまざまな相手先商標製造会社が提供する標準x86サーバーにインストールされます。
Lightbitsのストレージソリューションは、データストレージ用のNVMe SSDをホストする1つ以上のノードと、オプションのキャッシング用不揮発性デュアルインラインメモリモジュール（NVDIMM）で構成されます。多くのマイクロンのハードウェアが使用されています。私たちの目標は、Lightbitsがマイクロンの製品を最大限活用しているかをテストすることでした。
通常、ローカルの直接接続PCIeストレージは、ネットワーク接続されたストレージよりも高速ですが、プロトコルがレイテンシーに与える影響はどの程度でしょうか。このテストでは、ローカルNVMeドライブを使用したときの一般的なアプリケーションの動作と、Lightbits LightOSストレージサーバーを通して提供されたボリュームを使用したときの同じアプリケーションの動作を比較しました。ここでは、Yahoo!® Cloud Serving Benchmark（YCSB）を使用してApache® Cassandra®でのパフォーマンスとレイテンシーをテストしました。
テスト構成の詳細
私たちの実証試験では、2つのテスト構成を使用しました。構成1では、Lightbits LightOSのリモートストレージを使用した、4つのスタンドアロンCassandraサーバーが含まれていました。
Lightbits LightOSは、各サーバーのCPUコンプレックスを別々の「ストレージノード」として調整します。2ソケットサーバーは、CPUコンプレックスあたり1つのストレージノードをホストできます。1つのストレージノードをCPUソケット0に割り当ててテストしました。
ストレージノードは、8つの高性能Micron 9300 3.84TB NVMe SSDをホストしました。Lightbitsストレージノードから4.9TBの論理ボリュームを作成し、図2に示すように、各Cassandraデータベースサーバーに1つのボリュームを割り当てました。
4つの負荷生成サーバーは、50Gbイーサネットアダプターを使用してネットワークに接続され、YCSBワークロードAを実行しました。
構成2には、ローカルNVMeを使用した4つのスタンドアロンCassandraサーバーが含まれていました。各Cassandraサーバーは、2つのMicron 9300 3.84TB NVMe SSDをホストし、データをローカルに保存し、100Gbイーサネットネットワークに接続します。4つの負荷生成サーバーは、50GbEを使用してネットワークに接続され、YCSBワークロードAを実行しました。
以下の図3は、テスト構成を示しています。
両方のテスト構成で、1秒あたりの処理件数（OPS）の結果は、4つのCassandraサーバーの合計です。記録されたすべてのレイテンシーの測定は、4つのCassandraサーバーの平均です。
2つのテストで使用されたすべてのサーバー構成は、以下のように構成されていました。
Cassandraデータベースサーバー（4）
- 2つのIntel Xeon Platinum 8168（24コア@2.7GHz）
- 384GBメモリ
- 100Gbps Mellanox ConnectX-4
- Datastax Cassandra v3.0.9
- 2つの3.84TB Micron 9300 Max NVMeドライブ
- ローカルストレージテスト用にLVMソトライプ化ボリュームとして構成
直接接続テスト比較にのみ使用
- ローカルストレージテスト用にLVMソトライプ化ボリュームとして構成
Lightbitsストレージサーバー（1）
- 2つのIntel Xeon Platinum 8168（24コア@2.7GHz）
- 768GBメモリ（128GB NVDIMM、640GB PC2666）
- 100Gbps Mellanox ConnectX-5
- 8つの3.84TB Micron 9300 Max NVMeドライブ
- Lightbitsバージョン1.2.3
負荷生成サーバー（4）
- 2つのIntel Xeon E5-2690v4（14コア@2.6GHz）
- 256GBメモリ
- 50Gbps Mellanox ConnectX-4
- Cassandra圧縮可能データサポートを備えたYCSB v0.16.0
ローカル（4つのCassandraサーバー、各2つのSSD）とリモート（1つのLightbits LightOSノードと8つのSSD）で同数の合計SSDを使用し、パフォーマンスの違いに注目しました。さまざまな固定データベース処理ロードで、平均およびテールレイテンシーを測定しました。
すべてのテストはYCSBワークロードAを使用して実行しました。50%の読み取り、50%の更新ワークロードです。また、データ分散を「uniform」から「Zipfian」に調整し、テスト中のデータセットをより大規模にしました。これにより、メモリにキャッシュされたデータよりもストレージの使用が増加しました。YCSBでパフォーマンスを固定数のOPSに制限した一連のテストを実行し、クオリティオブサービス（QoS）（99.9%）レイテンシー指標の平均を測定しました。テストした各Cassandraデータベースのサイズは、1.39TBでした。
ローカルNVMeテストのCassandraでは、ソフトウェア圧縮を使用しました。通常はオーバーヘッドを生じさせ、パフォーマンスに直接的な影響を与えます。ローカルテストには、ローカルサーバーLVM（論理ボリュームマネージャー）ストライプ化を使用しました。
リモートNVMeテストでは、Cassandraでのソフトウェア圧縮を無効にし、LightbitsストレージサーバーのLightfieldストレージアクセラレーションアドインカードを使用した圧縮を有効にしました。リモートストレージテストでは、Lightbitsソフトウェアが提供するディスクストライピング機能を使用しました。また、Lightbitsは独立した複数のディスクの冗長性配列（RAID）と論理ボリュームのイレイジャーコーディングもサポートしています。これらの機能は、将来のテストで見ていく可能性があります。
テスト結果が示す興味深いレイテンシー
データベースの秒間処理数を増加させるにつれ、Lightbitsとローカルストレージ構成の両方で、平均読み取りレイテンシーの強い相関が確認できました。サーバーあたり60,000というOPS制限で、Lightbitsとローカルストレージ構成の差異が見え始めました。ローカルデータベースが、レイテンシー（線）とOPS（棒）に関して、Lightbits構成に追いつかなくなってきました。制限のないYCSBテスト（右の最後のデータセット）では、平均読み取りレイテンシーと合計OPSの両方で、Lightbitsストレージがローカルストレージ構成よりも測定可能な優位性を示しました。
クラウドワークロードも、優れたQoSレイテンシーを必要とします。以下の図は、99.9% QoSレイテンシー値を示しており、平均レイテンシーと似た結果になっています。ここでも、Lightbits構成の方が高いパフォーマンスを示しました。ローカルストレージの制限なしのQoSレイテンシー差異が28.9msであったのに対し、リモートストレージでは40.7msでした。
平均更新レイテンシーに関して興味深い点は、どちらのテストでも、負荷が増加するにしたがって平均レイテンシーが減少したことです。これは、YCSBの制限メカニズムのしくみによるものでした。LightbitsとローカルNVMe構成の両方について、制限なしの結果（以下の図の最右の棒）はほぼ同等の平均更新レイテンシー（42msと43ms）で、Lightbits構成の合計OPSの方が高くなりました。
更新テールレイテンシー（99.9%）で、両方のテスト構成で負荷の増加に伴い測定レイテンシーは同様に低下しました。これも、パフォーマンスを制限した場合にYCSBが更新レイテンシーを測定する仕組みの影響でした。サーバーあたりのOPSが60,000を超える負荷になっていくと、ここでも99.9%レイテンシーと合計OPSの両方で、Lightbitsのソリューションが測定可能な優位性を示しました。
発見内容のまとめ
Lightbits Labs NVMe/TCPソリューションはテールレイテンシーを低下させ、全体的な性能はCassandra用のローカルNVMeに対し同等または優れていました。ディスアグリゲーテッドストレージは、管理者が適切な容量をアプリケーションに割り当てつつ、プールされたNVMeの大規模なパフォーマンスを活用できるようにするため、Cassandraのようなアプリケーションで合理性があります。
Lightbitsストレージサーバーのセットアップと構成は簡潔であり、テストは1日で実行しました。テストは、Lightbits Labsの支えによって、マイクロンの最速のNVMe SSDを外部ストレージに移動しても、パフォーマンスの優位性を維持できることを示しました。
さらに詳しく知りたい方は
マイクロンは、投資先として検討するほど、LightbitsのNVMe/TCPアプローチを魅力的に捉えました。これらのNVMe/TCP Cassandraの結果について、マイクロンの技術概要の発行を計画しました。入手可能になった際の通知と、最新情報については、Twitter（@MicronTech）のフォローと、LinkedInのつながりをご利用ください。
