Amazon EC2 Auto Scalingを整理してみた

背景・目的

EC2 Auto Scalingについて、過去に数回利用した程度なので体系的に整理します。

まとめ

下記の特徴があります。

特徴	説明
概要	アプリケーションの負荷を処理するために適切な数のEC2インスタンスを利用できるようにする
Auto Scalingグループ	EC2のインスタンスの集合を作成する 下記が設定でき、これらの間でEC2が増減する ・最小 ・最大 ・希望するキャパシティ EC2インスタンスの起動テンプレートを使用する
Auto Scalingグループの機能	・実行中のインスタンスの状態のモニタリング ・カスタムヘルスチェック ・アベイラビリティーゾーン間での容量のバランス ・複数のインスタンスタイプと購入オプション ・スポットインスタンスの自動交換 ・ 負荷分散 ・スケーラビリティ ・インスタンスの更新 ・ライフサイクルフック ・ステートフルワークロードのサポート ※詳細は、[Amazon EC2 Auto Scaling の機能](#Amazon EC2 Auto Scaling の機能)を参照。
Auto Scalingのメリット	・耐障害性の向上 ・可用性の向上 ・コスト管理の強化 ※詳細は、[Auto Scalingのメリット](#Auto Scalingのメリット)を参照。
Auto Scaling インスタンスのライフサイクル	・スケールアウト ・スケールイン ・インスタンスのデタッチ ・インスタンスのアタッチ ・スタンバイ ・ライフサイクルフックによるイベント
ウォームプール	・インスタンスが大量データをディスクに書き込む必要がある場合等、起動時間が非常に長いアプリケーションのレイテンシーを低減できる ・ウォームプールの使用により、アプリケーションのパフォーマンスを向上させるために、レイテンシーを管理するために、Auto Scalingグループを過剰にプロビジョニングする必要がなくなった
スケーリング方法	・固定数のインスタンスを維持する ・手動でスケールする ・スケジュールに基づくスケーリング ・需要に応じて動的にスケーリングする ・プロアクティブにスケールする

概要

Amazon EC2 Auto Scaling とはを元に整理します。

Amazon EC2 Auto Scaling は、アプリケーションの負荷を処理するために適切な数の Amazon EC2 インスタンスを利用できるようにします。Auto Scaling グループと呼ばれる EC2 インスタンスの集合を作成します。各 Auto Scaling グループ内のインスタンスの最小数を指定することができ、Amazon EC2 Auto Scaling グループはこのサイズよりも小さくなることはありません。各 Auto Scaling グループ内のインスタンスの最大数を指定することができ、Amazon EC2 Auto Scaling グループはこのサイズよりも大きくなることはありません。グループの作成時、またはそれ以降の任意の時点で、希望するキャパシティーを指定した場合、Amazon EC2 Auto Scaling によって、グループのインスタンス数はこの数に設定されます。スケーリングポリシーを指定する場合、Amazon EC2 Auto Scaling でアプリケーションに対する需要の増減に応じて、インスタンスを起動または終了できます。

• アプリケーションの負荷を処理するために適切な数のEC2インスタンスを利用できるようにする
• Auto Scalingグループと呼ばれるEC2のインスタンスの集合を作成する
• 下記が設定でき、これらの間でEC2が増減する
  • 最小
  • 最大
  • 希望するキャパシティ

例えば、次の Auto Scaling グループで、インスタンス数の最小サイズが 1、希望するキャパシティが 2、最大サイズが 4 であるとします。定義するスケーリングポリシーによって、指定した条件に基づいて、インスタンスの最小数と最大数の間でインスタンス数が調整されます。

Amazon EC2 Auto Scaling の機能

Amazon EC2 Auto Scaling では、EC2 インスタンスは Auto Scaling グループに整理され、スケーリングと管理の目的で論理ユニットとして扱われます。Auto Scaling グループは、EC2 インスタンスの設定テンプレートとして起動テンプレート (または起動設定) を使用します。

• Auto Scalingグループは、EC2インスタンスの起動テンプレートを使用する

Amazon EC2 Auto Scaling の主な機能は次のとおりです。

実行中のインスタンスの状態のモニタリング
Amazon EC2 Auto Scaling は、EC2 ヘルスチェックを使用してインスタンスのヘルスと可用性を自動的にモニタリングし、終了したインスタンスまたは障害が発生したインスタンスを置き換えて、希望する容量を維持します。

• EC2ヘルスチェックを使用して、インスタンスのヘルスと可用性を自動的にモニタリング
• 終了したインスタンスや障害が発生したインスタンスを置き換え、希望する容量を維持する

カスタムヘルスチェック
組み込みヘルスチェックに加えて、アプリケーションに固有のカスタムヘルスチェックを定義して、期待どおりに応答していることを確認できます。インスタンスがカスタムヘルスチェックに失敗すると、希望する容量を維持するために自動的に置き換えられます。

• アプリケーション固有のカスタムヘルスチェックを定義できる
• 失敗すると、デフォルトのインスタンス状態のモニタリング同様に、希望する容量を維持するように置き換えられる

アベイラビリティーゾーン間での容量のバランス
Auto Scaling グループには複数のアベイラビリティーゾーンを指定できます。Amazon EC2 Auto Scaling は、グループのスケールに応じて、アベイラビリティーゾーン間でインスタンスを均等に分散します。これにより、アプリケーションを 1 か所で障害から保護することで、高可用性と耐障害性を実現できます。

• 複数のAZに指定できる
• AZ間で均等に分散する

複数のインスタンスタイプと購入オプション
単一の Auto Scaling グループ内では、複数のインスタンスタイプと購入オプション (スポットインスタンスとオンデマンドインスタンス) を起動できるため、スポットインスタンスの使用を通じてコストを最適化できます。グループ内のオンデマンドインスタンスと組み合わせて使用することで、リザーブドインスタンスと Savings Plan sの割引を活用することもできます。

• 複数のインスタンスタイプと購入オプションを選択できる
• スポットインスタンスを使用することでコストを最適化できる
• グループ内のオンデマンドインスタンスと組み合わせて使用することで、Savings planの割引を利用できる

スポットインスタンスの自動交換
グループにスポットインスタンスが含まれている場合、スポットインスタンスが中断されると、Amazon EC2 Auto Scaling は自動的に代替スポット容量をリクエストできます。キャパシティの再調整により、Amazon EC2 Auto Scaling は中断のリスクが高いスポットインスタンスをモニタリングしてプロアクティブに置き換えることもできます。

• スポットインスタンスを使用している場合、中断のリスクが高いスポットインスタンスをモニタリングし、プロアクティブに置き換えることもできる

負荷分散
Elastic Load Balancing の負荷分散とヘルスチェックを使用して、アプリケーショントラフィックが正常なインスタンスに均等に分散されるようにすることができます。インスタンスが起動または終了されるたびに、Amazon EC2 Auto Scaling はロードバランサーからインスタンスを自動的に登録および登録解除します。

• ELBの負荷分散とヘルスチェックを使用して、アプリケーショントラフィックが正常なインスタンスに均等に分散されるようにする
• インスタンスが起動・終了されるたびに、EC2 Auto ScalingはLBからインスタンスを自動的に登録・解除する

スケーラビリティ
Amazon EC2 Auto Scaling では、Auto Scaling グループをスケーリングする方法もいくつか用意されています。自動スケーリングを使用すると、ピーク負荷を処理する容量を追加し、需要が低いときに容量を削除することで、アプリケーションの可用性を維持し、コストを削減できます。必要に応じて Auto Scaling グループのサイズを手動で調整することもできます。

• Auto Scalingを使用すると、ピーク負荷を処理する容量を追加し、需要が低い時に容量を削除する
• サイズを手動で調整も可能

インスタンスの更新
インスタンスの更新機能は、AMI または起動テンプレートを更新するときに、ローリング方式でインスタンスを更新するメカニズムを提供します。Canary デプロイと呼ばれる段階的なアプローチを使用して、グループ全体にロールアウトする前に、少数のインスタンスで新しい AMI または起動テンプレートをテストすることもできます。

• インスタンス更新はAMI,起動テンプレートを更新する時に、ローリング方式を提供する
• Canaryデプロイによる段階的リリースもできる

ライフサイクルフック
ライフサイクルフックは、新しいインスタンスの起動時またはインスタンスの終了前に呼び出されるカスタムアクションを定義するのに役立ちます。この機能は、イベント駆動型アーキテクチャを構築するのに特に便利ですが、ライフサイクルを通じてインスタンスを管理するのにも役立ちます。

• 新しいインスタンスの起動時、終了前に呼び出されるカスタムアクションを定義できる

ステートフルワークロードのサポート
ライフサイクルフックは、シャットダウン時に状態を保持するメカニズムも提供します。ステートフルなアプリケーションの継続性を確保するために、スケールイン保護またはカスタム終了ポリシーを使用して、長時間実行されるプロセスのインスタンスが早期に終了しないようにすることもできます。

• 上記のライフサイクルフックは、シャットダウン時に状態を保持するメカニズムもて依拠するう
• ステートフルなアプリケーションの継続性を確保するために、スケールイン保護またはカスタム終了ポリシーを使用することで、長時間実行されるプロセスのインスタンスが早期に終了しないようにすることも可能

Amazon EC2 Auto Scaling のメリット

Amazon EC2 Auto Scaling をアプリケーションアーキテクチャに追加することは、 AWS クラウドの利点を最大化する方法の 1 つです。Amazon EC2 Auto Scaling を使用する場合、アプリケーションには次のようなメリットがあります。

• 耐障害性の向上。Amazon EC2 Auto Scaling では、インスタンスに異常が発生したタイミングを検出し、インスタンスを削除して、その代わりに新しいインスタンスを起動することができます。複数のアベイラビリティーゾーンを使用するように Amazon EC2 Auto Scaling を設定することもできます。1 つのアベイラビリティーゾーンが利用できなくなると、Amazon EC2 Auto Scaling は別のアベイラビリティーゾーンでインスタンスを起動して補正します。

• 異常発生時に、インスタンスにリプレイスする
• 複数AZに配置

• 可用性の向上。Amazon EC2 Auto Scaling は、現在のトラフィック需要を処理するための適切なキャパシティを、お使いのアプリケーションに常に持たせるのに役立ちます。

• 適切なキャパシティを保つ

• コスト管理の強化。Amazon EC2 Auto Scaling では、必要に応じて動的に処理能力を増減できます。使用する EC2 インスタンスの料金を支払うので、必要なときにインスタンスを起動し、不要な場合は削除することで費用を節約できます。

• 需要に応じて適切な容量を増減させる

例：変化する需要に対応する

このアプリケーションに Amazon EC2 Auto Scaling を追加することによって、3 番目の方法が利用可能になります。必要な場合にのみアプリケーションに新しいインスタンスを追加し、それらのインスタンスが不要になった場合は、インスタンスを終了できます。Amazon EC2 Auto Scaling では EC2 インスタンスを使用するため、インスタンスを使用した場合に、それらのインスタンスの料金のみを支払うだけで済みます。この方法により、費用効率が高いアーキテクチャの利用が可能になります。このようなアーキテクチャでは最適なカスタマーエクスペリエンスが提供され、費用を最小限に抑えることができます。

• 曜日によって需要が異なる場合に、必要最低限の容量を満たすように配置する

例: 複数のアベイラビリティーゾーン全体にインスタンスを分散させる

Auto Scaling グループを作成するときは、Auto Scaling グループをデプロイする VPC とサブネットを選択する必要があります。Amazon EC2 Auto Scaling は、選択されたサブネットにインスタンスを作成します。そのため、各インスタンスは Amazon EC2 Auto Scaling によって選択された特定のアベイラビリティーゾーンに関連付けられます。インスタンスを起動すると、Amazon EC2 Auto Scaling は、可用性と信頼性を高めるためにインスタンスをゾーン間で均等に分散させようと試みます。

• 可用性と信頼性を高めるために、インスタンスをゾーン間で均等に分散させようと試みる

Amazon EC2 Auto Scaling インスタンスのライフサイクル

Auto Scaling グループの EC2 インスタンスに、他の EC2 インスタンスとは異なるパスまたはライフサイクルがあります。Auto Scaling グループがインスタンスを起動すると、ライフサイクルが起動してサービスに組み込まれます。インスタンスを削除するとライフサイクルが終了するか、または Auto Scaling グループがインスタンスをサービスから削除して終了します。

• Auto ScalingグループのEC2インスタンスには、他のEC2インスタンスとは異なるパス、ライフサイクルがある

スケールアウト

• スケールアウトイベントが発生したとき、起動テンプレートを使用して、必要なEC2を起動する
• Pending状態で起動され、Auto Scalingグループにライフサイクルフックが設定されている場合は、ここでカスタムアクションを実行できる
• ヘルスチェックに合格すると、Auto Scalingグループにインスタンスをアタッチして、InService状態に遷移する
  • ELBからトラフィックを受信するように設定されている場合、Auto Scalingは、インスタンスをInServiceにする前に、ELBに登録する

スケールイン

• スケールインイベントが発生すると、Auto Scalingグループは1つ以上のインスタンスをデタッチする
• Auto Scalingグループは終了ポリシーを使用して、インスタンスを決定する
• Terminating状態に移行する
  • ELBからトラフィックを受信するようにAuto Scalingグループを設定されている場合、終了するインスタンスをELBからインスタンスを登録解除する
• ライフサイクルフックされている場合は、終了するインスタンスに対して、カスタムアクションを実行できる

インスタンスのデタッチ

• Auto Scalingグループからインスタンスをデタッチもできる
• 別のAuto Scalingグループにアタッチもできる

インスタンスのアタッチ

• 基準を満たす実行中のEC2インスタンスをAuto Scalingグループにアタッチもできる

ライフサイクルフック

• インスタンスを起動または終了したときにカスタムアクションを実行できるように、ライフサイクルフックを Auto Scaling グループに追加できる

スケールアウトイベント

• Auto Scaling グループに autoscaling:EC2_INSTANCE_LAUNCHING ライフサイクルフックを追加する
• 下記の通り遷移する
  • Pending状態Pending:Wait状態
  • ライフサイクルアクションが終了すると、Pending:WaitからPending:Proceed
  • 完全に設定が完了すると、Auto Scalingグループにアタッチされ、InServiceに遷移する

スケールインイベント

• Auto Scaling グループに autoscaling:EC2_INSTANCE_TERMINATING ライフサイクルフックを追加する
• 下記の通り遷移する
  • Auto ScalingグループからデタッチされTerminating状態へ移行する
  • Terminatingから、Terminating:Waitに移行する
  • ライフサイクルアクションが完了したら、Terminating：Proceedに移行する
  • インスタンスが完全に終了すると、Terminated状態へ遷移する

スタンバイを入力し終了

• InServiceをStandby状態へ移行できる
• インスタンスをサービスから削除し、トラブルシューティングや変更を加えてからサービスに戻す事が可能
• Standbyは、Auto Scalingにより継続して管理される
• しかし、インスタンスを稼働状態に戻すまでは、アクティブにはならない

Amazon EC2 Auto Scaling のウォームプール

Amazon EC2 Auto Scaling のウォームプールを元に整理しています。

ウォームプールを使用すると、インスタンスが大量のデータをディスクに書き込む必要があるなど、起動時間が非常に長いアプリケーションのレイテンシーを低減できます。ウォームプールの使用によって、アプリケーションのパフォーマンスを向上させるために、レイテンシーを管理するために Auto Scaling グループを過剰にプロビジョニングする必要がなくなりました。詳細については、ブログ記事 Scaling your applications faster with EC2 Auto Scaling Warm Pools (EC2 Auto Scaling ウォームプールを使用してアプリケーションをより高速にスケーリングする) をご覧ください。

• インスタンスが大量データをディスクに書き込む必要がある場合等、起動時間が非常に長いアプリケーションのレイテンシーを低減できる
• ウォームプールの使用により、アプリケーションのパフォーマンスを向上させるために、レイテンシーを管理するために、Auto Scalingグループを過剰にプロビジョニングする必要がなくなった

主要概念

ウォームプール
ウォームプールは、Auto Scaling グループに接続された初期化済みの EC2 インスタンスのプールです。アプリケーションがスケールアウトする必要があるときはいつでも、Auto Scaling グループはウォームプールに描画して、新しい希望する容量を満たすことができます。これにより、インスタンスがアプリケーショントラフィックを迅速化し、スケールアウトイベントへの応答を高速化できるようになります。インスタンスは、ウォームプールから離れたときに、グループの希望する容量にカウントされます。これは、ウォームスタートとして知られています。

インスタンスがウォームプールにある間、スケーリングポリシーは、InService 状態のインスタンスのメトリクス値がスケーリングポリシーのアラーム上限しきい値 (ターゲット追跡スケーリングポリシーのターゲット使用率と同じ値) を超える場合のみスケールアウトします。

• Auto Scalingグループに接続された初期化済みのEC2インスタンスのプール
• スケールアウトイベントへの応答を高速化できる

ウォームプールのサイズ
デフォルトでは、ウォームプールのサイズは、Auto Scaling グループの最大容量と希望する容量の数値の差として計算されます。例えば、Auto Scaling グループの希望する容量が 6 で、最大容量が 10 の場合、ウォームプールを最初にセットアップし、プールが初期化されるときに、ウォームプールのサイズは 4 になります。

• Auto Scalingグループの最大容量と希望容量の数値の差として計算される

ウォームプールの最大容量を個別に指定するには、グループの現在の容量よりも大きい最大準備容量の値を設定します。最大準備容量の値を設定すると、ウォームプールのサイズが、グループの最大準備容量と現在の希望容量の差として計算されます。例えば、Auto Scaling グループの希望する容量が 6、最大容量が 10、最大準備容量が 8 の場合、最初にウォームプールをセットアップして、プールが初期化されるときのウォームプールのサイズは 2 になります。

最大準備容量オプションは、大規模な Auto Scaling グループでの作業時にウォームプールを使用するコスト面でのメリットを管理するための使用以外は必要ないかもしれません。例えば、インスタンス 1,000 個、最大容量 1,500 個 (トラフィックの急増時に追加の容量を提供するため)、およびインスタンス 100 個のウォームプールがある Auto Scaling グループは、ウォームプール内に将来使用するインスタンスを 500 個予約しておくよりも、目標の達成に役立つ場合があります。

• 例
  • 希望が6
  • 最大が10
  • 最大準備が8
  • 最初にセットアップしてプールが初期化されるときのウォームプールのサイズは2

ウォームプールサイズの最小サイズ
最小サイズ設定を使用して、ウォームプール内で維持するインスタンスの最小数を静的に設定することを検討してください。デフォルトでは最小サイズは設定されていません。

• ウォームプール内で維持するインスタンスの最小数を静的に設定する

ウォームプールインスタンスの状態
ウォームプール内のインスタンスは、次の 3 つの状態のいずれかで保持できます: Stopped、Running、Hibernated。インスタンスをStopped状態で保持することは、コストを最小限に抑えるための効果的な方法です。停止したインスタンスでは、使用したボリュームとインスタンスにアタッチされた Elastic IP アドレスの分だけ料金が発生します。

• ウォームプール内のインスタンスは下記の3つの状態でいずれかで保持できる
  • Stopped
  • Running
  • Hibernated
• Stoppedは、コストを最小限に抑えるための効果的な方法
  • 停止したインスタンスでは、使用したボリュームとインスタンスにアタッチされたEIPの分だけ料金が発生

または、インスタンスを Hibernated 状態に保持して、メモリコンテンツ (RAM) を削除せずにインスタンスを停止することができます。インスタンスが休止状態になると、RAM コンテンツを Amazon EBS ルートボリュームに保存するようオペレーティングシステムに通知されます。インスタンスを再起動すると、ルートボリュームは以前の状態に復元され、RAM コンテンツがリロードされます。インスタンスが休止状態になっている間は、RAM コンテンツのストレージ、インスタンスにアタッチされた Elastic IP アドレスなどの EBS ボリュームに対してのみ料金が発生します。

• インスタンスをHibernated状態に保持すると、RAMを削除せずにインスタンスを停止できる
• 休止されると、RAMをEBSルートに保持するようにOSに通知される
• インスタンスを再起動すると、ルートボリュームは以前の状態に戻され、RAMコンテンツがリロードされる
• このとき、RAMコンテンツのストレージ、インスタンスにアタッチされたEIP、EBSボリュームに対して料金が発生する

ウォームプール内のインスタンスを Running 状態にしておくことも可能ですが、不必要な料金の発生避けるためにも、そうしておかないことを強くお勧めします。インスタンスを停止または休止状態にしておくと、インスタンス自体のコストが削減されます。インスタンスの料金は、インスタンスが実行されている場合にのみ発生します。

• Stopped、Hibernatedにすると、インスタンス自体のコストが削減できる

ライフサイクルフック
ライフサイクルフックを使用して、インスタンスに対してカスタムアクションを実行できるように、インスタンスを待機状態にします。カスタムアクションは、インスタンスの起動時または終了前に実行されます。

ウォームプール設定では、ライフサイクルフックは、初期化が完了するまで、スケールアウトイベント中にインスタンスが停止または休止されたり、稼働したりするのを遅延させます。ライフサイクルフックなしで Auto Scaling グループにウォームプールを追加すると、初期化の完了までに長い時間がかかるインスタンスは停止または休止状態になり、準備が整う前にスケールアウトイベントが開始する可能性があります。

• ライフサイクルフックにyリ、インスタンスに対してカスタムアクションを実行できるように、インスタンスを待機状態にする
• ウォームプール設定では、ライフサイクルフックは、初期化が完了するまで、スケールアウトイベント中にインスタンスが停止、休止されたり、稼働したりするのを遅延させる
• ライフサイクルフックなしだと、Auto Scalingグループにウォームプールを追加すると、初期化完了までに長い時間がかかるインスタンスは、停止または休止状態になり、準備が整う前にスケールアウトイベントが開始される可能性がある

インスタンスの再利用ポリシー
デフォルトでは、Amazon EC2 Auto Scaling は、Auto Scaling グループがスケールインするとインスタンスを終了します。次に、新しいインスタンスをウォームプールで起動し、終了したインスタンスを置換します。

置換する代わりに、インスタンスをウォームプールに戻す場合は、インスタンスの再利用ポリシーを指定します。これにより、アプリケーショントラフィックを処理するように設定されたインスタンスを再利用できます。ウォームプールが過剰プロビジョニングされないように、Amazon EC2 Auto Scaling はウォームプール内のインスタンスを終了し、その設定に基づいて、必要以上に大きくなったときにそのサイズを減らすことができます。ウォームプール内のインスタンスを終了する際に、Amazon EC2 Auto Scaling はデフォルトの終了ポリシーを使用して、最初に終了するインスタンスを選択します。

• デフォルトでは、スケールインすると、インスタンスを終了する
• 再利用ポリシーを設定することで、ウォームプールに戻す

Auto Scaling グループのサイズをスケールする

Auto Scaling グループのサイズをスケールするを元に整理します。

スケーリング方法を選択する

固定数のインスタンスを維持する
Auto Scaling グループのデフォルトは、スケーリングポリシーまたはスケジュールされたアクションがアタッチされていないことです。これにより、固定サイズが維持されます。Auto Scaling グループを作成したら、目的のキャパシティーを満たすのに十分なインスタンスを起動することから始めます。グループにスケーリング条件がアタッチされていない場合、インスタンスに異常が発生した場合でも、必要な容量を維持し続けます。Amazon EC2 Auto Scaling は、Auto Scaling グループ内の各インスタンスの状態をモニタリングします。インスタンスに異常があることがわかったら、新しいインスタンスに置き換えます。このプロセスの詳細については、「」を参照してくださいAuto Scaling グループ内のインスタンスのヘルスチェック。

• デフォルトでは、スケーリングポリシーまたはスケジュールされたアクションがアタッチされていない
• これにより固定サイズが維持される
• これにより、異常が発生した場合に必要な容量を維持し続ける

手動でスケールする
手動スケーリングは、Auto Scaling グループをスケーリングする最も基本的な方法です。Auto Scaling グループの希望するキャパシティーを更新するか、Auto Scaling グループ内のインスタンスを終了できます。詳細については、「Amazon EC2 Auto Scaling の手動スケーリング」を参照してください。

• 希望するキャパシティを更新する

スケジュールに基づくスケーリング
スケジュールによるスケーリングとは、スケーリングアクションが日付と時刻の関数として自動的に実行されることを意味します。グループのインスタンスの数を増減しなければならない状況が予測可能なスケジュールで発生するため、いつその数を増減すべきかが正確にわかっている場合に、このスケーリング方法は便利です。詳細については、「Amazon EC2 Auto Scaling のスケジュールされたスケーリング」を参照してください。

• 日付と時刻を指定する

需要に応じて動的にスケーリングする
動的なスケーリングを使用して、リソースをスケーリングする高度な方法では、需要の変化に応じて Auto Scaling グループを動的にサイズ変更するスケーリングポリシーを定義できます。例えば、現在 2 つのインスタンスで実行されているウェブアプリケーションがあり、アプリケーションの負荷が変化しても Auto Scaling グループの CPU 使用率を約 50% に維持する必要があるとします。この方法は、トラフィックの変更がいつ行われるかわからない場合に、トラフィックの変更が発生するときにスケーリングするのに役立ちます。対応するスケーリングポリシーを設定できます。トラフィックの変化に応じてスケールするために使用できる複数のポリシータイプ (またはその組み合わせ) があります。詳細については、「Amazon EC2 Auto Scaling の動的スケーリング」を参照してください。

• トラフィックの変化に応じてスケーリングする

プロアクティブにスケールする
また、予測スケーリングと動的スケーリング (それぞれ予防的アプローチと対処的アプローチ) を組み合わせて EC2 のキャパシティを高速スケールできます。予測スケーリングを使用して、トラフィックフローの日次および週次のパターンに先立って Auto Scaling グループ内の EC2 インスタンスの数を増やします。詳細については、「Amazon EC2 Auto Scaling の予測スケーリング」を参照してください。

• 予測スケーリングと動的スケーリングを組み合わせる

考察

今回、Auto Scalingについて整理してみました。今後もあまり利用する機会はないと思いますが、触れる機会が出てきたら、本ドキュメントも更新しようと思います。

参考