Category: AWS

Amazon SQS 触发 AWS Lambda 及重试/DLQ

2018-10-02 | 阅读(1,321)

Amazon 在 2018 年 6 月份宣布可以设置用 SQS 来触发 Lambda，SQS 不再是单纯用于 ECS 服务中，或用于伸缩控制的。这儿就来亲自尝试一下用 SQS 驱动的 Lambda，以及要注意的要素。

首先使用 Java 编写 Lambda 的话，AWS 在 com.amazonaws:aws-lambda-java-events:2.20 版本开始加入了 com.amazonaws.services.lambda.runtime.events.SQSEvent 类，可是这个版本的 aws-lambda-java-events 是有所限的，因为 SQSEvent.SQSMessage 类是私有的，这就造成不能获取到 SQSEvent 中的记录数据。

//下面的操作代码无法编译，因为 SQSEvent.SQSMessage 是私有的，不可访问
SQSEvent.SQSMessage sqs = sqsEvent.getRecords().get(0); 
sqsEvent.getRecords().get(0).getBody();

Java 使用 SQS 来驱动 Lambda 的话，至少需要 com.amazonaws:aws-lambda-java-events:2.2.1 版本，从此 SQSEvent.SQSMessage 变成 public 了。该版本是于  2018 年 6 月传到 Maven 官方中央仓库的，这就是那时才能真正用来写 Java 的 SQS 触发的 Lambda.

同时此篇也是作为上文 AWS Lambda 重试与死信队列(DLQ) 的一个很重要的补充。在此也会验证 SQS 触发的 Lambda 的重试机制以及 DLQ 相关的内容。 阅读全文 >>

AWS Lambda 重试与死信队列(DLQ)

2018-09-30 | 阅读(1,295)

AWS Lambda 允许设置 Debugging and error handling, 在 Lambda 出现异常，达到最大的重试次数后，把以下信息放到选择的 SNS 或 SQS 主题作为死信队列(DLQ - Dead Letter Queue)，包括

  1. 原始 Lambda 接收到的消息(基于 SNS 和 SQS 消息的总大小，可能会被截取，本人猜测，尤其是 Kinesis 的消息会比较大)
  2. 原始 Lambda 的 RequestId
  3. ErrorCode（三位数字的 HTTP 错误码）
  4. ErrorMessage, 即原 Lambda 抛出 Exception 的 getMessage() 信息，截取 1 KB 字符串

并且 Lambda 要使用 DLQ 的话还必须设置当前 Lambda 的 IAM role 有对于 SNS/SQS 主题相应的 sns:Publish 和 sqs:SendMessage 权限。

AWS Lambda 基本重试规则：对于 Kinesis 消息会无限重试直至消息过期，对于 SNS 或 SQS 的消息出现异常后会再重试两次。参考：AWS Lambda Retry Behavior。

而在重试次数用完后仍然失败，并且设置了 DLQ 的话就会发送消息到 DLQ 中去。 阅读全文 >>

AWS S3 应用 KMS Key 进行服务端数据加密

2018-05-13 | 阅读(2,403)

当我们把数据搬上云端，为了保护敏感数据一定要对数据存储进行加密。而对于 S3 上的数据加密最简单莫过于启用服务端数据加密，可以是 AES-256 或 AWS-KMS。进行了服务端加密码的文件有什么不同呢？首先从 AWS S3 文件列表视图中看到的文件大小与原始文件大小是一样的，其实数据在 AWS 机房是加密存储了的，比如说直接在 AWS 服务器上拷出那些 S3 文件是不能理解的。

本文涉及的内容包括：

  1. 服务器端加密后的 S3 文件有何不同
  2. 不启用 Bucket 的默认加密如何进行服务端数据加密(含 AWS CLI 和  Java 代码操作)
  3. 启用及应用 Bucket 的默认加密
  4. 上传与下载文件的 IAM role 需要的权限

服务器端加密后的 S3 文件有何不同

首先看现象，后面才能确认我们的操作是否对数据真的进行了服务端加密。查看使用 AWS-KMS key 加密后的 S3 文件的 Overview, 看到下面两个属性

Server-side encryption
AWS-KMS
KMS key ID
arn:aws:kms:us-east-1:123456789012:key/e4ce859b-786b-4b8e-8b73-4968adb6e4ed

没加密的话, Server-side encryption 是 None, 并且没有 KMS key ID 属性。 阅读全文 >>

AWS Batch 是如何向 Docker 容器传递参数

2018-04-01 | 阅读(868)

AWS Batch 提供了简单有效的方式来运行 Docker 镜像，在单纯执行一个计算任务时比 ECS 使用起来要方便许多。AWS Batch 在提交任务时可以执行 command, environment 和 parameters, 那么它将如何传递那些参数给 Docker 容器呢？

首先看一下提交任务的脚本

注：aws cli 命令参数中有 - 时需要用  --parameters='--name=Spring' 等号的格式

我们将用上面的脚本提交一个任务，然后用 docker inspect <container-id> 观察 Docker 容器收到了什么参数

也没什么意外的，inspect 容器后我们看到 阅读全文 >>

AWS SQS 队列的 DLQ 设置与行为

2018-03-29 | 阅读(1,533)

和 Lambda 类似，AWS 的  SQS 队列也提供了 DLQ(Dead Letter Queue) 来支持重试功能，可以设定某一个消息在接收多次重新变得可见后进入到另一个 SQS 队列中。比如说队列 user-id-queue，设定了它的 Redrive Policy 为三次接收后转入到另一个 SQS 队列 user-id-dlq, 就会显示为

Maximum Receives 3
Dead Letter Queue arn:aws:sqs:us-east-1:<account_id>:user-id-dlq

在运用 SQS 的 DLQ 之前首先要理解 SQS 中消息的几个概念
  1. Message Available:  SQS 客户端可以获取到的消息, 即 Visible Messages
  2. Messages in Flight: 消息被 SQS 收取了之后，由 Available 转为 In Flight, 该状态的消息不能被客户端接收到
  3. Visibility Timeout:  消息停留在 In Flight 状态的时间, 如果在 Timeout 之前未删除这个消息，该消息重新变为 Available 状态

我们可以设置 SQS 队列的默认 Visibility Timeout 大小，也可以在代码中收取消息时指定这个值。

所以我们能够在集群环境中应用 SQS 的这个特性让多个节点同时监听单个 SQS 队列，基本上保证每个节点处理各自不同的消息。有一种例外就是：假设我们设置了 Visibility Timeout 是 30 秒，客户端 1 获取到消息后，消息变为 In Flight 状态，但 30 秒后仍然在处理过程中，此时消息回到Available 状态，客户端 2 也能获取到该消息，这也会造成单条消息的重复处理。解决的办法之一是适当延长 Visibility Timeout 的时间，给予第一个客户端更充分的处理时间。 阅读全文 >>

推送 Docker 镜像到 Amazon ECR 仓库

2018-01-30 | 阅读(3,209)

Docker 镜像在未指定仓库时默认是从  Docker Hub 拉取的。如果需向 Docker Hub 推送镜像的话还可用 docker login 在交互中完成登陆 Docker Hub 的操作。docker login 的命令格式是

docker login [OPTIONS] [SERVER]

所以我们可以连接到任何的 Docker 镜像仓库，也可以是本机，但我们这里所要介绍的是如何推送镜像到 AWS 给我们提供的 Docker 镜像仓库(Amazon ECR - Amazon Elastic Container Registry)。每个帐号下都有自己独立的仓库，镜像推送到了  Amazon ECR 后我们能够很方便的在 ECS, Batch 服务中使用它，也可以从 ECR 拉取镜像到本地来。

首先我们来做一个运行 Spring Boot Web 的简单的 Docker 镜像，假定已用 mvc pacakge 生成了一个可独立运行的 jar 包 java-webapp-0.0.1-SNAPSHOT.jar 。该应用开启一个 Web 服务，访问 http://localhost:8080 显示一行字符串 Hello World!

创建一个目录 aws-docker, 并把 java-webapp-0.0.1-SNAPSHOT.jar 移入该目录，在其下创建 Dockerfile 文件，文件目录结构如下：

aws-docker
  ├── Dockerfile
  └── java-webapp-0.0.1-SNAPSHOT.jar

阅读全文 >>

实现 Amazon S3 数据(文件)分段上传

2017-12-07 | 阅读(10,112)

探索是否能以流式写数据到 S3

通常，在我们项目中用 Java 代码上传数据到 S3 是下面那样的操作

AmazonS3 s3Client = AmazonS3ClientBuilder.defaultClient();
s3Client.putObject("bucket_name", "s3key.txt", new ByteArrayInputStream("hello".getBytes()), new ObjectMetadata()); //ObjectMetadata 没什么特别的话可以为 null

虽然  putObject() 的第三个参数是一个流，但它是输入流, 并非输出流啊。也就是说在执行该方法时必须把所有待上传的上据全部准备在这个输入流中，所以这里就直接用一个 ByteArrayInputStream 来包裹需上入到 S3 的数据内容。

当然 putObject() 也就无法像 FileObjectOutputStream 那样流式写入内容到文件中，因为 putObject() 前后都没有与 bucket 上那个文件上有联系。即使是用 PipedInputStream/PipedOutputStream  也不行, 比如说下面的代码 阅读全文 >>

Terraform 进阶 - 部署 Lambda 并创建相关资源

2017-08-28 | 阅读(2,909)

昨日刚刚体验了 Terraform 是一个什么鬼东西 Terraform 使用 - 从最简单例子开始，今天再进一步。将来尝试的是使用 Terraform 来部署一个 Lambda 应用，并创建相关的资源。

本例中的 Lambda 要由 Kinesis 来触发，并写数据到 S3 Bucket 中去，所以需要做的事情大致如下：

  1. 创建 IAM Role, 该 Role 要能访问 S3, Kinesis 和 CloudWatch
  2. 创建一个 Kinesis Stream (指定 Shard 数目)
  3. 创建一个 S3 Bucket
  4. 部署 Lambda (要指定能访问 S3 Bucket 的 Role, 并其他参数，如环境变量)
  5. 设置 Lambda 的 Kinesis 触发器 (指定源 Kinesis Stream 和  batchSize)

以下是 Lambda 的实现代码，从 Kinesis 读出字符串，逗号分割，第一部分作为 S3 Key, 第二部分作为文件内容写入到 S3 Bucket 中去。S3 Bucket 名称从环境变量中读取。 阅读全文 >>

Terraform 使用 - 从最简单例子开始

2017-08-26 | 阅读(28,758)

Terraform 是一个 IT 基础架构自动化编排工具，它的口号是 "Write, Plan, and create Infrastructure as Code", 基础架构即代码。具体的说就是可以用代码来管理维护 IT 资源，比如针对 AWS，我们可以用它创建，修改，删除 S3 Bucket, Lambda, EC2 实例，Kinesis， VPC 等各种资源。并且在真正运行之前可以看到执行计划(即干运行-dryrun)。由于状态保存到文件中，因此能够离线方式查看资源情况 -- 当然，前提是不要在 Terraform 之外对资源进行修改。

Terraform 配置的状态除了能够保存在本地文件中，也可以保存到 Consul, S3, azure, http, swift 等处。

Terraform 是一个高度可扩展的工具，通过 Provider 来支持新的基础架构，AWS 不过为目前官方内建 68 个 Providers 中的一个。其他能用 Terraform 的地方有 Alicloud(阿里云, 实名制备案才能用), Google Cloud, Heroku, Kubernetes, Microsoft Azure, MySQL, RabbitMQ, Docker 等等。愿意的话可以写自己的 Provider, 如搞个 Kafka 的话，用来管理 Topic 等的创建，维护工作。

Terraform 之前我们对 AWS 的操作用的是 awscli, 或 Serverless。awscli 什么都能做，但它是无状态的，必须明确用不同的命令来创建，修改和删除。Serverless 不是用来管理基础架构的，用它创建  Lambda 时创建资源都是很麻烦的事。AWS 提供的 CloudFormation 才是与 Terraform 较类似的工具，但是看到用法就头疼。 阅读全文 >>

AWS Lambda 按序处理同一个 Kinesis Shard 中的消息

2017-05-19 | 阅读(1,263)

当 AWS Lambda 由 Kinesis 消息来触发时，一个 Kinesis Shard 会相应启动一个 Lambda 实例，比如说 Kinesis Stream 有 5 个 Shards, 那同时只会启动 5 个 Lambda 实例。那么把多条消息发送到同一个 Kinesis Shard 中去，这些消息会被如何消费呢？答案是按顺消息，不管这些消息是否被不同的 Lambda 实例处理。本文就是关于怎么去理解 https://aws.amazon.com/lambda/faqs/ 的下面那段话的内容：

Q: How does AWS Lambda process data from Amazon Kinesis streams and Amazon DynamoDB Streams?
AWS Lambda 如何处理来自于 Amazon Kinesis 和 DynamoDB 的数据
The Amazon Kinesis and DynamoDB Streams records sent to your AWS Lambda function are strictly serialized, per shard. This means that if you put two records in the same shard, Lambda guarantees that your Lambda function will be successfully invoked with the first record before it is invoked with the second record. If the invocation for one record times out, is throttled, or encounters any other error, Lambda will retry until it succeeds (or the record reaches its 24-hour expiration) before moving on to the next record. The ordering of records across different shards is not guaranteed, and processing of each shard happens in parallel.
从 Kinesis 和 DynamoDB 单个 Shard 上的记录会被 Lambda 严格的按序处理。这意味着如果你送两条记录到相同的 Shard, Lambda 将会保证第一条记录成功处理后才会处理第二条记录。假如处理第一条记录时超时，或超过资源使用上限，或碰到任何错误， Lambda 将会不断重试直到成功(或记录在 24 小时后过期), 而后才会去处理下一条记录。跨 Shard 的记录不保证到达顺序，且是并行处理多个 Shard 来的记录。

可以做几个试验，下面的代码可以保证消息总是被发送到同一个 Kinesis Shard，因为 PartitionKey 参数是一个常量 阅读全文 >>