#1.背景
S3の可用性や耐障害性って魅力的！
ただし、NFSマウントできないので、扱う側がS3のAPIで会話しないといけない。
現行では、複数台あるWebサーバがそれぞれファイルサーバへNFSマウントして共有コンテンツを参照していたんですが、S3だとこの構成がとれない。。。
なんとかならないか？そんな理由で始まった検討経緯を共有します。
#2.方式案
思いついたのは、大きく以下の4方式。早速各方式について検討開始しました。
①：S3コマンドで会話するよう、アプリケーション修正（AWS推奨）
②：何らかの形でS3のバケットをNFSマウントする（S3fsとか）
③：インスタンス側にデータを同期する（S3 syncとか）
④：EC2でファイルサーバを構築する（最終手段）
#3.検討の流れ
やはり最初は教科書通りにやろうとはしましたが、アプリケーション側の修正が大きいので非現実的でした。
ということで、まずはS3をマウントできないか調べました。
S3fsがヒットしたので、早速試してみることに。
、、、結果。S3fsは遅いし不安定。
ファイルを書き込んだ直後にlsコマンドでリストするとエラーになったり、
一括でファイル書込みしようとするとエラーが発生したりしました。
しかもAWS公式ではないツール。。。AWSとしても使ってくれるな、ということだったので、却下。
（あくまでも、今回の要件には見合わなかった、という意味です。S3fs自体を否定するつもりはありません）
はい、次。
AWS公式でできる手段は何だ？という観点で、S3 syncを発見。。試す。
公式CLIのコマンドだけあって早い。マルチパートで送受信する仕組みはさすがといったところ。
、、、しかし、S3 syncでデータ同期するためには、明示的にコマンドを叩いてあげないといけないので、cronなどで仕込みが必要（＝タイムラグが発生してしまう）
コンテンツ更新のリアルタイム性が求められるシステムだったため、採用できず。。。
、、、手詰まり。
#4.結論
S3の可用性・耐障害性の恩恵を受けつつ、リアルタイム同期しながらコンテンツ共有することはできない
という結論に達しました。
S3がNFSできたり、ひとつのEBSを複数のインスタンスでアタッチできれば問題なかったのに。。。
（AzureではFilesがPreviewされているので、AWSも必ずリリースしてくれると信じています！）
結局、EC2上にCRUSTERPROで冗長化したファイルサーバを構築しました。
そこでも色々ありましたので、よかったら下の記事も読んでみてください。
DX経由でアクセスされるAWS上のファイルサーバの冗長化方法(Failover方式)を考える
#5.まとめ
最後に、比較検討で書いた観点を表に纏めておきます。
| 方式 | メリット | デメリット | 評価結果 |
|---|---|---|---|
| S3コマンドで制御するようAP修正 | ・AWS推奨 ・EC2に追加EBS不要 |
・修正コスト大 ・AP改修リスク |
AP側の修正負担やスケジュールが 間に合うのならアリ |
| S3fsによるマウント | ・現行構成を流用可能 | ・EC2に追加EBSが必要 ・パフォーマンス遅 ・エラー発生、不安定 |
Enterprise利用には厳しい |
| S3 syncによる同期 | ・現行構成を流用可能 ・AWS公認の手段 |
・EC2に追加EBSが必要 ・定期実行必須（＝タイムラグ発生） |
ライムラグ許容できるのであればアリ |
| EC2でファイルサーバ構築 | ・現行構成を流用可能 ・現行と同じメンテナンス性 ・パフォーマンス期待 |
AWS利用コスト大 | オンプレミスと同じ感覚（要件）を求めるのであれば これを採用せざるを得ない。。。 |
CMS入れろよ！！！というツッコミは無しでお願いします 笑