はじめにこんにちは、インフラエンジニアのなみきです。私の担当プロダクトでは、ステージング環境のAuto Scaling Groupでスポットインスタンスを利用しています。当初、ステージング環境では費用の安さを優先して意図的にベストプラクティスから外れた設定にしていました。そんな中、スポットインスタンスの起動に関する2つの問題に遭遇しました。結論としては単純に「ベストプラクティスに従いましょう」というだけの話ですが、一見して何が悪いのかすぐには分かりませんでした。したがって、今後同じ問題に遭遇した人の役に立つよう、「こんな設定にするとこんな問題が起きる」という一例として紹介したいと思います。結論Auto Scaling Groupの設定を以下のように変更しました。対応前割り当て戦略（SpotAllocationStrategy）: lowest-priceインスタンスタイプ: t4g.medium対応後割り当て戦略（SpotAllocationStrategy）: price-capacity-optimizedインスタンスタイプ: t4g.medium / t4g.large / c6g.large / m6g.largeステージング環境では安定性よりも費用の安さを優先して、意図的に lowest-price かつインスタンスタイプ1種類としていました。ですが後述の問題が発生したため、割り当て戦略を変更し、インスタンスタイプを増やしました。問題1: インスタンスが無限に起動と終了を繰り返すある時、ステージング環境のAuto Scaling Groupにおいて、異常な頻度でスポットインスタンスが起動と終了を繰り返していることに気付きました。異常な頻度で増減するインスタンス数遡って確認すると05/16から発生しており、徐々に発生時間が長くなっていることが分かりました。ある時期から発生していたスポットインスタンスを使っているのはステージング環境だけなので本番ユーザーへの影響はありませんが、不安定な状態が続くことで予期せぬ問題が発生すれば開発に支障が出るため、詳しく調査することにしました。リバランスレコメンデーションの意図せぬ挙動Auto Scaling Groupのアクティビティ履歴を確認すると、およそ7分おきに次のようなイベントが発生していました。大量の「rebalance recommendation」イベントAt YYYY-MM-DDThh:mm:ssZ an instance was launched in response to an EC2 instance rebalance recommendation.At YYYY-MM-DDThh:mm:ssZ an instance was taken out of service in response to an EC2 instance rebalance recommendation.「rebalance recommendation」とは、スポットインスタンスの中断リスクが高まったときに、中断リスクの低い別のスポットインスタンスに置き換えを試みる機能です。今回、起動と終了を繰り返すスポットインスタンスはすべてap-northeast-1aに偏っていたため、ap-northeast-1aでスポットインスタンスのキャパシティを確保しづらい状態が続いていたことが分かります。このとき以下のようなループが発生していました。中断リスクが高いスポットインスタンスに対し、リバランスレコメンデーションが発生中断リスクが高いスポットインスタンスが終了するAuto Scaling Group内でAZのバランスをとるため、同じAZにインスタンスを起動するap-northeast-1aで起動したスポットインスタンスが、中断リスクが高いと判断される（1へ戻る）Auto Scaling Groupの設定見直しこの時点でのAuto Scaling Groupの設定は以下のとおりです。前述の通り、ステージング環境では費用の安さを優先してこのような設定にしていました。割り当て戦略（SpotAllocationStrategy）: lowest-priceインスタンスタイプ: t4g.medium割り当て戦略を lowest-price とすると、スポットインスタンスの中断リスクが高くなります。docs.aws.amazon.comlowest-price 割り当て戦略を使用している場合、代替スポットインスタンスが中断するリスクが高くなることがあります。これは、代替スポットインスタンスが起動後すぐに中断される可能性が高い場合も、必ず、その時点で利用可能な容量を持つ最低料金のプールでインスタンスを起動することが原因です。中断のリスクが高くなるのを避けるため、lowest-price 配分戦略を使用せず、代わりに price-capacity-optimized、capacity-optimized、capacity-optimized-prioritized 配分戦略を使用することを強くお勧めします。中断リスクを許容した上で lowest-price を選んでいましたが、ここまで頻繁に起動と終了を繰り返すのは想定外のため、まずは割り当て戦略を公式推奨の price-capacity-optimized に変えてみました。問題2: スポットインスタンスのキャパシティ不足今度は別の問題が発生しました。Auto Scaling Groupのアクティビティ履歴に Failed が連続して発生するようになったのです。大量の「failed」イベント（説明）Launching a new EC2 instance. Status Reason: Could not launch Spot Instances. UnfulfillableCapacity - Unable to fulfill capacity due to your request configuration. Please adjust your request and try again. Launching EC2 instance failed.（原因）At YYYY-MM-DDThh:mm:ssZ instances were launched to balance instances in zones ap-northeast-1a ap-northeast-1d with other zones resulting in more than desired number of instances in the group. At YYYY-MM-DDThh:mm:ssZ availability zones ap-northeast-1a ap-northeast-1d had 0 2 instances respectively. An instance was launched to aid in balancing the group's zones.スポットインスタンスの起動と終了を繰り返すのは収まりましたが、かわりにスポットインスタンスの起動ができなくなりました。ここでは以下のようなループが発生していました。ap-northeast-1dでスポットインスタンスを起動するap-northeast-1aに0台、ap-northeast-1dに2台、とAZが偏るAZのリバランス機能（AZRebalance）により、ap-northeast-1aに起動しようとするキャパシティ不足により起動失敗（3へ戻る）lowest-price では中断リスクが高いながらも起動できていたのに、 price-capacity-optimized では起動すらできなくなるのは不思議ですが、おそらくスポットリクエストの内部処理が異なるのでしょう。Auto Scaling Groupの設定見直しこの時点でのAuto Scaling Groupの設定は以下のとおりです。割り当て戦略は変更しましたが、インスタンスタイプは1種類のままです。安いインスタンスを使ってほしいためこのような設定にしていました。割り当て戦略（SpotAllocationStrategy）: price-capacity-optimizedインスタンスタイプ: t4g.mediumキャパシティ不足の対策としては、より多くのAZを使うこと、より多くのインスタンスタイプを使うことが有効とされています。repost.awsワークロードを設定する際には、リクエストするインスタンスタイプとデプロイするアベイラビリティーゾーンを柔軟に決定してください。 例えば、us-east-1a で m5.large をリクエストする代わりに、複数のアベイラビリティーゾーンで m4.large、c5.large、r5.large、または t3.xlarge をリクエストします。このタイプのリクエストにより、Amazon Web Services (AWS) が必要とする量のコンピューティングキャパシティを見つけて割り当てる可能性が高まります。具体的に、スポットプール数（AZ数 x インスタンスタイプ数）が20を超えるよう設定すべしという記事もあります。dev.classmethod.jpAWS ではスポットプール数について最低 20、可能なら 30 を⽬指すことをお勧めしてます。※スポットプール数 = インスタンスタイプの数 x AZ の数ap-northeast-1で利用可能なAZは3つなので、インスタンスタイプが1種類の場合のスポットプールの数は 3 x 1 = 3 です。さすがにこれでは少なすぎたため、起動テンプレートを上書きする形で、インスタンスタイプの選択肢を追加しました。t4g.mediumt4g.largec6g.largem6g.largeこのAuto Scaling GroupではArm64のAMIを使っているため、Gravitonベースかつなるべくt4g.mediumに近い性能のインスタンスタイプを選びました。世代を問わないAMIを使っていれば、前世代のインスタンスタイプも含めるとさらに安定すると思います。スポットプール数は 3 x 4 = 12 となり、20には満たないものの最初に比べると選択肢が大幅に増えました。設定変更後…t4g.mediumのキャパシティが確保しづらいap-northeast-1aでは、別のインスタンスタイプが起動するようになりました。ap-northeast-1aではt4g.largeが起動しているインスタンス数のメトリクスからも、高頻度の増減がなくなって安定していることが分かります。設定変更後はインスタンス数が安定したおわりに例えば「本番環境ではマルチAZで冗長構成、非本番環境では1台構成」というように、非本番環境ではベストプラクティスよりもコスト削減を優先することはよくあることかと思います。ですが、スポットインスタンスの利用においてはベストプラクティスに従わないと想定以上に安定性を欠くことが分かりました。同じ問題で悩む人の参考になれば幸いです。付録対応後のCloudFormationテンプレートを一部抜粋して掲載します。  AutoScalingAutoScalingGroup:    Type: 'AWS::AutoScaling::AutoScalingGroup'    Properties:      CapacityRebalance: true      MixedInstancesPolicy:        InstancesDistribution:          SpotAllocationStrategy: 'price-capacity-optimized'        LaunchTemplate:          LaunchTemplateSpecification:            LaunchTemplateId: !Ref EC2LaunchTemplate # 補足: AWS::EC2::LaunchTemplateのInstanceTypeでt4g.mediumを指定している            Version: !GetAtt EC2LaunchTemplate.LatestVersionNumber          Overrides:            - InstanceType: 't4g.medium'            - InstanceType: 't4g.large'            - InstanceType: 'c6g.large'            - InstanceType: 'm6g.large'

Auto Scaling Groupでスポットインスタンス費用を節約しようとしたけどうまくいかなかった話

はじめにこんにちは、インフラエンジニアのなみきです。これまでは所属企業でブログを書いていましたが、退職に伴い自分のブログを開設しました。改めてよろしくお願いします。さて、今日のお題はみんな大好きEC2 Auto Scalingです。EC2 Auto Scalingでできる自動スケーリングは、大きく分けて3種類あります。動的スケーリング負荷状況に合わせてスケールできるどのメトリクスを基準にするか？増減させるときは何台ずつ増やすか？などスケールの仕様を細かく設定できるスケジュールされたスケーリング（以下「スケジュール」と表記）予定した日時にインスタンス数を増減させる予測スケーリングリソースの使用率などの規則性から、適切なインスタンス数を予測するこれらのスケーリングを組み合わせて利用されている方は多いのではないでしょうか。今回は、「動的スケーリング」と「スケジュール」を組み合わせて利用する際のオススメ設定方法を紹介します。前提知識3種類のパラメータAuto Scaling Groupには、インスタンス数を制御するパラメータが3種類あります。Desired Capacity （希望容量）Minimum Size （最小サイズ）Maximum Size （最大サイズ）起動するインスタンス数は希望容量に依存します。動的スケーリングを利用している場合、希望容量は最小サイズと最大サイズの間で増減します。自動で最小サイズを下回ったり、最大サイズを上回ることはありません。1NOTE: この記事では、説明を分かりやすくするためインスタンスの重み付けには触れず、単純に「サイズ=インスタンス数」として扱います。ご承知おきください。Desired CapacityはMinimumとMaximumの間で増減する一方、スケジュールでは希望容量を指定できるのはもちろん、最小サイズと最大サイズも指定できます。スケジュールでMinimumとMaximumを変化させる例スケジュールの利用シーン多くの場合、Auto Scalingの動的スケーリングは数分間の負荷状況を見てからスケーリングを始めるため、急激な負荷上昇には対応しきれないことがあります。2動的スケーリングあるある: スケールアウトが間に合わないそこで、負荷の高まる時間が予測できる場合は、スケジュールを利用して待ち構えておくことで対応できます。負荷に備えあらかじめスケールアウトしておく前述の通り、スケジュールでは希望容量だけではなく最小サイズと最大サイズも指定できます。「希望容量を変えたいんだから、希望容量を指定すればいいんじゃないの？」と思われるかもしれません。動的スケーリングを使わずスケジュールのみでインスタンス数を増減させている場合は、その通りです。しかし、動的スケーリングとスケジュールを組み合わせて使う場合、思い通りのインスタンス数を維持するために スケジュールでは最小サイズを指定するのがオススメ です。どういうことか、詳しく見ていきましょう。よくある問題と回避策スケジュールで希望容量を増減させるとどのような問題が起こりうるか、そして最小サイズを指定することでどのように問題を回避できるかを紹介します。問題その1: 即座にスケールイン負荷が高まる時間が分かっている場合、時間に余裕を持たせたスケジュールにすることが多いと思います。すなわち、インスタンス数を増やしてから負荷が高まるまで少し時間があるということですが、この間にインスタンス数が減ってしまっては困ります。希望容量の問題スケジュールで希望容量を増やすと、負荷が高まる前に自動スケールインが発生し、狙ったインスタンス数が維持できないという問題が起こり得ます。例えば、12:00に負荷が高くなるシステムにおいて、11:30のスケジュールで希望容量を増やすとします。この30分間は負荷の低い状態が続くため、動的スケーリングによる自動スケールインが発生し、希望容量が減らされる可能性があります。そうなると肝心の12:00にインスタンス数が足りず、パフォーマンス悪化やエラーを起こしてしまいます。即座にスケールインするイメージNOTE: 動的スケーリングの自動スケールインを無効にして勝手に減らないようにする、というのも一つの回避策ですが、後述する問題その2を併せて回避するため自動スケールインは有効にしておく必要があります。最小サイズで解決では、希望容量のかわりに最小サイズを指定するとどうなるでしょうか。スケジュールを以下のように設定します。希望容量: 無指定最小サイズ: 維持したいインスタンス数希望容量を指定せずに最小サイズを指定すると、希望容量は必ず「最小サイズ以上」になります。それより減ることはないので、次のスケジュールで最小サイズを下げるまでインスタンス数が維持されます。最小サイズ指定でスケールインを回避する問題その2: 問答無用でスケールイン負荷に備えてインスタンス数を増やすのとセットで、負荷が落ち着く頃にインスタンス数を減らすのもよくある使い方です。しかし、負荷の高い状態が予想よりも長引いていたらどうなるでしょうか。希望容量の問題スケジュールで希望容量を指定すると、負荷状況によらず問答無用でインスタンス数を変更してしまいます。問答無用でスケールインするイメージ図最小サイズで解決では、希望容量のかわりに最小サイズを指定するとどうなるでしょうか。スケジュールを以下のように設定します。希望容量: 無指定最小サイズ: 平常時の最小インスタンス数希望容量を指定しないことにより、スケールインは動的スケーリングに任せることになります。負荷状況を見た上で「減らして大丈夫」と判断されて初めて減らされるため、適切なインスタンス数を維持できます。負荷に合わせてスケールインするまとめスケジュールで希望容量を指定するのは分かりやすいですが、動的スケーリングと組み合わせた場合、予期せぬ増減が発生することがあります。希望容量を狙った値にするため、ぜひ最小サイズの指定を取り入れてみてください。インスタンスの重み付けや予測スケーリングを利用している場合は例外的に最大サイズを上回ることがありますが、この記事では詳しく説明しません。↩↩

Auto Scaling Groupでスポットインスタンス費用を節約しようとしたけどうまくいかなかった話

EC2 Auto Scalingで動的スケーリングとスケジュールを組み合わせる