KuriKumaChan’s diary

Kuri ちゃんと Kuma ちゃんの飼い主の独り言

写真ファイルの管理用 NAS には 10GbE/HDD より 2.5GbE/SSD の方が快適? - (5) 実測!ベンチマーク

TBS-464 に対して一通りクライアントである Mac から自由にアクセスできるようになったので、Mac で利用できるベンチマークソフトの AmorphousDiskMark で測定してみました。
もともと今回の TBS-464 購入のきっかけは、ChatGPT に
🎯 結論:TBS-464(SSD)の方が Lightroom には向いている
と指摘されたことがきっかけなので、果たしで私の環境で ai の言う通りになるのか?の検証をベンチマークソフトで行ってみました。
最終的には私が実際に体感していた Lightroom を用いて同じデータをそれぞれの NAS において比較しようと思いますが、まだ Lightroom を含めた環境を決めきれていないのでお手軽に数値化できるベンチマークアプリで比較します。

測定対象は過去に 10GbE を導入した際に誇らしげに?掲げていた "MB/s(転送速度)" に加えて、ai が「画像ファイルへのアクセスくらいだったらこちらが重要!」とおっしゃる "IOPS(IO性能)" も測定してみた、というお話です。

そもそもの ChatGPT の指摘内容は

ai に冷や水を浴びせられた指摘を再確認しておきます。
私の Lightroom classic の環境は、カタログは Mac ローカルに置いて、画像ファイルのみ NAS におく前提の話です。 以下のようのに私が誇る?10GbE 接続の TS-453Be より TBS-464 が良い!とハッキリと言われたのです。

ChatGPT の内容を一旦 Craft に貼り付けた画像です

写真ファイルの管理用 NAS には 10GbE/HDD より 2.5GbE/SSD の方が快適? (2) 次期 NAS を ai に相談したら冷や水を浴びせられた - KuriKumaChan’s diary

ネットワーク環境

Hub-1,2 は、BUFFALO の LXW-10G2/2G4 で、10GbE x2 + 2.5GbE x4 の6ポート構成。10GbE は "Hub 間のケーブル"、および "Hub-1 - TS-453Be", "Hub-2 - Mac" の接続で使っているので 10GbE はもう空いていません。幸い残りのポートが 2.5GbE なので Hub-1 の空きポートに TBS-464 を接続します。 Mac は10,000円のオプションで 10GbE を追加した M2 Mac mini です。

上記 2台の NAS を下図のように接続

nano banana に描いてもらいました。修正も楽チンだし超便利!

blog0.kurikumachan.com

測定対象

上記の環境で、以前測定していた "MB/s" に加えて今回は "IOPS" も測定してみます。ベンチマークアプリのウィンド右上でそれぞれを切り替えることができるのはなんとなく知っていましたが、「転送速度こそ命!」くらいにしか思っていなかった私は "MB/s" しかチェックしていませんでした。

"MB/s" とは

転送(可能)速度 "Mega Byte per second" なので分かりやすいです。土管の太さで、帯域などとも呼ばれていますので馴染みのある方は多いと思います。

"IOPS" とは

直接的には "Input Output per second" なので一定時間に何回の input (read) 操作もしくは outout (write) 操作ができるか?と言うことで、下記の ai の説明を読んでもふーんと言う感じです。

chatGPT のチャットを Craft に貼り付けたもの

測定結果

実際のベンチマーク結果は下の《参考情報》に貼っておきますが、ChatGPT に数値を表にまとめてもらったのでそれで説明します。
なお、NAS のモデル名の後のカッコに記載されているものはテスト実施時の共有ドライブ名です。テスト時は TBS-464 にテストように作成した共有ドライブ名が MM でそれをマウントしてテストしたのでこのようになっています。

転送速度 "MB/s"

デカイファイルの読み込みでは 10GbE/HDD の勝ち - 倍以上の転送量

連続したデータ (1MB) の読み込みだけは 10GbE/HDD の圧勝です。2.5GbE/SSD の倍以上のパフォーマンスです。
10GbE/HDD のケースを単純に計算すると "671.19 MB/s" は "5.4G bps" なので、10 GbE のネットワークをそこそこ使っているので、各種オーバーヘッドも考えるとネットワークが 1GbE や 2.5GbE の環境ではここまでの数字は出ないでしょう。
一方の 2.5GbE/SSD の "296.49 MB/s" は 単純計算で "2.4G bps" なので、2.5GbE の帯域をほぼほぼ使い切っていて、より高速のネットワークであればさらに速くなりそうです

ランダムなデータ (4KB) の読み込み、および書き込みは連続でもランダムでも 2.5GbE/SSD の圧勝です。というか、HDD では全く歯が立たないことが分かります。

IO性能 "IOPS"

IOPS でも連続読み込みでは 10GbE/HDD が勝ったが

一方の IOPS でも数値の傾向としては "MB/s" と似た結果になりました。連続データの read のみ 10GbE/HDD の方が多くの read を捌いていて、1秒に 640回の read 命令を処理できています。(QD8)
しかしこの後のまとめで ChatGPT も取り上げていますが、
"RND4K QD64 Read : 70,402.3 IPOS"
と言う数値にはびっくりします。1秒間に 70万回の read 命令を処理している!と言うことです。もちろん HDD でも 20万回近くの処理をしているのですからこれもすごい。ちょっと現実感が無いのでこの表の見方を《参考情報》に貼っておきますので興味のある方はご覧ください。あまり興味のない方向けに一言だけ説明すると、"QD64" と言うことは、

"キュー深度64" 4KB 単位のランダムなデータ位置を、64個並列でアクセス。高負荷サーバーや複数タブ開いたりなど「同時にたくさんアクセスされる状況」を模擬

と言うテスト負荷状況とのこと。HDD も QD1 に比べて 12倍以上になっていますが、SDD だと QD1 に比べて 20倍以上になっているので、確かにランダムアクセスでは SDD に分があるようです。
特に HDD では ランダム write の QD64 は QD1 より劣っていますので、HDD の場合はあまりキュー深度を大きくするのは効率的ではないようです。

まとめ by ChatGPT 実行比較

ChatGPTのまとめを Ctaft に貼り付けた画像

よって Lightroom Classic の実作業には TBS-464 が最適。

ここまで明確に言い切ってくれるとそこそこの投資をしているので期待が高まります!

だけど Lightroom 環境で本当に TBS-464 が早いのか?

ただし今回のベンチマークだけで Lightroom で写真データを扱ったときも TBS-464 の方が早い、と言い切れるでしょうか?このベンチマークでは QD8 の連続読み込みでは TS-453Be は TBS-464 の帯域 (2.5GbE) の倍の 5Gb 以上の転送ができています。しかも写真ファイルは数MB〜二桁MB の大きさですから、ベンチマークの項目としては 4K のような小さなランダム読み込みはあまりないので意外とそうは差が出ないのでは?という気がします。

期待は高まりましてが、Lightroom でのパフォーマンス検証を行う前に、まずは TBS-464 を実際に Lightroom で利用できる環境作りを整えていきたいと思います。

《参考情報》

ベンチマーク結果:転送速度 "MB/s"

転送速度:TBS-464(MM)

転送速度:TS-453Be(Pro5300)

ベンチマーク 結果:IO性能 "IOPS"

IO性能:TS-453Be(Pro5300)
IO性能:TBS-464(MM)

ベンチマークアプリの表示の見方 by ChatGPT

以下の質問を ChatGPT にした結果です。
「結果画像で、縦に SEQ1M QD8, SEQ1M QD1, RAND4K QD64, RAND4K QD1 とあるのは何を示しているの? 上部のリストで 1GiB と選択しているサイズと関係ないの?」

とても良い質問です!AmorphousDiskMark や CrystalDiskMark などのディスクベンチマークソフトで表示される SEQ1M QD8 RND4K QD64 などの項目は、それぞれ アクセスパターンの種類と条件を示しており、上部の 1 GiB のような テストサイズとは意味が異なります。


✅ 各項目の意味(左側の項目)

項目 読み方 意味
SEQ1M QD8 シーケンシャル1MB、キュー深度8 1MB 単位の連続したデータを、同時に8個まで処理(並列処理)。大きなファイル転送(動画、RAWなど)向きのベンチマーク
SEQ1M QD1 シーケンシャル1MB、キュー深度1 同上だが、1つずつ順番に処理(非並列)。現実的な1ファイル転送に近い
RND4K QD64 ランダム4KB、キュー深度64 4KB 単位のランダムなデータ位置を、64個並列でアクセス。高負荷サーバーや複数タブ開いたりなど「同時にたくさんアクセスされる状況」を模擬
RND4K QD1 ランダム4KB、キュー深度1 4KB 単位のランダムアクセスを、1つずつ順番に処理。最もシンプルかつ現実に近い「1ファイルずつアクセスする」パターン

✅ テストサイズ(上部の1 GiB

これは「それぞれのテスト項目を何MBぶん実行するか」という設定です。

  • 1 GiB を選んだ場合:各項目(SEQ/RNDそれぞれ)について 1GB 相当の読み書きをテストします。
  • つまり、縦の項目は「アクセスの種類」, 上部のサイズは「それをどのくらいの量で測定するか」を意味します。

🧪 図解イメージ

テストサイズ: 1GiB   → 各テストごとに1GBぶん測る

  ↓ アクセスパターン(操作の種類)
+------------------------+----------------------+
| SEQ1M QD8              | 高速・並列な連続読み書き  |
| SEQ1M QD1              | 単発・現実的な連続読み書き|
| RND4K QD64             | 高並列・ランダム小データ  |
| RND4K QD1              | 単発・ランダム小データ     |
+------------------------+----------------------+

💡 Lightroomの例でいうと…

操作 該当項目 備考
大量のRAW画像を一括読み込み SEQ1M QD1 / QD8 シーケンシャルアクセス
サムネイル表示や個別切替 RND4K QD1 ランダム小ファイルアクセス
書き出し時のバッチ処理 SEQ1M QD8 / RND4K QD64 並列化が効く

📝 補足:QD = Queue Depth(キューの深さ)とは?

  • 同時にどれだけの読み書き要求を送るかを示す数字。
  • QD1:ひとつずつ順番に → 実環境に近い
  • QD64:64個を並列処理 → 高負荷サーバーやベンチマーク的な限界テスト

✅ まとめ

要素 意味
SEQ vs RND 連続データ vs ランダムな小さいデータ
1M vs 4K 1MB単位の大きなブロック vs 4KBの細かいブロック
QD8 vs QD1 同時アクセス数の違い(並列 vs 単発)
上部の 1GiB 各テストで使うデータの総量(測定時間や精度に影響)