AWS EC2でinsufficient errorがでたときの対処法について
AWS EC2を使っていると以下のように"insufficient capacity"エラーがでて起動が失敗することがある.
これは,AWSにおけるインスタンスの容量が上限に達したことが原因で発生するエラーである.
例えば,ap-northeast-1aのアベイラビリティゾーン(AZ)において,g4dn.xlargeを起動しようとしてこのエラーが出た場合,ap-northeast-1aのAZで,g4dn.xlargeの数あるいは容量が不足しているということになる.このエラーは一時的なもので,発生したときにはおそらくどこかの大企業が大量のインスタンスを一斉に立ち上げたりして発生するため,自分自身では解決できない問題(コンソール上で制限緩和などを行っても意味が無い)である.
Insufficient capacity errorに対する対処法として,私が最も有効だと思う対処法は「時間をおいて起動すること」である.
巷のブログなどをみていると,こういうときはインスタンスタイプを変更する,あるいはアベイラビリティゾーンを変更,の方法が紹介されているがあまりおすすめできない.
インスタンスタイプを変更することについては,EC2のコンソールから数クリックで変更できるため,設定を変更する方法の中では最も簡単な対処法である.しかし,筆者はGPUインスタンスを用いることが多く,元の環境が壊れないか心配になり,気軽にインスタンスタイプを変更することができない.
一応,過去に何度かインスタンスタイプの変更を行ったことがあるのだが,そのときに環境が壊れるなどのエラーに遭遇したことは無い(同じシリーズ内でのインスタンスタイプ変更だが)が,重要なスクリプトがインストールされたインスタンスとなるとインスタンスタイプの変更は怖いのだ.
また,過去にinsufficient capacity errorが発生したとき,インスタンスタイプの変更を試したのだが,変更した先のインスタンスでも同様のエラーが発生して起動できないことが多いのだ.これは,他の人も同じ考えで対処しているから,別のインスタンスタイプも枯渇してしまっているのではないかと考えている.
以上の理由からインスタンスタイプの変更でこのエラーを回避することはお勧めできない.
アベイラビリティゾーン(AZ)の変更については,特にお勧めしない.なぜなら手順が面倒だからである.AZを変更する場合,インスタンスタイプの変更と違って,コンソールで数クリックで変更とはいかない.AZを変更する場合,対象インスタンスのAMIを作成し,そのAMIから新たなインスタンスを起動するときに元のAZとは異なるAZを設定することが必要となる.この手順をみても面倒くささが伝わるかと思うが,実際にやってみるとかなり手間である.しかしながら,経験上,AZの変更はinsufficient capacity errorを回避できる確率が最も高いように感じる.
もしどうしても今インスタンスを起動する必要があるのであれば,インスタンスタイプの変更を試してから,AZを変更という手順が一番しっくりくる気がする.
緊急でない場合は,インスタンスを使ってする作業を後回しにして,他にできる作業から片付けるのが一番良い解決法に思う.下手に設定変更をすると環境が壊れてしまうこともあるからだ.
ディスカッション
コメント一覧
まだ、コメントがありません