インスタンスと購入形態の選定｜基礎を学ぶ

このレッスンでできるようになること

要件の文から「中断してよいか」「期間を固定できるか」「インスタンスを変える柔軟性が要るか」の3つを拾い、オンデマンド・リザーブド・Savings Plans・スポットのどれをどの部分に当てるかを決められるようになります。

まず要件を読む

ある会社が動画変換サービスを運用しています。注文を受け付ける Web サーバーが数台、24時間止まらずに動いています。その裏では、注文が入ったときだけワーカーが大量に立ち上がって変換処理を行います。ワーカーは途中で落ちても、キューに仕事が残っているので別のワーカーがやり直せば済みます。経営から「来年いっぱいはこの構成で行くので、費用を下げてほしい」と言われました。

SAA でこの手の問題が出たとき、インスタンスファミリーの記号を暗記していても答えは出ません。読むべきは次の3つです。

選定の3軸

軸1 中断してよいか

AWS の都合でインスタンスが取り上げられても業務が壊れないなら、スポットが候補になります。上の例のワーカーはこれに当てはまります。キューから仕事を取り直せるので、落ちても失われるのは進行中の1件だけです。逆に、注文を受け付ける Web サーバーは中断された瞬間に売上が落ちるので、スポットは選べません。

スポットは中断の前に通知が来ます(本記事執筆時点で2分前)。この2分で終われる後始末しか書けない、という前提で設計します。

軸2 期間を固定できるか

「来年いっぱいは動かす」と言い切れる分だけが、コミット割引の対象です。リザーブドインスタンスと Savings Plans はどちらも「一定期間これだけ使う」と約束する代わりに単価が下がる仕組みで、約束した分は使わなくても支払います。だからコミットするのは常に動いている最低ラインだけにします。

上の例なら、Web サーバーの数台がその最低ラインです。ワーカーの台数は注文次第なので、ここをコミットしてはいけません。

軸3 インスタンスを変える柔軟性が要るか

同じコミット割引でも、後から変えられる範囲が違います。

買い方	約束する対象	後から変えられるか
スタンダードRI	インスタンスタイプとリージョン	変更できない。マーケットプレイスで売るしかない
コンバーティブルRI	インスタンスタイプとリージョン	別のタイプへ交換できる
EC2 Instance Savings Plans	ファミリーとリージョンへの支出額	同じファミリー内ならサイズもOSも自由
Compute Savings Plans	支出額のみ	ファミリーもリージョンも、Fargate や Lambda への乗り換えも自由

さらにゾーンを指定して買う RI にはキャパシティの予約が付きます。「災害時にそのAZで必ずインスタンスを起動できること」という要件が出たら、ここが決め手になります。リージョン単位の RI にはこの予約は付きません。

要件語から構成への対応

要件の言い回し	選ぶもの
中断されても再実行すればよい / バッチ / ステートレス	スポット
短期の検証 / いつ止めるか読めない	オンデマンド
1年または3年は確実に使う / 常時稼働の下限	Savings Plans または RI
将来ファミリーを変えるかもしれない / コンテナ化も検討中	Compute Savings Plans
特定AZでの起動を保証したい	ゾーン指定のRI またはキャパシティ予約

よくある引っ掛け

その1 全部をコミットしてしまう選択肢。 「ピーク時の台数分を3年でリザーブする」という選択肢は、コストを下げるどころか使わない分まで払うので不正解です。コミットは谷の高さに合わせ、山はオンデマンドかスポットで埋めます。

その2 スポットを本番のフロントに当てる選択肢。 安いのは事実なので惜しく見えますが、要件に「常時利用可能」とあれば落ちます。要件語が優先です。

まとめ

読むのは「中断可否」「期間の確約」「変更の柔軟性」の3つ
常時稼働の下限だけをコミットし、変動分はオンデマンドかスポットで埋める
中断してよいワークロードにだけスポットを当てる
将来構成を変える可能性があるなら Compute Savings Plans が効く
AZ を指定した起動保証が要件ならゾーン指定の予約を見る