RapidCopy2 Matrix I/Oエンジンによるファイルコピーソフトウェアの設計と実装

Transcript

1. RapidCopy2 Matrix I/Oエンジンによる ファイルコピーソフトウェアの設計と実装 Kernel/VM探検隊 ハーフセッション（20分） 澤津 健吾 / RapidCopy研究所
2. 自己紹介 02 澤津健吾 (サワツケンゴ ) RapidCopy研究所 代表 略歴 2005年 (株) 日立INSソフトウェア（現 日立SIS）入社 2011年まで AIX/Linux中心にOLTP製品(OpenTP1/EE)の開発に従事 2011年 レスパスビジョン株式会社に入社 2015年 FastCopy for macOSを「RapidCopy」と命名して開発、販売開始 2015–2025年 システム運用の片手間で映像業界向け支援ツールを多数開発 LTFS運用支援：LTFS Quick Tools / LTFS LE Manager ファイル管理：RapidTree / RapidPack 映像/連番ファイルアセット管理：ShotList 音声QCツール：WavChecker 開発者としてのルーツは UNIX / Linux
3. なぜmacOSにファイルコピーソフトが必要だったのか 大容量映像データ 長いコピー時間 03 コピー後の完全性確認 • 映像業界では数TB級のデータ移動は日常的 • Finderコピーが遅い、不安定なせいで人員が徹夜で画面を見守る • コピー結果が検証できないため、納品データの破損検証が課題に
4. RapidCopy(1)の開発と周辺ツール開発（ 2015年） FastCopy v2.11 (BSDライセンス) macOS向けに 再設計・移植 04 RapidCopyとして 販売開始 コピー以外の業務改善 • 2013頃からFastCopyをmacOSに移植できないか検討開始 • 技術的な目途が立ったところで原作者に連絡/相談 • 自社だけではなく外部にも利用してもらうために販売開始 • その後はコピー以外の周辺課題の改善
5. RapidCopy1が解決したこと 高速(当時は)コピー ベリファイ （ハッシュチェック） 05 ジョブリスト 監査可能なログ macOS上で業務用の監査可能なコピーワークフローを実現。 ただしエンジン構造は、NVMe・100GbE世代を前提にしたものではなかった。 RapidCopy1は「コピーの信頼性」を確保することに成功 RapidCopy2では「現代のディスク性能を使い切る」ための再設計が必要
6. RapidCopy1の課題：性能限界 06 Open(一部並行 )/Write/Verify/Closeはシリアライズされている Readとsrc側のハッシュ計算だけが別スレッドで並行 Open (一部並行 ) Read src Hash src Write Read dst Compare Close Hash dst 並行しているのはハッシュ処理のみ 課題 • ネットワークコピー時、 RTTのせいで大量ファイルコピーが遅い • 巨大ファイル 1本の場合の性能不足、いわゆる Queue Depth(QD)=1
7. 世の中（ハードウェア）の変化 07 CPU多コア化 NVMe Queue Depth 40/100GbE 計算・Hashを 並列化できる 単一要求では 帯域を使い切れない RTTを隠蔽する 並行投入が必要 直線的なコピー処理から、 複数のI/O要求／Hash計算／Verifyを同時に走らせる設計へ再設計が必要
8. RapidCopy2の概要 RapidCopy1の外部仕様 操作性・ワークフローを継承 08 内部コピーエンジン部分を 「Matrix I/O」として全面再設計 現代のNVMe / 高速ネットワークが持つ並列性能を、検証付きコピーでも高速に 操作方法（運用）は変更しない。絶対に変更しない（ここ大事）
9. Matrix I/Oエンジンの全体像 ファイル間並行 :「X」 Inter-File Parallelism 09 ファイル内並列 :「Y」 Intra-File Parallelism 「Matrix I/Oエンジン」 X：複数ファイルの OpenからCloseまでを並行実行 Y：単一ファイルをオフセット単位で仮想的に分割、 I/Oシステムコールを同時発行 Z：Read/Hash/Write/Verifyを独立した段階として重畳実行 処理段階並列 :「Z」 Stage Parallelism
10. Matrix I/O X軸: ファイル間並列 10 OpenからCloseまで、ファイルを独立したレーンに流す File A File B File C File D Open Read Open Open Open Hash Read Write Hash Read Read Verify Write Hash Hash Write Write Close Verify Verify Verify • Open/Read/Write/Closeなどの待ち時間を他ファイルの処理で埋める • 各ファイルレーンの内部で処理内容によっては Y軸／Z軸で並行 (列)処理される（後述） Close Close Close
11. Matrix I/O X軸：ファイル間並行が効く場面 11 映像連番 研究データ 小〜中サイズファイル群 SMB/NAS環境 ファイル処理の往復レイテンシ (RTT)を隠蔽する
12. Matrix I/O Y軸: ファイル内並列アクセス 巨大ファイル C0 ReadWorker 0 ↓ pread(c0) pread(c4) C1 C2 C3 C4 12 C5 ReadWorker 1 ↓ pread(c1) pread(c5) C6 C7 C8… ReadWorker 2 ↓ pread(c2) pread(c6) ReadWorker 3 ↓ pread(c3) pread(c7) 各ReadWorkerがファイル内のオフセットを取得し、それぞれのスレッドで並列に pread()する 図の場合は ReadWorker = 4なので Queue Depth(QD) = 4 一つのファイルをチャンク単位に分割して複数スレッドで処理する 単一巨大ファイルを「複数 I/O要求」に分解、操作粒度を細かくする
13. Matrix I/O Z軸:処理Stage並列 13 • Discoveryがタスクを投入し、専用 Queueでワーカー群を接続することで処理単位粒度を独立させる Discovery Worker Task Queue Read Workers Buffer Pool (チャンク用バッファは事前確保で循環再利用 Write Queues Write Workers ReadHash Queues ReadVerify Workers Verify Queues ) RapidCopy1の「一本の直線」ではなく、複数の Workerが同時協調的に進む構成 WriteVerify Workers
14. Matrix I/O Z軸の課題 :ファイル内並列アクセスとハッシュ処理の相性問題 14 ファイル内並列アクセス (Y軸)ではpread()によるチャンク読み取りの結果受取は順不同。 が、通常のストリーミングハッシュではチャンクの論理順を保証する必要がある ← ← ← ← ← pread()完了順 C3 C0 C2 全体のハッシュ計算のためには並べ替えが必要に・・・ C1 H3 H0 H2 H1 H0 H1 H2 H3 せっかくのファイル内並列アクセスが台無し＆処理Stage並列の妨げに
15. Matrix I/O Z軸の課題解決 :ファイル内並列アクセスとハッシュ処理の独立化 C0 C1 H0 H1 C2 H2 C3 H3 H4 C4 C5 H5 独自Hash値 128bit digest チャンク単位(pread単位) でハッシュ計算(他スレッドと待ち合わせしない) 事前確保済ハッシュ結果配列(H0~H5)にindexベースでチャンク単位ハッシュを格納 全配列にハッシュが入ったところでハッシュ値配列全体を1回だけ再ハッシュ。 独自のハッシュ値として保存する。 ファイル内並列アクセスでもHash計算がI/Oを律速しないように改善 補足1：暗号学的ハッシュは不要なのでCPU負荷低減のためxxhash3(128bit)を採用 捕捉2：MarkleTreeはCPU負荷の観点で非採用(超高速環境だとCPU律速になりえる) 15
16. RapidCopy2プロトタイプの動作結果 (巨大ファイル ) 16 TB3バス利用の NVMe間コピー： RC2プロトタイプは 3.5GiB/sで概ねFinderの1.5倍くらい Finder 2.3GiB/s cp 2.3GiB/s 2.0 GiB/s RapidCopy 3.5GiB/s RapidCopy2 注：「ベリファイ」無効の場合の純粋な「コピーだけ」の転送速度 最低スペックの M4MacMiniにTB3(Max 40Gbps)にGen4NVMeを接続して検証。 Source側デバイスがTB3バス律速の可能性があり、本当はもっと速い？
17. RapidCopy2プロトタイプの動作結果 (連番ファイル 8MiB*3000) 10Gbpsコピー： SMBサーバからの読み取りー＞ローカル NVMeへの書き込み RC2プロトタイプは 0.9GiB/sで概ねFinderの4倍くらい高速化 Finder 0.2 GiB/s cp 0.23 GiB/s RapidCopy 0.3 GiB/s RapidCopy2 0.8 GiB/s 注：「ベリファイ」無効の場合の純粋な「コピーだけ」の転送速度 NICの動作にCPUパワーを30%くらい食われているので、 高性能なMacと40Gbps,100Gbpsだともっと伸びる可能性がありそう？ 17
18. Matrix I/Oでなぜ速くなったのか？まとめ 通信RTT低減(X) 複数ファイル同時並行処理で隠蔽 I/O待ち(Y) 他チャンク /他ファイルを並列に走らせる ハッシュ処理待ち (Z) Hashワーカーへ chunk単位分離して独自ハッシュで高速化 排他削減徹底(W?) BufferPoolの活用と排他関係に Atomic処理を徹底(今回は未解説) 18
19. 今後の課題 19 MatrixI/Oパラメータ自動設定 書込みアルゴリズムの改良 40Gbps/100Gbps実験 プロトコル特有の挙動対応 ユーザ出口関数機能の追加 本家FastCopyとの互換性確保 • 書き込み先が SMBの場合、相手システムによって最適なアルゴリズムが変わる？ことがある？ • 書き込みファイル途中キャンセル時の Resume、Chunk単位ハッシュが有効活用できるかも？ • コピー速度調節アルゴリズムの高度化 • 書き込み先を 1ではなく複数指定可能に（ RapidCopy1時代からある要望）
20. Linuxへの展望 20 • • macOSはカーネル内からサードパーティコードを排除する方針を取っている macOSではI/O経路を観測・改変できる範囲に限界（大事なとこは非公開） • Linuxなら公開されてるし、 io_uringシステムコールがあるな？ Matrix I/O 現在: macOS prototype Linux版RapidCopy2は io_uringで再設計？ 測定・改良・検証？ io_uring page cache / Direct I/O CC/NUMA SMB/NFS File System Specific Pure CLI Ver？ Matrix I/OはLinuxで本領発揮？より進化できるか？ 映像以外の HPC／AI用巨大データセットの汎用転送ソフトウェアとして通用するか？
21. 関連参考資料： 2025/8/19 Kernel/VM探検隊 FastCopy研究所 白水啓章 「Win32 で 50GB/s超コピーを実現するコツ＆そこから見える Windows内部の問題点」 https://www.youtube.com/watch?v=jwPLzsYGLHk&t=515s 22
22. 21 おしまい