何が問題か
P5、P4d、G7、G6、G5 といったEC2 GPUインスタンスファミリーのキャパシティは、需要が高まる時期には特に不足しがちです。インスタンスを停止するとキャパシティは共有プールに戻され、再度起動したいときに使える保証はどこにもありません。
これによって、日常的なメンテナンスがギャンブルに変わってしまいます。ドライバのパッチ適用、AMIのローテーション、ルートボリュームのサイズ変更、OSアップデートの適用などのためにGPUインスタンスを停止した瞬間、そのキャパシティは他のAWSユーザーが誰でも取得できる状態になります。
需要が高いタイミングでは、再起動しようとした際に InsufficientInstanceCapacity エラーが返り、「10分で終わるはずのメンテナンス」が何時間ものリトライループに、最悪の場合はキャパシティが空くのを待つ間の障害へと発展しかねません。
On-Demand Capacity Reservationで実際にできること
EC2 On-Demand Capacity Reservation(ODCR) は、特定のインスタンスタイプ・特定のアベイラビリティゾーンに対して、予約をアクティブにしている間ずっとコンピュートキャパシティを確保します。ポイントは、インスタンスが稼働しているかどうかにかかわらずキャパシティが押さえられ続けるという点です。
まさにこの性質があるからこそ、ODCRはメンテナンスに最適な選択肢になります。予約に紐づくインスタンスを停止しても、予約したコンピュートリソースはそのまま確保されたままです。AWSはそのキャパシティをお客様のアカウント専用に割り当て続け、インスタンスを再度起動した際には、予約したキャパシティが確実に利用できることを保証します。
押さえておきたいポイント
名前の印象とは裏腹に、即時タイプのCapacity Reservationは長期的なコミットメントではありません。必要なときに必要なEC2キャパシティが使えることを保証するだけのものです。計画が変わったり、予約したキャパシティが不要になったりした場合は、いつでもキャンセルできます。キャンセル料も最低利用期間もありません。
Capacity Reservationの料金は、On-Demand EC2インスタンスを稼働させる場合と同じです。該当するSavings PlansやReserved Instancesを保有していれば、割引レートはCapacity Reservationにも適用されます。唯一違うのは、インスタンスが停止している間も、Capacity Reservationをキャンセルするかインスタンスを起動するまで、予約したキャパシティに対して料金が発生し続ける点だけです。
なぜメンテナンス作業でこれが特に重要なのか
皮肉なことに、最もリスクが高まるのはメンテナンスの最中です。インスタンスを停止した瞬間、そのキャパシティはAWSの共有プールに戻ります。同じアベイラビリティゾーンで別のAWSユーザーが条件の合うインスタンスを起動すれば、あなたのインスタンスを支えていたキャパシティをそのまま持っていかれ、計画的なメンテナンス枠が予期せぬ障害に変わってしまう可能性があります。
停止/起動オペレーション
メンテナンス作業の多くは、再起動ではなく完全な停止/起動を必要とします:
- 新しいAMIへの切り替え
- 特定のインスタンス属性の変更
これらを行うと、インスタンスは共有キャパシティプールに返されます。
フリート全体のローリングメンテナンス
フリートをノード単位でパッチ適用していく場合、通常は1台ずつドレインしてから停止します。予約キャパシティがなければ、停止したノードが戻ってこないことがあり、結果としてフリートが恒久的に縮小してしまう事態にもなりかねません。
計画的なハードウェアイベント
AWSでは、基盤となるホストに対するメンテナンス(ハードウェア劣化やホスト廃止など)が予定されることがあります。Capacity Reservationがあれば、影響を受けるホストから移行するためにインスタンスを停止・起動しても、コンピュートリソースは確実に確保されます。
実際の使い方
EC2コンソールから、以下の条件に一致する open On-Demand Capacity Reservation を作成します:
- インスタンスタイプ
- アベイラビリティゾーン
- オペレーティングシステム(プラットフォーム)
Capacity Reservationのサイズは、ローリングメンテナンス中に該当アベイラビリティゾーン内に存在する同一タイプ(例:g7.xlarge)のインスタンス総数に合わせて設定します。
インスタンスが予約を消費していることを確認してください。EC2インスタンスは、条件の合うopen Capacity Reservationがあればデフォルトで自動的にそれを利用します。作成したCapacity Reservationが実際にインスタンスから利用されているかを必ず確認しましょう。
Capacity Reservationsは、特定のworkloads向けのtargeted Capacity Reservationsなど、より高度なユースケースにも対応しています。それらのシナリオは本記事の対象外です。
あとは通常どおりメンテナンスを実施します:
- インスタンスを停止する。
- 必要な変更を適用する。
- インスタンスを再度起動する。
キャパシティは予約されたままなので、インスタンスは空きGPUキャパシティを取り合うことなく起動します。
メンテナンスが完了し、Capacity Reservationが不要になったらキャンセルしてください。インスタンスはそのまま通常どおり稼働し続けます。
コストはいくらだったか
インスタンス停止中に予約キャパシティへ支払った正確な金額を確認するには、メンテナンス完了から 約48時間 待ちます。AWSの請求データはリアルタイムではなく、これらの料金が反映されるまで最大2日かかることがあります。
請求データが更新されたら:
- AWS Billing → Bills を開きます。
- "Unused Reservation" で検索します。
次の内容が明細として表示されます:
- インスタンスタイプ
- 稼働中のインスタンスに利用されていない間にCapacity Reservationに対して請求された金額
これで、メンテナンス枠中にキャパシティを保証するためのコストを手軽に把握できます。
筆者のケースでは、メンテナンスは 30分 未満で完了しました。Capacity Reservationがなければ、GPUキャパシティが再び空くまで何時間も待たされていたかもしれません。
まとめ
キャパシティ不足は、共有クラウド環境でworkloadsを動かす以上、避けては通れないものです。幸い、AWSは最も重要な場面でこの不確実性を取り除くシンプルな手段を用意しています。
GPUインスタンス、あるいはキャパシティが不足しがちなEC2インスタンスタイプのメンテナンスを計画しているなら、一時的なCapacity Reservationこそが、いつもどおりのメンテナンス枠で済むか、何時間もの予期せぬダウンタイムに陥るかを分ける決定的な違いになります。