こんにちは！
BFT名古屋支店の佐野です。
突然ですが、AWSのストレージサービスであるS3はEC2 インスタンスにマウントできることはご存知でしょうか。
通常であればEC2 インスタンスに格納されるファイルは、立ち上げ時に同時に作成するEBSに置くことになるかと思います。
しかしEBSは容量に制限があり、その制限を大きくした場合にかかる費用もS3と比べると割高です。
大量のデータを保存するとなった時には、その分をS3に回してしまうことで容量超過の懸念排除とコストの削減を行なうことができ、その際にS3をEC2にマウントしておくことでスムーズなファイルのやり取りが可能になります。
また、例えばファイルサーバーとなるインスタンスを外部から送られるファイルの中継受け口をして用い、そこからS3へ送るという流れが必要となった際、発想を変えてそのファイルサーバーインスタンスにS3を載せてしまえば「送る処理」を丸々省くことができます。
今回はそういった話が出た時、実際に行なった検証の手順をお送りさせて頂きます。
はじめに：試したいことと、その構成図
本記事で検証する要点は以下の通りになります。
下線を引いた部分が、今回の検証で特に重要視された要点です。
- インスタンスにgoofysをインストールし、マウント用ディレクトリを用意してS3をマウントできるか。
- マウントしたS3にインスタンスからファイルを追加できるか
- インスタンスにマウントされたS3およびその内容をS3マネジメントコンソールで確認できるか
- インスタンスにマウントされたS3の内容を、S3をマウントしたインスタンスとは別のインスタンスから確認・操作できるか
- S3をマウントしたインスタンスとは別のインスタンスがマウントされたS3に追加したファイルを、S3をマウントしたインスタンスで確認・操作できるか
以上の項を確認することで、S3はインスタンスにマウントされたとしても通常のS3と同様に扱えるかを検証します。
また今回の検証における構成図は以下となります。
（インスタンスのOSはAmazon Linux 2を使用しています）
EC2 インスタンスの前提
以上の構成図の通り、今回は４台のインスタンスの利用を想定していますが、パブリックサブネットにあるものはS3にアクセスを行なうインスタンスに接続するための踏み台サーバとなります。
インターネットに接続されていないプライベートサブネットに属するインスタンスは、エンドポイントを通じてS3への接続を行なうことになりますが、その際S3の操作を行なえる権限を持っていなければなりません。
なので aws configure コマンドによってS3の操作権限があるIAMユーザーを関連付けるか、インスタンスそのものにS3の閲覧・操作権限を持つポリシーを含んだIAMロールを割り当てる必要があります。
今回はaws configure コマンドでIAMユーザーを関連付ける方法を使用し、またS3をマウントするインスタンスと、そのマウントされたS3の閲覧・操作を試行するためのインスタンスでは別のIAMユーザーを使用する形としています。
インスタンスにS3にマウントするための準備・goofysのインストール
まずS3をインスタンスにマウントするための準備として、goofysのインストールを行なっていきます。
goofysとはまさにS3をファイルシステムとしてマウントするためのソフトウェアであり、Go言語で実装されています。
このgoofysを、S3をマウントするインスタンスに以下のコマンドを使用してインストールしていきます。
またインストールを行なう際、インストールを行なうインスタンスが属しているプライベートサブネットに一時的にインターネットゲートウェイをアタッチし、その後デタッチしています。
まず以下のコマンドでrootユーザーに昇格します。
今後行う手順は、すべてrootユーザーで行なうことを前提としています。
sudo su -
rootユーザーに昇格後、まずはgoofysを使うために必要なgoのインストールを行ないます。
yumコマンドを使用し、以下の内容で実行します。
yum -y install golang fuse git
goをインストールした後、goを使用するための環境変数“GOPATH”を設定します。
環境変数GOPATHはGoコードを探す場所を表すもので、今回は以下のようにコマンドを実行し、設定を行ないます。
export GOPATH=$HOME/go
環境変数を設定後、本命となるgoofysをダウンロード・インストールを以下のコマンドを順に実行して行なっていきます。
go get github.com/kahing/goofys go install github.com/kahing/goofys
留意点として、これらのコマンドでダウンロードおよびインストールする際、その経過などは表示されません。
またgetでのダウンロード時は体感で結構な時間（１０分弱）が掛かりました。
何も表示されない状態で待たされるので不安になるかもしれませんが、完了するまで操作を行なわないようにしてください。
ダウンロード・インストール完了時にも特に何か表示が出るということがありませんので、コマンド入力受付状態となったら次の手順に進みます。
マウント用ディレクトリを作成し、S3をマウントする
goofysのインストールが完了したら、S3をマウントするためのディレクトリを作成します。
今回は以下のコマンドを実行し、mnt配下にディレクトリを作成します。
mkdir /mnt/S3
ディレクトリを作成したら、いよいよS3のマウントを行ないます。
とはいえgoofysをインストールしているなら、以下の１コマンドを実行するだけでマウントを行なうことができます。
./go/bin/goofys [マウントするS3バケット名] /mnt/S3
特にエラーなければ、マウント用ディレクトリに指定したS3バケットがマウントできているはずです。
テストとして、例えばS3バケットをマウントしたディレクトリに以下のコマンドを実行してファイルを作成します。
その後、S3マネジメントコンソールからマウントしたS3バケットを閲覧し、作成したファイルがあることが確認できればマウントが行えていることになります。
vi /mnt/S3/test
マネジメントコンソールでバケットにアップロードしたファイルを、S3バケットをマウントしたインスタンス側で見る
S3バケットをマウントしたディレクトリに追加したファイルは、S3バケットに問題なく追加されることは確認できました。
では逆にマネジメントコンソールからバケットにアップロードしたファイルを、バケットをマウントしたインスタンス側で確認することはできるのでしょうか。
結論から言えば、これも可能です。
またマネジメントコンソールからS3バケットにアップロードされたファイルを、そのバケットをマウントしたインスタンス上で削除・編集をすることもできます。
AWS-CLIでもS3バケット内のファイルの編集はできませんので、これもバケットをマウントすることで行なえるようになる特徴と言えます。
別VPCにある、別IAMユーザーの認証情報を持ったインスタンスから、マウントされたS3バケットを見る
さて、今回の検証の本題です。
インスタンスにマウントされたS3バケットを、他のVPCにある（かつS3バケットを作成したユーザーとは別のIAMユーザーの認証情報を使用している）インスタンスから見ることはできるのか。
これも結論から述べると、可能でした。
またAWS-CLIでS3バケットを閲覧するインスタンスから、テストファイルとして“ec2add_test.txt”のアップロードを試行し、問題なく行なえることを確認しました。
さらにこのS3バケットからのファイルダウンロードも行えることも確認しております。
その後S3バケットをマウントしたディレクトリから“ec2add_test.txt"が見えるか念のため確認を行ないましたが、想定通り問題なく見えることが確認できました。
どうやらS3バケットは、ひとつのインスタンスにマウントしたとしても、それ自体は通常の（マウントされていない）S3バケットと同様の性質を保ち続けるようです。
であればファイルの受け口となるインスタンスに共有リソースとなるS3バケットをマウントしておくことで、ファイルのやり取りをスムーズに、かつ安価に行なうことができるということになります。
さいごに
以上がインスタンスにS3バケットをマウントする方法と、マウントしたS3バケットがどうなるかの解説になります。
今回の検証は行なってみれば、なるべくしてなっているなという感があるものでしたが、それが実際に証明できているかいないかでは大きな違いです。
この立証ができていることで、S3バケットをインスタンスにマウントして使うという選択肢がより使いやすくなるかと思います。
もしS3バケットを共有のファイルストレージのような形で使う際、インスタンスとのやり取りがある場合は、是非この記事を参考にし、ひとつの方法として検討していただければ幸いです。
以上、お読みいただきありがとうございました。
