amazon-web-services - 需要帮助在 Amazon Web Services 上选择 EBS 与 S3

Question

我正在开发一个包含文件存储和共享功能的项目，经过几个月的研究利用 AWS 的最佳方法，我仍然有点担心。

基本上我的决定是使用 EBS 存储来存储用户文件还是使用 S3。当用户想要下载少量文件时，系统将合并即时 zip 存档。另外，当用户下载任何文件时，我不希望暴露文件的 URL。

我提出的两个最佳选择是:

1. 拥有一个 EC2 实例，该实例安装了多个 EBS 卷来存储用户文件。

   • 优点:它看起来比 S3 快得多，并且从 EBS 卷中压缩文件非常简单。
   • 缺点:我相信 Amazon 限制了您可以使用的 EBS 存储量，并且没有 S3 那样冗余。

2. 文件上传并处理后，系统会将这些文件推送到 S3 存储桶以进行长期存储。当请求文件时，我将从 S3 检索文件并将其输出回客户端。

   • 优点:冗余、无文件存储限制
   • 缺点:看起来非常慢，无法将 S3 存储桶作为文件系统中的卷挂载，提供压缩文件意味着将每个文件传输到 EC2 实例，压缩，然后最终发送输出(同样，慢!)

我的假设有缺陷吗？有没有更好的方法来管理大量文件存储？

Answer 1

如果您的服务将由不确定数量的用户使用，请务必记住，可扩展性始终是一个问题，无论采用哪种选项，您都需要扩展服务以满足需求，因此，可以方便地假设您的服务将在具有 EC2 实例池而不是单个实例的 Auto Scaling 组中运行。

关于保护 URL 以仅允许授权用户下载文件，有很多方法可以做到这一点，而不需要您的服务充当中间人，那么您将需要处理至少两个问题:

1. 文件名可预测性:为了避免 URL 可预测性，您可以将上传的文件命名为哈希，并将原始文件名和所有权存储在 SimpleDB 等数据库中，您可以选择设置 http诸如“Content-Disposition: filename=original_file_name.ext”之类的 header 建议用户浏览器相应地命名下载的文件。

2. 授权:当用户要求下载您的服务的给定文件时，使用 Query String Authentication 发出临时授权。或Temporary Security Credentials对于在一段时间内授予文件读取权限的特定用户，您的服务将重定向到 S3 存储桶 URL 以便直接下载。这可以极大地减轻您的 EC2 池实例的负担，从而可以更快地处理其他请求。

为了减少 S3 存储桶的空间和流量(请记住，您按存储和传输的 GB 付费)，我还建议在上传到 S3 之前使用 gzip 等标准算法压缩每个单独的文件，并设置 header “Content-Encoding” :gzip "以便在用户浏览器中自动解压缩。如果您选择的编程语言是 Java，我建议您查看插件代码 webcache-s3-maven-plugin我创建它是为了从 Web 项目上传静态资源。

关于压缩文件夹的处理时间，您经常无法确保在短时间内压缩文件夹，以便用户立即下载，因为最终可能会出现巨大的文件夹，压缩可能需要几分钟甚至几小时。为此，我建议您使用 SQS 和 SNS 服务以允许异步压缩处理，其工作原理如下:

1. 用户请求文件夹压缩
2. 前端 EC2 实例在 SQS 队列中创建压缩请求
3. 后端EC2实例，消耗SQS队列的压缩请求
4. 后端实例将文件从 S3 下载到 EBS 驱动器，因为生成的文件是临时的，我建议选择至少使用带有临时类型磁盘的 m1.small 实例，这些实例是位于虚拟机本地，以减少 I/O 延迟和处理时间。
5. 生成压缩文件后，服​​务会将文件上传到 S3 存储桶，并可选择设置 Object Expiration属性，这将告诉 S3 存储桶在一段时间后自动删除该文件(再次降低存储成本)，并发布一条通知，表明该文件已准备好在 SNS 主题中下载。
6. 如果用户仍然在线，则读取主题中的通知，并通知用户 zip 文件已准备好下载，如果一段时间后此通知没有到达，您可以告诉用户压缩正在进行比预期的时间长，一旦文件准备好下载，服务就会通过电子邮件通知他。

在此场景中，您可能有两个 Auto Scaling 组，分别是前端和后端，它们可能具有不同的可扩展性限制。