使用快照管理自动创建快照

概览

AWS具有一个Lambda函数，可用于自动对特定地区运行的KDA（Kinesis数据分析）应用程序进行快照。请参考Lambda函数源代码此处。用户可以根据自己的需求修改Lambda函数。

注意：截至2023年8月30日，Amazon Kinesis 数据分析（KDA）已更名为亚马逊托管的Apache Flink服务。

它是用来做什么的？

• 对所有运行中的KDA应用程序进行快照。
• 获取每个KDA应用程序的快照数量列表。
• 检查快照数量是否大于指定的阈值。
• 如果超过阈值，则删除任何旧快照。

使用的资源

• Lambda函数
• CloudWatch事件（Amazon EventBridge）
• SNS主题
• AWS KDA（Kinesis数据分析）
• AWS DynamoDB表格（可选）

需要的IAM角色/策略

"资源": "*"

CloudWatch日志策略

"logs:CreateLogStream"

"logs:CreateLogGroup"

"logs:PutLogEvents"

Kinesis Analytics策略

"kinesisanalytics:ListApplicationSnapsots"

"kinesisanalytics:DescribeApplicationSnapshot"

"kinesisanalytics:DescribeApplication"

"kinesisanalytics:DeleteApplicationSnapshot"

"kinesisanalytics:ListApplications"

"kinesisanalytics:CreateApplicationSnapshot"

亚马逊SNS策略

"sns:Publish"

架构

当创建调度时，每次运行CloudWatch事件时，都会触发快照管理器Lambda函数，该函数将执行快照，并将通知发送到SNS主题。

注意：在大多数情况下可能不会使用DynamoDB（但如果需要在图表中存储有关快照的元数据，则显示在图表中）。

Lambda函数内部会发生什么？

• 当调用Lambda函数时，首先读取所有环境变量。
• 然后，调用以检索所有运行中的KDA应用程序的列表。
• 接下来，它遍历列表以检查每个KDA应用程序是否处于运行状态。如果没有，或者如果它目前不健康，则会抛出错误并向指定的SNS主题发送通知。
• 如果KDA应用程序正在运行，则对其进行快照。
• 初始化快照创建过程。如果超时，则会抛出错误并向SNS主题发送通知。
• 在成功完成快照后，会启动删除较旧快照的过程。
• 它检索所有快照列表并检查应用程序的快照计数是否超过配置为环境变量的最大数字。
• 如果数量超过最大值，则删除最旧的快照。

资源创建

SNS主题

• 创建一个SNS主题以发送电子邮件/任何其他有关快照失败的通知。
• 创建订阅该主题。
• 成功和失败的快照都发送到该主题。
• 可以更改为仅在失败时发送通知而不是每次成功的通知。
  • 失败后我们需要发送通知
  • 我们可能需要通过电子邮件接收通知
  • 配置消息以发送失败消息
    • 或者，您还可以发送通知到Slack

Lambda

• 首先，我们需要创建一个Lambda函数。选择Python作为语言，x86_64作为架构。
• 完成后，我们需要将快照管理器Python代码粘贴到编辑器中。我们还需要进行一些配置更改，如下所示。
• 将超时更改为约“X”分钟（可配置）以确保完成所有KDA应用程序快照。
• 添加一些环境变量：
  • aws_region: 获取在该区域运行的所有应用程序的列表
  • number_of_older_snapshots_to_retain: 保留旧快照的数量
  • snapshot_creation_wait_time_seconds: 在检查快照是否已完成之前等待这段时间。我们进行4次检查，如果在4次重试后仍未完成，则失败。
  • agents: 可以同时进行的并行快照数量。
  • realm:获取包含领域名称的管道列表
  • sns_topic_arn: 在失败时向其发送电子邮件通知的SNS主题的ARN。

Amazon EventBridge

• CloudWatch事件已更名为Amazon EventBridge。
• 我们可以创建一个按指定要求执行的规则。
• 在创建规则时，我们可以指定表达式运行的计划。这可以是cron作业表达式或固定频率。
• 我们需要确定这个规则需要被调用的频率，无论是每隔“X”天，小时还是分钟。
• 一旦计划定义好了，我们需要选择先前创建的Lambda函数。

示例设置

• 旧快照保留的数量：100（至少保留2天的快照）
• 频率：30分钟
• 同时运行的拍摄数量（并行性）：5

失败场景

以下是一些故障场景以及快照的帮助与否：

场景1

• 由于Flink中的错误，KDA管道已重新启动。
• 在这种情况下，KDA管道会自动重新启动。然而，它不会定期拍摄快照以应对故障。
• 在这里，Flink中每隔大约30秒至1分钟运行一次的检查点功能起到作用。管道将从最新的检查点恢复。

场景2

• 由于变更，比如糟糕的配置或源/同步变更，KDA管道陷入了重新启动循环。
• 在尝试更新KDA应用程序时，更新失败，因为应用程序在执行更新之前尝试拍摄快照。
• 由于KDA管道被卡在重新启动循环中，拍摄快照失败。在这种情况下，快照管理器的定期快照变得至关重要。
• 首先，我们需要停止管道的运行，执行所需的更改/更新，然后从最新的快照重新启动应用程序。
• 数据不会丢失，但可能会存在重复，因为管道将重新处理自上次快照以来的所有消息。可以添加去重功能来去除重复的消息。

场景3

• 在某些情况下，甚至无法拍摄单个快照，因为应用程序被卡在重新启动循环中。
• 在这种情况下，我们调整配置并重新启动管道，而没有拍摄任何快照。
• 在这种特殊情况下，将会丢失数据。