Amazon S3バケットをローカルディレクトリとしてマウントするs3fsはどの程度安定しているのか【非公開

質問

linuxでAmazon S3バケットをローカルディレクトリとしてマウントするs3fsはどの程度安定していますか？需要の高い本番環境では推奨/安定されているのでしょうか？

より良い/類似のソリューションがありますか？

更新しました。 EBSを使用して、他のすべてのAMIにNFS経由でマウントする方が良いでしょうか？

どのように解決するのですか？

s3fsについては、こちらに良い記事があります。 を読んでから、私は EBS 共有に頼りました。

s3fs を使用する際のいくつかの重要な考慮事項、すなわち S3 の固有の制限に関連する事項を強調しています。

• 5GB を超えるファイルを作成できない
• ファイルの部分的な更新はできないので、1 バイトを変更するとファイル全体が再アップロードされます。
• 多くの小さなファイルに対する操作は非常に効率的です（結局、それぞれが個別の S3 オブジェクトです）が、大きなファイルは非常に非効率的です。
• S3 は部分的なダウンロードをサポートしていますが、s3fs はこれを利用しないため、1GB のファイルの 1 バイトだけを読みたい場合、GB 全体をダウンロードする必要があります。

したがって、s3fs が実行可能なオプションであるかどうかは、何を保存しているかによります。 たとえば写真を保存していて、ファイル全体を書き込んだり、ファイル全体を読み込んだり、ファイルを段階的に変更することはないのであれば、問題ありませんが、このようなことをするならば、なぜ S3 の API を直接使用しないのかと聞かれるかもしれませんね。

もしあなたがアプリケーションデータ（例えばデータベースファイルやログファイル）について話しているのなら、小さな増分変更をしたいのなら、それは間違いなくノーだ-S3はそのように動作しないので、ファイルを増分変更することはできない。

上記の記事には、同様のアプリケーションについて書かれています。 s3backer - これは S3 上で仮想ファイルシステムを実装することで、パフォーマンスの問題を回避しています。 これはパフォーマンスの問題を回避するものですが、それ自体にいくつかの問題があります。

• 書き込みが遅延するため、データが破損するリスクが高い。
• 小さすぎるブロック サイズ (例: デフォルトの 4K) は、大きな追加コスト (例: 50GB の 4K ブロックのストレージで 130 ドル) を発生させる可能性があります。 追加コストが発生する (たとえば、4K ブロック相当のストレージで 50GB の場合 130 ドル)
• ブロック サイズが大きすぎると、データ転送およびストレージの料金が大幅に増加する可能性があります。 料金が発生します。
• メモリ使用量が膨大になる可能性があります。デフォルトでは、1000 ブロックがキャッシュされます。
  
  デフォルトの 4K ブロック サイズでは問題にはなりませんが、ほとんどのユーザーは
  
  はブロック サイズを大きくしたいと思うでしょう。

私は EC2 インスタンスから EBS Mounted Drived 共有に頼りました。 しかし、最もパフォーマンスの高いオプションではありますが、1 つの大きな問題があることを知っておく必要があります。 EBS ボリュームを共有しているマシンが停止すると、その共有にアクセスするすべてのマシンでアクセスが失われるからです。

これは、私が許容できるリスクであり、最終的に選択したオプションでした。 これがお役に立てれば幸いです。