AWS EC2のスポット価格がオンデマンド価格より高いのはなぜですか？

昨日、Ansibleを介してスポットインスタンスをプロビジョニングしようとしていたため、スポット価格==そのインスタンスのオンデマンド価格を設定しても、ほとんどすべてのリクエストが失敗しました。

そのため、スポット価格グラフを見てみると、非常に興味深いことがわかりました。

us-east-1aのインスタンスのスポット価格はオンデマンド価格よりも高いため、混乱しました。[実際、〜5倍高い]

低コストのためにスポットインスタンスは好まれませんか？はいの場合、価格がオンデマンド価格より高いのはなぜですか？

AWSのドキュメントによると：

スポットインスタンスは、未使用のAmazon EC2容量へのアクセスを、オンデマンド価格に比べて大幅に割引して提供します。

また、これは人々がオンデマンド価格に入札していることを意味しますか？ はいの場合、なぜそうですか？オンデマンドインスタンスの方が良いとは思いませんか？

または、スポットインスタンスの概念を間違って理解しましたか？

これは実際に、人々がわずかに悪用している素晴らしい例です。人々は「私たちの作業負荷は本当に重要ですが、私たちは完全なオンデマンド価格を支払いたくない」と言っています。 「可能な限り安い」スポット価格を提供します。

人々がスポット市場の利益を望んでいるので、例えば、1000ドル（少なくとも一度はこれが起こったと言われています）に入る人々がいます。もちろん、当然のことながらある時点で需要が発生し、人々がオンデマンドよりも高い賃金を支払うためのスポット価格SOARS。

スポットマーケットの仕組みは、AmazonにXインスタンスの空き容量があり、すべてのXインスタンスのニーズを満たすまでトップからカウントダウンすることです。したがって、「価格」は、それらのXインスタンスを満たせる最低価格です。

Amazonに10,000個のインスタンスがあると想像してください。10,000個のインスタンスが満たされるまで、それらは（たとえば）$ 0.43にカウントダウンします。しかし、その供給が突然100インスタンスに低下した場合、100インスタンスに対して10,000ドルの入札価格を設定する人が数人いると、突然1時間あたり1万ドルを支払うことになります。

Tl; drスポットの仕組みを理解し、支払う準備ができている上限を設定します。

これには2つの理由があります。

• 多くのユーザーがスポットインスタンスを使用することがあります（バッチ処理について考え、スポットインスタンスとして100台のマシンを起動し、処理を終了します）。

• スポットインスタンスの場合、入札価格を支払うのではなく、現在のスポット価格を支払います。入札価格はカットオフポイントです。現在のスポット価格が入札価格のスポット価格を超える場合、AWSはそのインスタンスを終了します。

これが最後の理由で、一部のユーザーがスポット価格で大幅に高値を付けます。インスタンスが頻繁にシャットダウンすることを望まないため、スポット価格が到達しないほど高い価格で入札します。現在のスポット価格のみを支払うため、インスタンスは99％の時間でずっと安くなります。

誰かがオンデマンド価格で入札する理由を理解するのに役立つ情報は、スポットインスタンスの概要にあります。

スポットインスタンスを使用して、大量のコンピューティングキャパシティに対する不定期のニーズを満たすことができます（スポットインスタンスのデフォルト制限は、オンデマンドインスタンスのデフォルト制限20に対して100です）。ニーズが緊急の場合は、指定できます。高い最高価格（オンデマンド価格よりも高い可能性があります）。これにより、リクエストの相対的な優先度が上がり、他のリクエストとその時点で利用可能なスポットインスタンスの容量を考慮して、できるだけ多くの即時容量にアクセスできます。

サービスの需要が非常に急増している場合（他の人気サイトからリンクされている可能性があります- スラッシュドット効果を参照）、スポットインスタンスのオンデマンド価格を上回る入札は、より多くのインスタンスにアクセスするのに役立ちます。文書に記載されています。

もちろん、これは長期的には持続可能ではなく、オンデマンドのインスタンスを購入するだけで、長期的なコンピューティングの方がはるかに優れた取引を得ることができます（さらに、値上がりするリスクが少なくなります！）。

大量のコンピューティングパワーが必要な状況にいる場合は、オンデマンドインスタンスを購入するだけで得られる以上の速度で、過剰入札が理にかなっています。

チャートをよく見ると、スパイクは常に非常に短い期間であることがわかります。所有者が作成した自動監視システムがそれらのシステムを正常に終了するのに十分な時間です。さらに、スパイクの直後に価格が0に下がることがあります。これは、そのデータセンター内のすべてのシステムがオンデマンドシステムとして使用されており、スポット価格設定に利用できるシステムがなく、価格が事実上ゼロだからです。

スポットインスタンスに終了のフラグが立てられると、これを示すメッセージがシステム上のhttp://169.254.169.254/latest/meta-data/spot/termination-timeのローカルメタデータuriで利用可能になります。あります3分、それが終了するまで。ほとんどの場合、終了を自動的に処理するのに十分な時間です。需要価格を超える入札は、正常に終了するのに数分以上かかるデプロイメントにのみ必要です。

3分以内に正常に終了したり、データをアーカイブしたりするようにシステムを設計できない場合は、時間を稼ぐために需要価格よりも高い値で入札できます。システムは、現在のスポット価格を積極的に監視し、価格が終了する前に交換するように設計することもできます。ただし、そのような場合は、時間をかけて正常に終了する価値があるかどうかをビジネスで決定する必要があります。

システムを維持するために、4〜5時間で1時間あたり100ドルを支払うのは愚かです。ただし、システムがすべてのプロセスを正常に終了するのに30分かかる場合は、データを失う可能性のあるビジネス価値を決定するか、水平スケーリングされたサービスを低下させることができます。1時間あたり10,000ドルの純利益を持つ電子商取引サイトでは、デマンドシステムとアーカイブデータを立ち上げながら、15から30分間、2つのスポットインスタンスを実行するために1000ドルを支払う余裕があります。

WebベースのアプリケーションはElastic Load Balancerを使用して、終了に自動的に対処するのに役立ちます。賢明な実装者は、アラートを処理するための一連のスクリプトを配置します。ロードバランシングされた2つの低コストのオンデマンドインスタンスを維持できます。さらに、スポットインスタンスを介して最大6個の中コストシステムを使用して、高いパフォーマンスを維持し、同じ容量の単一のオンデマンドシステムをより少なく使用できます。

そのうち3人は1時間あたり100ドルまで、3人はオンデマンド価格の半分までしか支払いません。AWSがインスタンスを終了すると、ELBは自動的に調整します。わずか200ドルで調整するために、自動システムを最大1時間提供します。