在分布式架构中，经常需要保存应用程序的日志，对于亚马逊云科技的客户来说，保存通常是通过一个 Amazon S3 桶来完成。这些日志可能包含运行时事务、错误、故障状态、应用程序指标和统计信息。这些日志将被用于商业智能，以提供有用的见解并生成仪表盘、分析和报告。在一些应用程序中，日志文件作为事实的最终来源，对于治理和审计目的至关重要。因此，有必要在保证高可用性和持久性的情况下永久保留日志。许多客户选择以各种格式将日志直接写入 S3，而其他客户则喜欢通过亚马逊云科技服务来流转日志，如 Amazon Kinesis。
在这篇博文中，我重点介绍了将数以百万计的日志文件归档到 Amazon S3 Glacier 存储层中的一些成本相关的考虑因素。Amazon S3 Glacier 存储层（S3 Glacier Instant Retrieval、S3 Glacier Flexible Retrieval 和 S3 Glacier Deep Archive）是一种安全、耐用且成本极低的 Amazon S3 云存储分层，用于数据归档和长期备份。为了将对象转换到 S3 Glacier 存储层，S3 提供了 Amazon S3 Intelligent-Tiering 存储层，这是唯一一个在数据访问模式发生变化时自动节省存储成本的云存储类，不会影响性能或运营开销。此外，S3 还提供了桶/对象生命周期策略，可以自动执行转换操作或终止操作。有效的归档策略有助于降低存储成本，同时保证了数据的可用性和持久性。
亚马逊云科技开发者社区为开发者们提供全球的开发技术资源。这里有技术文档、开发案例、技术专栏、培训视频、活动与竞赛等。帮助中国开发者对接世界最前沿技术，观点，和项目，并将中国优秀开发者或技术推荐给全球云社区。如果你还没有关注/收藏，看到这里请一定不要匆匆划过，点这里让它成为你的技术宝库！
Amazon S3 Intelligent-Tiering 存储层
本篇文章中详述的数据归档用例直接来源于亚马逊云科技客户——Primex Inc。Primex 是一个用于监测疫苗和医疗资产的复杂平台，它充分利用亚马逊云科技，围绕对象归档的现有资源，开发了一个解决方案，最终将对象转换到 S3 Glacier 存储层的成本降低了两个数量级以上。
Primex 公司的归档用例
在一个物联网设备群上运行的应用程序3年内产生了4.5亿个日志文件。这些日志文件在 S3 Standard 存储层上超过 40TB，平均每个日志文件约为 88KB。为了降低存储这些很少访问的数据的成本，Primex 考虑将这些数据归档至 S3 Glacier Flexible Retrieval (以前的 S3 Glacier)。由于生命周期转换成本与被转换的对象数量成正比，因为 Primex 有大量的小文件要转换到 S3 Glacier Flexible Retrieval (4.5亿)，通过有效的生命周期策略来归档的成本相对较高。因此，该解决方案的主要目标是尽量减少归档数据所需的生命周期转换次数。这是通过利用日志聚合和压缩来实现的。
S3 Glacier Flexible Retrieval (以前的 S3 Glacier)
日志大小对 S3 Glacier 存储成本的影响
转换到 S3 Glacier 存储层的对象在存储时，会增加 32KB 的数据，包含索引信息和相关的对象元数据。此外，S3 使用 8KB 的存储空间用于存储对象的名称和其他元数据，并按 S3 Standard 存储费用收费。这些元数据对象加在一起，允许您从 S3 中识别、列出和检索对象，无论它们处于什么存储层级。尽管任何大小的对象都可以被归档到 S3 Glacier 存储层中，但由于这种管理存储开销，归档小于 128KB 的对象时效率较低，最好建议在归档前聚合较小的对象。这可以确保生命周期转换成本和 S3 Glacier 存储开销成本最小化。S3 console 中的生命周期策略配置显示框特别提醒了这个问题，并提供了如何避免此问题的建议。
● 图1：生命周期策略成本警示信息
此外，有效的文件压缩协议（如 bzip2 或 gzip）可将存储需求降低一个数量级。就存储相关的成本而言，这意味着您可能以同样的成本存储十倍的数据。然而，压缩并不能减少需要通过生命周期转换归档到 S3 Glacier 存储层中的日志数量，因此，对象压缩对生命周期转换成本没有影响。
S3 Glacier 存储层为您提供了最低成本的云中归档存储。关于 S3 Glacier 存储层和相关费用的更多细节，请参见 S3 存储层 FAQs。
日志的数量对生命周期转换成本的影响
如果您有业务需要永久保留日志文件，同时减少存储成本，归档到 S3 Glacier 存储层是很好的选择。为了减少与生命周期转换相关的成本，将生成的日志数量降至最低至关重要。生成的日志数量取决于机群中设备的数量以及这些设备产生日志的频率（日志轮换策略）。一些应用程序通常按时间间隔轮换日志，而其他应用程序则按大小轮换日志。了解应用程序的日志行为和产生日志的设备数量，应该可以很好地估计出在某个时期产生的日志总数。知道了产生日志文件的数量，就可以通过利用 Amazon Pricing Calculator 来估计与生命周期转换相关的归档成本。
为了降低与生命周期转换相关的成本，我们必须减少转换到 S3 Glacier 存储层的对象数量。减少转换对象数量的一个有效方法是利用对象聚合的优势。例如，假设我们想把3.65亿个日志对象从 S3 Standard 转换到 S3 Glacier 存储层中的一个上。下图突出显示了近似的生命周期转换成本：
● 图2：对象聚合前的生命周期转换成本
通过将365个对象聚合到一个 tar 存档中，我们将转换到 S3 Glacier 存储层的次数减少到100万。在发表这篇博文的时候，100万个对象聚合后的生命周期转换成本大约是100美元。如数据所示，通过利用对象聚合，显著降低了进入 S3 Glacier 存储层的生命周期转换成本。
参考架构和源代码
在亚马逊云科技上设计一个解决此用例的方案有多种方式。这里介绍的参考架构是一种 producer/consumer 模式，满足以下要求。
- 档案中的文件
要嵌入存档的文件必须首先从 S3 中列出。
- 构建一个存档
要嵌入存档的文件必须从 S3 中读取。
- 归档压缩
生成的 tar 归档文件必须被压缩。
- 上传归档文件到 S3 Glacier 存储层
压缩后的归档文件被上传到所需的 S3 Glacier 存储层中。
一个完整的解决方案也会考虑到档案端到端生命周期的要求，包括对档案检索的影响。例如，通常应将要一起还原的对象聚合在一起。在时间数据的背景下，这将是按时间进行的，但也可以是通过各种索引、命名或前缀技术，如通过设备 ID 或其他唯一的描述符。将对象随机放置到档案中并不是一个好的策略，因为它最终会导致高的检索成本。具体来说，在设计 producer 应用程序时，为档案制定一个索引策略（如命名规则），来优化检索模式的成本。这个架构可以作为构建解决方案的起点，该解决方案可能会有额外的需求。
● 图3：Producer/consumer 归档参考架构
为了协调 producer 和 consumers 之间的处理，我们使用了 Amazon Simple Queue Service (SQS)。Amazon SQS 是一种完全管理的消息队列服务，使您能够解耦和扩展微服务、分布式系统和无服务器应用程序。SQS 消除了与管理和操作面向消息的中间件有关的复杂性和开销，并使开发人员能够专注于差异化的工作。使用 SQS，可以在任何数量的软件组件之间发送、存储和接收消息，而不会丢失消息或要求提供其他服务。
Amazon Simple Queue Service (SQS)
SQS Producer 是一个单线程的应用程序，运行在 Amazon EC2 实列上。它的功能是列出源 S3 存储桶中的对象并构建归档文本。归档文本对象是一个 JSON blob，它包含了归档文件（tar）中所有密钥的信息。然后，SQS Producer 将归档文本（工作项目）上传到可以被 SQS Consumers 处理的 SQS Standard Queue 中。
Amazon EC2 实列 SQS Standard QueueSQS Consumers 是多线程、分布式的应用程序，并在 EC2 instances 运行。它们的功能是检索和处理从 SQS 收到的存档文本。在检索到一个归档文本时，SQS Consumer 线程或实例将从 S3（异步）读取该文本中包含的所有对象。然后，它将把这些对象作为流写入压缩的归档文件流（tar.gz）中。一旦压缩的归档文件被创建，SQS Consumers 将把它上传到所需的 S3 Glacier storage class，并从 SQS 中删除归档文本。成功归档后，SQS Consumer 可以选择从源桶中删除归档文本中包含的对象密钥。
关于这个参考架构的更多细节，以及帮助建立这个解决方案的示例源代码。请查看此 GitHub 存储库：
https://github.com/aws-samples/amazon-s3-archive-builder?trk=cndc-detail
参考架构解决方案成本
解决方案整体成本的重要考虑因素是与提出的架构模式相关的亚马逊云科技成本。为了估计这个解决方案的成本，必须对要生成的存档数量和生成存档所需的时间（计算成本）做出一些假设。假设用例仍然是最初定义的那样：4.5亿个日志文件，S3 标准为 40TB，每个存档450个日志文件，产生100万个存档对象。我们还假设这个工作负载将在一个月内完成。
● SQS 的成本估算：每月100万条信息，SQS 成本为0.48美元。
● SQS Producer：不是计算密集型，可以在 Amazon EC2 free tier 上执行。
● SQS Consumers：取决于所使用实例的数量和类型，这一成本还取决于所需的性能。假设一个 8vCPU 实例，4GB 内存、8TB SSD、1Gbps 网络 ~ 149.72美元/月
● S3 Standard 成本：列出并读取4.5亿个日志文件 ~ 1,130美元/月
● S3 Glacier 成本：4TB/月 ~ 14.75美元/月
● Lifecycle 成本：0美元（因为应用程序直接上传到 Amazon S3 Glacier 存储层）。
● 共计：~1,294.95美元
归档到 S3 Glacier 存储层的未来考虑
提出正确的问题是优化工作负载的关键，有助于找到一条清晰、经济高效的备份/归档路径。是否可以通过修改应用程序的记录行为来减少生命周期的转换，从而降低成本呢？如果答案不明确，或者成本太高而无法有效实施，那么就会出现另一个问题：怎样才能将日志汇总并压缩到存档文件中，以降低与数百万次生命周期转换相关的成本呢？选择一个有可能重复使用的高效归档工具，并确保它的设计正确，这是一种很好的做法。请咨询亚马逊云科技解决方案架构师、 亚马逊云科技认证合作伙伴或亚马逊云科技专业服务部门来解决设计问题。此外，询问是否有办法进一步优化你的工作负载，找到一条清晰且经济高效的路径来实现对象归档。
Amazon S3 Glacier 存储层 (Amazon S3 Glacier Instant Retrieval, Amazon S3 Glacier Flexible Retrieval, and Amazon S3 Glacier Deep Archive) 是专门为数据存档而设计的，旨在提供性能最高、检索最灵活和成本最低的云归档存储。在使用 S3 Glacier 存储层提供的所有功能之前，必须要有一个将数据迁移过去的清晰简洁的计划。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。