Object Storage Service:ローカルデータキャッシュ

背景情報

ossfs 2.0 を使用して OSS にアクセスする場合、ファイルを読み取るたびにリモートからデータを取得する必要があります。AI トレーニングやモデルの読み込みなど、同じデータを複数回繰り返し読み取る必要があるシナリオでは、頻繁なリモートアクセスによりネットワーク遅延の増大と帯域幅の消費が発生します。

ossfs 2.0 のローカルデータキャッシュは、以前に読み取られたファイルデータをローカルディスクに保持するため、後続のアクセスではデータがローカルディスクから直接提供されます。これにより、繰り返し読み取りのパフォーマンスが大幅に向上し、OSS へのリクエストコストが削減されます。

ossfs 2.0 のローカルデータキャッシュには、以下の特徴があります。

• 優れたパフォーマンス：大容量ファイルと小容量ファイルの両方で繰り返し読み取りを行うシナリオにおいて、帯域幅は ossfs 1.0 よりも大幅に向上します。詳細については、後述のパフォーマンス比較をご参照ください。

• 自動エビクション：内蔵の LRU エビクションポリシーにより、キャッシュが満杯になると、手動でクリーンアップすることなく、最も長い間アクセスされていないファイルが自動的に解放されます。

• 大量の小規模ファイルのサポート: メタデータキャッシュ (--max_inode_cache_count および --attr_timeout) と併用することで、AI トレーニングデータセットの複数回にわたる読み込みを大幅に高速化できます。

仕組み

キャッシュの粒度

キャッシュは OSS オブジェクト (ファイル) を基本単位とします。読み取られた各ファイルはキャッシュディレクトリ内のキャッシュファイルに対応し、キャッシュは必要に応じて書き込まれます。

読み取りプロセス

• 初回読み取り：データは OSS から取得され、ローカルのキャッシュディレクトリに同期的に書き込まれます。

• 後続の読み取り：データはローカルキャッシュから直接読み取られます。

領域解放

キャッシュが容量制限に近づくと、LRU (Least Recently Used) ポリシーに基づいて古いファイルが自動的にエビクションされ、新しいデータ用の領域が解放されます。解放は、単一のキャッシュファイルを最小単位として実行されます。

設定方法

制限事項：

• --disk_data_cache_dir で指定するディレクトリは、既存の空のディレクトリである必要があります。キャッシュパスは独立したパーティションまたは独立したディスク上に配置することを推奨します。

• --disk_data_cache_size は、キャッシュディレクトリが存在するディスクの利用可能な領域を超えることはできません。

• 同じマシンに複数の ossfs2 インスタンスをマウントする場合、各インスタンスは独立したキャッシュディレクトリを使用する必要があります。

• ossfs2 プロセスが終了しても、キャッシュディレクトリは自動的にクリーンアップされないため、手動でクリーンアップする必要があります。

• マウント後、予期せぬエラーを防ぐため、キャッシュディレクトリパスに対する操作は避けてください。

マウントコマンドの例：

ossfs2 mount /mnt/oss/ \
  --oss_bucket <your-bucket> \
  --oss_endpoint <your-endpoint> \
  --oss_access_key_id <ak> \
  --oss_access_key_secret <sk> \
  --disk_data_cache_dir /mnt/disk/ossfs2/cache \
  --disk_data_cache_size 256G

環境要件

利用の推奨事項

ローカルデータキャッシュは、読み取りが多く書き込みが少なく、同じデータへの繰り返しアクセスが必要なシナリオに適しています。

IO エンジン (disk_data_cache_io_engine) の設定に関する推奨事項：

• psync：同期読み取り/書き込みシステムコールを使用し、読み取り時にデータはオペレーティングシステムのページキャッシュを通過します。キャッシュされたデータ量が利用可能なメモリに近いかそれより小さい場合、ホットデータは自然にページキャッシュに保持され、メモリ速度に近い読み取り速度を実現します。これは、汎用的なシナリオ、低スペックのクラウドディスク、および tmpfs キャッシュディスク (tmpfs は libaio をサポートしていません) に適しています。

• libaio：Linux の非同期 IO インターフェースを使用し、ページキャッシュをバイパスしてディスクを直接操作します。これは、大容量のローカル NVMe を使用し、データセットがメモリよりはるかに大きいシナリオに適しており、通常、psync と比較して約 20% のパフォーマンス向上が得られます。

以下の表は、典型的なシナリオと推奨される設定をまとめたものです。

パフォーマンス比較

テスト対象：ossfs 2.0.8 と ossfs 1.91.10。表内の「初回読み取り/後続読み取り」は、それぞれキャッシュミス (データを OSS から取得する必要がある) とローカルキャッシュヒットに対応します。「—」は、その設定にキャッシュがなく、初回と後続の読み取りを区別しないことを示します。

シナリオ 1：大容量ファイルのシーケンシャル読み取り (4 スレッドで 100 GB のファイルを読み取り)

テスト環境

• マシン：ecs.i4.4xlarge (16 vCPU、128 GiB)

• ローカル NVMe ディスク：3576 GiB NVMe (読み取り帯域幅 6 GB/s、書き込み帯域幅 3 GB/s、IOPS 900,000)

• ossfs 2.0：--disk_data_cache_dir=<path> --disk_data_cache_size=3T

• ossfs 1.0：-ouse_cache=<path> -oparallel_count=128

結果

結論：

• キャッシュを有効にした後、大容量ファイルの後続読み取りシナリオにおいて、ossfs 2.0 は ossfs 1.0 の約 2.2 倍のパフォーマンスを発揮し (libaio モード：5947 vs 2648 MB/s) 、ローカル NVMe のパフォーマンス上限に達します。一方、CPU 使用率は大幅に削減されます (約 250% vs 800%) 。

シナリオ 2：大量の小容量ファイルの読み取り (ImageNet トレーニングデータセットの読み込み)

テスト環境

• マシン：ecs.i4.32xlarge (128 vCPU、1024 GiB)

• ローカル NVMe ディスク：8 × 3576 GiB NVMe

• データセット：ImageNet トレーニングセット (約 130 万画像) 、複数エポックにわたって繰り返し読み込み

• ossfs 2.0：--disk_data_cache_dir=<path> --disk_data_cache_size=1500G --disk_data_cache_io_engine=libaio --attr_timeout=36000 --max_inode_cache_count=11000000 (メタデータキャッシュを有効化)

• ossfs 1.0：-ouse_cache=<path> -oreaddir_optimize -omax_stat_cache_size=11000000 -ostat_cache_expire=72000

結果

結論：

• ディスクキャッシュとメタデータキャッシュを有効にすると、後続のエポックでの ossfs 2.0 の読み込みパフォーマンスは初回読み取りの 2.7 倍に達し (895 vs 329 MB/s) 、OSS へのネットワークリクエストは完全になくなります。同じデータセットを複数ラウンドで繰り返し読み込む AI トレーニングのワークロードには、ossfs 2.0 のローカルデータキャッシュ (libaio エンジン) とメタデータキャッシュの併用を強く推奨します。