2013-02-06 9 views
6

私はEC2スポットインスタンス要求を行うためにJava AWS SDKを使用しています。オンデマンドのインスタンスとは対照的に、API for spot requestsClientTokenと似ていないので、そのままの冪等性をサポートしていません。AWSスポットインスタンス要求の冪等性の実装

これを行うために私が考えることができる最も簡単な方法は、LaunchGroupプロパティを一意のUUIDに設定することでした。私が確認すると、私はDescribeSpotInstanceRequestsに電話し、同じ打ち上げグループで既にリクエストがあるかどうかを確認します。

私の驚いたことに、記述コールが以前に送信されたスポットリクエストを返すまでに時間がかかるようです。私はこれについてJUnitテストを書いており、それが一貫しているためには、2つの呼び出し(リクエストのインスタンスとリクエストのインスタンス要求を記述する)の間に少なくとも60秒のタイムアウトを設定する必要があるようです。何らかの障害が発生した場合、リクエストがこの間隔でアプリケーションによって繰り返される可能性があります。つまり、要求を送信した後に何かが壊れてしまいましたが、Amazonから返された結果を読み取る前に、要求が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が60秒に設定されている場合は常にテストが行​​われます。断続的に動作します。これ以下のものは毎回失敗します。

誰もこの遅延を回避できましたか?現状の要求に対して、AWS APIのみを使用し、クライアントアプリケーションに状態を保存しないでidempotencyを実装できますか?

+0

この質問にもう少しコンテキストを追加する:これは、Axemblr Provisionr上で行っている作業の一部です。仮想マシンのプールを作成するのに役立つサービスです。 https://github.com/axemblr/axemblr-provisionr –

+1

興味深い問題 - 現在、[Bamboo AWS Plugin](https://www.windowsfiles.jp)のコンテキストでさまざまな同様のAPI遅延が発生したことを確認する以外には、 //plugins.atlassian.com/plugin/details/774227)、AWS APIは全面的にしか扱われていないと結論づけられました(http://en.wikipedia.org/wiki/Eventual_consistency)。例えば私は、作成呼び出しからリソースIDを受け取ったケースでも、そのIDに基づいてリソースにタグを付けることができましたが、まだそれが存在しないため(まだ)存在しないため、それ以降は記述しません。 –

+0

ありがとうSteffen!物事は時間とともに改善されることを願っています。 –

答えて

0

この場合、私はリクエストを繰り返すことは望ましくありません。私はちょうどそれが登録され、移動するのを見たいと思っています。

あなたが200のバックを持っていれば、それは登録されています。すぐには表示されないかもしれませんが、登録されているので、あなたの流れの中で進むことができます。

AWS APIのみを使用し、クライアントアプリケーションに状態を保存しないスポット要求の冪等性を実装していますか?

私はそう信じません。 AmazonのEMRと同じ問題があります。私がそれを回避する方法は、クラスターを観察することの仕事のコンポーネントを持つことです。私がEMRクラスターを要求すると、クラスターIDが返され、それをある観測者に渡します。オブザーバーは、そのクラスターが状態を変えるときに、他のコンポーネントを呼び出します。すぐにEMRによって承認されないことは有効なケースであり、例外のように扱われません。

それがあなたにとって適切かどうかはわかりません。おそらくSpotInstanceRequestIdを維持しようとする可能性があります。私の場合、私はそれらを記憶にとどめておくだけですが、必要であればそれらを永続的に保つことができます。

関連する問題