導入
「クラウド上のファイルを複数サーバーから扱いたい」という要件は頻繁に発生します。AWSでは長年Amazon EFSがその筆頭でしたが、fstabによる自動マウントのサポートを開始した「Mountpoint for Amazon S3」という選択肢も登場しました。
この記事では、NewRelic移行時が発端となったステートフル問題の解消と共に「Mountpoint for Amazon S3」と「Amazon EFS」の違いを明らかにし、パフォーマンス、ユースケース、コストの観点から比較します。この記事を読んでいただいた方々のストレージ戦略のお助けになれれば幸いです。
発端
EC2複数台構成で成立しているサービスにおいて、特定のインスタンス内で保存している画像ファイルを他のインスタンスから参照しているケースがありました。
このステートフル問題は課題として認識していましたが、固有コンテンツを保有するEC2インスタンスを複製して、ターゲットグループにぶら下げるなどの運用対処でサービスの停止を回避していました。
NewRelic移行を進めていた頃、インストールの際に関連するミドルウェアの再起動でサービスの停止を伴うことがわかっていたので、この際解消してしまおうということで外部のストレージに移行することの検討を開始し、その際に上がったのが「Mountpoint for Amazon S3」と「Amazon EFS」でした。
Mountpoint for Amazon S3 の 検証
Amazon EFSについては長年使用していることもあり社内に保有しているナレッジは多くありましたが、Mountpoint for Amazon S3 については社内で保有しているナレッジが少なかったため、主に Mountpoint for Amazon S3 の検証の様子を重点的に記載します。
要件の整理と検証環境の用意
要件の整理
- 対象インスタンス：インスタンスA
- 対象のコンテンツパス：静的コンテンツのパス
- DoD：インスタンスAのミドルウェアが停止していた場合も、他のインスタンスから固有のコンテンツを参照できる状態になっていること。
- バケットをマウントするインスタンス：インスタンスB、インスタンスC
- マウントする場所は静的コンテンツの配置先
検証環境の用意
- 対象インスタンスからAMIを作成する。
- AMIからインスタンスを起動する。
- 起動時の設定は対象インスタンスに揃える。
- キーペア、VPC、サブネット、セキュリティグループ
- 起動後にIAMロールを付与(対象インスタンスと同様)
- 起動時の設定は対象インスタンスに揃える。
Mountpoint for Amazon S3 の用意
- 検証用のバケット(test-mount-s3)をコンソール操作から作成。
- SSMで接続して以下の通り操作し、動作を確認。
[root@ip-192-168-81-255 ~]# wget https://s3.amazonaws.com/mountpoint-s3-release/latest/x86_64/mount-s3.rpm
[root@ip-192-168-81-255 ~]# yum install ./mount-s3.rpm
[root@ip-192-168-81-255 ~]# aws s3 ls | grep mount
2024-03-08 18:08:27 test-mount-s3
[root@ip-192-168-81-255 ~]# mkdir mountpoint
[root@ip-192-168-81-255 ~]# mount-s3 test-mount-s3 ./mountpoint/
bucket stg-ltf-mount-s3-test is mounted at ./mountpoint/
[root@ip-192-168-81-255 ~]# cd mountpoint/
[root@ip-192-168-81-255 mountpoint]# echo "test" > test.txt
検証
mv
- コンテンツを移動してみる。
- タイムスタンプを保持したまま移動できないメッセージが出力される
- 所有者を保持したまま移動できないメッセージが出力される
- パーミッションを保持したまま移動できないメッセージが出力される
[root@ip-192-168-81-26 ~]# mv files mountpoint/
mv: preserving times for ‘mountpoint/files/hogehoge’: Operation not permitted
mv: failed to preserve ownership for ‘mountpoint/files/hogehoge’: Operation not permitted
mv: preserving permissions for ‘mountpoint/files/hogehoge’: Operation not permitted
cp
- コンテンツをコピーしてみる。
- タイムスタンプを保持したままコピーできないメッセージが出力される
- メッセージは表示されないが、コピーしたディレクトリ、ファイルは root:root に変更されている。
- メッセージは表示されないが、コピーしたディレクトリは755、ファイルは644に変更されている。
[root@ip-192-168-81-255 ~]# cp -rp files mountpoint/
cp: preserving times for ‘mountpoint/files/hogehoge’: Operation not permitted
cp: preserving times for ‘mountpoint/files/hogehoge’: Operation not permitted
...
[root@ip-192-168-81-255 ~]# ll mountpoint/files/
total 0
drwxr-xr-x 2 root root 0 Mar 14 15:53 hogehoge
drwxr-xr-x 2 root root 0 Mar 14 15:53 hoge
...
[root@ip-192-168-81-255 ~]# ll mnt/files_bk/hogehoge/
total 670
-rw-r--r-- 1 root root 685597 Mar 14 19:35 fugafuga
rsync
- rsyncで同期してみる。
- メッセージは表示されないが、タイムスタンプは同期した時刻に変更される
- 所有者を保持したまま移動できないメッセージが出力される
- パーミッションを保持したまま移動できないメッセージが出力される
[root@ip-192-168-81-255 ~]# rsync -av files_bk mnt/
sending incremental file list
files_bk/
files_bk/hogehoge/
...
rsync: chown "/files_bk/hogehoge" failed: Operation not permitted (1)
rsync: rename "/files_bk/fugafuga" -> "files_bk/fugafuga": Function not implemented (38)
other
- 警告を無視(タイムスタンプ、所有者、パーミションの保有をしないで)コピーしてみる。
[root@ip-192-168-81-255 ~]# cp -vr files_bk mnt/
‘files_bk’ -> ‘mnt/files_bk’
‘files_bk/hogehoge’ -> ‘mnt/files_bk/hogehoge’
...経過時間2.5時間くらいかかる...
‘files_bk/fugafuga’ -> ‘mnt/files_bk/fugafuga’
‘files_bk/piyopiyo’ -> ‘mnt/files_bk/piyopiyo’
- S3バケットのバプリックアクセスを一時的にオフにして上記を一通り試す。
- マウント時にオプションを付与して一通り試す。
- 結果に変化なし
- 付与したのは
Mount options:に含まれる--allow-hogehoge
[root@ip-192-168-81-255 ~]# mount-s3 --help
Mountpoint for Amazon S3
...
Mount options:
--read-only Mount file system in read-only mode
--allow-delete Allow delete operations on file system
--allow-overwrite Allow overwrite operations on file system
--auto-unmount Automatically unmount on exit
--allow-root Allow root user to access file system
--allow-other Allow other users, including root, to access file system
--uid Owner UID [default: current user's UID]
--gid Owner GID [default: current user's GID]
--dir-mode Directory permissions [default: 0755]
--file-mode File permissions [default: 0644]
...
- インスタンスの停止・起動でマウントポイントが外れないか確認する。
- 停止・起動によりマウントは外れてしまう。
- サービスファイルの作成（またはcron, .bashrc）などで自動マウントしてみる。
- 一旦サービスファイルを作成してenabeldにして自動マウントは実装可能（warn吐いてるけど一旦無視）
[root@ip-192-168-81-255 ~]# cat -n /etc/systemd/system/mount-s3.service
1 [Unit]
2 Description=Mountpoint for Amazon S3 mount
3 Wants=network-online.target
4 After=network-online.target
5
6 [Service]
7 Type=oneshot
8 RemainAfterExit=yes
9 ExecStart=/usr/bin/mount-s3 mount-s3-test /*** --allow-other --allow-overwrite --allow-delete
10 ExecStop=/usr/bin/fusermount -u /mnt
11
12 [Install]
13 WantedBy=default.target
[root@ip-192-168-81-255 ~]# systemctl status mount-s3.service
● mount-s3.service - Mountpoint for Amazon S3 mount
Loaded: loaded (/etc/systemd/system/mount-s3.service; enabled; vendor preset: disabled)
Active: active (exited) since Fri 2024-03-15 16:00:44 JST; 3min 20s ago
Process: 4397 ExecStart=/usr/bin/mount-s3 *** // --allow-other --allow-overwrite --allow-delete (code=exited, status=0/SUCCESS)
Main PID: 4397 (code=exited, status=0/SUCCESS)
Memory: 11.7M
CGroup: /system.slice/mount-s3.service
└─4700 /usr/bin/mount-s3 *** // --allow-other --allow-overwrite --allow-delete
検討した結果、Amazon EFSを利用することに
Mountpoint for Amazon S3 に関してAWSにも聞いてみた
- 問い合わせ内容
- EC2インスタンスにマウントしたS3バケットに対して、同一インスタンス内に存在するディレクトリ及びファイルを、全ての情報（タイムスタンプ、所有者、所有グループ、パーミッション）を保持したまま、マウントされたS3バケットに移動またはコピーすることは可能か回答いただきたい。また、それらに関する記載のあるドキュメント等があればご案内いただきたい。
- 回答
- S3マウントポイントは機械学習のログなどを外に逃がしたいけど、毎回処理の中でS3のAPI叩いてPutObjectするのが面倒なときに使う想定である。権限周りを完全にコピーするなど、インスタンスを跨いだ共通のファイルシステムとしての使用は想定と違う利用方法に見える。実現不能ではないが、調査しながらになるのでそれならSDKでAPI叩くほうが早いし、想定外は起きないと言える。EFSでの実現が今回の要件には適している。
Mountpoint for Amazon S3 と Amazon EFS の比較
両者の違いを簡単にまとめました。
| 項目 | 🗄️ Amazon EFS (ファイルサーバー) | 🚀 Moutpoint for Amazon S3 (S3クライアント) |
|---|---|---|
| 主な用途 | 複数サーバーで共有・共同編集するファイル置き場 (Webサーバー、CMS、開発環境など) | 大規模データを高速に読み込む処理 (機械学習、データ分析、レンダリングなど) |
| ファイル操作 | 読み書き、編集、削除、権限変更など全てのファイル操作に対応 (フルPOSIX互換) | 読み込みと新規作成のみ。既存ファイルの編集や追記は不可 (POSIX非互換) |
| パフォーマンス | 汎用的で安定したスループット。レイテンシーは比較的低い | 読み込み性能に特化。S3の圧倒的なスループットを活かせる。書き込みは低速 |
| データ一貫性 | 強力な書き込み後読み取り一貫性を保証。複数サーバーからの変更が即座に反映 | S3の結果整合性に依存。変更が反映されるまでに若干の遅延がある場合も |
| コスト | 保存したデータ容量とスループットモードに対して課金。S3より高価 | 無料。Mountpoint自体の料金はなく、裏側で発生するS3のAPIリクエストとデータ転送料金のみ |
ユースケースで比較する
この設計思想の違いから、それぞれが得意とするユースケースは明確に分かれます。
Amazon EFSが輝くシナリオ
EFSは、複数サーバー間でのファイル共有と共同編集が不可欠な場面で真価を発揮します。
- Webサーバー・CMS: WordPressなど、複数台のWebサーバーでコンテンツやプラグインを共有する。
- 開発環境: 複数開発者がアクセスする共有リポジトリや開発ツール置き場。
- コンテナの永続ストレージ: 複数のコンテナが同じデータにアクセスし、書き込みを行う。
一言でいうと、「従来のファイルサーバー（NAS/NFS）の置き換え」が必要な場合はEFSが最適です。
Moutpoint for Amazon S3が輝くシナリオ
Mountpointは、S3上のデータを変更せず、とにかく速く大量に読み込みたい場面で無類の強さを誇ります。
- 機械学習のトレーニング: S3にある数テラバイトの画像データセットを、複数の学習インスタンスから一斉に読み込む。
- ビッグデータ分析: データレイクとしてS3に保存された大量のログを、分析クラスターが直接処理する。
- メディアレンダリング: VFXのレンダーファームが、S3上の巨大な3Dモデルやテクスチャデータを読み込んでレンダリングする。
ポイントは「データをEC2インスタンスにコピーする手間と時間をなくせる」ことです。
結論まとめ
Webサイトや開発環境のように、複数サーバーからファイルを自由に読み書きしたいなら Amazon EFS を選択する。機械学習やデータ分析のように、S3上の巨大なデータを高速に読み込みたいだけなら Moutpoint for Amazon S3 を選択する。
Amazon EFS と Moutpoint for Amazon S3 は競合するサービスではなく、それぞれが異なる課題を解決するために設計されたツールでした。両者の特性を正しく理解し、要件に合う最適なストレージ戦略を描きましょう！
Views: 0
