AWS AutoScailingのスポットインスタンスリクエスト失敗について
トラ概要
2023/6/14からAWS AutoScailingのスポットインスタンスのリクエストの失敗が立て続けに起きている。
AWSのリソース不足かもしれないが、こちら側で待つだけなのも癪なので今まで行った対応と経過をここにまとめる
既存の設定
使用しているAZ
- ap-northeast-1a
- ap-northeast-1c
- ap-northeast-1d
インスタンスタイプの要件
- t3.small
- t3a.small
- t3.medium
トラt3.mediumは不要？
・t3.smallとt3.mediumの違いはメモリ容量が2GBか4GBかのみ
・t3.mediumはt3.smallの倍の料金
・t3.smallのメモリ容量で足りない場合はt3.medium・t3a.mediumが最小の構成にするはず…
同一インスタンスファミリーの場合、ホストマシンのハードウェアは同じため、小さいインスタンスの方が起動できる確立が高い？
→ 同一ファミリーでは大きなインスタンスタイプを加えても起動できる確立は上がらなそう...
トラt3.mediumを削除してしまったので新しくインスタンスタイプを追加したい
要件
インスタンスタイプは既存のt3, t3aと同様にバーストができるt系のインスタンスにする必要がある
候補
- t2.small
→ t3, t3aに比べてコスパ悪そう...
t2.small オンデマンド$22.19/月 1コア 2GB スポット$0.0091/1時間=$6.552/月
t3.small オンデマンド$19.86/月 2コア 2GB スポット$0.0082/1時間=$5.904/月
t3a.small オンデマンド$17.89/月 2コア 2GB スポット$0.0080/1時間=$5.760/月
- t4g.small
→ t4gはarmプロセッサでt3でできたAMIとは互換がないかも？
https://aws.amazon.com/jp/blogs/news/new-t4g-instances-burstable-performance-powered-by-aws-graviton2/
候補のインスタンスでサービスが動くか検証
- t2.small
→ 問題なく動いた！ - t4g.small
→ やっぱりインスタイプのアーキテクチャが違うことが要因で動かないみたい
Launching a new EC2 instance. Status Reason: Could not launch On-Demand Instances. InvalidParameterValue - The architecture 'arm64' of the specified instance type does not match the architecture 'x86_64' of the specified AMI. Specify an instance type and an AMI that have matching architectures, and try again. You can use 'describe-instance-types' or 'describe-images' to discover the architecture of the instance type or AMI. Launching EC2 instance failed.
t2.smallダメそう？
t2.smallを追加した次の日からt2.smallのインスタンスでのみ下記エラーが出る。
cURL error 28: Operation timed out after 10000 milliseconds with 0 out of -1 bytes received
t2.smallのみインスタンスのCPU使用率が高いのでこれが原因そう？
t3.small, t3a.smallはvCPUが2なのに対して、t2.smallは1なのが原因っぽい...
対策
- t2.smallを削除、vCPUが2のt2.mediumを追加
→ t2.mediumはコスパ悪すぎ...
t2.small オンデマンド$22.19/月 1コア 2GB スポット$0.0091/1時間=$6.552/月
t2.medium オンデマンド$33.40/月 2コア 4GB スポット$0.0182/1時間=$13.104/月
t2.mediumをスポットのみでリクエストするようにはできないか？
- 重みの変更
→ 重みはインスタンスの優先度ではなく、アクセスを流す量の重み？
重みの合計=希望する容量になるっぽい - 新しくt2.mediumのみのAutoScailingグループを作成して2つのグループを1つのターゲットグループに向ける
→ やり方よくわからんし管理が面倒...
トラAZの追加
ap-northeast-1a, ap-northeast-1c, ap-northeast-1d以外にもap-northeast-1bというのがあるらしい。
試した
- VPCにap-northeast-1b新規作成
- ルートテーブル変更
- ALBにap-northeast-1b追加
The following Availability Zones ap-northeast-1b cannot be associated with a load balancer. Please try a different Availability Zone.
ap-northeast-1bは廃止予定で使えないみたい...
トラ他の対策案
リージョンの追加
現在東京リージョン(ap-northeast-1)のみで運用しているのに大阪リージョン(ap-northeast-3)を追加する
- 今使っているALBにap-northeast-3を追加はできないので、新しくALBを作成し、Route53で振り分けを行う
- ap-northeast-3はスポットインスタンスはt3a.smallはなさそう。t3.smallはap-northeast-1と同じ価格
→ 管理が面倒な割にメリットが少ないのでなし
スポット割り当て戦略の変更
現在料金キャパシティ最適化を使っているのでこれをキャパシティ最適化に変更
キャパシティ最適化は中断のリスクが最も低いみたいなのでリクエストをする頻度が減る → リクエストの頻度が減る？
→ 設定変更するだけなので試す価値アリ！
トラスポット選択割り当て戦略の変更
現在の設定
料金キャパシティ最適化
アベイラビリティゾーン内で最も利用可能なプールから最低料金のスポットインスタンスをリクエストします。これは、インスタンス料金と中断リスクのバランスを取るための最良の戦略です。
変更を検討している設定
キャパシティ最適化
アベイラビリティゾーン内で最も利用可能なプールからスポットインスタンスをリクエストします。この戦略は、中断のリスクが最も低くなります。
中断のリスクが最も低くなります
中断のリスクが低いのであればリクエストの頻度が減るはず？
変更を試してみる
2023/8/2 追記
キャパシティ最適化に変更してからオートスケールが安定したので一旦解決とする