S3 Files という新しい機能が発表されましたので、さっそく使ってみました。
また、ざっとドキュメントを読んだ所感もあわせて書いておきます。
概要
S3 Files は、**汎用 S3 バケットを EC2、Lambda、ECS/EKS などからマウントし、ファイルシステムとして利用できる機能**です。
S3 Vectors のように別種の S3 リソースが増えるわけではなく、利用するのは通常の汎用 S3 バケットです。
以前から Mountpoint for Amazon S3 という仕組みはありました。
こちらも S3 バケットをマウントして使えるという点では似ていますが、あくまでクライアント側のツールであり、共有ファイルシステムそのものではありません。
それに対して S3 Files は、S3 バケットを背後に持ちながら、より本格的なファイルシステムとして扱えるようにした機能、という理解です。
ファイルシステム作成
前提として、リンク先となる汎用 S3 バケットではバージョニングを有効化しておく必要があります。
「ファイルシステムを作成」をクリックします。
事前に作成しておいたバージョニング有効済みのバケットと、マウントターゲットが作成される VPC を選択します。
私の環境では、この後 5 分ほどで作成が完了しました。
作成できました。見た目はかなり EFS を思い出させます。
実際、ドキュメントによれば S3 Files は Amazon EFS を用いて実装されているようです。
マウントターゲット
EFS と同様に、マウントターゲットが指定した VPC 配下に作成されます。
セキュリティグループはデフォルトのものがアタッチされていました。
このままでは使えない場合があるため、マウント元の EC2 などから通信できるよう、適切なセキュリティグループに変更または設定を調整しておく必要があります。
EC2 からのマウント
前提：EC2 に付与された IAM ロールに十分な権限が必要です。今回は検証のため、Administrator 権限を付与した状態で実行しています。
上記画面の「EC2 インスタンスへのアタッチ」より、マウント手順を確認できます。
アタッチ先 EC2 やマウントポイントなどを指定すると、下部のコマンド例に内容が反映されます。
この画面の入力はコマンド例に反映されるだけで、実際の変更はそのコマンドを実行して行います。
手順どおりに実行するだけですが、内部的には efs-utils を使うようです。
したがって、efs-utils の前提条件は満たしておく必要があります。
$ sudo mount -t s3files fs-011ca9d3df3f21efd /mnt/s3files $ sudo mount | tail -n 1 127.0.0.1:/ on /mnt/s3files type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,noresvport,proto=tcp,port=20721,timeo=600,retrans=2,sec=sys,clientaddr=127.0.0.1,local_lock=none,addr=127.0.0.1) $ df -T /mnt/s3files Filesystem Type 1K-blocks Used Available Use% Mounted on 127.0.0.1:/ nfs4 9007199254739968 0 9007199254739968 0% /mnt/s3files
OS からは NFSv4 のファイルシステムとして見えていることが分かります。
続いて、一般ユーザーが扱えるサブディレクトリを作成し、その中でファイルを作成してみます。
$ sudo mkdir -p /mnt/s3files/work $ sudo chown ec2-user:ec2-user /mnt/s3files/work $ chmod 755 /mnt/s3files/work $ touch /mnt/s3files/work/hello.txt $ ls -l /mnt/s3files/work/hello.txt -rw-r--r--. 1 ec2-user ec2-user 0 Apr 8 10:06 /mnt/s3files/work/hello.txt $ echo "Hello S3 Files" >> /mnt/s3files/work/hello.txt $ cat /mnt/s3files/work/hello.txt Hello S3 Files
ファイルの作成と追記ができました。
S3 バケット側を確認すると、ファイルが作成されており、内容も反映されていました。
自動マウントについては、fstab などを使って構成できそうですが、今回は未検証です。
アーキテクチャ
おおよそ以下のような構成になっているようです。 ※ あくまでドキュメントを読んだ上での個人の理解です。
S3 とのやり取りを仲介する S3 Files が中間層として動作し、EC2 や Lambda、ECS/EKS などの compute resource は、この S3 Files を共有ファイルシステムとして利用するイメージです。
ファイルの変更はまず S3 Files 側で処理され、その後 S3 バケットへ同期されます。
一方、読み取りについては常に同じ経路を通るわけではなく、データサイズやアクセスパターンに応じて最適化されるようです。
前述の Mountpoint for Amazon S3 は、クライアント側で動くツールとしてファイル操作と S3 API の間を橋渡しするものでした。
それに対して S3 Files は、共有ファイルシステムとしての意味合いが強く、設計思想からかなり異なるように見えます。
また、S3 Files 作成時には S3 Files 用の IAM ロールが作成され、その権限で S3 バケットとの同期処理を行う構成になっています。
ただし、これだけで完結するわけではなく、マウントする側の EC2 などにも別途 IAM 権限が必要です。
権限関連
当然ながら、利用には IAM 権限が必要です。
権限はざっくり分けると、以下の 3 種類があります。
- S3 Files を作成・管理するための権限
- S3 Files 自身が S3 バケットと同期するための権限
- EC2 や ECS/EKS など、実際にマウントして使うクライアント側の権限
単に S3 の権限だけでよいわけではなく、新しい service prefix である s3files: の権限も必要になります。
また、クライアント側には s3files:* 系の権限に加えて、状況によってはリンク先 S3 バケットを直接読むための権限も必要です。
したがって、実運用では権限設計はかなり丁寧にやる必要がありそうです。
最後に
今回は EC2 からマウントして試してみましたが、同時に Lambda や ECS/EKS からも利用できるようです。 そのため、サービス間でファイルを受け渡すような構成はかなりやりやすくなりそうです。
S3 を単なるオブジェクト置き場として使うのではなく、共有ファイルシステムのように扱えるようになる、というのがこの機能の面白いところだと思いました。
今回はハンズオン目的だったため、権限関連はかなり雑に試しています。その点はご了承ください。
お読みいただきありがとうございました。