经过

在某项服务中进行用户行为分析时，我们需要一个系统来接收日志数据并尽可能实时地进行加工和输出，因此我们决定进行调查以了解如何构建这个系统。
在此过程中，我觉得以下资料非常有用，特此做个备忘记录。

总结

日志管理的最佳实践

这是AWS日本解决方案架构师提供的资料。通过使用AWS，我能够学习很多实用的经验和技巧。

将数万个日志秒级处理的架构优化成更加流畅的状态。

Cookpadのログへの考え方からシステムの変遷まで書かれていて、ログというものへの全体像を実感するのにとても役立ちました

【2016年AWS峰会东京发言内容】关于Townwork的无服务器架构设计

• 前編

 

• 後編

 

「タウンワークにおけるサーバーレスアーキテクチャ」AWS Summit Tokyo 2016 登壇記

无服务器架构的模式化用例。

每个组成部分

运动感知

这对于暂时接收数据非常方便。Kinesis分为三种服务：Streams、Firehose和Analytics。

Kinesis流

“Kinesis火导”

Amazon Kinesis Streams和Amazon Kinesis Firehose有何不同之处？

比较Amazon Kinesis Stream和Amazon Kinesis Firehose的API #reinvent

尝试运行AWS Kinesis Firehose

Kafka和AWS Kinesis的比较

我学到了与AWS以外的服务进行比较、以及学习不受AWS限制的系统架构等内容。

使用fluent-plugin-kinesis将日志发送到Kinesis Streams。

这个例子非常实用，非常值得参考。

使用流利的插件 fluent-plugin-kinesis-firehose 将日志传输到 Amazon Kinesis Firehose。

在Firehose版本中，这也是一个很有参考价值的。

结合的例子

整理AWS Lambda在Kinesis Stream上的并发启动数和数据提取方式。

我对Kinesis Streams和Lambda的组合方法有了一些学习。

使用Fluentd、Kinesis和Lambda构建灵活且高可用性的日志收集基础架构。

Fluentd -> Kinesis -> Lambda -> [S3, DynamoDB…] などの流れが明快にわかってとても参考になります

使用API Gateway、Lambda和Kinesis来实现流式批处理执行平台。

这个考察很细致，并且非常易于理解。

通过将Kinesis Producer Library（KPL）、fluentd和Lambda协同工作，提高Kinesis的吞吐量。

关于第二篇文章，已经添加了解释，很容易理解。

数据存储

亚马逊DynamoDB

既然这是一个公式，我先浏览一下。

API网关

暂时来说，API网关给我留下了非常方便的印象。
我一直在纠结是选择EC2好呢，还是API网关+Lambda好呢，但其实最主要的是学到了有很多不同的使用方式。

这是一个入门级的资料。

在Amazon API Gateway中设置自定义域名作为API主机名。

【新功能】Amazon API Gateway支持ACM（AWS证书管理器）。轻松将自定义域名的API实现SSL化。| Developers.IO

启用API Gateway资源的CORS – 亚马逊API Gateway

将API Gateway的API的请求参数进行映射 – 亚马逊API Gateway。

如何将参数从Amazon API Gateway传递到AWS Lambda – Qiita

将EC2迁移到Lambda上

使用AWS自家製的aws-serverless-express，通過APIGateway + Lambda + Node + Express來最快地建立RESTful服務的模板- Qiita

因为我想将已经搭建在Express上的服务迁移到Lambda上，所以这个工具帮了我大忙。

从AWS Lambda中获取IAM Role的凭证信息，并用于Redshift的COPY处理。

由於每次都在權限問題上出現各種混亂，所以這樣的文章真的很有幫助。