关于减少 Amazon Managed Service for Apache Flink 中 Flink 应用程序更新的影响的问题

Question

我们通过 Amazon Managed Service for Apache Flink 部署了 Flink 应用程序。整个应用程序在运行时按预期执行。但在 Flink 应用程序升级过程中，我们在维持吞吐量方面遇到了挑战。

设置：

从高层次来看，这是一个实时流应用程序：

业务事件将进入源 Kinesis 流

来源：使用 EFO（增强型扇出）轮询上述 Kinesis Stream 然后，Flink App 处理并转换数据 目标接收器：这是 Sagemaker 功能组的自定义接收器（您可以将其视为目标数据库）

通过管道运行的记录

Kinesis -> Flink -> Sagemaker Feature group (the target database)

将经历大约 100 - 200 毫秒的延迟。

有些下游应用程序期望记录在 1 秒内到达目标 Sagemake 功能组（原始事件到达 Kinesis 流后）。

我们扩展到至少 8 个 KPU。

我们面临的问题：

在新版本的 Flink jar 更新期间（例如从

version1.jar

更新到

version2.jar

），我们将面临一到两分钟的停机时间。我们使用 Terraform 更新 Flink jar s3 前缀

application_code_configuration {
  code_content {
    s3_content_location {
      bucket_arn = "s3://example_bucket"
      file_key   = version2.jar       <--- update to new jar setup
    }
  }

放大后其他部分不变，只是更新了jar。

我们注意到，记录的端到端延迟（我们有一个监视器设置来监视记录到达 Kinesis 时到其推送到接收器时的延迟）将达到 20 秒或更长。

指标

millisbehindLatest

（来自 https://docs.aws.amazon.com/management-flink/latest/java/metrics-dimensions.html）也会跳至 10 - 20 秒或更长时间。指示 flink 不落后于最新的 kinesis 流。

最终在 1 - 2 分钟后，两条记录的平均延迟和

millisbehindLatest

将恢复到正常速度。

但是依赖目标数据库（Sagemaker 功能组）及时填充的下游应用程序将受到延迟的影响。

我们的理解是，这是由于 flink 正在重新加载 + 重新分配 kinesis 分区 + 从检查点重新加载。因此不会丢失任何数据（因为数据是从检查点 + 最后一个运动流位置加载的）。

我们的问题：

AWS Support 提到，像我们上面看到的那样，在 jar 更新期间，flink 摄取/传出“较慢”是“正常的”。但无法提供什么是“平均中断时间”（1 - 2 分钟正常吗？

那么想知道 Amazon Managed Service for Apache Flink 的其他用户是否也遇到类似的问题？减少它的建议是什么？

我们内部思考：

我们的应用程序性质可能会在一段时间内将数据输出到目标数据库（Sagemaker 功能组）以包含旧数据/新数据

升级期间，我们会

• 在更新期间与旧的 Flink 应用程序并行启动新的 Flink 应用程序（蓝色/绿色）
• 新申请完成后，将终止 旧的 flink 应用程序（或者只是停止它，在未来的更新中用作下一个“绿色”）

这比较复杂，但会减少更新造成的停机时间。

我们的应用程序能够承受两个 Flink 应用程序写入同一目标（最新记录将覆盖之前写入的记录）+可能使用较旧的 Flink 应用程序是最新记录。

但想知道其他人是否有更好的想法来做到这一点。

谢谢！

Answer 1

您可以通过减少检查点间隔来减少新 jar 部署后“赶上”所需的时间。但我没有找到一种方法可以在此过程中将延迟保持在 1 秒以下，因为 AWS 必须拆除（使用保存点）当前的 Flink 作业，然后重新部署（从保存点）。

所以我认为您运行第二个 Flink 作业的建议可能是最好的选择。当然，您需要小心地从第一个作业的保存点开始该作业，以确保结果一致（重复）。