スポットインスタンスは、基本的に現在無料のリソースを大幅な割引で販売しています。 さらに、インスタンスはいつでもオフにして元に戻すことができます。 この記事では、AWSからのこのオファーを使用する際の機能と実践について説明します。
スポットインスタンスを使用するコストは、時々変化する場合があります。 注文中に入札します-使用に対して支払う意思のある最高価格を示します。 最終的なコストを形成するのは、料金と無料リソースのバランスです。これは同時に、異なる地域や地域の可用性ゾーンでも異なります。
ある時点で、加重価格が通常のオンデマンドインスタンスの価格を超える場合があります。 だからこそ、過度の賭けをすべきではありません-あなたは本当に1時間あたり1000ドルでインスタンスを販売することができます。 どのような種類の入札を行うべきかわからない場合は、オンデマンドインスタンスの価格を指定します（デフォルトで使用されるものです）。
スポットインスタンスのライフサイクル
そのため、リクエストを作成し、AWSがインスタンスを提供します。 Amazonが発行されたインスタンスを必要とするか、価格が指定した制限を超えるとすぐに、リクエストは終了します。 これは、インスタンスが終了/休止状態になることを意味します。
また、リクエストのエラーによりリクエストがクローズされる場合があります。 そして、ここで注意する必要があります。 たとえば、リクエストを作成し、インスタンスを受け取りました。 そして、関連するIAMロールが削除されました。 リクエストはステータス「エラー」で終了します。 この場合、インスタンスは停止します。
そしてもちろん、いつでもリクエストをキャンセルできます。これは、インスタンスの一時停止にもつながります。
要求自体は次のとおりです。
- ワンタイム-インスタンスが当社から取得されるとすぐに、リクエストはクローズされます
- 永久-インスタンスは再包含後に返されます。
- 1〜6時間の保証サービス付き。
その結果、希望する100％の稼働時間を備えたサービスの2つの主なタスクがあります。
- 最適なスポットリクエストを生成する
- インスタンスのシャットダウンイベントを処理する
意味
最も強力なスポットクエリツールの1つはスポットフリートです。 これにより、指定された条件を満たすような方法でクエリを動的に形成できます。 たとえば、あるAvailabilityZoneでインスタンスの価格が上昇した場合、別のAvailabilityZoneで同じインスタンスをすばやく起動できます。 また、インスタンスの「重み」などの素晴らしい要素があります。 たとえば、タスクを完了するには、100個のシングルコアノードが必要です。 または50デュアルコア。 つまり、T2タイプのインスタンスの例では、100個のスモール、50個のラージ、または25個のxラージを使用できます。 コストと、要求が満たされない可能性の両方を最小限に抑えるのは、最適な配布と再配布です。 ただし、すべてのAvailabilityZonesに、パラメーターを持つインスタンスの数が適切でない可能性がまだあります。
幸いなことに、AWSは、停止することを決定してからシャットダウンするまでに2分かかります。 つまり、この瞬間にシャットダウンタイマーがリンクから戻り始めます。
http://169.254.169.254/latest/meta-data/spot/termination-time
このようなものは、デーモンとして実行できる単純なハンドラーのように見えます。
#!/usr/bin/env bash while true do if [ -z $(curl -Is http://169.254.169.254/latest/meta-data/spot/termination-time | head -1 | grep 404 | cut -d \ -f 2) ] then echo “Instane is going to be terminated soon” # Execute pre-shutdown stuff break else # Spot instance is fine. sleep 5 fi done
タスクを少し複雑にしましょう-インスタンスはElastic Load Balancer（ELB）に接続されています。 上記のスニペットからデーモンを使用して、APIを介してバランサーにステータスを通知できます。 しかし、もっとエレガントな方法があります-SeeSpotプロジェクト 。 要するに、デーモンは/ spot / termination-timeの両方と、オプションでサービスのヘルスチェックURLを調べます。 AWSがインスタンスを取り消そうとすると、ELBでOutOfServiceとしてマークされ、オプションで最終的なCleanUPタスクを完了できます。
そこで、シャットダウンを適切に処理する方法を見つけました。 突然インスタンスを取得することにした場合にのみ、必要なシステムパフォーマンスを維持する方法を学習する必要があります。 ここでは、 自動スポッティングプロジェクトが役立ちます。 アイデアは次のとおりです。オンデマンドインスタンスを含む通常の自動スケーリンググループを作成します。 自動スポッティングスクリプトはこれらのインスタンスを検出し、一度に1つずつ完全に対応するスポットインスタンスに置き換えます（検索はタグによって実行されます）。 自動スケーリンググループには独自のヘルスチェックがあります。 メンバーの1人がテストに失敗するとすぐに、グループはボリュームを取り戻そうとし、元のタイプ（オンデマンド）の「正常な」インスタンスを作成します。 このようにして、たとえば価格の上昇を待つことができます。 スポットリクエストが再び満たされるとすぐに、自動スポッティングは段階的な交換を開始します。 プロジェクトは非常に質的に作成されており、とりわけ、テラフォームまたはクラウドフォーメーションを使用した構成のアプローチを持っていることを自分で付け加えます。
結論として、可能な限りステートレスサービスにスポットインスタンスを使用することをお勧めします。 または、S3 / EFSを使用します。 ECS構成の場合、タスクの再調整について考える必要があります。