Apache Cassandra™は、世界中で膨大な量のデータを格納するNoSQLデータベースです。1 私のチームは最近、Micron 6500 IONを使用してCassandraのテストを行い、競合他社のQLCドライブとパフォーマンスを比較しました。その結果は、最近公表された技術概要でご覧いただけます。
Cassandraのテストには、eBPF2ベースのLinux NVMeトレーシングツールを使用し、ワークロードの入出力(IO)パターンがディスクにどのように到達するかを詳しく調べました。その結果には、洞察に富む発見がありました。
平均パフォーマンス
アプリケーションをベンチマークツールでテストする際、結果は通常、テスト期間全体の主要業績評価指標(KPI)の平均で示されます。これは、システムのスケーリングとパフォーマンスを広い視点から把握するのには有用ですが、実際のところ全体像が分かるわけではありません。得られた結果の例を示しましょう。この結果は、YCSBスレッド数をスケーリングする一連のテストにおいて、素晴らしいパフォーマンスブーストとサービス品質(QoS)レイテンシー3の低減を示しています。データポイントは、8、16、32、64、128のYCSBスレッドで20分間のテストを4回実行した際の平均パフォーマンスを表しています。
しかし、iostatのような標準的なLinuxツールを使用して平均ディスクスループットを確認すると、非常に低いパフォーマンスが確認できます。
YCSBスレッドが32の場合、Micron 6500 IONを使用したテストで読み取り平均は357MB/秒、書き込みは136MB/秒となっています。NVMe SSDsはそれよりも高速なはずです。一体何が起きているのでしょうか?
一体何が起きているのでしょうか? YCSB 50% 読み取り / 50% 更新(32スレッド時)
ワークロードのトレースから、私たちはストレージデバイスアクティビティのサマリーを取得しました。そこから、20分間の実行時間におけるストレージ集約型ワークロードの様子が分かります。
Cassandra、YCSB 50% 読み取り / 50% 更新 |
6500 ION |
100% 4KB |
|
総読み取りGB数 |
680GB |
書き込みブロックサイズ |
74% 508KB~512KB |
総書き込みGB数 |
255GB |
破棄したブロックサイズ |
80% > 2GB |
総破棄GB数 |
69GB |
IO数における読み取り割合 |
99.6% |
量における読み取り割合 |
68% |
IO数における書き込み割合 |
0.4 |
量における書き込み割合 |
25% |
IO数における破棄割合 |
0% |
量における破棄割合 |
7% |
ブロックサイズ
ワークロードのIOサイズ(ブロックサイズ)は、そのパフォーマンスに劇的な影響を与えます。ここでは、4KBの読み取りが100%で、書き込みは主に508KBと512KBであり、さらに小さな書き込みが多く散在していることが分かります。
スループット
時系列データからは、読み取りが最大518MB/秒、平均357MB/秒に達していることが示されており、読み取りが安定していることが分かります。平均スループットは91,000入出力操作毎秒(IOPs)で、NVMeドライブなら容易に処理できる範囲です。
書き込みでは興味深い結果が得られました。最大5.6GB/秒のスパイクが見られ、6500 IONの最大シーケンシャルパフォーマンスに近い値です。Cassandraの書き込みワークロードは、バースト性が高いです。主な理由は、メモリ内の更新をディスクにファイル移動し、可能な限り高速に書き込みを行うMemtableフラッシュコマンドです。その結果、2GB/秒~5.6GB/秒というバースト書き込みと平均スループットの136MB/秒の間に大きな差が生じています。
レイテンシー
レイテンシーに目を向けると、読み取りで最大40ミリ秒、書き込みで約90ミリ秒のビークが観察されます。書き込みの結果は、定期的に大きなIO(512KB)でバーストが多数発生していることを考えると理解できます。読み取りはすべて4KBであるため、何らかのブロッキングが発生して読み取りレイテンシーがスパイクしています。
これらのレイテンシーは、SSDの観点から見ると懸念すべき点となるため、ファームウェア内のOCPレイテンシーモニターログを分析したところ、システムレベルのレイテンシーであることが分かりました。Memtableフラッシュコマンド中にキューが急速に満たされ、システムに負荷が掛かっています。しかし、このワークロード中、SSDでは異常なレイテンシー(>5ミリ秒)は報告されていません。
キュー深度
最後に、システムで観測されたキュー深度には興味深い周期性がありました。20~200の間で変動し、時折QD800まで大きくスパイクしています。
この挙動は、大量のブロック書き込みによって生じるレイテンシーの影響と一致しています。Memtableフラッシュコマンドはディスクに大量のデータを書き込むため、キュー深度が増大します。この高いキュー深度により、一部の4KB読み取りIOが遅延し、システムレベルでレイテンシースパイクを引き起こす可能性があります。Memtableフラッシュ操作が完了すると、Cassandraは削除されたデータを一掃するために破棄コマンドを出します。
学んだことをまとめてみましょう。
平均アプリケーションスループット、レイテンシー、ディスクIOは、SSDの性能を他のSSDと比較したり、主要なハードウェアやソフトウェアの変更によるパフォーマンスへの影響を測定したりする際に適切な視点を提供します。
Cassandraのようなアプリケーションは、平均ディスクIOを分析するには、iostatのようなツールで低い平均スループットが観測されるため、ストレージパフォーマンスに対して鈍感に見える場合があります。しかし、それでは高いキュー深度で大量のブロックデータを可能な限り高速に書き込むSSDの能力が、Cassandraのパフォーマンスに不可欠であるという重要な事実を見逃してしまいます。ディスクレベルでワークロードを真に理解するためには、平均値を超えて掘り下げる必要があるのです。
- Apache Cassandraの詳しい情報は、https://cassandra.apache.org/_/index.htmlをご覧ください。
- eBPFの詳しい情報は、https://ebpf.io/what-is-ebpf/をご覧ください。
- サービス品質(QoS)は、レイテンシーの一貫性を表す一般的な指標です。SNIAディクショナリー:https://www.snia.org/education/online-dictionary/term/qos
© 2023 Micron Technology, Inc. All rights reserved. ここに掲載されるすべての情報は何らの保証なく「現状有姿」の状態で提供されます。マイクロンは、製品がマイクロンの生産データシートの仕様を満たしていることのみを保証します。製品、プログラム、仕様は予告なく変更される場合があります。Micron Technology, Inc.は、印刷や写真における誤記や脱落について一切の責任を負いません。マイクロン、マイクロンのロゴ、およびその他のすべてのマイクロンの商標はMicron Technology, Inc.に帰属します。他のすべての商標はそれぞれの所有者に帰属します。Rev. A 01/2023 CCM004-676576390-11635