Amazon Web Services ブログ

アップデート — EC2 Auto Scalingのキャパシティリバランシング機能によるスポットインスタンスの事前置き換え

本記事は、EC2プロダクトサービスチームのDeepthi ChelupatiとChad Schmutzerによる寄稿です。

本日より、Amazon EC2 Auto Scaling のキャパシティリバランシング機能を提供するようになりました。これは、Auto Scaling グループで Amazon EC2 スポットインスタンスのライフサイクルをプロアクティブに管理するための新機能です。キャパシティリバランシングは、最も余裕のある空きキャパシティを自動的に選択する capacity-optimized 配分戦略 (英語記事)と、複数のアベイラビリティーゾーンにまたがって複数のインスタンスタイプを活用できるミックスインスタンスポリシー機能を補完する位置付けの機能です。キャパシティリバランシングは、スポットインスタンスが Amazon EC2 サービスによって中断される前に、 Auto Scaling グループのスポットインスタンスを自動的に置き換えます。これにより、お使いの Auto Scaling グループの可用性をより一層高めることができます。

スポットインスタンスの事前置き換えを実現するため、キャパシティリバランシングは EC2 サービスの新機能である、 EC2 インスタンスのリバランス通知を活用します。これは、スポットインスタンスが中断のリスクが高まった際に送信されるシグナルです。リバランス通知は、これまで提供してきた 2 分前のスポットインスタンス中断通知よりも早く提供されることが期待されるため、来たる中断に備え、ワークロードをプロアクティブにリバランスする機会を提供します。

EC2 Auto Scaling のキャパシティリバランシングは、スポットインスタンスのライフサイクルを踏まえ、その時点で必要な希望容量を維持するためのシームレスで自動化された仕組みを提供します。これには、リバランス通知の監視、また中断のリスクが高い場合の代替キャパシティーの事前起動、さらに必要に応じて Elastic Load Balancing からのデタッチや、設定されたライフサイクルフックの実行が含まれます。この記事では、スポットインスタンスを中心としたワークロードに対して、EC2 Auto Scaling でキャパシティリバランシングを使用して Auto Scaling グループを管理する方法の概要を説明し、お使いの環境でキャパシティリバランシングを活用するためのユースケースの例を紹介します。

EC2 Auto Scaling と スポットインスタンス — これまでのおはなし

さてここで、スポットインスタンスが何であるか、また EC2 Auto Scaling がスポットインスタンスのバックアップワークロードを管理するための最適なプラットフォームである理由について見ていきましょう。これは、キャパシティリバランシングがどのようなメリットをもたらすかを説明するのに役立ちます。

スポットインスタンスは、AWS クラウドにおける未割り当ての EC2 コンピューティング容量であり、オンデマンド価格から大幅な割引でお使いいただくことができます。割引の提供と同時に、スポットインスタンスには簡単なルールが付属してきます。オンデマンドインスタンスの起動需要が高まったとき、EC2 サービスに容量を返却していただく必要があり、このときにスポットインスタンスは中断されることがある、という点です。では、この未割り当てのコンピューティング容量はどこから来るのでしょうか。任意の時点で予測不能な需要に対して容量を準備するために、77 のアベイラビリティーゾーンと 24 のリージョンのそれぞれで、350 を超えるインスタンスタイプに渡って、AWS には余分な容量が発生することがよくあります。その予備容量を遊ばせておくようにするのではなく、大幅な割引価格で提供するのがスポットインスタンスです。

ご想像のとおり、任意の時点で利用可能な予備容量、そしてその物理的な配置場所は動的に変化し、リアルタイムで継続的に変化します。そのため、スポットインスタンスのお客様にとって、真に中断に耐えうるワークロードのみを実行することが非常に重要です。さらに、スポットインスタンスで稼働するワークロードは柔軟性を備えている必要があります。つまり、スポットインスタンスで稼働するワークロードは、その時点で予備容量がある場所にリアルタイムでシフトできる必要があります（または、予備容量が再び利用可能になるまで一時停止できる必要があります）。ただし実用上は、「柔軟性」と言ったときには、複数の EC2 インスタンスタイプ（複数のファミリ、サイズ、世代など — 可能な限りたくさんの候補を検討してください！）、および複数のアベイラビリティーゾーンで、選り好みせずワークロードを稼働させられるようにしておくことを意味します。

そして、ここで EC2 Auto Scaling の出番です。EC2 Auto Scaling は、アプリケーションの可用性を維持するために設計されています。また、定義した条件に従って EC2 インスタンスを自動的に追加または削除することもできます。私たちは EC2 Auto Scaling に継続的に新しい機能を追加し、EC2 ワークロードの柔軟な設定をネイティブでサポートすることで、お客様の革新を支援し続けてきました。これらの革新の 1 つは例えば、単一の Auto Scaling グループで複数のインスタンスタイプと購入オプションをサポートするミックスインスタンスポリシー機能（2018 年に提供開始）です。そしてもう 1 つの革新は、capacity-optimized 配分戦略（2019年に提供開始）です。これは、スポットインスタンスで稼働するワークロードに最適な、最も余裕のある空きキャパシティを特定して提供するために設計された配分戦略です。これらの機能は、柔軟なワークロードのベスト・プラクティスをサポートし、キャパシティの変化に動的に追随していくことを目的としています。

スポットインスタンスとEC2 Auto Scalingを次のレベルへ — 後手の対応から、キャパシティリバランシングによる先手の対応へ

スポットインスタンスの中断に対する EC2 Auto Scaling のデフォルト動作は、いわば事後のアプローチです。つまり EC2 Auto Scaling は、インスタンスが EC2 によってシャットダウンされ、ヘルスチェックが失敗した後にのみ、中断されたスポットインスタンスを別のスポットインスタンスに置き換えようとします。この事後対応のアプローチは、多くのワークロードで正常に動作します。一方で私たちはこれまでに、EC2 Auto Scaling がスポットインスタンスの中断を処理するための、より積極的なアプローチを採用できないか、とのフィードバックを頂戴してきました。

EC2 Auto Scaling でのキャパシティリバランシングは、このご要望に対する回答です。キャパシティリバランシングは、時々刻々と変化し続ける EC2 キャパシティの動的な性質を踏まえ、事前のアプローチを採用するように設計されています。これは、「最終の」2 分間のスポットインスタンス中断通知に加えて、EC2 インスタンスのリバランス通知を監視することによって実現されています。リバランス通知が検出されると、そのインスタンスが中断される前に、まず自動的に新しいスポットインスタンスを開始しようとします。キャパシティリバランシングは、代替のスポットインスタンスを起動することで希望容量を維持しようとするだけでなく、ロードバランサーからの登録解除やインスタンス削除時のライフサイクルフックの実行といった通常のシャットダウンプロセスを通じて、お客様の Auto Scaling グループからスポットインスタンスを安全に削除する機会を提供します。

EC2 Auto Scaling でのキャパシティリバランシングは、いくつかのベストプラクティスと組み合わせたとき、最も効果があります。

柔軟であること。キャパシティリバランシングの効果は柔軟性とともに発揮されます。特定のインスタンスタイプに固執せず、EC2 Auto Scaling のミックスインスタンスポリシーを活用し、可能な限り多くのインスタンスタイプ、アベイラビリティーゾーンを活用してください。可能な限りたくさんの候補を検討するため、ワークロードに対して複数のインスタンスファミリー、サイズ、世代を検証し、また可能であればすべてのアベイラビリティーゾーンを使用してください。

capacity-optimized 配分戦略を使用すること。キャパシティリバランシング機能は、capacity-optimized 配分戦略と、インスタンスタイプとアベイラビリティーゾーンの幅広い候補リストと組み合わせたとき、最適に機能します。これは、ワークロードを再配置する際の最適な空きキャパシティを選択することにつながります。

削除時のライフサイクルフックを活用すること（オプション）。削除時のライフサイクルフックは、シャットダウン前に実行すべき処理がある場合に大変強力な機能です。

チュートリアル — Webアプリケーションワークロードを例に

キャパシティリバランシングを活用するためのベストプラクティスをご紹介したところで、具体的なワークロードの例を見ていきたいと思います。ここでは、Auto Scaling グループ内の 75% スポットインスタンスと 25% のオンデマンドインスタンスで稼働するウェブアプリケーションがあり、前段にアプリケーションロードバランサーがリクエストを受け付けているワークロードを考えます。Auto Scaling グループ内のスポットインスタンスの中断に対して、可用性を維持するため、キャパシティのリバランスを自動的に処理させるように構成します。

Auto Scaling グループの設定は次のようになります。ミックスインスタンスポリシー（MixedInstancesPolicy）の設定として、インスタンスタイプおよびアベイラビリティーゾーンに柔軟性を持たせている点と、capacity-optimized配分戦略を選択している点、それぞれベストプラクティスに沿った構成となっていることを確認してください。

 

{
   "AutoScalingGroupName": "myAutoScalingGroup",
   "CapacityRebalance": true,
   "DesiredCapacity": 12,
   "MaxSize": 15,
   "MinSize": 12,
   "MixedInstancesPolicy": {
      "InstancesDistribution": {
         "OnDemandBaseCapacity": 0,
         "OnDemandPercentageAboveBaseCapacity": 25,
         "SpotAllocationStrategy": "capacity-optimized"
      },
      "LaunchTemplate": {
         "LaunchTemplateSpecification": {
            "LaunchTemplateName": "myLaunchTemplate",
            "Version": "$Default"
         },
         "Overrides": [
            {
               "InstanceType": "c5.large"
            },
            {
               "InstanceType": "c5a.large"
            },
            {
               "InstanceType": "m5.large"
            },
            {
               "InstanceType": "m5a.large"
            },
            {
               "InstanceType": "c4.large"
            },
            {
               "InstanceType": "m4.large"
            },
            {
               "InstanceType": "c3.large"
            },
            {
               "InstanceType": "m3.large"
            }
         ]
      }
   },
   "TargetGroupARNs": [
      "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/my-targets/a1b2c3d4e5f6g7h8"
   ],
   "VPCZoneIdentifier": "mySubnet1,mySubnet2,mySubnet3"
}

 

続いて、Auto Scaling グループを作成します。

aws autoscaling create-auto-scaling-group \
  --cli-input-json file://myAutoScalingGroup.json

 

そして削除時のライフサイクルフックを構成し、インスタンスの削除前にログをダウンロードするといった、事後動作のための待機時間を持たせるようにします。

aws autoscaling put-lifecycle-hook \
  --lifecycle-hook-name myTerminatingHook \
  --auto-scaling-group-name myAutoScalingGroup \
  --lifecycle-transition autoscaling:EC2_INSTANCE_TERMINATING \
  --heartbeat-timeout 300

上記の設定により、9 台のスポットインスタンスと 3 台のオンデマンドインスタンスが Auto Scaling グループに起動されます。それぞれのアベイラビリティーゾーンごとに 3 台のスポットインスタンスと 1 台のオンデマンドインスタンスが稼働することになります。

キャパシティリバランシングを有効にすると、9 つのスポットインスタンスのいずれかが EC2 インスタンスのリバランス通知を受信したとき、EC2 Auto Scaling は配分戦略（capacity-optimized）に従って代替のスポットインスタンスを自動的にリクエストします。その結果、一時的に 10 台のスポットインスタンスが実行されることになります。新しいスポットインスタンスが EC2 ヘルスチェック、および定義されている場合は ELB ヘルスチェックに合格すると、そのスポットインスタンスはロードバランサーに登録され、サービスのリクエストトラフィックを受けるようになります。ここから EC2 Auto Scaling は、リバランス通知を受信したスポットインスタンスのシャットダウンプロセスに進みます。ロードバランサーからインスタンスを登録解除して新規接続を受け付けないようにし、また削除時のライフサイクルフックを実行します。ロードバランサーの登録解除の遅延待機時間、およびライフサイクルフックのハートビートタイムアウトの設定によっては、インスタンスのシャットダウンに時間がかかる場合があることに注意してください。ライフサイクルフックが完了すると、EC2 Auto Scaling はインスタンスをシャットダウンし、Auto Scaling グループのスポットインスタンス容量は 9 台に戻ります。

終わりに

お使いの環境で EC2 Auto Scaling の新しいキャパシティリバランシング機能を活用し、スポットインスタンスの事前置き換えをぜひお試しください。キャパシティリバランシングは、必要に応じて容量を自動的に再配置することで、ワークロードの可用性を維持し、スポットインスタンスの中断を管理するためのシームレスで自動化された仕組みを提供します。キャパシティリバランシングは、インスタンスタイプの柔軟性とcapacity-optimized配分戦略と組み合わせたとき、最も効果的です。また、キャパシティの変化に容易に追随できる、次のようなワークロードで特に有用です。

  • コンテナベースのワークロード
  • ビッグデータと分析ワークロード
  • アニメーション、3Dといったメディアレンダリングワークロード
  • バッチ処理ワークロード
  • ウェブアプリケーションワークロード

EC2 Auto Scaling のキャパシティリバランシングについてさらに深く理解するために、ドキュメント：Amazon EC2 Auto Scaling Capacity Rebalancing を参照してください。

またEC2 インスタンスのリバランス通知についてさらに深く理解するために、ドキュメント：EC2 instance rebalance recommendations を参照してください。

この記事はソリューションアーキテクト滝口が翻訳しました。原文はこちら。