2013-02-06 2 views
6

저는 EC2 스팟 인스턴스 요청을하기 위해 자바 AWS SDK를 사용하고 있습니다. 온 디맨드 인스턴스와 달리, API for spot requestsClientToken과 유사하지 않으므로 즉시 멱등 원 (idempotency)을 지원하지 않습니다.AWS 스팟 인스턴스 요청에 대한 멱등 원 (imempotency) 구현

내가 이것을 생각할 수있는 가장 쉬운 방법은 LaunchGroup 속성을 고유 한 UUID로 설정하는 것이 었습니다. 내가 그걸 확인하면 DescribeSpotInstanceRequests라고 전화해서 이미 같은 발사 그룹의 요청이 있는지 확인합니다.

놀랍게도 설명 호출이 이전에 전송 된 스팟 요청을 반환하기까지 지연이있는 것으로 보입니다. 이것에 대한 JUnit 테스트를 작성했는데 일관성을 유지하기 위해 두 호출 (요청 인스턴스 인스턴스 및 지점 인스턴스 요청 설명) 사이에 적어도 60 초의 시간 초과를 설정해야하는 것으로 보입니다. 실패한 경우 (즉, 요청을 보낸 후 중단되지만 아마존에서 돌아온 결과를 읽을 수 있기 전에) 요청이이 간격으로 응용 프로그램에 의해 반복 될 수 있기 때문에 10 분의 세분화가 필요합니다. 이 경우 요청을 반복하지 않으려 고합니다. 단지 등록 된 것을 확인하고 계속 진행하고 싶습니다.

@Test 
public void testRunSpotInstances() throws Exception { 

    activity.execute(execution); 

    timeout(TIMEOUT); 

    // shouldn't do anything 
    activity.execute(execution); 

    timeout(TIMEOUT); 

    DescribeSpotInstanceRequestsResult result = client.describeSpotInstanceRequests(
      new DescribeSpotInstanceRequestsRequest().withFilters(new Filter() 
       .withName("launch-group").withValues(BUSINESS_KEY))); 

    assertThat(result.getSpotInstanceRequests()).hasSize(1); 

    timeout(TIMEOUT); 
} 

TIMEOUT이 60s로 설정된 경우마다 테스트가 작동합니다. 40-50 초 동안은 간헐적으로 작동합니다. 이보다 작은 항목은 매번 실패합니다.

누구든지이 지연을 피할 수 있었습니까? 스팟 요청에 대해 idempotency를 구현하는 것이 AWS API만을 사용하고 클라이언트 애플리케이션에 상태를 저장하지 않는 것입니까?

+0

이 질문에 조금 더 많은 컨텍스트를 추가하려면 : 이것은 우리가 Axemblr Provisionr에서 수행중인 작업의 일부입니다.이 서비스는 가상 시스템 풀을 만드는 데 도움이 될 수 있습니다. https://github.com/axemblr/axemblr-provisionr –

+1

흥미로운 이슈 - 현재 [Bamboo AWS Plugin]의 컨텍스트에서 다양한 유사한 API 지연이 발생했음을 확인하는 것 외에 다른 것을 추가 할 수 없습니다 (https : //plugins.atlassian.com/plugin/details/774227) AWS API는 전체적으로 만 [_eventually consistent_] (http://en.wikipedia.org/wiki/Eventual_consistency)로 취급되어야한다고 결론지었습니다. 예 :, 내가 만든 호출에서 리소스 ID를받은 경우도 발생했습니다. 리소스는 id를 기반으로 태그를 붙일 수는 있지만 아직까지는 존재하지 않기 때문에 나중에 설명하지는 않습니다. –

+0

감사합니다. Steffen! 나는 일이 시간이 지남에 따라 향상되기를 바랍니다. –

답변

0

그런 경우에는 요청을 반복하고 싶지 않습니다. 단지 등록 된 것을보고 싶습니다.

200이면 다시 등록됩니다. 금방 나타나지는 않겠지 만 등록되어있어 당신의 흐름 속으로 나아갈 수 있습니다.

AWS API 만 사용하고 클라이언트 응용 프로그램에 상태가 저장되지 않은 스폿 요청에 대해 멱등 원을 구현합니까?

나는 그렇게 생각하지 않습니다. Amazon의 EMR과 같은 문제가 있습니다. 내가 해결할 수있는 방법은 클러스터를 관찰하는 일을하는 구성 요소를 갖는 것입니다. EMR 클러스터를 요청하면 클러스터 ID가 반환되어 일부 관찰자에게 전달됩니다. 관찰자는 클러스터가 상태를 바꿀 때 다른 구성 요소를 호출합니다. EMR에 의해 즉시 승인되지 않는 것은 유효한 경우이며 예외처럼 취급되지 않습니다.

나는 그것이 당신에게 적합한 지 잘 모릅니다. 아마도 SpotInstanceRequestId을 유지하려고 할 수 있습니다. 제 경우에는 기억 속에 남겨 두지 만, 필요하다면 그것들을 어딘가에 보관할 수 있습니다.

관련 문제