こんにちは, 大窄 直樹(おおさこ)です.
今回は, EC2のキャパシティー不足(Insufficient Instance Capacity)を解消する手法についてまとめようと思います.
背景
ある社内サービスで, 定期的に今日は処理が遅いなということがありました.
調査した結果, EC2のオートスケーリングで希望数のインスタンスを確保できていないことが原因で処理が遅くなっていることがわかりました.
EC2のキャパシティー不足の解消方法がまとまってると良いなと考え, 今回のブログを書きました.
EC2のキャパシティー不足(Insufficient Instance Capacity)のエラーとは
EC2のキャパシティー不足(Insufficient Instance Capacity)のエラーは
AWS基盤にEC2のキャパシティーが不足した場合に発生するエラーです.
EC2のキャパシティーはAZ粒度, インスタンスファミリー×インスタンスサイズ粒度で管理されているため, この粒度でエラーが発生します.
インスタンス作成時, 停止したインスタンスの起動時に発生することがあります.
キャパシティー不足を解消する方法
キャパシティー不足を解消する方法を大分すると下記の4手法です.
- キャパシティーに空きが出るのを待つ
- 起動するインスタンスの種類(インスタンスファミリー, インスタンスサイズ)を変更する
- 起動するインスタンスのAZを変える
- キャパシティーを予約する
手動操作でエラーが発生した場合
手動操作でこのエラーが発生した場合,
- キャパシティーに空きが出るのを待つ
- 起動するインスタンスの種類(インスタンスファミリー, インスタンスサイズ)を変更する
- 起動するインスタンスのAZを変える
という選択肢があると思います.
1. キャパシティーに空きが出るのを待つ を選択した場合は, 数分待ってから再度インスタンスの立ち上げにチャレンジ.
2. 起動するインスタンスの種類(インスタンスファミリー, インスタンスサイズ)を変更する を選択した場合は, インスタンスの種類を変更してチャレンジ, つまりt3.mediumでキャパシティ不足が発生した場合, t3.largeやt2.mediumといったインスタンスに変更してチャレンジ.
3. 起動するインスタンスのAZを変える を選択した場合は, AZを変更してチャレンジ.
してみてください.
おすすめは, 1. キャパシティーに空きが出るのを待つ です.
システムでエラーが発生した場合
システムでEC2のキャパシティー不足が発生するのは, 大分すると下記の2パターンだと思います.
- オートスケーリング時
- バッチ処理などでサーバーを立ち上げる時
オートスケーリングの場合は, 下記のような手法があります.
大きく分けてオートスケールの設定を変更する, 事前に予約しておくの2つがあります.
| 手法 | 詳細 |
|---|---|
| オートスケーリング:シングルAZ+単一インスタンスタイプ | インスタンスを確保できる可能性が一番低い. 確保できなかった場合, 待つ必要がありキャパシティが空き次第スケーリング |
| オートスケーリング:シングルAZ+属性ベース | インスタンスファミリー, サイズを複数選択できるため, インスタンスを確保できる可能性が高い |
| オートスケーリング:マルチAZ+単一インスタンスタイプ | AZにインスタンスの空きがあれば確保できるため, インスタンスを確保できる可能性が高い |
| オートスケーリング:マルチAZ+属性ベース | インスタンスを確保できる可能性が一番高い |
| オンデマンドキャパシティ予約 | AZ, インスタンスファミリー,インスタンスサイズ, 確保期間を指定してキャパシティを確保 |
| ゾーンリザーブドインスタンス | 最低1年以上AZ, インスタンスファミリー,インスタンスサイズ, 確保期間を指定してキャパシティを確保 |
また, バッチ処理のように単発でサーバーを立ち上げる場合で確実に確保したい場合は, オンデマンドキャパシティ予約をするしかないです.
(ゾーンリザーブドインスタンスを利用していたなら, キャパシティ不足のエラーが発生しないため)
選び方
何が許容できるかによって選び方が変わります.
必ず確保しなくてもよい, 確保できる可能性を上げるだけで良いのならオートスケーリングで良いと思います.
その上でのオートスケーリングの設定の選び方ですが, 下記のようになると思います.
| オートスケーリングの設定 | 選び方 |
|---|---|
| シングルAZ+単一インスタンスタイプ | インスタンスの確保に時間がかかって良い |
| シングルAZ+属性ベース | AZは変えたくない, インスタンスの種類は変わっても良いから確保できる可能性をあげたい |
| マルチAZ+単一インスタンスタイプ | インスタンスの種類は変えたくない, AZが変わっても良いからインスタンスを確保できる可能性をあげたい |
| マルチAZ+属性ベース | インスタンスの種類, AZが変わっても良いからできるだけインスタンスを確保できる可能性をあげたい |
どれを選ぶかはシステム性質や要件によリます.
また, 確実にキャパシティ確保する必要があるのなら, オンデマンドキャパシティ予約で事前に予約するのがおすすめです.
ゾーンリザーブドインスタンスでもインスタンスを確保できますが, こちらはEC2の利用料の割引がメインのサービスでかつ, 割引がメインならセービングプランの方がおすすめのため特別な事情がない限りはおすすめしないです.
割引としてセービングプランを利用する場合は, "セービングプラン+オンデマンドキャパシティ予約"のように組み合わせて使うこともできます.
オートスケーリングとオンデマンドキャパシティ予約を上手く組み合わせることでスケーラビリティを確保しつつ, 確実にキャパシティを確保することもできます. 従って, おすすめしないゾーンリザーブドインスタンスを省いて まとめると下記のようなオートスケーリングの設定, オンデマンドキャパシティ予約をするかどうかから選択することになると思います.
- オートスケーリングの設定
- シングルAZ+単一インスタンスタイプ
- マルチAZ+単一インスタンスタイプ
- シングルAZ+属性ベース
- マルチAZ+属性ベース
- オンデマンドキャパシティ予約
- する
- しない
まとめ
システムの性質によって, EC2のキャパシティー不足を解消する方法が異なるのでどの手法で解消するかは難しいと思います.
このブログを通して適した方法を選ぶ手助けになれば幸いです.
Q & A
Q: AZのインスタンスのキャパシティの空き状況を見ることができるか?
A: 今現在見る方法はない. 非公式だがspot instanceの空き状況と相関があるらしい. (spot instanceの空き状況は見ることができる)
Q: 最新, 過去のインスタンスどちらの方ががキャパシティ空いてるとかありますか?
A: 無いです. t2.medium, t3.mediumでどちらの方が空いてるとかはない
