レイテンシーは、ストレージのパフォーマンスを特徴づける上で最も重要な指標の1つで、ストレージデバイスがデータ要求に応答するまでにかかる時間を指します。レイテンシーが低いとデータに迅速にアクセスできるため、アプリケーションのパフォーマンスに大きな影響を与え、ユーザーエクスペリエンスを改善します。レイテンシーに影響を与える要因には、さまざまなハードウェアコンポーネント、ネットワークスタック、ワークロード特性、ストレージアーキテクチャー、ソフトウェアスタックなどがあります。
RocksDBは、Metaの多くのオペレーションのバックボーンとなる、ストレージに重点を置いたキーバリュー型データベースです。RocksDB.orgでは次のように説明しています。
「RocksDBはLevelDBをベースに構築されており、スケーラブルで多数のCPUコアを持つサーバー上で実行することが可能で、高速ストレージを効率的に使用し、IOバウンド、インメモリ、ライトワンスワークロードに対応し、イノベーションを実現する柔軟性を備えています」
Yahoo! Cloud Serving Benchmark（YCSB）プロジェクトの目標は、さまざまな「キーバリュー」ストアと「クラウド」ストアのパフォーマンスを評価するためのフレームワークと共通ワークロードセットを開発することです。このプロジェクトを構成しているのは、主に以下の2つのコンポーネントです。
- YCSBクライアント：拡張可能なワークロード生成ツール
- コアワークロード：生成ツールで実行される一連のワークロードシナリオ
RocksDBのYCSB読み取り負荷の高いワークロードを実行している間に、何度もレイテンシーの大きなスパイクが発生しました。読み取りレイテンシーは（以前の実行結果と一致する）5ミリ秒未満と予想していましたが、連続して実行したところ、約113ミリ秒という大きなレイテンシーが発生しました。この問題をエミュレートするために私たちはFIOを使用し、再現に成功しました。FIOで観測された最大レイテンシーは18ミリ秒で、RocksDBで観測されたレイテンシーとは異なりますが、やはり予想した値よりも大きな値です。
FIOの場合、私たちはジョブファイルのトランザクションログを調べて、一定の時間、何も発生していないことを確認しました。これは、レイテンシーが発生しているのと同じことです。ただし、NVMe™ドライバー層に目を向けると、18ミリ秒に近いレイテンシーのトランザクションは存在しないため、レイテンシーの原因はアプリケーションにあることがわかります。
レイテンシーの異常はドライブの問題ではなく、おそらくはその上の層の動作によるものでしょう。
- FIOのようなシンプルなツールでも、システムに影響を受けて高いレイテンシーが報告されることがある。
- システムのノイズがFIOの最大レイテンシーについての報告に影響を与えることがある。
- QoSレイテンシーは7x9までは一定であるように見える。
113ミリ秒というRocksDBのレイテンシーは、bpftraceスクリプトで測定したブロック層で発生しました。bpftraceは、ユーザーがシステム実行時のさまざまな要素をトレースし、プロファイルできるLinux用のトレーシングフレームワークです。私たちが参考にしたのは、各ストレージデバイスのI/Oの詳細をレイテンシーとともに出力して時間順のパターンを調べる、ブレンダン・グレッグ氏のパフォーマンスツールのBIOスヌープスクリプトです。
スクリプトで使用するkprobe（カーネルプローブ）は、Linuxカーネルの動的トレーシングメカニズムです。これを使うことで、ユーザーはほぼすべてのカーネル関数にブレークポイントを挿入し、ハンドラーを呼び出して実行を継続できるようになります。
私たちは根本原因をデバッグするために、さまざまな統計情報を収集して、高いレイテンシーがどこから生じているのかを把握しました。
- IO統計情報
- デバイスとパーティションのシステム入出力統計情報
- カーネル層での測定
- バスアナライザー - PCIeバス上で送信されるデータを収集して分析する
- 個々のトランザクション情報 - トランザクションタイプ、アドレス、データペイロードなど
- 信号タイミングを表示する
- Open Compute Project（OCP）レイテンシー監視
- ハードウェア層とファームウェア層で測定
結論として、観測された高いレイテンシーはシステムスタックで生じています。カーネル層、PCIeバス、ハードウェア・ファームウェア層のいずれのレイテンシーも、ワークロードトレースで発生したレイテンシースパイクに近いものではないためです。
