Spotを理解する

この単元で学ぶこと

• Spotの余剰容量と中断の性質を説明する
• 再試行・チェックポイント・外部保存を設計する
• 柔軟な容量選択と完了期限を両立する判断を行う

本文解説

1. 余剰容量を使う Spotは空いているEC2容量を利用する方式で、オンデマンドより低い料金が期待できます。その代わりAWSが容量を必要とすると中断される可能性があります。割引率は条件で変わり、安価であることが必要な時刻の起動や継続実行を保証するわけではありません。再実行できる画像処理やバッチを例に考えます。

2. 中断と通知 中断時には終了が基本で、条件に応じて停止や休止を指定する構成もあります。停止・終了では通常2分前の中断通知が案内されますが、通知はベストエフォートです。休止の場合は休止がすぐ始まり、同じ2分の猶予を前提にしません。通知後に全データを初めて保存する設計では間に合わない可能性があるため、普段から中断へ備えます。

3. 処理を小さく分ける 一つの長い仕事を独立した小さな単位へ分けると、再実行する範囲を狭められます。例えば千枚の画像を一括で最後にだけ保存するのではなく、完了した画像ごとに結果を記録します。ただし並列に増やした台数だけでなく、入出力の処理能力や重複実行も確認します。中断しない前提の単一サーバーとは設計が違います。

4. 途中結果を残す チェックポイントは、どこまで処理したかを記録する仕組みです。Spotインスタンスの消失に耐える保存先へ進捗と必要なデータを置きます。例えばS3等へ結果を保存してから完了状態を記録し、再起動した処理が続きから進められるようにします。途中結果を失うローカル領域だけへ保存すると、再開の根拠を失います。

5. 重複に備える 中断の直前に外部処理が成功したのに、完了記録だけ残らない場合があります。再試行しても同じ注文を二重請求しないよう、業務ID等で実行済みを確認する冪等な設計が必要です。キューから仕事を受け取ったことだけでは業務完了ではありません。結果の確定、再試行、メッセージ削除等の順序を意識します。

6. 容量候補を増やす 一つのAZと一つのインスタンスタイプだけに固定すると、その余剰容量が不足した場合に処理を続けにくくなります。要件に合う複数タイプやAZを候補にし、価格と容量を考慮した配分を比較します。ただし候補を増やしても、中断の可能性がなくなるわけではありません。CPUアーキテクチャや必要メモリ等、互換性を保つことも必要です。

7. 締切と通常容量 完了期限が厳しい処理では、Spotだけでなくオンデマンド等を組み合わせる判断があります。例えば再試行できる夜間バッチでも、締切までの残り時間が少なければ必要な通常容量へ切り替える方針を設けます。重要なのは最安単価だけでなく、やり直しと待ち時間を含めて業務を完了できることです。

8. 総費用を比較する 説明用にSpotで1時間0.10ドルの課金対象の利用時間が、やり直しを含め合計30インスタンス時間であるとき、計算料金は3ドルです。成功した仕事の実行時間だけでなく失敗分も確認します。中断した主体、OS、最初の時間等で課金条件が異なるため、実際の課金対象を公式資料で確認します。チェックポイント間隔を短くするとやり直しを減らせますが、保存要求やデータ転送等の負担が増える場合があります。処理量と完了率を測り、間隔や購入方式を調整します。

図解

重要ポイント

• 中断通知だけへ依存せず、普段から再開可能にする。
• チェックポイントと冪等性を組み合わせる。
• 価格・容量・期限と再試行を含む総費用で判断する。

間違えやすい点

• 2分の通知があれば長い保存処理も間に合うと考える。
• 最大価格の指定だけで容量や連続稼働が確保されると考える。

用語解説

Spot

中断の可能性を受け入れてEC2の余剰容量を使う方式。

チェックポイント

中断後の再開に使う処理進捗や状態の記録。

冪等性

同じ操作を再実行しても意図した結果が重複しない性質。

関連教材

• EC2購入方式・容量・支援の違いと使い分け
• Reserved Instances（RI）を理解する
• 料金・容量・サポートのシナリオ判断
• Savings Plansを理解する
• ストレージクラスとライフサイクルを理解する