bcacheとdm-cacheの比較:Linux SSDキャッシングの比較
11分で読めます - 2026年5月28日

LinuxのSSDキャッシングについて、bcacheとdm-cacheを比較する。セットアップ、パフォーマンス、キャッシング・モード、それぞれを使用するタイミングなど。
bcacheの仕組み
bcacheは、バージョン3.10(2013年6月)以降、Linuxカーネルに組み込まれています。ブロックレイヤーで動作するため、UUIDをサポートするあらゆるファイルシステムで利用可能です。
内部的には、bcacheはハイブリッドなB+木/ログ構造を採用しています。SSDストレージを、消去ブロック境界にアラインされた固定サイズのバケット(128KB~2MB)に分割します。これにより、ランダム書き込みがシーケンシャル書き込みに変換され、書き込み増幅が低減され、SSDの寿命が延びます。4MBを超えるシーケンシャルI/O操作は自動的にキャッシュをバイパスし、SSDが最大の価値を発揮するランダムアクセスパターンに集中できるようにします。
また、bcacheはSSDのレイテンシをリアルタイムで監視します。読み取りレイテンシが2msを超えたり、書き込みレイテンシが20msを超えたりした場合、キャッシュデバイスがボトルネックになるのを防ぐためにトラフィックを制限します。
セットアップ
インストール bcache-toolsを実行し、バッキングデバイスとキャッシュデバイスをフォーマットします:
make-bcache -B /dev/sdb # format HDD as backing device
make-bcache -C /dev/sdc # format SSD as cache device
echo <UUID> > /sys/block/bcache0/bcache/attach # attach cache実行時のチューニングは /sys/block/bcache<N>/bcache/ sysfsインターフェースを通じて行われ、そこでキャッシュモード、シーケンシャルI/Oのしきい値、およびレイテンシ目標値を調整できます。RAIDアレイの場合は、 --data-offset を使用してストライプ幅に合わせて配置してください。
注意点:セットアップは破壊的です。両方のデバイスを bcache ターゲットとしてフォーマットする必要があるため、既存のファイルシステムに bcache を追加するには、まずそのファイルシステムを消去する必要があります。また、bcache デバイスは作成後にサイズ変更できません。
パフォーマンス
Bcacheの書き込み統合機能により、ランダム書き込み性能が大幅に向上します。ベンチマークでは、単体の生SSDが12,200 IOPSであるのに対し、Bcacheは約18,500 IOPSのランダム4K書き込みIOPSを達成しています。適切なハードウェア環境下では、ランダム読み取りスループットは約1,000,000 IOPSに達します。
暗号化ワークロードの場合、基盤となるドライブを個別に暗号化するのではなく、 /dev/bcache<N> デバイス上にdm-cryptレイヤーを適用することを推奨します。これにより、Bcacheが暗号化前に書き込みを統合できるため、通常はパフォーマンスが向上します。
dm-cacheの仕組み
dm-cacheは、既存の論理ボリュームの上に配置されるDevice Mapperターゲットです。これは、3つのサブデバイスを使用します。すなわち、オリジンデバイス(HDD)、キャッシュデバイス(SSDまたはNVMe)、およびブロックの位置やダーティ状態を追跡するメタデータデバイスです。デフォルトのキャッシュポリシーはsmq(Stochastic Multi-Queue)であり、混合ワークロードにおいてホットデータを特定します。
主な利点:dm-cacheは、既存のデータを破壊することなく、稼働中のLVMボリューム上に重ねて適用できます。また、標準のLVMコマンドを使用してサイズ変更を行うことも可能です。
LVM を使用した設定
dm-cache を実用的に設定するには、 lvmcacheです。手動 dmsetup 設定も可能ですが、ミスが発生しやすく、再起動後も設定が維持されません。LVM によるアプローチ:
- HDDとSSDの両方に物理ボリューム(PV)を作成します。
- 両方のPVを単一のボリュームグループ(VG)に追加します。
- 3つの論理ボリュームを作成します。1つはデータ用(HDD)、1つはキャッシュ用(SSD)、もう1つはメタデータ用(SSD)です。
- キャッシュ用とメタデータ用の LV をキャッシュプールに結合します:
lvconvert --type cache-pool --poolmetadata <meta_lv> <cache_lv> - プールをオリジンにアタッチします:
lvconvert --type cache --cachepool <pool_lv> <data_lv>
注意点:ファイルシステムは /dev/mapper/ パスを使用してマウントしてください。UUIDによるマウントでは、キャッシュ層をバイパスしてオリジンデバイスに直接アクセスしてしまう可能性があります。
パフォーマンスとメモリ
書き込みバックモードにおいて、読み書き比90:10のジップフ分布ワークロード下で、dm-cacheは約193 MB/sの読み取り速度と約21 MB/sの書き込み速度を達成しました。別のベンチマークでは、100 GBのHDDを10 GBのNVMeパーティションでキャッシュすることで、ランダム書き込みIOPSが118から798に増加しました。
その代償となるのがメモリです。dm-cacheのメタデータオーバーヘッドはブロックサイズに依存します。512バイトのブロックサイズの場合、キャッシュ100GBあたり16GB以上のRAMを消費する可能性があります。これを4,096バイトに増やすと、メモリ使用量は100GBあたり約2GBに減少します。 平均I/Oサイズに近いブロックサイズを選択し(64 KBが妥当な出発点です)、32 KBから1 GBの範囲内で、64セクタ(32 KB)の倍数であることを確認してください。
メタデータは、FLUSHまたはFUAによる書き込みが行われるたびに、あるいは少なくとも1秒に1回フラッシュされます。高可用性を確保するため、単一障害点を回避するよう、メタデータデバイスをミラーリングしてください。
キャッシュモード
bcache と dm-cache は、どちらも同じ中核となるキャッシュモードをサポートしています。選択は、パフォーマンスとデータの安全性の両方に影響します。
| モード | 動作原理 | 速度 | リスク |
|---|---|---|---|
| ライトスルー | 書き込みはSSDとHDDの両方に同時に行われる | 読み込みブーストのみ | 低。HDDには常に最新のデータが保存されている。 |
| ライトバック | 書き込みはまずSSDに行われ、後でHDDにフラッシュされる | 読み取りと書き込みのブースト | 高。フラッシュ前にSSDが故障するとデータが失われる。 |
| 書き込みバイパス/パススルー | 書き込みはキャッシュを完全にバイパスする | 読み取り性能のみ向上、SSDの摩耗を低減 | 低。HDDには常に最新のデータが保持される。 |
両ツールにおいて、Writethroughが安全なデフォルト設定です。Writebackは高速ですが、重大なリスクを伴います。フラッシュされていないデータを保持している最中にSSDが故障した場合、そのデータは失われ、ファイルシステムが破損する可能性があります。Writebackは、冗長化されたSSDがある場合、または時折のデータ損失を許容できる場合にのみ使用してください。
bcache 対 dm-cache:どちらを使うべきか
| 要因 | bcache | dm-cache |
|---|---|---|
| 既存データへの設定 | 破壊的(ワイプが必要) | 非破壊的(オンライン変換) |
| リサイズ | 非対応 | LVM経由で対応 |
| ランダム書き込みの最適化 | 高 (順次書き込みの統合) | 標準 |
| シーケンシャルI/Oバイパス | 自動(4MB以上) | smqポリシーによる管理 |
| メモリオーバーヘッド | 低 (B+木) | 高い(ブロックサイズに依存) |
| メタデータ | キャッシュデバイス上 | 別デバイス、ミラーリング可能 |
システムをゼロから構築し、可能な限り最高のランダムI/Oパフォーマンスを求める場合は、bcacheを使用してください。これは、データベースやVMストレージのような書き込み中心のワークロードや、ランダム書き込みのパフォーマンス低下が深刻なRAID 6アレイにおいて、より適した選択肢です。
既に稼働中のサーバーにキャッシュ機能を追加する必要がある場合は、dm-cacheを使用してください。LVMとの統合により、ダウンタイムやデータ移行なしにキャッシュをアタッチできます。これは、読み込みが中心のワークロードや、ストレージのサイズ変更や再構成をオンザフライで行う柔軟性が必要な環境に適しています。
結論
どちらのツールも同じ問題を解決しますが、適した状況は異なります。Bcacheは新規構築におけるパフォーマンス重視の選択肢です。dm-cacheは既存のLVMシステムにおける実用的な選択肢です。どちらを選択する場合でも、SSDの信頼性に確信が持てるまではwritethroughモードから始め、書き込みパフォーマンスが必要な場合はwritebackモードに切り替えてください。
SSDキャッシュ構成の専用サーバーが必要な場合は、FDCの専用サーバーオプションをご検討ください。
Linuxパケット処理のためのXDPとeBPF
XDPとeBPFがNICドライバレベルで毎秒数百万のパケットをどのように処理するか。ベンチマーク、DDoSユースケース、ツールチェーンのセットアップ、ハードウェア要件。
14分で読めます - 2026年5月27日
パワフルで無制限のVPSが重要な理由
3分で読めます - 2025年5月9日

ご質問またはカスタムソリューションが必要ですか?
柔軟なオプション
グローバル・リーチ
即時展開
柔軟なオプション
グローバル・リーチ
即時展開