NetDriveでS3ディレクトリ一覧表示が遅い問題を解決
NetDriveで大規模なAmazon S3バケットをマウントした際のファイル一覧表示の遅延を診断し解決します。S3 API制限、NetDriveのキャッシュ設定、バケット構造のベストプラクティスを解説。
あるバックエンドチームは、CIフィクスチャパイプライン用にAmazon S3バケットをNetDrive経由でWindowsのドライブレターとしてマウントしていた。数か月間は問題なく動作していたが、あるリファクタリングで単一のS3プレフィックス配下に4万件の新しいテストフィクスチャオブジェクトが追加された。翌朝のビルドは、Explorerでフィクスチャディレクトリが表示されるのを待つテストセットアップの段階で90秒間ハングした。NetDrive自体が固まっているわけではない。その1つのディレクトリを列挙するために、40回の逐次的なS3 API呼び出しを行っているのだ。
S3バケットをネイティブなWindowsまたはmacOSドライブとしてマウント
NetDrive を使えば Google Drive、OneDrive、S3、SFTP、WebDAV などが Windows と macOS でネイティブドライブとして表示されます — 同期も、まるごとダウンロードも不要です。
- S3バケットがWindows上でD:、E:など任意のドライブレターとして表示される
- 初回マウント後の再アクセスを高速化するディレクトリ一覧のキャッシュ
- アップストリームのオブジェクトが変更された際に特定フォルダを強制リフレッシュ
無料トライアル。永久ライセンスとサブスクリプションプランあり。
S3の一覧表示がローカルファイルシステムより遅い理由
S3はオブジェクトストレージであり、階層型ファイルシステムではない。fixtures/integration/ という名前のフォルダのように見えるものは、実は共有キープレフィックスにすぎない。つまり、その文字列で始まる数千個のオブジェクトキーの集合だ。実際のディレクトリは存在しない。NetDrive(そしてrcloneやExpanDriveを含む他のすべてのS3マウントツール)は、S3のListObjectsV2 APIを呼び出すことでディレクトリを疑似的に再現している。
ここに落とし穴がある。1回のListObjectsV2呼び出しで返却されるオブジェクトは最大1,000件だ。4万個のキーを持つプレフィックスを完全に列挙するには、40回の逐次API呼び出しが必要になる。S3エンドポイントへの往復に50ms(同一AWSリージョン内であれば妥当な数値)かかるとすると、Explorerに最初のファイル名が表示されるまでに純粋なAPIオーバーヘッドだけで2秒かかる計算だ。企業プロキシ経由や異なるリージョンへのアクセスでは、この40回の呼び出しが30〜90秒に膨れ上がることもある。
これはNetDriveのバグではない。S3 APIの仕様そのものであり、aws s3 lsやrcloneのマウントモード、その他大規模なS3プレフィックスを一覧表示するあらゆるツールに同様に影響する。対策は2つの側面にある。NetDriveがディレクトリ一覧をどうキャッシュするか、そしてバケットをどう構造化するかだ。
NetDriveのディレクトリキャッシュが再アクセスのオーバーヘッドを削減する仕組み
大規模なプレフィックスを最初に一覧表示した後、NetDriveはディレクトリツリーをローカルにキャッシュする。以降、どのプロセスがD:\fixtures\integration\に移動しても、NetDriveはS3 API呼び出しを一切行わずにキャッシュされた一覧を返す。このキャッシュはセッションをまたいで永続化される。コールドブート後でも前回のマウント時のキャッシュがまだ温かい状態のため、ビルドサーバーを一晩再起動した後でも2回目の一覧表示は瞬時に完了する。
キャッシュストレージのサイズは最大1TBまで設定可能だ(NetDrive 3.16.589で導入)。数十のプレフィックスにまたがる数十万個のオブジェクトを持つバケットでは、キャッシュ容量を増やすことでCI実行間により多くのツリーを温かい状態に保てる。これはDrive Managerのドライブ設定から調整できる。
トレードオフとなるのはキャッシュの鮮度だ。同僚やアップストリームのパイプラインがAWSコンソール、別のツール、あるいは別のマシンから直接S3へ新しいオブジェクトをアップロードした場合、NetDriveのキャッシュされたビューは、キャッシュが期限切れになるかリフレッシュをトリガーするまでその変更を反映しない。特定のフォルダをリフレッシュするには、Windows Explorerで右クリックしてRefreshを選択する。NetDriveはそのプレフィックスに対してListObjectsV2呼び出しを再発行し、キャッシュを更新して最新の一覧を返す。
一覧表示のオーバーヘッドを削減するバケット構造の変更
これらの対策にはS3バケットの整理方法自体の変更が必要だが、NetDriveに限らずそのバケットを読み取るすべてのツールにとって恩恵がある。
深いプレフィックス階層をフラット化する。 ナビゲートする階層のレベルごとに、それぞれ独自の一覧表示呼び出しがトリガーされる。fixtures/integration/service-a/env-staging/2026/05/ のようなパスは6階層あり、オブジェクトに到達するまでに最大6回の逐次API呼び出しが必要になる。これをフラット化すると、fixtures/integration/service-a-staging-2026-05/ として同じデータを1回の一覧表示呼び出しで末端まで到達できる。
カーディナリティの高いプレフィックスを時間やカテゴリで分割する。 単一のlogs/プレフィックスに2年分の日次出力にまたがる8万個のオブジェクトが保存されている場合、logs/2025/とlogs/2026/に分割する。NetDriveがlogs/を一覧表示する際、1回のAPI呼び出しで2つのサブプレフィックスを認識する。logs/2026/にナビゲートすると、その年のためだけにもう1回の呼び出しが行われる。
ホットデータとコールドデータを分離する。 頻繁に読み取られるオブジェクトはfixtures/active/のような限定されたプレフィックスに保持し、古いものはfixtures/archive/にアーカイブする。バケット全体をマウントしていてもfixtures/active/のみを読み取るCIパイプラインは高速に一覧表示され、コールドなアーカイブはキャッシュされずクリティカルパスの外に留まる。
ドライブにRoot pathを設定する。 NetDriveのS3接続設定にあるRoot pathフィールドを使うと、特定のプレフィックスをドライブのルートとしてマウントできる。これをfixtures/activeに設定すると、NetDriveはそのプレフィックスをD:\として扱う。バケットの残りの部分はマウントセッション中に一覧表示されることはなく、実際にツール群が必要とするパスだけが処理される。
エンドポイントのリージョンを確認する。 Drive ManagerでS3接続を開き、リージョンがバケットのホームリージョンと一致しているか確認する。クロスリージョンのリクエストはAPI呼び出し1回あたり50〜200msを追加する。40回のページネーション付き一覧表示呼び出し全体では、コールドなディレクトリオープンごとに2〜8秒の避けられないネットワーク遅延が発生する。
まとめ
S3ディレクトリの一覧表示が遅い場合、その原因はほぼ常にNetDriveの設定問題ではなくバケット構造の問題だ。S3 APIの1回あたり1,000オブジェクトという制限は固定されているが、あなたが管理できるのはオブジェクトに到達するまでに何回の呼び出しが必要かという部分だ。深い階層をフラット化し、カーディナリティの高いプレフィックスを分割し、Root pathを設定してマウント範囲を絞り込み、ディレクトリキャッシュによって再アクセス時の一覧表示を瞬時にしよう。
パフォーマンスではなくS3の権限エラーに直面しているチームは、Fix S3 Access Denied Error with NetDriveを参照してほしい。CIパイプラインでAWS S3の代わりにWasabiを使用している場合も、同様の一覧表示の挙動が当てはまる。詳しくはMount Wasabi on Windows with NetDriveを参照。
— Jay, NetDrive