0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Mountpoint for Amazon S3のファイル操作で躓いた話 - 制約を理解して正しく使おう

Last updated at Posted at 2025-12-15

1. はじめに

前回の記事では、Mountpoint for Amazon S3の概要と基本的な使い方について紹介しました。Mountpoint for Amazon S3は、S3バケットをローカルファイルシステムのようにマウントできる便利なツールですが、実際に使ってみると「あれ?このコマンド動かない...」という場面に遭遇します。

今回は、実際に使って困ったことにフォーカスして、Mountpoint for Amazon S3のファイル操作における制約と、その回避方法について解説します。

想定読者

  • Mountpoint for Amazon S3の導入を検討している方
  • すでに使い始めて制約に困っている方
  • S3をファイルシステムとして扱う際の注意点を知りたい方

検証環境

- OS: Amazon Linux 2
- Mountpoint for Amazon S3: v1.14.0
- 環境: ECS on EC2 (m6i.4xlarge)
- マウント先: /mnt/s3

2. 基本的なファイル操作は問題なく動作する

まずお伝えしたいのは、一般的なファイル操作の大部分は問題なく動作するという点です。

2.1 読み込み系コマンド

以下のような読み込み操作は全て正常に動作します。

# ファイル一覧表示
$ ls -l /mnt/s3/

# ファイル検索
$ find /mnt/s3/ -name "*.txt"

# ファイル内容の表示
$ cat /mnt/s3/data.txt

# 文字列検索
$ grep "error" /mnt/s3/logs/app.log

# ディレクトリ構造の確認
$ tree /mnt/s3/
/mnt/s3/
├── data
│   ├── 2024
│   │   └── report.csv
│   └── 2025
│       └── summary.txt
└── logs
    └── app.log

2.2 書き込み系コマンド

新規ファイルの作成も問題ありません。

# 新規ファイル作成
$ touch /mnt/s3/newfile.txt

# データ書き込み
$ echo "Hello World" > /mnt/s3/hello.txt

# ddコマンドでの書き込み
$ dd if=/dev/urandom of=/mnt/s3/testfile.bin bs=1M count=100

# ファイルコピー
$ cp /tmp/data.csv /mnt/s3/backup/

2.3 削除・ディレクトリ操作

削除やディレクトリ作成も基本的には動作します。

# ディレクトリ作成
$ mkdir /mnt/s3/newdir

# ファイル削除
$ rm /mnt/s3/oldfile.txt

このように、読み込み・新規作成・削除といった基本操作は可能です。

3. 動かないコマンドとその理由

しかし、いくつかの操作は失敗します。これらは全てMountpoint for Amazon S3の設計思想に起因する制約です。

3.1 ファイル名の変更(mv/rename)

❌ 失敗する操作

$ mv /mnt/s3/old.txt /mnt/s3/new.txt
mv: cannot move '/mnt/s3/old.txt' to '/mnt/s3/new.txt': Function not implemented

ファイル名の変更はサポートされていません

3.2 既存ファイルの編集(vim/echo追記)

❌ 失敗する操作

# vimでの編集
$ vim /mnt/s3/config.txt
# 保存時にエラー

# 追記
$ echo "new line" >> /mnt/s3/existing.txt
bash: /mnt/s3/existing.txt: Operation not permitted

既存ファイルへの追記や編集は未対応です。Mountpoint for Amazon S3は順次書き込みのみをサポートしており、ファイルのクローズ後は読み取り専用になります。

3.3 権限変更(chmod/chown)

❌ 失敗する操作

$ chmod 755 /mnt/s3/script.sh
chmod: changing permissions of '/mnt/s3/script.sh': Operation not permitted

$ chown user:group /mnt/s3/file.txt
chown: changing ownership of '/mnt/s3/file.txt': Operation not permitted

権限の変更はサポートされていません。S3にはファイルシステムのような権限概念がないためです。

3.4 なぜ動かないのか? - S3 APIとFUSEの制約

これらの制約は、Mountpoint for Amazon S3の設計思想に起因します。

┌─────────────────────────────────────┐
│      アプリケーション                │
│   (ls, cat, vim, mv など)           │
└──────────────┬──────────────────────┘
               │ ファイルシステムAPI
┌──────────────▼──────────────────────┐
│   FUSE (Filesystem in Userspace)    │
│     Mountpoint for Amazon S3        │
└──────────────┬──────────────────────┘
               │ 変換
┌──────────────▼──────────────────────┐
│         S3 REST API                 │
│  (GET, PUT, DELETE, LIST...)        │
└──────────────┬──────────────────────┘
               │
┌──────────────▼──────────────────────┐
│         Amazon S3                   │
└─────────────────────────────────────┘

Mountpoint for Amazon S3は、ローカルのファイル操作をS3のREST API呼び出しに変換しています。しかし、S3 APIとオブジェクトストレージの特性により、以下のような制約があります:

ファイル操作 対応するS3 API 実装可能性 制約の理由
ファイル作成 PUT Object ✅ 可能 -
ファイル読み込み GET Object ✅ 可能 -
ファイル削除 DELETE Object ✅ 可能 -
ファイル名変更 COPY → DELETE ❌ 非効率・非アトミック S3にRename APIがない + Mountpointの設計方針
ファイル追記 ❌ API未提供 ❌ 不可能 S3に部分更新APIが存在しない
権限変更 ❌ 概念がない ❌ 不可能 S3はPOSIX権限の概念を持たない

公式ドキュメントでも明言されています:

"Mountpoint won't try to emulate operations like directory renames that would require many S3 API calls and would not be atomic."

つまり、S3 APIで効率的に実装できない操作はサポートしないという設計方針です。

4. ファイル容量の制約

ファイルサイズにも制約があります。ただし、最近のアップデートで大幅に改善されました。

4.1 読み込み: 50TBまで対応(2025年12月アップデート)

✅ 50TBまで読み込み可能

2025年12月、Amazon S3のオブジェクトサイズ上限が5TB→50TBに拡張されました。Mountpoint for Amazon S3もこれに対応し、50TBまでのファイルを読み込めるようになりました。

# 50TBのファイルも読み込み可能
$ ls -lh /mnt/s3/huge-dataset.bin
-rw-r--r-- 1 root root 50T Dec 15 10:00 huge-dataset.bin

$ cat /mnt/s3/huge-dataset.bin | process-data
# 問題なく処理できる

参考: Amazon S3 increases the maximum object size to 50 TB

4.2 書き込み: デフォルト78.1GB、最大5TB

一方、書き込みには依然として制約があります。

┌─────────────────────────────────────┐
│    書き込み可能サイズ               │
├─────────────────────────────────────┤
│ デフォルト: 78.1 GB                 │
│   (8 MiB × 10,000パート)            │
│                                     │
│ 最大: 5 TB                          │
│   (--write-part-size 524.3 指定時)  │
└─────────────────────────────────────┘

なぜ5TBまで?

Mountpoint for Amazon S3は、内部的にS3のマルチパートアップロードを使用しています。S3のマルチパートアップロードには以下の制約があります:

  • 最大パート数: 10,000個
  • 最大パートサイズ: 5 GB

よって、理論上の最大サイズは:

524.3 MiB × 10,000パート ≒ 5 TB

4.3 容量制限を拡張する方法

大きなファイルを書き込む場合は、--write-part-sizeオプションで調整します。

# デフォルト(78.1GB)
$ mount-s3 my-bucket /mnt/s3

# 1TBまで対応(104.8 MiB/パート)
$ mount-s3 my-bucket /mnt/s3 --write-part-size 104.8

# 5TBまで対応(524.3 MiB/パート)
$ mount-s3 my-bucket /mnt/s3 --write-part-size 524.3

注意点

--write-part-sizeを大きくすると:

  • より大きなファイルを書き込める
  • PUTリクエスト数が減り、並列度が下がる可能性
  • メモリ使用量が増加

本番環境では、ワークロードに応じて適切な値を設定する必要があります。

5. 要注意パターン - 削除操作の落とし穴

削除操作は基本的に動作しますが、S3特有の挙動により予期しないエラーが発生することがあります。

5.1 存在しないファイルを削除したとき

通常のファイルシステムと同様にエラーが返されます。

$ rm /mnt/s3/nonexistent.txt
rm: cannot remove '/mnt/s3/nonexistent.txt': No such file or directory

5.2 ディレクトリごと一括削除したとき

ここが要注意ポイントです。以下のようなディレクトリ構造を削除してみます。

/mnt/s3/
└── test
    └── nested
        └── level1
            ├── file1.txt
            └── level2
                ├── file2.txt
                └── level3
                    └── file3.txt

削除を実行

$ rm -r /mnt/s3/test/nested
rm: cannot remove '/mnt/s3/test/nested/level1/level2/level3': No such file or directory

❓ なぜエラーが出る?

実は削除自体は成功しています

$ tree /mnt/s3
/mnt/s3
└── test
    # nestedディレクトリは消えている

エラーの原因はS3の自動フォルダ削除仕様です:

1. rmコマンドが file3.txt を削除
   → S3で file3.txt が削除される
   
2. S3が「level3フォルダ内が空」と判断
   → level3フォルダを自動削除
   
3. rmコマンドが level3フォルダを削除しようとする
   → すでに存在しない → エラー

つまり、処理は成功しているが、S3の仕様により先回りして削除されてしまうのです。

5.3 アスタリスク指定での一括削除

さらに注意が必要なのが、アスタリスク指定での削除です。

/mnt/s3/
└── test
    └── data
        └── subdir
            ├── file1.txt
            └── file2.txt
# data配下の全ファイルを削除(dataディレクトリは残したい)
$ rm -rf /mnt/s3/test/data/*

# 確認
$ tree /mnt/s3
/mnt/s3
└── test
    # dataディレクトリまで消えている!

❗ 意図しないディレクトリ削除

CLIでは通常、/mnt/s3/test/data/ディレクトリは残るはずですが、S3では内部のファイルがすべて削除されるとディレクトリも自動削除されます。

5.4 S3の自動フォルダ削除仕様

これは、S3の基本的な動作仕様です:

┌──────────────────────────────────────┐
│ S3の「フォルダ」は実は存在しない     │
└──────────────────────────────────────┘

実際のS3オブジェクト:
  test/data/subdir/file1.txt
  test/data/subdir/file2.txt

↓ ファイルを全削除

S3上には何も残らない
(空のフォルダという概念がない)

つまり、S3には「空のディレクトリ」という概念がなく、ファイルが全て消えるとディレクトリも消えるのです。

参考記事: S3でファイルを削除するとフォルダも一緒に消える理由

6. 実務での設計のポイント

Mountpoint for Amazon S3を使う際の設計指針:

要件 判定 代替案
大量の小さなファイルの書き込み ❌ 不向き ファイルをバッチ化
既存ファイルの頻繁な更新 ❌ 不向き DynamoDBやRDSを検討
順次書き込みのログファイル ✅ 適している -
大容量ファイルの読み込み ✅ 適している -
複数プロセスからの同時書き込み ⚠️ 要注意 ファイル名の衝突に注意

7. まとめ

制約を理解すれば強力なツール

Mountpoint for Amazon S3は、いくつかの制約はあるものの、適切なユースケースでは非常に強力なツールです。重要なのは:

  1. できること・できないことを明確に理解する
  2. 制約を回避する設計を行う
  3. S3の特性(オブジェクトストレージ)を意識する

Mountpoint for Amazon S3が向いているユースケース

おすすめ

  • 大容量ファイルの読み込み(データレイク、機械学習)
  • バッチ処理でのログファイル書き込み
  • 順次書き込み(append)のみのワークロード
  • 読み込み中心のアプリケーション
  • S3の容量無制限を活かしたアーカイブ

向いていないユースケース

避けるべき

  • 頻繁なファイル編集・更新が必要
  • ファイル名の変更が頻繁に発生
  • 複雑なPOSIX権限管理が必要
  • 小さなファイルの大量並列書き込み
  • Gitリポジトリなどのランダムアクセスが多い用途

これらの場合は、Amazon FSx for LustreやAmazon EFSの検討をおすすめします。

制約を理解し、適材適所で使いこなしましょう!

本記事が、Mountpoint for Amazon S3を使う際の参考になれば幸いです。

参考リンク

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?