EKS上Spring Boot应用调用AWS SageMaker/Feature Store高延迟排查

我们近期为某业务场景集成了AWS SageMaker与FeatureStore服务，通过CloudWatch观测到：SageMaker的p99延迟为50-60ms（含开销+模型），FeatureStore的p99延迟为15-20ms。但在部署于EKS的容器化Spring Boot应用中，使用AWS Java SDK 2.0调用这两个服务时，却观测到较高延迟：SageMaker的p99延迟约180ms，FeatureStore约100ms。

以下为客户端初始化示例代码及依赖配置：

FeatureStore调用代码 #

private static SageMakerFeatureStoreRuntimeClient featureStoreRuntimeClient;

@PostConstruct
public void init() {
    ClientOverrideConfiguration clientOverrideConfiguration = ClientOverrideConfiguration.builder()
            .apiCallTimeout(Duration.of(featureStoreConfig.getApiCallAttemptTimeout(), ChronoUnit.MILLIS))
            .retryPolicy(RetryPolicy.builder().numRetries(0).build())
            .build();

    featureStoreRuntimeClient = SageMakerFeatureStoreRuntimeClient.builder()
            .overrideConfiguration(clientOverrideConfiguration)
            .credentialsProvider(DefaultCredentialsProvider.create())
            .region(Region.AP_SOUTHEAST_1).build();
}

SageMaker调用代码 #

private static SageMakerRuntimeClient sageMakerRuntimeClient;

@PostConstruct
public void init() {
    ClientOverrideConfiguration clientOverrideConfiguration = ClientOverrideConfiguration.builder()
            .apiCallTimeout(Duration.of(sageMakerConfig.getApiCallAttemptTimeout(), ChronoUnit.MILLIS))
            .retryPolicy(RetryPolicy.builder().numRetries(0).build())
            .build();

    sageMakerRuntimeClient = SageMakerRuntimeClient.builder()
            .overrideConfiguration(clientOverrideConfiguration)
            .credentialsProvider(DefaultCredentialsProvider.create())
            .region(Region.AP_SOUTHEAST_1)
            .build();
}

依赖配置 #

<dependency>
  <groupId>software.amazon.awssdk</groupId>
  <artifactId>sagemakerruntime</artifactId>
  <version>2.20.26</version>
</dependency>

<dependency>
  <groupId>software.amazon.awssdk</groupId>
  <artifactId>sagemakerfeaturestoreruntime</artifactId>
  <version>2.20.26</version>
</dependency>

• 网络链路差异：CloudWatch统计的是AWS服务端内部或同区域低延迟链路的处理延迟，而EKS容器到AWS服务的请求若未配置VPC端点，会经过NAT网关、公网路由，往返时间（RTT）大幅增加。需检查是否配置对应服务的VPC端点，确保请求走AWS内部网络。
• SDK HTTP客户端性能不足：AWS SDK 2.x默认使用URLConnection作为HTTP客户端，不支持连接池和多路复用，高并发下频繁建立TCP连接会产生显著开销。建议切换到Netty或Apache HttpClient实现，通过连接复用减少连接建立时间。
• 凭证获取开销：DefaultCredentialsProvider会依次尝试多种凭证获取方式，若EKS未配置IRSA（IAM Roles for Service Accounts），容器可能多次尝试才能拿到凭证，每次请求都会产生额外延迟。建议配置IRSA让Pod直接关联IAM角色，降低凭证获取耗时。
• SDK版本陈旧：使用的2.20.26版本发布于2023年初，后续版本针对网络连接、重试逻辑、序列化性能有不少优化，升级到最新稳定版可能缓解延迟问题。
• 序列化/反序列化开销：请求或响应的payload序列化（如JSON处理）可能占用大量CPU时间，尤其是数据量较大时。可检查序列化逻辑，尝试使用更高效的序列化配置（如Jackson性能优化参数）。
• EKS集群资源瓶颈：若EKS节点的CPU、内存或网络带宽被耗尽，容器进程会被调度限流，导致请求处理延迟上升。可通过监控节点的CPU使用率、网络吞吐量等指标，确认是否存在资源不足情况。
• 隐性重试或超时等待：虽配置了numRetries(0)，但apiCallTimeout是整个请求的超时时间，若请求过程中出现DNS解析失败、TCP连接超时等情况，即使不重试，等待超时的时间也会被计入总延迟。建议添加详细的SDK日志，排查是否存在这类隐性等待。
• DNS解析延迟：EKS容器的DNS配置不合理时，每次请求AWS服务都需花费较长时间解析域名。可在容器内执行nslookup测试域名解析耗时，确认是否存在DNS性能问题。

内容的提问来源于stack exchange，提问作者tusharRawat